XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post Reply
User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA
Contact:

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Chamberly »

I was thinking about the download from redirect, even tho the number only stop at when the download is finished at a different #, wonder if that can be changed with XC GE?
Image
Image
Image Edit: Why does my sig not work anymore?
User avatar
Wises
Godlike
Posts: 1089
Joined: Sun Sep 07, 2008 10:59 am
Personal rank: ...

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Wises »

Chamberly wrote:I was thinking about the download from redirect, even tho the number only stop at when the download is finished at a different #, wonder if that can be changed with XC GE?
what it is ... is that the # you see i the window when downloading is the Un-compressed filesize which is why it appears to download quicker.. (compressed)
the 451 Patch fixed this small issue.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Higor »

This is what my log printed when my pawn moved every single frame:

D = (EndTrace - StartTrace)
E = extent
Log: [XC_ENGINE] FCC: ActorLineCheck D:0.000000,0.000000,-24.099869 E:17.000000,17.000000,39.000000 0 >> Movement initiates
Log: [XC_ENGINE] FCC: RemoveActor TMale1 >> lol?
Log: [XC_ENGINE] FCC: AddActor TMale1 >> lol?
Log: [XC_ENGINE] FCC: ActorLineCheck D:0.000000,0.000000,-6.999634 E:17.000000,17.000000,39.000000 0 >> movement ends (post-move adjustment?, purposely moving player below for slope checks?).
Log: [XC_ENGINE] FCC: ActorLineCheck D:-13.865505,-3.671631,0.000000 E:17.000000,17.000000,39.000000 0 >> Movement initiates
Log: [XC_ENGINE] FCC: RemoveActor TMale1
Log: [XC_ENGINE] FCC: AddActor TMale1
Log: [XC_ENGINE] FCC: AddActor RocketPack2 >> Picked up rocket pack, copy spawned
Log: [XC_ENGINE] FCC: RemoveActor RocketPack2
Log: [XC_ENGINE] FCC: AddActor RocketPack2 >> dunno, clusterfuck with the copy before given to player
Log: [XC_ENGINE] FCC: RemoveActor RocketPack2
Log: [XC_ENGINE] FCC: AddActor RocketPack2
Log: [XC_ENGINE] FCC: RemoveActor RocketPack1 >> ground rocket pack hides itself, going into respawn state
Log: [XC_ENGINE] FCC: AddActor RocketPack1
Log: [XC_ENGINE] FCC: RemoveActor RocketPack2 >> copy finally given to player and removed from hash
Log: [XC_ENGINE] FCC: ActorLineCheck D:0.000000,0.000000,-6.299072 E:27.000000,27.000000,12.000000 0 >> where'd this one come from? rocket pack?
Log: [XC_ENGINE] FCC: ActorLineCheck D:0.000000,0.000000,-6.999634 E:17.000000,17.000000,39.000000 0 >> post-move adjustment
Log: [XC_ENGINE] FCC: ActorLineCheck D:-13.865505,-3.671631,0.000000 E:17.000000,17.000000,39.000000 0 >> pre-move check
Log: [XC_ENGINE] FCC: RemoveActor TMale1
Log: [XC_ENGINE] FCC: AddActor TMale1
Log: [XC_ENGINE] FCC: AddActor UT_Eightball1 >> picking up the eightball, copy spawned
Log: [XC_ENGINE] FCC: RemoveActor UT_Eightball1
Log: [XC_ENGINE] FCC: AddActor UT_Eightball1
Log: [XC_ENGINE] FCC: RemoveActor UT_Eightball1
Log: [XC_ENGINE] FCC: AddActor UT_Eightball1
Log: [XC_ENGINE] FCC: ActorLineCheck D:0.000000,0.000000,-6.299927 E:30.000000,30.000000,10.000000 0 >> checking collision for newly spawned copy?
Log: [XC_ENGINE] FCC: RemoveActor UT_Eightball0 >> base goes into respawn state
Log: [XC_ENGINE] FCC: AddActor UT_Eightball0
Log: [XC_ENGINE] FCC: RemoveActor UT_Eightball1 >> copy finally in player's hands, removed from hash
Log: [XC_ENGINE] FCC: ActorLineCheck D:0.000000,0.000000,-6.999634 E:17.000000,17.000000,39.000000 0 >> post move checks on player
Log: [XC_ENGINE] FCC: ActorLineCheck D:-231.775940,-61.374390,-80.126266 E:0.000000,0.000000,0.000000 0 >> my hud's TraceIdentify
Log: [XC_ENGINE] FCC: ActorLineCheck D:-3.916191,-1.036987,0.000000 E:17.000000,17.000000,39.000000 0 >> pre-move checks
Log: [XC_ENGINE] FCC: RemoveActor TMale1
Log: [XC_ENGINE] FCC: AddActor TMale1
Log: [XC_ENGINE] FCC: ActorLineCheck D:0.000000,0.000000,-6.999634 E:17.000000,17.000000,39.000000 0 >> post move checks
There's a huge amount of redundant operations in there, which is what explains massive slowdowns when lots of things move at the same time.
This is merely the first step into decoding this...
User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA
Contact:

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Chamberly »

