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

Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

Finally managed to make a port of CollisionGrid for Linux.
https://github.com/CacoFFF/XC-UT99/comm ... c3fa81cb5a

Build will be available after some private tests are done.
Chose GCC 5.xxas the target compiler and boy that brought a few problems in.

======================
As some may know, UT was compiled using GCC 2.95 where c++ was not exactly an official feature and the amount of incompabilities and inconveniences go beyond the naming conventions.

- In newer GCC virtual destructors appear to be laid out according to Itanium C++ ABI, you get two destructor entries in the vtable, one for uninitialization and another for deletion.
UT's vtables only have one destructor in the vtable, which performs both tasks.
So in order to make the code generated by the new compiler compatible with the old one I had to remove the destructor function and add a dummy 'virtual void SimulatedDestroy()' which then manually did the destruction.

Code: Select all

#ifdef __GNUC__
	//GCC 2.95 uses a single destructor entry (instead of 2)
	virtual void SimulatedDestructor() = 0;
#else
	virtual ~UObject() {};
#endif
- vtable offsets are different in both compilers (8 bytes)
In order to make UT able to call functions from the new grid, and make the grid call functions from UT objects (brush, actor) the new compiler had to generate it's vtables (and function calls) using a similar layout as with the old compiler.
This was solved by adding two dummy functions at the beginning of all classes, the method used was to subclass all UT compatible structs from the following 'GNUFix' class.

Code: Select all

class GNUFix
{
#ifdef __GNUC__
	virtual void vPad1() {};
	virtual void vPad2() {};
#endif
};
- UT physics code (PHYS_Walking specifically) messes up stack alignment.
This means that all entry points into CollisionGrid.so (Tick, AddActor, RemoveActor, ActorLineCheck, ActorPointCheck, ActorRadiusCheck, ActorEncroachmentCheck) needed an alignment override so that the packed SSE instructions wouldn't crash the game.

Code: Select all

#define GCC_STACK_ALIGN __attribute__((force_align_arg_pointer))
...
GCC_STACK_ALIGN void FCollisionGrid::AddActor( AActor* Actor)
{
	Grid->InsertActor( Actor);
}
======================

MinGW still cannot produce working builds, but Visual Studio 2015 is doing a job more awesome than I ever expected thanks to the library/code tweaks to reduce the DLL size... with a little exception, after updating VS2015 the compiler thinks member function pointers should have a size of 8 bytes, instead of 4 bytes on x86 targets, which is completely wrong and forced me to rewrite some of the assembly code.

With this said I'll be able to look into the replication bug on pawns sooner than expected.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

Beta build setup on unreal://193.111.136.210:7788

======= Changes:

Uses CollisionGrid.so
- Fixed movers (99,9%), traces, encroachment.
- Better server performance.

Reworked pawn bandwidth hack in new relevancy:
- Now also saves bandwidth from unnecessary rotation, velocity updates.
- More aggressive on non-walking physics.
- Less aggressive on stairs (fixes terrible simulation on clients).
- Triggers an additional update when player/monster stops moving to correct standing position.

New relevancy traces fixed, they no longer go through non-translucent surfaces.
** Less actors received by client, channel list no longer fills up.
User avatar
Deepu
Adept
Posts: 350
Joined: Mon Nov 11, 2013 7:56 am
Personal rank: Average
Location: India
Contact:

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

Post by Deepu »

Work with high tick rated server without any position errors?
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

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

Post by sektor2111 »

PatchCode crash:

Code: Select all

		if (string(A.Name) ~= "doubleenforcer1") // Position 241
		{
			NewRot.Yaw=16536;
			A.bGameRelevant = False;
			doubleenforcer(A).MyMarker.MarkedItem = Spawn(class'enforcer',,,vect(-432,1344,-144),NewRot);
			doubleenforcer(A).MyMarker.MarkedItem.bRotatingPickup = False;
			doubleenforcer(A).MyMarker = None;
			A.LifeSpan=1;
			continue;
		}
		Spawn(class'doubleenforcer',,,vect(431,1344,-143),NewRot);
		if (string(A.Name) ~= "doubleenforcer0") // Position 242
		{
			NewRot.Yaw=16536;
			A.bGameRelevant = False;
			doubleenforcer(A).MyMarker.MarkedItem = Spawn(class'enforcer',,,vect(431,1344,-143),NewRot);
			doubleenforcer(A).MyMarker.MarkedItem.bRotatingPickup = False;
			doubleenforcer(A).MyMarker = None;
			A.LifeSpan=1;
			continue;
		}
Resulting CrashLog

Code: Select all

