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

[sektor2111]

Hey, at least I learned what the 'Extent' vector does in traces!

You can even write a small document and send it to Polge... some things were messed up here, with traces done wrong and that's why A.I. sometimes commit suicide with their own weaponry. They trace simple between weapon fire-offset and enemy's location taking in account bodies, for sure starting from enemy to their weapon returns enemy body so will fire weapon. This is completed with a FastTrace check (but not always - not from all states) so CanFireAtEnemy returns a false positive result making them to fire in a wall - issue is common for all A.I. If they have a splash-damage weapon with bad A.I. code then death is the most often case. CanFireAtEnemy would be better to have a double check or a single one like I did with that ValidSight. No attack from behind doors, LOL.

[Higor]

Finally bugfixed my Trace code, i'll proceed with the second FCollisionHashBase function: ActorRadiusCheck, should be fairly simple.

Btw, the default hash crashes with an assertion of this kind if you attempt to call RemoveActor on an actor with bCollideActors=False:
- Assertion failed: (Actor->bCollideActors) - UnActCol.cpp - Line 250.
I guess the same goes for AddActor, this means that bCollideActors is the main switch that tells if an actor should go into the hash or not, and stuff like bBlockActors and bBlockPlayers only work if you have bCollideActors=true

So,
Movers do have bCollideActors=True on their defaults, this way they get hashed.
Movers appear to have a second LineCheck function located in the UModel UPrimitive object, so this leads me to believe that:
- Movers are hashed as cubes(?) (or other kind of simple bounding box).
- If the mover's bounding box is hit, call the corresponding UPrimitive of said mover's LineCheck function to check for surface hits.
- This method makes mesh collision implementation easy. (Don't get any hopes here)
You can change a mover's bCollideActors to False if you don't intend said mover to have any collision (optimized sheet movers!)

[sektor2111]

I was playing with a mutator using such function:

Code: Select all

function RuinStupidStuff()
{
	local int NAc;
	local Actor Any;

	ConsoleCommand("set BlockMonsters bNodelete False");
	ConsoleCommand("set BlockMonsters bStatic False");
	ConsoleCommand("set BlockMonsters bBlockActors False");
	ConsoleCommand("set BlockMonsters bDeleteMe True");
	foreach AllActors(class'Actor',Any)
	{
		if (Any != None)
		NAc++;
	}
	log ("Helper reports the Number of Actors = "$NAc);
}

Believe me or not, it doesn't crash, it logs undeleted actors and happily started removal. Simple checking later using admin powers returned NONE. They were removed without any ScriptWarning or such things.
Next: Pawn is killed (monster), won't collide, won't do anything but for sure will be destroyed at a moment having bDeleteMe.
I'm not worried. If troubles will occur I won't use that.

Yes, if bCollideActors=False, blocking doesn't exist. For cubing traces, agree, some water surfaces were mapped Solid and ADD brush, they never blocked anything and never stopped any projectile. So, movers thin as a non-cubed block using only a simple sheet I think they react like unexistent in visibility and some hashes. PlayerCanSeeMe() works through movers.

[SC]-[WARTZ_{HoF}]

Is this XC_GameEngine safe to use on a MH server yet or is there still work to be done.

[sektor2111]

XC_Engine for me seems safer at this point. I mean I can play until I make my eyes red. I sorted bad maps out, I fixed others and I'm hunting monsters in On-Line environment. It is not a public place because I don't need "guests" talking about un-existent bugs. I gotta admit I play only MH504 and MonsterHuntArena (also from 504) with a small mutator performing my custom wishes (example fore-mentioned "feature").

[Higor]

Servers that I'm aware of that use XC_GameEngine:
- UnrealKiller's ComboGib (v6)
--- Known enabled settings: NexGen PreLoginHook, Timing Fix, Moving Brush Tracker fix.
- To be setup: UnrealKiller's Siege (v8)
- Gust's server.
- Cham's development server (v8).
--- Known enabled settings: NexGen PreLoginHook, Timing Fix, Fast Upload, Moving Brush Tracker fix, Travel Manager for coop.
- HIGH[+]Rato's server (?).
- Nelsona's MH server.

So, critical reasons to use XC_GameEngine on your server:
- Coop and MH - Fixes PlayerCanSeeMe() crashes, monsters can't see through movers.
- Coop - Allow clients to not lose inventory upon reconnecting (Travel Manager).
- Non-redirected servers - NetSpeed alterations to allow faster upload.
- Non UTPure/NN servers (LCWeapons/Siege/Jailbreak/etc) that use multiple custom weapons - GetWeapon binds work without being edited.
- Linux servers with mapvotes that can't sort maps alphabetically - You can sort globally or by subfolder!
- v436 servers where your admin's constantly using GET and SET commands.
- You host Unreal's Single Player levels.

Reasons you'd like to put this on your client:
- v436 client and you're constantly using GET and SET commands.
- You have over 1000 maps on your maps folder.
- You host LAN or VPN sessions frequently and need to upload files faster without using a redirect.
- Timing issues after applying dual core fix (offline or LAN server).
- You host Coop sessions (Travel Manager).
- You play with bots and monsters at the same time (other than MH).
- Automatic cache conversion.
- You host Unreal's Single Player levels.
- You're a mod developer (lots of logging and additional commands).
- You don't play on AnthChecker servers

[Chamberly]

I think this forum had a back up. I'm seeing something very trippy or what, but wises had posted after this. Hmm. I hate it when it happen, looses some data lol.

- You don't play on AnthChecker servers

Those thing are kicky happy. So I had to revert to original engine when I play on a few server for this usually on a weekend for some matches.
But still, XC GE is much better.

[papercoffee]

I think this forum had a back up. I'm seeing something very trippy or what, but wises had posted after this. Hmm. I hate it when it happen, looses some data lol.

Nope, Wises deleted his post himself.

[Higor]

Decided to give the middle finger to movers and keep them in the old hash.
I'll operate with both my octree and the old hash at the same time.

Why?
Encroachment checks for movers are way too arbitrary and it's pretty damn obvious that Epic spent days tweaking them to prevent movers from killing players when landing on them, getting stuck after hitting an obstruction instead of returning, or directly passing thru solid actors at high speeds without affecting them.

Regarding the octree, went with a simple max depth of 7 (512x512x512 cubes) as smallest unit.
Will be reimplementing the actor querying functions and releasing the octree source when it's tested, maybe I can get some feedback from someone who's actually worked on this (and isn't legally bound).

A simple node.

Code: Select all

#define MAX_OCTREE_DEPTH 7
class XC_ENGINE_API FCollisionOctree
{
public:
	FCollisionOctree* Parent;
	FCollisionOctree* Children[8]; //X,Y,Z based bitwise.
	FBox BoundingBox;
	FVector CenterPoint;
	INT CurDepth;
	BYTE ChildIndex;
	TArray<AActor*> Actors;
	FCollisionOctree() {};
	FCollisionOctree( FCollisionOctree* InParent, FVector InMin, FVector InMax, INT InDepth, BYTE InChild=0)
	:	Parent(InParent)
	,	BoundingBox(InMin,InMax)
	,	CenterPoint( (InMin+InMax) * 0.5)
	,	CurDepth(InDepth)
	,	ChildIndex( InChild)
	{};
	FCollisionOctree( FCollisionOctree* InParent, FBox InBounds, INT InDepth, BYTE InChild=0)
	:	Parent(InParent)
	,	BoundingBox(InBounds)
	,	CenterPoint( (InBounds.Min+InBounds.Max) * 0.5)
	,	CurDepth(InDepth)
	,	ChildIndex( InChild)
	{};
	~FCollisionOctree()
	{
		for ( INT i=0 ; i<8 ; i++ )
			if ( Children[i] )
				delete Children[i]; //Deletion becomes recursive
	}
	FBox GetSubOctantBox( FVector Point, INT& Idx);		//Fast, does not do sanity checks
	FCollisionOctree* InsertActor( AActor* Actor);		//Recursive, if outside of main box, add via FCollisionCacus!!
	FCollisionOctree* RemoveActor( AActor* Actor);		//Recursive, may fail safely
	FCollisionOctree* SlowRemoveActor( AActor* Actor);	//Last resort usage, when an actor is moved without notifying the octree
	FIteratorActorList* RadiusQuery( FMemStack& Mem, FVector Location, FLOAT Radius, DWORD ExtraNodeFlags, FIteratorActorList* PrevLink );
	FBox ActorBoundingBox( AActor* Actor)				//Does not do Mover checks, fast
	{
		FVector Extent( Actor->CollisionRadius, Actor->CollisionRadius, Actor->CollisionHeight);
		return FBox( Actor->Location-Extent, Actor->Location+Extent);
	}
	UBOOL FitsBox( const FBox& Sample, const FBox& Container)
	{
		return (Sample.Min.X >= Container.Min.X) && (Sample.Min.Y >= Container.Min.Y) && (Sample.Min.Z >= Container.Min.Z)
			&& (Sample.Max.X <= Container.Max.X) && (Sample.Max.Y <= Container.Max.Y) && (Sample.Max.Z <= Container.Max.Z);
	}

};

//Recursive actor insertion
//Returns a pointer to the node containing the incoming actor
//Creates new nodes if necessary

Code: Select all

FCollisionOctree* FCollisionOctree::InsertActor( AActor* Actor)
{
	FBox ABox = ActorBoundingBox( Actor);
	if ( FitsBox( ABox, BoundingBox ) )
	{
		if ( CurDepth >= MAX_OCTREE_DEPTH )
		{
			Actors.AddItem( Actor);
			return this;
		}
		INT Idx;
		FBox SubBox = GetSubOctantBox( Actor->Location, Idx);
		if ( FitsBox( ActorBoundingBox( Actor), SubBox) )
		{
			if ( !Children[Idx] )
				Children[Idx] = new FCollisionOctree( this, SubBox, CurDepth+1, (BYTE)Idx);
			return Children[Idx]->InsertActor( Actor);
		}
		Actors.AddItem( Actor);
		return this;
	}
	return NULL;
}

//Recursive actor removal
//Does not get rid of the child octree node

Code: Select all

FCollisionOctree* FCollisionOctree::RemoveActor( AActor* Actor)
{
	FBox ABox = ActorBoundingBox( Actor);
	if ( FitsBox( ABox, BoundingBox ) )
	{
		if ( CurDepth >= MAX_OCTREE_DEPTH )
			return Actors.RemoveItem( Actor) ? this : NULL;
		INT Idx;
		FBox SubBox = GetSubOctantBox( Actor->Location, Idx);
		if ( FitsBox( ActorBoundingBox( Actor), SubBox) )
			return Children[Idx] ? Children[Idx]->RemoveActor(Actor) : NULL;
		return Actors.RemoveItem(Actor) ? this : NULL;
	}
	return NULL;
}

//Recursive actor removal
//Does not get rid of the child octree node
//Used when some dumb coders like hacking location values for no reason
//I should really add an exception handling macro here just to mess with them

Code: Select all

FCollisionOctree* FCollisionOctree::SlowRemoveActor( AActor* Actor)
{
	if ( Actors.RemoveItem(Actor) )
		return this;
	for ( INT i=0 ; i<8 ; i++ )
		if ( Children[i] )
		{
			FCollisionOctree* Result = Children[i]->SlowRemoveActor(Actor);
			if ( Result )
				return Result;
		}
	return NULL;
}

// Obtain a child box based on a position
// This doesn't do any kind of sanity checks for speed reasons

Code: Select all

FBox FCollisionOctree::GetSubOctantBox( FVector Point, INT& Idx)
{
	if ( Point.X >= CenterPoint.X )
	{	if ( Point.Y >= CenterPoint.Y )
		{	if ( Point.Z >= CenterPoint.Z )
			{
				Idx = 7;
				return FBox( CenterPoint, BoundingBox.Max); //7 = (1,1,1)
			}
			Idx = 6;
			return FBox( FVector( CenterPoint.X, CenterPoint.Y, BoundingBox.Min.Z), FVector( BoundingBox.Max.X, BoundingBox.Max.Y, CenterPoint.Z) ); //6 = (1,1,0)
		}
		if ( Point.Z >= CenterPoint.Z )
		{
			Idx = 5;
			return FBox( FVector( CenterPoint.X, BoundingBox.Min.Y, CenterPoint.Z), FVector( BoundingBox.Max.X, CenterPoint.Y, BoundingBox.Max.Z) ); //5 = (1,0,1)
		}
		Idx = 4;
		return FBox( FVector( CenterPoint.X, BoundingBox.Min.Y, BoundingBox.Min.Z), FVector( BoundingBox.Max.X, CenterPoint.Y, CenterPoint.Z) );//4 = (1,0,0)
	}
	if ( Point.Y >= CenterPoint.Y )
	{	if ( Point.Z >= CenterPoint.Z )
		{
			Idx = 3;
			return FBox( FVector(BoundingBox.Min.X, CenterPoint.Y, CenterPoint.Z), FVector( CenterPoint.X, BoundingBox.Max.Y, BoundingBox.Max.Z) ); //3 = (0,1,1)
		}
		Idx = 2;
		return FBox( FVector(BoundingBox.Min.X, CenterPoint.Y, BoundingBox.Min.Z), FVector( CenterPoint.X, BoundingBox.Max.Y, CenterPoint.Z) ); //2 = (0,1,0)
	}
	if ( Point.Z >= CenterPoint.Z )
	{
		Idx = 1;
		return FBox( FVector(BoundingBox.Min.X, BoundingBox.Min.Y, CenterPoint.Z), FVector( CenterPoint.X, CenterPoint.Y, BoundingBox.Max.Z) ); //1 = (0,0,1)
	}
	Idx = 0;
	return FBox( BoundingBox.Min, CenterPoint);//0 = (0,0,0)
}

[sektor2111]

// This doesn't do any kind of sanity checks for speed reasons

There probably we must be sure that actor doesn't have a chance to get vanished in critical moments. Unfortunately I cannot help as long as I failed Engine chapter, section binaries.

Anyway I give you full credits for those fixes implemented in V8, I have now new gates opened since Visibility check works as it should.

[Higor]

So I run 75v75 bots (and botz) for a while using the octree system, and the crash I get is a script recursion (>250) in Botz's AdjustHitLocation.
I can't catch a break here.

[sektor2111]

...the crash I get is a script recursion (>250) in Botz's AdjustHitLocation

I imagine that you were using Linux. Animations did not reported errors ? Like Animsequence 'Something' not found in mesh 'Amesh' ? I suspect that Linux is lazy in animations, reconsider how looks a Tentacle firing under a Linux server (if can see you well).
Let me tell you what In want to use in a root abstract for custom ScriptedPawn.
AdjustHitlocation things

Code: Select all

if (animsequence == "")
return False;

Also a mesh check ? I'm only asking because I really did not see these in Windows servers, probably are very rare ?
Also the question is if exists a HitLocation. Is impressive to see some deals with that, but did it happens ? In that moment does pawn had a valid health and collision ?

[Higor]

This is the octree build, little to no optimization and lots of exception handling macros, ideal for testing purposes.
This one comes with bUseCollisionHack=True by default and will setup the octree immediately after map start.

Regarding speed
- Line checks (99% of checks made) will currently take beteen 50%-100% extra cycles to process.
By design the octree works better in big maps with lots of actors clumped up, so there may not be speed differences the bigger (and more actors) the map is.
- Encroachment checks for movers on maps with many colliding actors will see a huge speedup.
Special mention to map AS-Redemption][, where the default hash takes 10ms to do the encroachment checks, and the octree takes 2ms.

Regarding crashes
Please submit any crashlog you get originating from the collision checks or traces.

The octree source is included as well.

[sektor2111]

GotoState('Exploding','ANastyOne');

[attachment=0]Octree_Crash.jpg[/attachment]

I couldn't even enter to pick a game-type.

Code: Select all

XC_Engine: NotifyLevelChange() begin...
XC_Engine: NotifyLevelChange() end
Log: Collecting garbage
Log: Purging garbage
Log: 0.0ms Unloading: Package CityIntro
Log: 0.0ms Unloading: Package city
Log: 0.0ms Unloading: Package ArenaTex
Log: 0.0ms Unloading: Package GenFX
Log: 0.0ms Unloading: Package NaliCast
Log: 0.0ms Unloading: Package RainFX
Log: 0.0ms Unloading: Package DecayedS
Log: 0.0ms Unloading: Package NaliFX
Log: 0.0ms Unloading: Package AmbAncient
Log: 0.0ms Unloading: Package Uttitle
Log: 0.0ms Unloading: Package openingwave
Critical: ULevel::Destroy
Critical: UObject::ConditionalDestroy
Critical: (Level CityIntro.MyLevel)
Critical: DispatchDestroy
Critical: (15420: Level CityIntro.MyLevel)
Critical: DispatchDestroys
Critical: UObject::PurgeGarbage
Critical: UObject::CollectGarbage
Critical: Cleanup
Critical: UGameEngine::LoadMap
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: ClientTravel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Log: DirectDraw End Mode
Exit: UD3D9RenderDevice::ShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 01/28/15 20:36:26

And it passed away.

[Higor]

It was kind of server oriented, but you can start it as a client using this workaround:

[URL]
LocalMap=UT-Logo-Map.unr
;LocalMap=CityIntro.unr

EDIT:
I see, the ?entry keyword is also a valid entry map switch.
The engine wasn't unhooking after said browse command.

Will fix that as well.