XC_Engine [20] - XC_Core [7b] - XC_IpDrv
- 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
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?
Re: XC_GameEngine [build 8 - Faster upload - MH related fixe
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)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?
the 451 Patch fixed this small issue.
Re: XC_GameEngine [build 8 - Faster upload - MH related fixe
This is what my log printed when my pawn moved every single frame:
D = (EndTrace - StartTrace)
E = extent
This is merely the first step into decoding this...
D = (EndTrace - StartTrace)
E = extent
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.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
This is merely the first step into decoding this...
- 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
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).Wises wrote: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)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?
the 451 Patch fixed this small issue.
Higor, that look like some crazy stuff lol.
- 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
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 ?
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.
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 ?
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.
- 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
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 ?
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 ?
Re: XC_GameEngine [build 8 - Faster upload - MH related fixe
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...
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'
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;
...
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'
- 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
I won't count on that, it returns even Accessed Nones because it is called when get some damage from an owned projectile.Higor wrote:damageAttituteTo returns immediately
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;
Re: XC_GameEngine [build 8 - Faster upload - MH related fixe
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:
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.
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.class FCollisionTree : public FCollisionBranchBase
- INT MaxDepth;
Might make it a constant, but it's best to keep this here for memory efficiency.
- 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
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).
- 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).
Re: XC_GameEngine [build 8 - Faster upload - MH related fixe
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:
Init timer
This doesn't even loop the whole pawnlist.
Super generic, this becomes more populated on things like team balancers, etc.
Now for the watcher:
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.
Super fast, no need for mutator, just spawn it and players/bots won't cause problems anymore.
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;
Code: Select all
event PostBeginPlay()
{
SetTimer(1 / Level.TimeDilation,false);
}
event Timer()
{
if ( Level.Game.CurrentID > CurrentID )
DetectNewPlayers();
SetTimer(1 / Level.TimeDilation,false);
}
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;
}
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();
}
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();
}
- 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
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...
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...
Re: XC_GameEngine [build 8 - Faster upload - MH related fixe
FerBotz's Botz_NavigBase.uc (native branch):
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.
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;
}
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.
- 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
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.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.
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.
Re: XC_GameEngine [build 8 - Faster upload - MH related fixe
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.
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.
And the big one...
Hey, at least I learned what the 'Extent' vector does in traces!
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 );
}
}
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;
}
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;
}