Wises wrote:
Chamberly wrote:I was thinking about the download from redirect, even tho the number only stop at when the download is finished at a different #, wonder if that can be changed with XC GE?
what it is ... is that the # you see i the window when downloading is the Un-compressed filesize which is why it appears to download quicker.. (compressed)
the 451 Patch fixed this small issue.
No. Like playing Unreal, the download say it reach 100% on each download. UT99 doesn't do it because of redirect (this is why if you download from redirect, it stop like 50% instead of 100% on such file).

Higor, that look like some crazy stuff lol.
Image
Image
Image Edit: Why does my sig not work anymore?
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

Hmm, maybe I'll reconsider that 8 players (bIsPlayer having names) against 22-24 monsters randomly dropped in two teams in stock maps with small places will process a lot until one of those frames is lost and next frame will be Null. Oops K.O. To not mention that monsters are moving to hunt threats so might take place when other wants to spawn and new pawn need adjusted (engine seems to adjust location but I don't know criteria).

Example: 1 on 1 match, me vs Monster, run, gun, kill, die, silence... oops. Where is monster ? Seeking using pathing = 0 results. Dammit... I just heard spawn noise, log as admin, use admin power to check. Moron was threatening down in snow (Map DM-Zeto). He simply spawned around a node and engine moved it in the best free location ? Now is down - game break, lol.
After a few hours I decided to reconfigure spawning formula even setting up an additional process. Somehow worked but... for more pawns looks like might be a big problem indeed because simply monsters aren't telefragging each-other except... Queen and subclasses. Queen might gib others... (causing here a lottery into MH but not all people have skill in configuring monsters). So to speak, I'm moving, monsters are moving, other wants to spawn... Where ? :loool:
Maybe I have to think at taken to avoid such a node?
Not sure what's going on into MH with CreatureFactory when monsters are forced to spawn in a bunch... the mostly spamming games. So I was wise to reduce spawning at a bigger time interval and less monsters than SpawnPoint-s, he, he... that's why I got some stability in MH2.
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

Next section that might be a tweak subject - is probably a need. My games includes some fixes but it might be welcomed a more native acceleration.

For introduction I'll call it Monster-Combo-LockDown, shortly MCL.
Logs ? Impossible, file is probably unclosed. We might expect HDD errors ?

Where happens MCL? Both Linux and Windows servers are nice frozen and only a different Task-Manager-Like tools might solve problem. How goes ? Server won't respond at any command, it is simply halted and even in Linux takes some time until will come back (probably pushed externally by some software guard).

MCL happens into MH but Coop might not be a common exception if accidents are happening.

