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

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [5]

Post by sektor2111 » Thu Mar 31, 2016 6:25 am

Higor wrote:Known bugs:
Reconnecting into the same map (mostly as spectator) may cause the skyboxes to not be linked, I suspect the level isn't being fully cleaned up when reloading itself.
This... might be an older issue.
I was using a sort of child MonsterEnd Trigger added in maps for MH2 in order to make end functional (this is how do works attached MHs). Apparently everything is normal... until players decides to re-vote the same Level... and then client is crashing post-travel. Solution is to subclass a new trigger not a child of an already mapped trigger, else client is forced to a restart.

Edit

Code: Select all

ScriptLog: Emailer's No Crash Skin Hack Implemented.
ScriptLog: Emailer's No Crash Skin Hack Implemented. //Double lines even with newer ucc
...
ScriptLog: Spawned DM-Annama.Garb0 for removing garbage > 24 minutes.
ScriptLog: Spawned DM-Annama.Garb0 for removing garbage > 24 minutes.
...
Log: Browse: DM-Xenon][.unr?Name=OwnerSrv?Class=Botpack.TMale2?team=1?skin=SoldierSkins.blkt?Face=SoldierSkins.Othello?game=NsDM3.DeathMatchPlus?Mutator=ActorCLP.ActorCLP,MapVoteULv2NS.BDBMapVote?difficulty=3
Log: XC_LoadMap: DM-Xenon][.unr?Name=OwnerSrv?Class=Botpack.TMale2?team=1?skin=SoldierSkins.blkt?Face=SoldierSkins.Othello?game=NsDM3.DeathMatchPlus?Mutator=ActorCLP.ActorCLP,MapVoteULv2NS.BDBMapVote?difficulty=3
XC_Engine: NotifyLevelChange() begin...
XC_Engine: NotifyLevelChange() end
XC_Engine: Reverting RELIABLE_BUFFER assertion hack
XC_Engine: Reverting GetWeapon hook
XC_Engine: Reverting PreLogin hook
XC_Engine: Reverting PlayerPawn.AdminLogin hook
XC_Engine: Reverting UT_Eightball.NormalFire.Tick hook
XC_Engine: Reverting Bot.SetOrders hook
XC_Engine: Reverting PlayerPawn.ShowPath hook
XC_Engine: Reverting PlayerPawn.ShowInventory hook
XC_Engine: Reverting Weapon.ForceFire hook
XC_Engine: Reverting Weapon.ForceAltFire hook
NetComeGo: Close TcpipConnection2 03/31/16 17:16:29 //This is... interesting. First is closed connection and then player with None Connection ?
Critical: UObject::ProcessEvent
Critical: (NsTFemale1 DM-Annama.NsTFemale0, Function Engine.PlayerPawn.Destroyed)
Critical: ProcessDestroyed
Critical: ULevel::DestroyActor
Critical: (NsTFemale1 DM-Annama.NsTFemale0)
Critical: UPlayer::Destroy
Critical: UNetConnection::Destroy
Critical: XC_IpDrv::~UTcpipConnection
Critical: UObject::ConditionalDestroy
Critical: (TcpipConnection Transient.TcpipConnection2)
Critical: DestroyClientConnections
Critical: UNetDriver::Destroy
Critical: UObject::ConditionalDestroy
Critical: (XC_TcpNetDriver Transient.XC_TcpNetDriver1)
Critical: ExitLevel
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: ServerTravel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: UServerCommandlet::Main
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
The same problem

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

Re: XC_Engine [16] - XC_Core [5]

Post by Higor » Fri Apr 01, 2016 4:51 am

Added a small hack that prevents unnecessary playerpawn destruction when the server's net driver is detached, see if it crashes.
You do not have the required permissions to view the files attached to this post.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [5]

Post by sektor2111 » Fri Apr 01, 2016 9:58 am

Higor wrote:Added a small hack that prevents unnecessary playerpawn destruction when the server's net driver is detached, see if it crashes.
It do seems to work - no more crashes.
The rest of twice lines written in logs are still there... it do not happens in v16.

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

Re: XC_Engine [16] - XC_Core [5]

Post by Higor » Sat Apr 02, 2016 7:52 am

ResetLoaders() kinda works on my server... I guess not in all conditions.
I could try a second garbage collection call inbetween map (re)load to see what happens.

============
Update, this version runs two garbage collectors instead of one:
- New one, happens right after previous level is deinitialized, forces deletion of the MyLevel object.
- Default one, happens post level load, forces deletion of all level actors not belonging to actor list (aka deleted), also cleans up other unused resources.

These are the possible scenarios with this GC:
1 - Level unloaded, no outside references to the level's actors, the level's actors are also washed away by the garbage collector.
2 - Level unloaded, non-static actor spawned midgame is referenced by something and kept, level is reloaded with default actor list, this actor will be washed away by the second garbage collection and an invalid reference will be had.
3 - Level unloaded, actor originally loaded with the map is referenced by something and kept, level is reloaded with default actor list, this actor will be re-referenced and possibly not cleaned up but a valid reference will be had.

Problems:
In case 2, if something holds a reference to the actor, it won't be nulled out (nexgen window, transient object, entry, etc) so attempting to access it will result in crash.
In case 3, this actor will most likely won't get refreshed and will carry over values from last game (same map reloaded), but there won't be crashes.

This makes absolute sense, as it vanilla UT these crashes were too common when holding references to some level's actors.
So one way to deal with this, is to run the transient cleaner right after the map is deinitialized and right before the first garbage collector, so this way any actor referenced from outside of the level will be destroyed without leaving bad references and at the same time making sure that level-loaded actors are 100% reloaded instead of reused.

Maybe there's a chance I can actually make the engine a lot more stable at mapswitch regardless of how retarded a modder is!!
You do not have the required permissions to view the files attached to this post.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [5]

Post by sektor2111 » Sat Apr 02, 2016 9:00 am

Note according to lasts posts related to server-trash. I run an actor for cleaning - not mutator + a starter checking if map loaded is start-map in order to trigger a game-end and switch to a random map according to map-vote rules for an empty server - it works.
Okay... now if I'm looking at logs, my actors in next Level are named Garb0, Thestart0. My problem comes at DMMutator. It is stacking with DMMutator0 DMMutator1 DMMutator2... perhaps at a moment we have DMMutator812. I think this cannot be healthy. Why Mutator doesn't have a fresh copy as an actor and we still have tracking of an older - I think it's not entirely unloaded - right ? And then I'm gonna write a timer / tick different, or a cleaner actor ?

Edit:
GridTest5.2 seems to not cause any surprise, I gotta admit I'm not using any Nexgen or such things, it's only a sort rewritten a MapVote with stepping iterations doesn't do any harmful thing - as a "special" mutator. Today I have tested stuff at 79 ms ping from another Network VIA redirect LZMA and client XC simple (no INI edited). Everything was fine (even with antivirus running during game in client). No issues and No Accessed None found in Server Logs (the rest of client problems are not a lot... but... damn default weapons/meshes/states).

Edit2:
Looks like an actor operating tweaks at start and who self destruct after doing the job can be unload as a normal package at purging garbage in game, which means the garbage collector works properly without to hold objects in memory after their usage.

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [5]

Post by sektor2111 » Wed Apr 06, 2016 7:10 pm

I have a request: DO revision to player speech "fix". In CTFGame it says "AssaultTheBase" not "TakeTheirFlag". If anything else is messed please put booleans for disabling them when it needs. V16 doesn't have this issue. I thought that some Test-Server has problems but not - it's an XC issue. I hardly noticed this because my CTFGame doesn't need orders, Bot knows what to do rather than smelling your butt all the time.
Edit: The same for Domination - No longer "SearchAndDestroy" just "AssaultTheBase"

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [5]

Post by sektor2111 » Thu Apr 21, 2016 11:54 pm

Another problem has been found by hunters.
Map MH-Lemmings-{EASY}.unr. Even by disabling BrushTracker <NoBrushTrackerFix=MH-Lemmings-{EASY}> SteelBox19 will stay stuck with Mover234 (door-button), and door can't be opened because Box cannot be pushed away for releasing button. At least Off-Line it do breaks.
[attachment=0]Stuck_Here.PNG[/attachment]
You do not have the required permissions to view the files attached to this post.

User avatar
Barbie
Godlike
Posts: 2152
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: XC_Engine [16] - XC_Core [5]

Post by Barbie » Fri Apr 22, 2016 4:04 am

sektor2111 wrote:because Box cannot be pushed away for releasing button
Try a bigger gun! ^^ That even didn't work?
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [5]

Post by sektor2111 » Fri Apr 22, 2016 6:27 am

Barbie wrote:Try a bigger gun! ^^ That even didn't work?
I did not drink anything before posting this for spamming forum useless. Load XC_Engine and do figure. Those hunters are not noobs and I'm not playing MH from yesterday.
Note: this is v16 because v17 has orders broken.
All right then, I'll prepare an actor intended for fixing it in way or another after coming from work.

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

Re: XC_Engine [16] - XC_Core [5]

Post by Higor » Mon May 02, 2016 2:05 am

So I figured out the source of many of the grid crashes, invalid/deleted actors remaining in the grid without a unhash call for some reason.
In the meantime I'll add a few more hooks/systems.

The main one will be the actor recycler.
All recycled actors will be batch grouped into 128 byte blocks (1 block chain ref, 1 size marker, 30 actor refs).
The blocks will be chained so we'll be adding storage of 30 refs at a time.
The blocks will only store actors of a single class so the class check is only done once and then add/retrieve operations will be simple.
The class matching will be implicitly done with a TMap<Class,ActorBlock> type, where each class will have associated each block 0.
So, when actors are deleted they'll be stored in the blocks (allocated if necessary).
When a new actor is about to be spawned, XC_Engine will attempt to retrieve a stored actor so that it's memory and name entry are reused.

As you can see, actor memory isn't the only thing that's being wasted, but name entries each take a lot of space too and these aren't exactly cleaned up outside of Garbage Collection as well.
So, we'll basically have actors coming back from destroyed with their old name and being faked into newly spawned actors.
If this works then servers could run indefinetely without calling the garbage collector.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [5]

Post by sektor2111 » Mon May 02, 2016 3:37 pm

But at ending game we run Garbage Collector, right ?

User avatar
Barbie
Godlike
Posts: 2152
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: XC_Engine [16] - XC_Core [5]

Post by Barbie » Mon May 02, 2016 4:19 pm

Higor wrote:name entries each take a lot of space too
Does this mean that the name table only grows but never got shrinked during one map play? Then every map with repeated created and deleted Actors must crash earlier or later because lack of memory.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [5]

Post by sektor2111 » Mon May 02, 2016 8:10 pm

That's why anything called Overkill (which I tested), Excessive, Abusive, Over-dozen and such things are not good for servers, I leaned this hard way, it's time for others to learn this lesson.

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

Re: XC_Engine [16] - XC_Core [5]

Post by Higor » Mon May 02, 2016 11:51 pm

Actor validity check prevents collison grid crashes (hopefully all 100% of them).
Lots of access exception handlers.
Temporary reimplementation of ULevel::MoveActor for debugging.
Very rudimentary actor recycler, can add up to additional 30mb of initial extra memory usage but then it won't grow anymore as the name table won't endlessly increase.

It's not the ideal solution, actors are cleaned up by default just fine but the name creator is the one doing the memory consumption.
So maybe future builds will instead recycle names, if I get to crack down on that.

PD: The actor recycler cannot be turned off in this build so keep backups.
You do not have the required permissions to view the files attached to this post.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

ShaiHulud
Adept
Posts: 427
Joined: Sat Dec 22, 2012 6:37 am

Re: XC_Engine [16] - XC_Core [5]

Post by ShaiHulud » Tue May 03, 2016 1:42 am

Thanks Higor. Do you know anything behind the mechanisms that cause "wall bugs" - that phenomenon where, when you move close to a wall, you sort of get "snagged" on it? It's become an intentional feature of some BunnyTrack maps, and an incidental nuisance in others.