NavAdder: > Navigation Core Loaded.
NavAdder: Map's name is: MH-(SF)Cryptrunners_v1e
NavAdder: Map's name length is: 20 characters.
NavAdder: Cutting Name...
NavAdder: Looking for a class called > TRUNNERS_V1E.PathsMapper
NavAdder: Found module, attempt loading...
CryptRunners: PathsMapper0 Patching Level.
Log: [CG] Allocating extra element holder for ActorInfo
Log: [CG] Allocating extra element holder for ActorInfo
Log: [CG] Allocating extra element holder for ActorInfo
Log: [CG] Allocating extra element holder for ActorLink
Log: [CG] Allocating extra element holder for ActorInfo
Log: [CG] Allocating extra element holder for ActorInfo
Log: [CG] Allocating extra element holder for ActorInfo
Log: [CG] Allocating extra element holder for ActorInfo
Log: [CG] Allocating extra element holder for ActorLink
Log: [CG] Allocating extra element holder for ActorInfo
Critical: appError called:
Critical: Assertion failed: Generic memory stack fully used [File:d:\ut src\collisiongrid\collisiongrid\GridMem.h] [Line: 46]
Critical: Windows GetLastError: The system cannot find the file specified. (2)
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Log: DirectDraw End Mode
Exit: UD3D9RenderDevice::ShutdownAfterError
Critical: ULevel::CheckEncroachment
Critical: UXC_Level::SpawnActor
Critical: (doubleenforcer)
Critical: UObject::ProcessEvent
Critical: (PathsMapper MH-(SF)Cryptrunners_v1e.PathsMapper0, Function TRUNNERS_V1E.PathsMapper.PreBeginPlay)
Critical: UXC_Level::SpawnActor
Critical: (PathsMapper)
Critical: UObject::ProcessEvent
Critical: (NavAdder MH-(SF)Cryptrunners_v1e.NavAdder0, Function NavAdder.NavAdder.PreBeginPlay)
Critical: UXC_Level::SpawnActor
Critical: (NavAdder)
Critical: UObject::ProcessEvent
Critical: (MonsterHunt MH-(SF)Cryptrunners_v1e.MonsterHunt0, Function XC_MonsterHunt.XC_MonsterHunt.InitGame)
Critical: BeginPlay
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: ClientTravel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Exiting.
Gotta try without new Grid...
EDIT:
Nah, my bad. Should not mess inside an iterator...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

The generic memory stack is only 256 kb long, this was done on purpose because it's not realistic to expect more than 1000 results with actual good coding practices.
Intentionally crashing the game after ~5k results is a way to enforce said good practises.

On the other side, the element holders do spawn new holders when needed.

Code: Select all

//
// XC_Engine's first interaction
//
extern "C"
{

TEST_EXPORT FCollisionHashBase* GNewCollisionHash( ULevel* Level)
{
	if ( !LoadUE() )
		return nullptr;
	if ( Loaded == 1 )
		debugf_ansi( "[CG] CollisionGrid library succesfully initialized.");
	if ( !G_ALH )	G_ALH = new (A_16) ActorLinkHolder();
	if ( !G_AIH )	G_AIH = new (A_16) ActorInfoHolder();
	if ( !G_MTH )	G_MTH = new (A_16) MiniTreeHolder();
	if ( !G_Stack )	G_Stack = new (SIZE_KBytes, 256) GenericMemStack( 256 * 1024); //5461 results
	debugf_ansi( "[CG] Element holders succesfully spawned.");
	//Unreal Engine destroys this object
	//Therefore use Unreal Engine allocator
	G_CHB = new(TEXT("FCollisionGrid")) FCollisionGrid( Level);
	return G_CHB;
}

}
Windows build of the grid running in Dev2 server.
Changes:
- Back to single grid system.
- Mover encroachment ignores non-bCollideWorld actors (optimization from the old grid, maps with automatic/rotating movers run better).
- Trace code bounding box is 4 units bigger on each direction, this prevents players from being detached from movers.
- Fixed Mover Encroachment code using wrong position, causing standing players to encroach it.
- Fixed PointCheck using wrong position.
CollisionGrid_03.7z
(11.88 KiB) Downloaded 68 times
The XC_Engine build with the net stuff will remain private for now.


================================================================
Dev2 tests have show far greater accuracy with monster positions, although I still spot some high bandwidth consumption, but maybe it's because of the bots lol.
Need to run more tests.

Recommend me a big, playable, (not exactly botpathed) finishable (without BS mods) MH map to add?
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

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

Post by sektor2111 »

Cannot see shock combos all time, randomly they are invisible - some updates are missing ? Recommended client settings (I used previous XC stuff) ?

Edit: To mention Dev2 server with that combo issue not mine.
Map... big... not pathed - GardenOfDeath in original - not modifications from here and there, is Zero in DevPath so far...
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

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

Post by sektor2111 »

Something interesting to see
MH-CryptRunners_v1e.unr

Everything was perfect OFF-LINE. Things went nasty at ON-Line (tested with LevelHook turned on)
Door to first Pupae boss looks like it was leaving collision trails. the same Patcher was screwing map in the same way but On-Line was nasty, even Bots were almost stuck in a sort of invisible barrier.
[attachment=1]CryptRunners.jpg[/attachment]

Map is here
[attachment=0]MH-(SF)Cryptrunners_v1e.zip[/attachment]

Things to take in account:
- I suspect BrushTracker mooing because map has initially infinite timers at these movers - or I'm wrong;
- Map has duplicated actors so I don't have any clue how do engine will process iterators at this point and this is not doing something evil with objects.
I see it was a good looking level so I decided to deploy some paths inside it and a few things.
It doesn't seems a good idea... To not forget that I see versions and majority have None mover fix probably the rest of borks are only moved not solved...
Whoever was author or the dude doing these I think he has grave mental problems...