Player is playing a Level. It fires a few projectiles with delay (grenade, biogel types, etc.). If by accident is losing connection or other such problem shows up, then... Monsters victims if aren't killed, will respond at damageAttitude with hate. Hating... None, player is no longer there. After a few such "interesting" takedamage calls server gets locked. It is the same thing as when some whatever sort of pawns non-player and Non-UT (read well) kill a few monsters. AttitudeTo, relativeStrength, are a part of the last speech from Console and BYE. Projectiles still have "signature" of instigator which is gone - I'm not curious how goes MCL for Monster Vs Monster things.

I was reconfiguring some LogOut in a different way to prevent these "deals" and function "Killed". Else I'm speaking about other game-types recoded properly.

Are these solvable in defaults ?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Higor »

When a PlayerPawn reference is passed as instigator, it there shouldn't be any problem.
Two possible cases that come to mind when player disconnects:
- All projectiles fired by the player have their instigator set to none (in native code), damageAttituteTo returns immediately.
- Actor isn't cleaned from memory, so Instigator var is still valid (from a c++ point of view), monsters will attack at where the player disappeared at until another routine tells them not to.
First, find out what's happening from the above two.

In the meantime...

Code: Select all

class XC_ENGINE_API FCollisionCacus : public FCollisionHashBase
{
public:
#define MAX_LOOKUP_DIST 300.0
	FCollisionHashBase* Hooked;
	FVector OldDelta;

	struct ActorRemove
	{
		AActor* Actor;
		INT Idx; //Index in XOrdered
	};

	TArray<ActorRemove> PendingRemove;
	TArray<AActor*> XOrdered;
...
My goal is to make the engine use both hashes (lol).
Movers, huge or static actors will remain in the old hash.
All else will go into the new FCollisionCacus which will use an X-axis ordered Actor list.
Ideally the old hash should process first then my hook should complement, the X-ordering of the array is done and list maintaining should be way faster:
- RemoveActor called, finds actor in list, adds to PendingRemove.
- AddActor called (for same actor, because movement removes and adds), attempts to find in PendingRemove -> removes PendingRemove entry instead.
If AddActor isn't called on the remainder of the frame, then PendingRemove will indeed clear the actor from XOrdered and then self-remove.

- TODO:
Make a fast actor-finding function for XOrdered, cutting the array in half by checking the middle and then recutting until found should work wonders... but I might attempt to store the XOrdered IDX on the actor itself if I can find some unused memory lol.
Prevent old hash from adding actors I want to keep in XOrdered (small, moving non-brush stuff).
Try and find out what void CheckActorNotReferenced( AActor* Actor ) does, so far it appears to be called on every actor upon destruction. (Maybe it's a safeguard for removing colliding actors?)
Try and get the same behaviour for the ActorLineCheck, ActorPointCheck, ActorRadiusCheck, ActorEncroachmentCheck for the hook.
Then make these functions work together with the old hash ones'
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

Higor wrote:damageAttituteTo returns immediately
I won't count on that, it returns even Accessed Nones because it is called when get some damage from an owned projectile.
They forgot more wrappers, not only here. Monster can even attack itself because it hates bIsPlayer without except itself, if fails weapon Skaarj will attack his own entity. Also original TeamGame is so cute...

Code: Select all

	if ( (Other == Self) || (Other == None) || (FlockPawn(Other) != None) ) //Where is bDeleteMe ?
		return;
For sure AtittudeTo again is missing in checks as RelativeStrength. If Other == None || Other.bDeleteMe return something to complete a null byte :ironic2: . To not mention SetEnemy that should return false if Other.bDeleteMe or such and completely avoid comparing RelativeStrength - and maybe Bump is another nasty thing that needs some love. It is badly affected when such things happens, I can recreate such evil things being only a simple player without any cheat.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Higor »

I'm considering building an octree system, I have zero experience in that but I have an idea on how it works.
It's gonna be considerably better than looping a whole ordered list lol.

So far I'm thinking with:
class FCollisionBranchBase
- INT CurDepth;
Do not make more breanches after reaching certain depth

- FLOAT RefPoints[3][3][3];
Center, mid, end of cube in coordinates.

- FCollisionBranchBase* Branches[2][2][2];
The eight subcubes.

- TArray<AActor*> Actors;
The actors contained in this cube.
If an actor is small enough to fit a subcube, do not register here, but in a subcube instead so we avoid duplicate references.
I guess that's where AddActor, RemoveActor do their job.
class FCollisionBranch : public FCollisionBranchBase

- FCollisionBranchBase* Parent;
Parent branch.
class FCollisionTree : public FCollisionBranchBase

- INT MaxDepth;
Might make it a constant, but it's best to keep this here for memory efficiency.
So with this I can get to grab actors from certain spots instead of looping a whole list, will still use the XOrdered system to do reverse engineering before coding this one.
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

Letting hard jobs for a later session or at least I think they are hard. Let's see what I expect:
- An actor is a projectile. Track it ? In which purpose ?
a) See if has bReplicateInstigator - probably checking if initially setting it to True is not bugged... fired by some spawners;
b) if this actor doesn't have an Instigator valid anymore put bReplicateInstigator=False.
- Alternate way, if Instigator is not valid (no pawn assigned, invalid pawn, no pawn without a proper mesh, any sort of such dumb check) then remove the retarded thing - assign a bDeleteMe=True and I guess will get lost in next Tick, I already destroyed bStatic things like this. I don't even care if is bNetTemporary since mainly game is controlled by server and I simply don't care on what can see player or not... Destroy the mess from server or allow a self destruction. Player can look at false explosions as long as Me the server, I'm simply OK.
History - I recall such a server lock-down and I witnessed already the cooler's noise.

