I just wonder how this got past under everyone's noses for so much time.UCC.exe (and every engine launcher) spawn their own Logger, Memory allocator, Error handler and File manager for the engine to use.

Higor wrote:I just wonder how this got past under everyone's noses for so much time.UCC.exe (and every engine launcher) spawn their own Logger, Memory allocator, Error handler and File manager for the engine to use.

It passed... ignored. All the time I found topics in forums debating sort of useless things and I got bored even to bump such nothings.

UCC like I said was stucking servers using UnrealI creatures and derivates even in Non MonsterHunt games. Executable (any shortly called UT.exe) did another sort of trash, no stuck but still crash. Engine crash anyway with a mountain of errors. A better launcher to prevent a frozen server is a good thing after all. I have already installed this and it runs for a couple of hours pretty solid with no issue + XCGE v16, XC_Corev3, XC_IpDrv, Custom CTF, DM, Custom creatures.

I'm using a batch firing "start" command with a few parameters - nothing evilized to report. Perhaps tomorrow I'll put up a MH/MH2.

Aside , I was wondering when you'll step into UCC at least for a check and some "unknown" tricks that can be done with this UCC, examples of commandlets, ect. Next check might go at UWeb and maybe for XCGE a nice Log for reporting messed up things from a Level (duplicate actors, bad values - letter vs numbers, corrupted Path-Net, Pickups bad set which mess up replacements, ect.).

Any more things to be added...Thread safe memory allocator? It's possible to make it platform independant by using two 'FMalloc' objects (one locks the thread, other allocates).That way it'd be possible to have multithreaded natives use TArrays and etc...

Also gotta find out how messages are being printed to UCC's window, that way I can also filter messages there.The game's timing is affected by Engine.ServerCommandlet and not UCC so that'd be something I have to implement in XC_Core (and a proper timing fix, alternative to XC_Engine).

Returning to chapter stupid UCC lock downs - I have voted in purpose LiandriInvasionV2 with awesome XidiaMPack's freaky weapon-holders.No response from server, game has been lost. Nothing shown like a server-address in any Lan Tab or such. Well, if stuff is such brilliant I would like an actor/object trouble maker removed even with the price of a crash/restart normally itself rather than a completely frozen crap.

Last image shown by me was with "S.W.A.T. agents" in water but no intention for swimming - Red Flag and Good Night.This kind of loop boosting CPU usage cannot be notified somehow in order to fire a critical event ? A test thread like an attempt to ping server in purpose to gain a response ?

Let me introduce what I was figuring last time. When a state goes rammed triggering another state which returns pawn back in previous state cycling like this you might get a presumed server running but is not really too responsive, boosting a hard process. Looks like there is nothing to spy "Infinite State Changes Loop" and to properly crash rather than developing a loop running an useless server at maximum CPU usage. I might be on a wrong road but I was almost to recreate such a loop freezing with 0 response - the only master for this situation was task manager.

In XidiaMPack looks like some pawn simply fires a state change from state A to state B which drops it back to state A and moved again to B and this seems to loop insanely wasting all UT's CPU cycles. If we don't get a solution for such cases this means that I have to decompile (again) that package and to do a long work around for figuring issue and some months of testing resulting finally in another MISMATCH. Or probably fixing if I'm thinking better won't be a nasty challenge as long I have already 2 weapon-holders a la XidiaMPack which I can drop there as basement as long as my pawns never stuck games and are able to use even default Redeemer which is not friend with default Skaarj + have some features to get a weapon with any matter ignoring bullshit default replacement + won't drop weapon invisible in On-Line games + won't be blabbering PlayerReplicationInfo a la Skaarj.EDIT:Running a server using primitive dynamic mesh THIS ucc got mad. It DOES NOT happening using UnrealTournament.exe file for firing server. However, I like new dynamic mesh - I think I'll get rid of UCC from my run-lines as long as it has started to piss me off.This belongs to UCC

A traditional server stuck UCC based, and the way how allocates memory this sort of "Compiler-Only".It cannot sustain a Master-Server and neither a Game-Server.

Perfectly agree, but exist people which were not taking their pills.According to these "Feign-Cool" issues type of people I think you can rename map correctly by getting rid of crap.

Note: Nobody told to that MH mapper guy uploading trash at MapRaider to forget SPACE in file-names used ? All there commenting are chickens or what ? Please anyone give him a manual with Operating PC basics including to those which weren't speaking louder. They need some MS-DOS classes before to bring them in front of Win3.1.

MS-Dos takes ANSI characters as input, therefore these special chars may not be possible to add.It's a different story if you let XC_Engine's autocompressor thread do it.Technically XC_Engine passes the filename using Window's Unicode characters so if server does compressing and client does decompressin, then it's possible to do.

Gonna extend tests outside of coding machine as long as it do seems more stable right now. I'll see more results after loading a MH2 server with PrimitiveMesh stuff. Also I have made some code optimization (eg: count monsters only if Tick-Rate is almost at value configured 28ticks/30ticks, don't count monsters if party is too hot 24ticks/30ticks or lower).