Edit: The strawberry
MapManager doesn't seems to recognize all devs required here. I recall right now "Anc2.utx" - another crap with no custom tag which anyone can do on the other side of planet and which seems not added as a dev file for map. I have to take a walk for other toys that are more useful for admins in packing maps. This map escaped from me in the past, probably it did not include "PathNode" and "MonsterWayPoint" strings... or heck... I don't know more details...
However, that Mover32 has bNoDelete = False :loool:
By forcing it to default True will crash client because it will cause Net borks. Solution is Editing but not releasing another crap with infinite timers and duplicated actors.
Attachments
MH-(SF)Cryptrunners_v1e.zip
(3.28 MiB) Downloaded 69 times
CryptRunners.jpg
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

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

Post by sektor2111 »

Bump: Perhaps is LOL in stage
[attachment=0]NotEvenCloserToReachable.jpg[/attachment]

I think I'll stay with previous version of XCGE with no external collision grid and NO changes to DevPath.
As you can see, waypoint is not even closer to reachable, it is at 3 rooms far away. When I found myself hunting alone I was wondering where the heck are Bots. All, but all of them were busy to push walls trying to reach at target, one of them is still "addicted" to some WayPoint which is not reachable in any UE1 version. These changes should have an option for being disabled - seriously speaking...

So desired move is to put back what was before, doing a backup and... that's all.
Thanks so far.
Attachments
NotEvenCloserToReachable.jpg
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

That looks like forced attraction, but w/e.
The milestones for next release are set:

- XC_Core:
Asynchronous decompression.
Enhanced package finder (matches GUID+Name)
A few more natives.

- XC_Engine:
New relevancy refinement.
SSE/SSE2 Collision Grid.
Enhaced server join (no need to remove mismatching packages, see all files' download progress).

Gonna be abroad so I'll be off during late November, early December. :rock:
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

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

Post by sektor2111 »

Attraction or not, in account
DEAD seeker should not have MOVETARGET, neither a response from devpath because has not logic, respawning later in other spot will crap out everything.
Pawn with physics NONE also won't do nothing - DevPath should return NONE here. Ghost seekers should be ignored - probably removed if non-players - more easy and fast to do these in native but having option to disable these in case of sudden "great pawns" appearing from some bullshit lab.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

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

Post by sektor2111 »

Still 2 problems at new <collisiongrid.dll>.
1 - Fake boost still exist even is rare but can be critical when you fly suddenly where your rocket will explode like rocket is pulling you with an invisible rope - happens with other projectiles too;
2 - random items are vanished and they never come back - never respawn - i know those maps so I can figure these easy. First time a Shieldbelt did not return in game and then in a closer spot a HealthVial was lost.
Disabling for now. Map was build properly with no bsp gaps or borks so a discussion about geometry is not in account as long as with default collision these things are never happening.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

Name maps where items disappear
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

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

Post by sektor2111 »

It was that CryptRunners which I think I'll quit blabbering with it. I spawned VIALS. At random one of them never respawned and then a default shieldbelt from map. Doesn't happen all time. I disabled collision and doesn't look like it do happens any more. Never mind, that map even with a rebuild still has some evil editing or whatever things left from some source. As a note, mover in front of pupae boss does ugly things ON-LINE - original v1e. By excepting map from tweaking it looks invisible...
Too bad I have generated paths file and client tweak and... I can drop them away...

The problem stays with boost - I died killed by my own flak-slug being moved right into explosion...

Next thing which for me is NOT okay, Logs delivered by UCC2. In company of some Epic Errors I can see duplicated lines involving mutators having nothing in common with monster in cause.

Code: Select all

RandWeapon: Cow MH-BirdBrainedResearch.Cow1 (State UnrealShare.ScriptedPawn.Retreating:0242) Accessed None
ScriptWarning: Cow MH-BirdBrainedResearch.Cow1 (State UnrealShare.ScriptedPawn.Retreating:0242) Accessed None
What exactly has to do my weapon loader with default retarded cow ? Log system is still rammed not to mention still repeated lines at "dynamicloadobject" used and logged.

Code: Select all

NavAdder: Target class is called > P_LOGO-MAP.StuffTweaker
NavAdder: Target class is called > P_LOGO-MAP.StuffTweaker
NavAdder: Target class is called > P_LOGO-MAP.StuffTweaker
NavAdder: Did not find a tweaking module for this Level.
Maybe I have to fallback at some old ucc which I used.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

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

Post by Higor »

Phew, so far I've managed to:
- Put decompressor on a separate thread for both UZ and LZMA, there's a spinlock to ensure thread safety access to memory allocator, hope it works 100% fine.
- If client fails to find a file in the redirect, it will not discard the redirect for the next file (AKA: the download modules don't get cleared!!!).
- If client detects a mismatching file (Example: Dusk.umx) it will attempt to download the server's version even if the client has it's own.

Still need to make the client actually load that package, o ho!
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

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

Post by sektor2111 »

Gladly awaiting for checks...
Post Reply