These normally can be solved with a heavy tick using UScript and foreach-ing a lot but... I think via C++ is much faster and accurate and won't inflict a hard UScript-ed process.

If I would knew some C++ probably the most of my troubles could be solved using similar tools like WebChatLog (which uses an external DLL to get over UScript limits and/or speed limits).
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Higor »

Hooking the Destroy() function in Actor is a kinda nasty task.

Use a player watcher for now,

This is the standard player watcher code I use in my mods and mutators:

Code: Select all

class InstigatorFixer expands Info;
var int CurrentID;
Init timer

Code: Select all

event PostBeginPlay()
{
	SetTimer(1 / Level.TimeDilation,false);
}

event Timer()
{
	if ( Level.Game.CurrentID > CurrentID )
		DetectNewPlayers();
	SetTimer(1 / Level.TimeDilation,false);
}
This doesn't even loop the whole pawnlist.

Code: Select all

function DetectNewPlayers()
{
	local pawn P;

	For ( P=Level.PawnList ; P!=none ; P=P.nextPawn )
		if ( !P.IsA('MessagingSpectator') && P.PlayerReplicationInfo != none )
		{
			if ( P.PlayerReplicationInfo.PlayerID >= CurrentID )
				AddWatcher(P);
			else
				break;
		}
	CurrentID = Level.Game.CurrentID;
}
Super generic, this becomes more populated on things like team balancers, etc.

Code: Select all

function AddWatcher( Pawn P)
{
	P.Spawn( class'InstigatorWatcher');
}

Now for the watcher:

Code: Select all

class InstigatorWatcher expands Info;

event Tick( float DeltaTime)
{
	if ( Pawn(Owner) == none || Owner.bDeleteMe )
		ClearInstigators();
}
Globally clear invalid instigators, that includes those from other deleted pawns if they happen to have bDeleteMe as well.
Self destruct, we don't need this watcher anymore.

Code: Select all

function ClearInstigators()
{
	local Actor A;
	ForEach AllActors (class'Actor', A)
		if ( A.Instigator == Pawn(Owner) || (A.Instigator != none && A.Instigator.bDeleteMe) )
			A.Instigator = none;
	Destroy();
}
Super fast, no need for mutator, just spawn it and players/bots won't cause problems anymore.
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

