Mover Location Via Code - Odd Behavior?

[1337GameDev]

So I have an actor that loops through certain actors in a specific distance, and checks if any are of a specific class + a specific tag.

I use this:

Code: Select all

local Actor a;
foreach RadiusActors(class'Actor', a, FMax(self.CollisionHeight, self.CollisionRadius), self.Location) {//should essentially be a sphere-cast around the given location, with radius = the 3rd paramater
    //Should only be Actors that are within distance (of the max dimension of this actor's collider)

}

I tried to visualize the radii around the actor of this script, and used a basic sphere brush (as there's no way to display colliders in the editor - or a plugin i've found), with the same collision size, with origin on the actor.
I then have a MOVER, and it is iterated over.... BUT the distance seems wrong...
It's keyframes OVERLAP the sphere, but it isn't overlapping the sphere in it's base keyframe. When I load my map, it checks it, and the mover is included in the loop.... even though it's not overlapping the sphere (so it's collider shouldn't be triggering it's inclusion) and is away from the trigger....

Why would this be? Shouldn't "RadiusActors" iterator calculate distance of overlap between the given origin location, and surrounding actors/their colliders to determine overlap? Or does this function calculate overlap with the given location, and then a radius around it equal to the given distance+ self.CollisionRadius AND the overlap to the other actor's collider?

I see this UnDox instance online:
https://www.madrixis.de/undox/Source_en ... r.html#834

Ideas?

[ShaiHulud]

Sorry, I can't contribute anything very helpful, but it did make me think of Know's BT server (95.211.109.182:7760) where he's done something a bit similar.

If you visit there and type: !bt - you'll see a custom dialog with lots of options. Under the Special Settings tab there's an option for "Show Collisions":



With that enabled you see things like this:

[Barbie]

Hmm, I always thought that the collision cylinder of a mover is irrelevant because it is a brush.

[sektor2111]

CollisionRadius and Height have not too much with a brush - Higor teached me these, either way Mover is located where Pivot is and nowhere else.
Radius checker finds actors with their coordinates INSIDE radius and not outside even if cylinder is "touching" radius. This is why Titan won't get damage from Shock Balls because damage radius (iterator in stage) won't see Titan's location and so resulting no damage because Titan has a bigger radius than projectile's damage radius, returning a very logic immunity at these splash damage things just because of iterators rule.

[Buggie]

This is why Titan won't get damage from Shock Balls because damage radius (iterator in stage) won't see Titan's location and so resulting no damage because Titan has a bigger radius than projectile's damage radius, returning a very logic immunity at these splash damage things just because of iterators rule.

As i Know fixed started from v469a.
You can kill Titan with CollisionRadius = 500 from Alt Shock fire (Projectile hurt radius 70).

https://github.com/Slipyx/UT99/blame/f2 ... or.uc#L929

[sektor2111]

Ignoring hidden ? Interesting...

Code: Select all

foreach VisibleCollidingActors( class 'Actor', Victims, DamageRadius, HitLocation, , true)

I gotta ask if hidden things as Forts, Triggers, won't suffer by not taking damage or iterator is just screwed up out of logic...
Either way there are still old servers and RULE is the same as I described.

Edit: LOL ? Right now I see another parameter which 436 doesn't have. If is about adding news for making a mess with old mods perhaps more geometry manipulation and paths manipulation can be added too if is about to change natives like that. If we mess with extended functions then we can change all of them...

[Barbie]

Edit: LOL ? Right now I see another parameter which 436 doesn't have. If is about adding news for making a mess with old mods perhaps more geometry manipulation and paths manipulation can be added too if is about to change natives like that.

Correct, new param is "optional bool bAddOtherRadius".
V436:

Code: Select all

native(312) final iterator function VisibleCollidingActors ( class<actor> BaseClass, out actor Actor, optional float Radius, optional vector Loc, optional bool bIgnoreHidden );

V469b:

Code: Select all

native(312) final iterator function VisibleCollidingActors ( class<actor> BaseClass, out actor Actor, optional float Radius, optional vector Loc, optional bool bIgnoreHidden, optional bool bAddOtherRadius );

But because the new parameter is optional, it should be compatible with older code.

[sektor2111]

Then compile a code with parameter in 469 and run it in 436...
It needs a check for EngineVersion or else... Does it (436) crashes or not ? If this thing is mandatory in code, does actor go borked in 436 ?

Nah, I'm compiling assets using version up to 440 and nothing else and not dependent on these unless it's a complete Server-Side thing aiming 469 only - good bye compatibility. I smell that someone is saying one thing and he does another thing not what he said. I'm not sure if in next months I won't delete all that "patch", compatibility in a non-compatibility way it's not my way, so I don't have big plans around... neither to screw my server.
New empty actors, new parameters and you expect me to believe a nice compatibility story ? Another time not today.
DescribeSpec was hard to be written properly (adding Spam) but we are adding adds which I don't get who asked these and based on what logic.

[Barbie]

It needs a check for EngineVersion

Very good! Does such exist in the newer versions? If not, why not? I experienced the same with my custom function Locs() what was introduced as a native one additionally. If now my version of MonsterHunt should run on an older version of UT, a conditional compile like this would be the solution:

Code: Select all

$IF (ENGINEVERSION < 469)
function Locs() {
// define it in UScript for older versions
...
}
$ENDIF

VisibleCollidingActors() could be called like this then:

Code: Select all

$IF (ENGINEVERSION > 451)
	// Param6 exists in v469a (?) and later
	VisibleCollidingActors(Param1, Param2, Param3, Param4, Param5, Param6)
$ELSE
	VisibleCollidingActors(Param1, Param2, Param3, Param4, Param5)
$ENDIF

[Buggie]

https://github.com/Slipyx/UT99/blob/f2e ... fo.uc#L102
v436-v451:

Code: Select all

var string EngineVersion; 		// Engine version.

v469a:

Code: Select all

var string EngineVersion; 		// Engine version.
var int    ServerMoveVersion;	// Max supported ServerMove protocol

v469b:

Code: Select all

var string EngineVersion; 		// Engine version. 
//
// OldUnreal: Max supported ServerMove protocol
//
// Version 0:
// * Original v400-451b movement
//
// Version 1:
// * Used in 469 betas + 469a
// * Added missing replay of the current pending move after getting a ClientAdjustPosition call. This caused constant desync at 90+ fps
// * Added mergecount to movement packets. This allows the server to replay client movement with roughly the same steps the client used prior to merging
// * Send uncompressed acceleration components
// * Do not force client resync if the position error is small
// * Account for gamespeed when calculating resync interval
// * Use a minimum netspeed of 10000 when calculating resync interval
// * Smooth position adjustments for minor desync errors
// * Replicate pending move immediately if (a) updated accel is significantly different from accel in pending move, (b) player has just (alt)fired, jumped, or started a dodge.
// * Fixed dodgedir/dodgeclicktimer not resetting when receiving a position adjustment in the middle of an active dodge move
// * Implemented invisible collision fix for PHYS_Falling
// * Fixed APawn::physLedgeAdjust bugs that caused bots to fail at walking over certain ledges
// * APawn::stepUp no longer applies an absolute adjustment. This fixes ridiculous acceleration boosts at high fps
//
// Version 2:
// * Rewrote the invisible collision fix because it still failed due to substantial floating point rounding errors that occured on slopes that were far away from the center of the map
//
var int    ServerMoveVersion;	
var string EngineRevision;      // Revision of this engine version.

Replication:

Code: Select all

replication
{
	reliable if( Role==ROLE_Authority )
		Pauser, TimeDilation, bNoCheating, bAllowFOV, ServerMoveVersion;
}

So ServerMoveVersion come from server. All other things is local. And if you need know server version, you need send it to client.

[Barbie]

But conditional compile is not possible with that.

[sektor2111]

I don't know, for me was easier writing things for XCGE. By using a sanity check common code runs out of XC any time except dedicated server-side things.

[Buggie]

But conditional compile is not possible with that.

Yep.
But you can make two .u files and load desired with specified code.

not sure if this stuff work with client-server model. Possible not work.

In UE1 no any way do what you want. Only some hacks and tricks.

[Barbie]

After another minute thinking of it I realize that conditional compiling wouldn't solve the problem with the Locs() version - that has to be detected in runtime.

[Buggie]

No any reflection in UT. So rename your Locs to LocsSB and use in all UT versions.

--- EDIT ---

Some sort of reflection stuff exists:

Code: Select all

native final function string GetPropertyText( string PropName );
native final function bool   SetPropertyText( string PropName, string PropValue );
native static final function name GetEnum( object E, int i );
native static final function object DynamicLoadObject( string ObjectName, class ObjectClass, optional bool MayFail );

But this not help for your case.

UT not designed for conditional includes.