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

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 11 - Dynamic Package Loading]

Post by Chamberly »

^Agree.
Image
Image
Image Edit: Why does my sig not work anymore?
Mar
Novice
Posts: 26
Joined: Tue Aug 27, 2013 1:04 am

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Mar »

Higor wrote:That crash has occured because either:
- A non-NavigationPoint was placed into the navigation point list (super unlikely)
- A NavigationPoint is using an invalid reachspec index (not in reachspec table)
- The 'End' NavigationPoint of a reachspec was deleted (or unreferenced)

I had that kind crashes when I was developing the navigation editor for FerBotz, can't remember what caused it but my code was messing with the above listed things.
There may be a chance the map has an error (like a deleted navigation point)
Thanks for the info :tu: and sorry for the offtopic, didnt knew it wasnt related to the new engine.
SC]-[LONG_{HoF} wrote:One thing is for certain. There are many noob made MH maps out there and you can't blaim Higor's XCGE for noticing them. LOL
You are right :mrgreen:
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by sektor2111 »

Mar wrote:We got this error from our MH server.
Using build 11.
Advice: F..ck that map. You have my permission. Who am I? Trash remover aka Man on Duty.
When I faced such crap and I went ahead in a forum against such a noob "fix" because it was named "fix"; some idiot powered as admin got mad telling me that I'm posting craps. I would like to make him to swallow my entire drive with logs. The most of these "mappers" are hunting popularity rather than helping community.

I can recreate all time such crash. Go to a map with Bot Support, delete a PathNode around monsters, Save map as a test version. Try to play, might work or crash depending on situation... Enjoy !!

My MH2 version has a feature to discover such things in firsts seconds (before to add it in a public playground). Player will hunt a path to whatever WayPoint or End. In such a map will deliver instant crash. Response: Negative, map won't be added before to be properly "ruined".

Edit: Note number 2. Someone think that monster is roamer and delivered order "Roaming" at monster. This bug might have a fix in MHv5.04... or you can simply make a small mutator against "ideas".
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by sektor2111 »

And now a XC_Engine issue ? Looks like YES.
Map DM-Bishop - Mover0 - Lift StandOpenTimed unlinked properly with paths but... somehow works in original.
In XC_Engine seems to not move if player follows the green route also might swallow player.
Still_Octree.JPG
Problem has occurred in Dedicated Server and Local Play too, simply mover gets screwed. UT versions used only 436.
Not because of XC_Engine, but because of some paths messed up in noob style I will screw this one.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Higor »

Wow, you found a very obscure bug, in my node placer.
Octree.PNG
Check the node bounds and the actor bounds, Y coordinates.
The maximum Y coords of the mover bounds is touching the minimum Y coords of the octree node 44.
This is bad, because the mover bounds aren't contained in the node bounds, but instead they're adjacent!!!

I know what's happening here:

Code: Select all

			FCollisionOctree* TestNode = DepthGrid[j].Get( NewInfo.Box.Max);
I'm using the Max point to get a grid slot... i should be using center, thanks for the report
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by sektor2111 »

I did other test, I was trying to play NsDM normally but... in PostBeginPlay into BaseMutator I set (0,0) movers collisions. It was fascinating to see no difference but default seems to mess with 160,160 and I don't get why needs declared a kind of collision this brush :noidea .
The rest of stuff seems good...

I was quitting idea to replace NavigationPoints. I didn't see any crash at this operation, but I have seen paths screwed after 30 seconds. I cannot copy ReachSpecs using UScript and I don't know how to catch Editor's stuff in PreBeginPlay()...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Higor »

Use native FerBotz mutator (with zero Botz lol), and learn to use the FerBotz pathing.
You'll no longer have do that navigation point mess... ever.

EDIT:
Collision system uses something called 'UPrimitive' when calculating bounds and hits.
Actors have no primitive, so the game defaults to the master 'UPrimitive' object which treats collisions as cylinders.
Movers have a UModel primitive which is their 'Brush' var, UModel is a subclass of UPrimitive and shares all virtual methods.
Static Mesh actors work the same way because UMesh is a derivate of UPrimitive and has all virtual collision check methods.
This means that collisions for non-UPrimitive actors (brushes) don't use CollisionRadius and CollisionHeight.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by sektor2111 »

Stuff to rebuild paths in FerBotz works fast? I would like to see tiny codes for starting a soup. Why I'm interested about this chapter?
During games I have 0 errors but at a moment that bullshit TranslocStart wants to destroy my happiness. I did replacement but data gets badly screwed when I was trying to implement it.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Higor »

Well, I'm yet to make the Botz transloc nodes to work with normal bots (only work with other Botz), but the remaining navigation points you can add (except piston launching a module) do properly interact with all Unreal creatures, unfortunately Pawn doesn't properly grabs a navigationpoint when PHYS_Flying is set, because FerBotz does have air node support (you have to calc from ground and the cache the route).
FerBotz can fly the quantum fighter jets but it's extremely unstable for my tastes, so I never went beyond one map and a few tests.

Since I realized that FerBotz is using bTicked wrongly and the non-native version has it's built in 'ActionPathCoster' (yep, botz dynamically add cost to routes based on experience) broken I HAVE to make a new FerBotz release soon... with UPackageMap handling support (be it native, or via XC_GE) so that the client interface works and skins are properly selected in online games without using 'ServerPackages'.

Yeah, once I do a final LCWeapons update I'll get on with it, but if you're using FerBotz to load navigation points into a map, then you're good to go.

EDIT:
Building paths works pretty much like half-life path builders for bots, the actual path loading is dynamically rebuild post-load and is super fast (doesn't do extent traces, so place them carefully!!!).
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by sektor2111 »

I don't intend to modify properties for new point. My problems looks as follows:
- all points downstream and upstream need modified to link new point including related reachspecs;
- new point need to copy everything from old point.

Looks like I did job 50%. I found path to enemy flag and later... NONE. Bots started to wander confused. If I can load a fast "paths rebuild" after destroying bad point then mission can be claimed completed.
New point is done generally for pawn able to operate a translocation Bot like but... for sure a Manta might be grated to follow that route because can fly, LOL.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Higor »

Well shit, I just noticed that my XC_Engine.so is importing the __Context::Env symbol, and only works with a few v436 Core.so files.
I can provide the Core.so file I use with my GCC compiler as a workaround for anyone unable to run this on v436, that one does have said symbol...

BTW, how the hell is it there's two Core.so files?
Anyone?
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by sektor2111 »

Higor wrote:BTW, how the hell is it there's two Core.so files?
Anyone?
As I know so far there is a .SO file "original" (by Loki I guess). With this file a 436 Linux server might crash when a Monster or whatever WoodenBox try to join in server. Probably later someone solved this problem because it was a real bullshit since original Win 436 server doesn't include this sort of dumb bug, it was developed (hell knows for what reason). Also it seems to be a need to tweak INT, I'm wonder why Core doesn't include automatic protection.

If your decision is to debate a bit Core binaries I would like to solve that unfinished clock system "/*..*/" because includes information but I can't be sure if exist something native done there or just remarks - if won't be an insane effort. Also you were saying about "ISA" as being slow, if you can redo a faster formula I'll appreciate this work. I'm already feel pretty happy for your effort to solve problems via XC_Engine. Yes, I think CORE needs love too.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Higor »

All of my linux releases (FerBotz, UBinary, XC_Engine) are importing the __Context::Env symbol

From UnGnuG.h

Code: Select all

// Stack control.
#include <sys/wait.h>
#include <signal.h>
#include <setjmp.h>
class __Context
{
public:
	__Context() { Last = Env; }
	~__Context() { Env = Last; }
	static void StaticInit();
	static jmp_buf Env;
 
protected:
	static void HandleSignal( int Sig );
	static struct sigaction Act_SIGHUP;
	static struct sigaction Act_SIGQUIT;
	static struct sigaction Act_SIGILL;
	static struct sigaction Act_SIGTRAP;
	static struct sigaction Act_SIGIOT;
	static struct sigaction Act_SIGBUS;
	static struct sigaction Act_SIGFPE;
	static struct sigaction Act_SIGSEGV;
	static struct sigaction Act_SIGTERM;
	jmp_buf Last;
};
And this is happening even when I'm not using the 'guard' and 'unguard' macros for exception handling in gcc.
I really wonder why the original v436 server Core.so doesn't export said symbol, but whatever, I simply have to not compile this code...
So I either remove this from my headers, or use the '#DEFINE DO_GUARD 0' command which disables the code using this class.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by sektor2111 »

Any news related to that mover issue ?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 11 - Dynamic Package Loading]

Post by Higor »

I'm doing severe changes to the octree.

- The mover issue is completely fixed, and is handled a lot better now.
The FCollisionCacus node family takes around 2 mb less in memory now that it doesn't create a new node for every actor (instead waits intil it gets three before subdividing).

- The branchless AABB/ray check was replaced with a BackFace culling algorithm for octree node hit detection.
Results: bigger function, but timings were a lot better. For 22v22, CTF-Warzone.unr, benchmarking the AABB checks for a total of 100 frames before printing to log (500 traces per frame avg).
Old AABB checks: 250 milliseconds.
New AABB checks: 70 milliseconds.
Also, it's now calling less actor traces, so I guess the old code had bugs.
Short traces are still not as fast as the old hash's, but the whole physics code now takes barely extre 30% time than before (tiny millisecond fraction difference, but I'm not convinced lol).
Post Reply