Reading a few lines Destroy() related, some coders avoided that in certain moments. That's why I reconsidered my Position attacking them using ... a boolean. I'm using that way to destroy BlockMonsters. Until now I ruined them but now I think is time to remove them forever.

For lost projectiles I can deal with function killed and Logout. But I was thinking at a faster solution and one available for all games.

Else I think in Uscript SpawnNotify might be another way. Track projectiles with a guardian. When instigator is invalid - modify the nasty boolean.

I'm copying previous codes...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Higor »

FerBotz's Botz_NavigBase.uc (native branch):

Code: Select all

function bool PathVisible( NavigationPoint Start, NavigationPoint End, optional bool IgnoreMovers)
{
	local Actor A;
	local vector HitLocation, HitNormal;
	
	ForEach TraceActors (class'Actor', A, HitLocation, HitNormal, End.Location, Start.Location)
	{
		if ( A == Level )
			return false;
		if ( A.IsA('BlockMonsters') )
			A.SetCollision(false,false,false);
		if ( A.IsA('BlockAll') )
			return false;
		if ( !IgnoreMovers && Mover(A) != none )
			return false;
	}
	return true;
}
No need to go around the nasty practices of removing static actors via script, when you can simply remove them from the collision hash.

Edit:
Manually setting bDeleteMe on a colliding actor is a way to crash the engine... at least to crash it on my FCollisionCacus lol.
You're always supposed to use Destroy() and nothing else, and if you can't destroy, then change bStatic and bNoDelete to false first, and I'm not sure as to what extent that is safe.
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

Higor wrote:You're always supposed to use Destroy() and nothing else, and if you can't destroy, then change bStatic and bNoDelete to false first, and I'm not sure as to what extent that is safe.
Of course first move is setting them normally, ruin collision, and nice let engine to "manage" job. XC_Engine acts well into "MHTunes" a small mutator in purpose to set a few things as I've seen so far, it initializes self destructions generally early, it logs number of actors, it spawns a temporary target to avoid left-over monster attacks - might help here and there, it might deal with any experimental default weapon, it clones a weapon dropped including ammo with a limited life getting over PlayerCanSeeMe() checks which is too short from my side, I am currently thinking what anything else I need, might be nice to implement that instigator control right inside as a feature.

I'll quit forever using 451 if you can debate in XC_Engine those presumed 32 bugs solved by UTPG and later that fixed Unreliable buffer exploit. 436 would be good to be only fixed without any useless add-on.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Higor »

This is my actor trace code, between a cylinder and a line (with cylindric extent):

Part of the code in ActorLineCheck... spams a lot the log for now.

Code: Select all

	FVector Y;
	FVector X = End-Start;
	if ( !XYCylinder( &X, &Y) )
		return Result;
	for ( INT i=0 ; i<XOrdered.Num() ; i++ )
	{
		FVector HitLocation;
		FVector HitNormal;
//UBOOL CylCylLineHit( AActor *Actor, const FVector& TStart, const FVector& AdjustedEnd, const FVector& TExtent, const FVector& X, const FVector& Y, FVector *HitLocation, FVector *HitNormal)
		if ( CylCylLineHit( XOrdered(i), Start, Delta, Extent, X, Y, &HitLocation, &HitNormal) && (Delta != OldDelta) && !XOrdered(i)->IsA(APlayerPawn::StaticClass() ) )
		{
			FVector HitOffset = HitLocation - XOrdered(i)->Location;
			debugf( NAME_Log,TEXT("[XC_GE] CACUS hit %s HO:%f,%f,%f HN:%f,%f,%f"), XOrdered(i)->GetName(),HitOffset.X, HitOffset.Y, HitOffset.Z, HitNormal.X, HitNormal.Y, HitNormal.Z );
		}
	}
Generate X and Y horizontal axes (relative to trace dir), X is forward, Y is right.
If the trace is upwards, both X, Y are zero.

Code: Select all

UBOOL FCollisionCacus::XYCylinder( FVector *X, FVector *Y)
{
	guard( FCollisionCacus::GetCylComps )
	if ( X->IsNearlyZero() )
		return 0;
	X->Z = 0;
	if ( ! X->Normalize() ) //Up or down
		*Y = FVector(0,0,0);
	else
		*Y = FVector( -X->Y, X->X, 0); //Rotate 90º to right in 2D
	return 1;
	unguard;
}
And the big one...
Hey, at least I learned what the 'Extent' vector does in traces!

Code: Select all

	UBOOL CylCylLineHit( AActor *Actor, const FVector& TStart, const FVector& AdjustedEnd, const FVector& TExtent, const FVector& X, const FVector& Y, FVector *HitLocation, FVector *HitNormal)
	{
		//Centralize actor
		FVector AdjustedActor = Actor->Location - TStart;
		FLOAT TotalSide = TExtent.X + Actor->CollisionRadius;

		//Vertical trace
		if ( X.IsZero() || Y.IsZero() )
		{
			//Out of cylinder radius or opposite directions
			if ( (AdjustedActor.Size2D() > TotalSide) || (Sign(AdjustedActor.Z) !=  Sign(AdjustedEnd.Z) ) ) 
				return 0;
			//The condition that negates traces from inside the actor isn't here for now
			if ( Abs(AdjustedActor.Z) - (TExtent.Z + Actor->CollisionHeight) > Abs(AdjustedEnd.Z) )
				return 0; //No reach
			*HitNormal = FVector(0,0,-Sign(AdjustedEnd.Z));
			if ( AdjustedEnd.Z > 0 )
				*HitLocation = TStart + FVector(0,0, Max(0.f, AdjustedActor.Z - (TExtent.Z + Actor->CollisionHeight)) );
			else
				*HitLocation = TStart + FVector(0,0, Min(0.f, AdjustedActor.Z + (TExtent.Z + Actor->CollisionHeight)) );
			return 1;
		}

		FLOAT XDist = AdjustedActor | X;
		if ( XDist <= 0 && (Abs(AdjustedEnd.Z-AdjustedActor.Z) < Actor->CollisionHeight + TExtent.Z) ) //Cylinder is behind me and both heights not touching (base engine behaves like <=)
			return 0;
		if ( XDist > (AdjustedEnd | X) + TExtent.X + Actor->CollisionRadius ) //Actor further than our trace
			return 0;

		//TODO: IF STARTING POINT INSIDE ACTOR + EXTENT, INSTA-COLLIDE

		FLOAT TouchSide = Abs(AdjustedActor | Y);
		if ( TouchSide > TotalSide ) //Extent line never hits the actor
			return 0;
		//Now we gotta place both cylinders at a X,Y touching location
		FLOAT XDelta = TotalSide*TotalSide - TouchSide*TouchSide;
		if ( XDelta > 0.f )	XDelta = appSqrt(XDelta);
		else				XDelta = 0.f;
		FVector VStart = AdjustedEnd.UnsafeNormal();
		VStart = VStart * (1 / VStart.Size2D()) * (XDist - XDelta);
		if ( Abs(VStart.Z - AdjustedActor.Z) <= (Actor->CollisionHeight + TExtent.Z) )
		{
			*HitLocation = VStart + TStart;
			*HitNormal = (VStart - AdjustedActor).SafeNormal(); //I should normalize to perfect cylinder instead
			return 1;
		}
		if ( AdjustedEnd.Z == 0 )
			return 0;
		if ( Abs(VStart.Z) > Abs(AdjustedActor.Z) ) //We passed the actor already!
			return 0;
		FLOAT PlaneZ = AdjustedActor.Z - Sign(AdjustedActor.Z) * (Actor->CollisionHeight + Abs(TExtent.Z));
		VStart = AdjustedEnd * PlaneZ / AdjustedEnd.Z;
		if ( (VStart - AdjustedActor).Size2D() > TotalSide )
			return 0;
		*HitLocation = TStart + VStart;
		*HitNormal = FVector(0,0,-Sign(AdjustedEnd.Z));
		return 1;
	}
Post Reply