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

[sektor2111]

And CTFGame (named exactly as default CTFGame) sounds like "AssaultTheBase" - Where do I disable this "fix" ? Better Put back codes from V16.

[Higor]

Are you running garbage collector mid game?
None of the other test servers have this issue.

[sektor2111]

Since that thing did not start (it works only at random intervals), I don't see what problem might be as long as it is, works properly in MH (Including in MonsterArena) but for CTF is unchanged, I would like to known how does it sound for a custom one as EUTCTFGame and similar child classes.
Server 436 full configured with XCGE, client having only files without INIs. This issue never existed in V16.

Edit:
In several UScript modules I'm gonna return to "ISA" because... it's good after all.

[sektor2111]

I'm curious if does worth a bit of work at a small mutator for using XC_PrimitiveMesh in V17. Or it doesn't ?...

Edit:
BotOrders set to false, log still saying Bot's orders hook success - it overrides my setup...

[sektor2111]

I got news at Purging Garbage chapter. Something went wrong which I did not see before.

Code: Select all

ScriptLog: Garb0  >> Cleaning garbage objects!
Log: Collecting garbage
Critical: TestReach
Critical: UObject::GetFullName
Critical: TArray<<
Critical: UModel::Serialize
Critical: TestReach
Critical: (Model MH-AS_ColdSteel_Rv.Model1)
Critical: ULevel::Serialize
Critical: TestReach
Critical: (Level MH-AS_ColdSteel_Rv.MyLevel)
Critical: UStruct::SerializeBin
Critical: (Class Botpack.ThighPads XLevel[0])
Critical: UObject::Serialize
Critical: (ThighPads MH-AS_ColdSteel_Rv.ThighPads0)
Critical: AActor::Serialize
Critical: TestReach
Critical: (ThighPads MH-AS_ColdSteel_Rv.ThighPads0)
Critical: UStruct::SerializeBin
Critical: (Class Engine.InventorySpot markedItem[0])
Critical: UObject::Serialize
Critical: (InventorySpot MH-AS_ColdSteel_Rv.InventorySpot971)
Critical: AActor::Serialize
Critical: TestReach
Critical: (InventorySpot MH-AS_ColdSteel_Rv.InventorySpot971)
Critical: UStruct::SerializeBin
Critical: (Class UnrealShare.Spawnpoint VisNoReachPaths[0])
Critical: UObject::Serialize
Critical: (Spawnpoint MH-AS_ColdSteel_Rv.Spawnpoint17)
Critical: AActor::Serialize
Critical: TestReach
Critical: (Spawnpoint MH-AS_ColdSteel_Rv.Spawnpoint17)
Critical: UStruct::SerializeBin
Critical: (Class UnrealShare.Spawnpoint VisNoReachPaths[0])
Critical: UObject::Serialize
Critical: (Spawnpoint MH-AS_ColdSteel_Rv.Spawnpoint18)
Critical: AActor::Serialize
Critical: TestReach
Critical: (Spawnpoint MH-AS_ColdSteel_Rv.Spawnpoint18)
Critical: UStruct::SerializeBin
Critical: (Class Engine.PathNode VisNoReachPaths[0])
Critical: UObject::Serialize
Critical: (PathNode MH-AS_ColdSteel_Rv.PathNode283)
Critical: AActor::Serialize
Critical: TestReach
Critical: (PathNode MH-AS_ColdSteel_Rv.PathNode283)
Critical: UStruct::SerializeBin
Critical: (Class Engine.PathNode nextNavigationPoint[0])
Critical: UObject::Serialize
Critical: (PathNode MH-AS_ColdSteel_Rv.PathNode284)
Critical: AActor::Serialize
Critical: TestReach
Critical: (PathNode MH-AS_ColdSteel_Rv.PathNode284)
Critical: UStruct::SerializeBin
Critical: (Class Engine.PathNode nextNavigationPoint[0])
Critical: UObject::Serialize
Critical: (PathNode MH-AS_ColdSteel_Rv.PathNode285)
Critical: AActor::Serialize
Critical: TestReach
Critical: (PathNode MH-AS_ColdSteel_Rv.PathNode285)
Critical: UStruct::SerializeBin
Critical: (Class Engine.PathNode nextNavigationPoint[0])
Critical: UObject::Serialize
Critical: (PathNode MH-AS_ColdSteel_Rv.PathNode9)
Critical: AActor::Serialize
Critical: TestReach
Critical: (PathNode MH-AS_ColdSteel_Rv.PathNode9)
Critical: UStruct::SerializeBin
Critical: (Class MonsterHunt.MonsterWaypoint MyPoint[0])
Critical: UObject::Serialize
Critical: (MonsterWaypoint MH-AS_ColdSteel_Rv.MonsterWaypoint1)
Critical: AActor::Serialize
Critical: TestReach
Critical: (MonsterWaypoint MH-AS_ColdSteel_Rv.MonsterWaypoint1)
Critical: UStruct::SerializeBin
Critical: (Class MonsterHunt.MonsterHunt MHTarget[0])
Critical: UObject::Serialize
Critical: (MonsterHunt MH-AS_ColdSteel_Rv.MonsterHunt0)
Critical: AActor::Serialize
Critical: TestReach
Critical: (MonsterHunt MH-AS_ColdSteel_Rv.MonsterHunt0)
Critical: UStruct::SerializeBin
Critical: (Class Engine.LevelInfo Game[0])
Critical: UObject::Serialize
Critical: (LevelInfo MH-AS_ColdSteel_Rv.LevelInfo0)
Critical: AActor::Serialize
Critical: TestReach
Critical: (LevelInfo MH-AS_ColdSteel_Rv.LevelInfo0)
Critical: UStruct::SerializeBin
Critical: (Class XC_Engine.XC_ServerActor Level[0])
Critical: UObject::Serialize
Critical: (XC_ServerActor MH-AS_ColdSteel_Rv.XC_ServerActor0)
Critical: AActor::Serialize
Critical: TestReach
Critical: (XC_ServerActor MH-AS_ColdSteel_Rv.XC_ServerActor0)
Critical: UStruct::SerializeBin
Critical: (Class XC_Engine.XC_GameEngine AdminLoginHook[0])
Critical: UObject::Serialize
Critical: (XC_GameEngine Transient.XC_GameEngine0)
Critical: UGameEngine::Serialize
Critical: (XC_GameEngine Transient.XC_GameEngine0)
Critical: UGameEngine::Serialize
Critical: (XC_GameEngine Transient.XC_GameEngine0)
Critical: UXC_GameEngine::Serialize
Critical: TestReach
Critical: (XC_GameEngine Transient.XC_GameEngine0)
Critical: TArray<<
Critical: UObject::SerializeRootSet
Critical: UObject::CollectGarbage
Critical: UObject::StaticExec
Critical: UEngine::Exec
Critical: UGameEngine::Exec
Critical: UXC_GameEngine::Exec
Critical: UObject::execConsoleCommand
Critical: ScriptDebugV
Critical: Garb0.ConsoleCommand
Critical: ScriptDebugV
Critical: Garb0.DoPurgeGarbage
Critical: UObject::ProcessEvent
Critical: (Garb MH-AS_ColdSteel_Rv.Garb0, Function Garb.Garb.Timer)
Critical: AActor::Tick
Critical: TickAllActors
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: UServerCommandlet::Main
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.

What was happening at TestReach ? It wasn't me...

[Higor]

Did you destroy the XC_ServerActor?
Otherwise memory was lost...


EDIT:
That 'model' is the level's BSP construction that for some reason failed to give out a proper name/object id to the garbage collector.
Likely a memory corruption issue.

[sektor2111]

I gotta do multiple checks to gain details.
What to say... It is not the best ever map (some "original" portation had PathNode in wall and some spots with None).

I was running that evilized LightningTw_3 (which I changed right now using an ugly compilation this time). Now I have "sheduled" a destruction after all WhateverBeginPlay things more properly, simulated for client too, using LifeSpan and letting Engine to handle it as it wants.
Looks like in other ambience the older LightningTw_3 was causing bad things visual related. Server without visuals perhaps has been screwed in other way but still bad results, and then, Garbage Collector applied fatality. I'm gonna check V4 abnormally compiled with programmed destruction... First checks looks well (I have operated manually a garbage removal and it did not crashed).

I think now I have a true confirmation about destruction in PostBeginPlay and before. It badly screws Actors/Objects array - conclusion: Destroy Actors ONLY after at least 1 second and never when game still initializes, that's the deal with this engine. So BiterFish by example is a bad thing... or it's OK when it destroy by itself and not from "outside".

[Higor]

Mmmhh, you actually want to destroy actors before they initialize and call PostBeginPlay()
What's the problem?

[sektor2111]

I cannot say because I don't know engine's internals but is not the first time when it was crashing at an early actor destruction in Levels a bit loaded... I even recall something from oldskool's codes - a remark saying "no risk destroying". What's that risk then ?
Okay memory back up. See a map with many BlockMonsters. In contact with some... monsters ? Kitarra ? Destroy all BlockMonsters, might have a crash party 40% 50% ? Happened a lot until I took measures Disable them only and/or fall them away... Was causing an issue Actor->This not other is -> .... something like that. Including a fast player destruction sometimes leads in the same crash... see an earlier post...

[sektor2111]

Bump
In hoping to not mistake I drew a conclusion - toward compiling forced and messing with constants forced screwed. I think it's causing troubles which you cannot predict. I have simply recompiled MH2 a bunch of times because I saw things suddenly NON-Functional and which were working in previous compilations. Using ConsoleCommand and different deals, and compiling normally things, everything was working properly. I won't use anything which screws constants, if compiler doesn't compiling mods attacking constant must be a reason to not mess things up. Else I'm not surprised about "memory corruptions" - FALSE, if OS did not said anything EVER, then UT is lying - it screws itself when a dumb strategy is being used.
At least I have learned a nasty lesson. That crash belongs to me, I have screwed actors list by deleting stuff bNoDelete using brute force not a normal compilation. Results were showing up shortly... it won't happen again.

[Higor]

Well, the entire object/actor system in UE was designed for memory-related safety.
Think of Unreal 1:
- Menus exist in level.
- The transient package is barely used for the main subsystems.
- The subsystems' references are controlled and they can be destroyed/replaced during runtime.
- The name system was designed to never cause segmentation faults (and to allow game saving).
- Entry level doesn't tick.
- Deleted actors being flushed out of memory in batches, other actors have their references nulled out during that process.
- bStatic and bNoDelete actors are trated differently internally.
- Objects never manually deleted, except mainly for channels and connections where they cannot be referenced via script or elsewhere.

An obvious set of guidelines was used here, but when you look at UT some things are different:
- Main renderer cannot be destroyed due to some change in the reference system (can console be replaced as well?)
- Menus exist in transient package, the UWindow system opens up the can of worms of dangerous references.
- Entry ticks and therefore, opens up the possibility of running code on it, causing more dangerous references.

Deleting a bStatic actor outside of level initialization will permanently leave an empty actor list slot.
Setting bStatic=False on a bStatic actor won't make it visible to iterators that run exclusively on dynamic actors.
bNoDelete and bStatic actors won't use 'by-channel' net serialization but instead 'by-package' one, basically they're treated the same as textures and other resources.
Therefore, adding the bNoDelete or bStatic flag to a net relevant actor will make it impossible to send to clients, lucky for us there's no crash directive.

Ideally all you want to do is lock a server-only actor with the bNoDelete flag when you ABSOLUTELY NEED the actor to remain in the game.
One case: XC_Engine's AdminLoginHook actor will cause a crash if destroyed, and I have to prevent that on next version, so locking it with bNoDelete is an ideal solution.

==========
EDIT:
I may have found a way to fix up some bad sliding players issues.
Basically, we move all UTX files on the package map list to the last slots.
So if one UTX package has a bad generation (dataripped vs s3tc) then there won't be massive replication issues.

[MrLoathsome]

This thread just gets more interesting all the time.

Re: The ST3C textures replication issue.

So this method would solve the sliding players nonsense for both any 3rd party
ST3C textures that might be causing issues as well as fixing it on server installs
where the admin is confused and installed the "default" bonus pack ST3C textures?

------------

I have a question that is related to garbage collection and destroying things.
This is not directly related to XCGE, but seems related to a number of recent posts in this
thread. (Maybe..... )

For one of my recent projects, which I hope will work with XCGE, I have been making attempts to
avoid just destroying actors. Instead, I have just been setting a very short lifespan for them.

Been trying to code in a way that works with the core engine, rather than fighting it.
Seems this way, my code can assume the actor is gone, and the engine can purge it out when it wants.
Sometimes the actor lingers on the level for a few moments longer than it would if I just destroy it outright, but
this just seems better.

Any thoughts on that?

[Higor]

LifeSpan is a destruction timer.
It doesn't matter whether you destroy manually or let a timer handle it, it's still actor destruction.
BTW, actors are indeed cleaned up from memory so EVERY time you destroy an actor, make sure it's not referenced outside of the level (menu, entry).
The actor cleanup routine clears bad references inside the level but not outside of it.

Also, when it says: 'Destruction is latent, it waits until the remainder of the tick'
It means: When there's 256 destroyed actors in queue, they're all batch-deallocated at the end of level tick.

So, destroying 256 actors at once, or destroying one every frame for 256 frames has the same effect in the memory deallocator.


==========================
The problem with S3TC is very simple, a wise crack didn't properly datarip the packages, so one of the dataripped packages (NOT GONNA FIND OUT WHICH) has an incorrect number of exports and therefore, creates a bad net table.
The net table is progressive and unique per-player, meaning:
- The packagemap (as in packages, and element count) varies per player, this allows multiple version clients to understand the server.
- If package A has 120 elements [0-119], all of package B's elements will start on index 120 and so on, meaning that a bad package in the middle screws up the entire package list from there on.

So, i'm not going to attack it on version yet... but I'll do it on ordering.
By moving the texture packages to the last, all of the code/audio/music packages will be first and therefore, unaffected by badly dataripped texture packages.


So we'd be turning this:

Spoiler

DevNet: PendingLevel received: USES GUID=26DE69D44CE2B4F642F8E1B87DF72119 PKG=CTF-SGRestart_v1 FLAGS=1 SIZE=448871 GEN=1 FNAME=CTF-SGRestart_v1.unr
DevNet: PendingLevel received: USES GUID=1E90ACC711D1ED664544279700005453 PKG=Skaarj FLAGS=1 SIZE=57890 GEN=2 FNAME=Skaarj.utx
DevNet: PendingLevel received: USES GUID=D18A7B9211D38F04100067B9F6F8975A PKG=Engine FLAGS=1 SIZE=1149858 GEN=17 FNAME=Engine.u
DevNet: PendingLevel received: USES GUID=4770B88411D38E3E100067B9F6F8975A PKG=Core FLAGS=1 SIZE=59233 GEN=10 FNAME=Core.u
DevNet: PendingLevel received: USES GUID=1E90ACA811D1ED664544279700005453 PKG=Detail FLAGS=1 SIZE=22575 GEN=2 FNAME=Detail.utx
DevNet: PendingLevel received: USES GUID=4770B88811D38E3E100067B9F6F8975A PKG=Fire FLAGS=1 SIZE=15248 GEN=10 FNAME=Fire.u
DevNet: PendingLevel received: USES GUID=1E90ACAF11D1ED664544279700005453 PKG=GenFX FLAGS=1 SIZE=131061 GEN=2 FNAME=GenFX.utx
DevNet: PendingLevel received: USES GUID=1E90ACCF11D1ED664544279700005453 PKG=xfx FLAGS=1 SIZE=23579 GEN=2 FNAME=XFX.utx
DevNet: PendingLevel received: USES GUID=C47BBD4011D38CFBC00084B50A1E604F PKG=DecayedS FLAGS=1 SIZE=55284 GEN=3 FNAME=DecayedS.utx
DevNet: PendingLevel received: USES GUID=1E90ACC111D1ED664544279700005453 PKG=Palettes FLAGS=1 SIZE=92697 GEN=2 FNAME=Palettes.utx
DevNet: PendingLevel received: USES GUID=1E90ACAE11D1ED664544279700005453 PKG=genfluid FLAGS=1 SIZE=104123 GEN=2 FNAME=GenFluid.utx
DevNet: PendingLevel received: USES GUID=4770B88C11D38E3E100067B9F6F8975A PKG=UnrealShare FLAGS=1 SIZE=22124694 GEN=1 FNAME=UnrealShare.u
DevNet: PendingLevel received: USES GUID=A3B94EE411D1ED674544E58A00005453 PKG=Ambmodern FLAGS=1 SIZE=4638 GEN=2 FNAME=AmbModern.uax
DevNet: PendingLevel received: USES GUID=4770B88D11D38E3E100067B9F6F8975A PKG=UnrealI FLAGS=1 SIZE=18549361 GEN=1 FNAME=UnrealI.u
DevNet: PendingLevel received: USES GUID=1C69657611D38F44100067B9F6F8975A PKG=Botpack FLAGS=1 SIZE=39016791 GEN=14 FNAME=BotPack.u
DevNet: PendingLevel received: USES GUID=A3B94EE811D1ED674544E58A00005453 PKG=Doorsmod FLAGS=1 SIZE=2413 GEN=2 FNAME=DoorsMod.uax
DevNet: PendingLevel received: USES GUID=1942A47C11D1ED664544A4BF00005453 PKG=unreal4 FLAGS=1 SIZE=939568 GEN=1 FNAME=Unreal4.umx
DevNet: PendingLevel received: USES GUID=93CC0A8111D3888FE0006295BE341081 PKG=SoldierSkins FLAGS=1 SIZE=102233 GEN=3 FNAME=Soldierskins.utx
DevNet: PendingLevel received: USES GUID=86A1D119408C6873A5F66CB4E2D5F703 PKG=SoldierSkins_XC_ FLAGS=1 SIZE=1814938 GEN=1 FNAME=SoldierSkins_XC_.utx
DevNet: PendingLevel received: USES GUID=E96BC96311D31D2F4F006B8CDE9A0349 PKG=CommandoSkins FLAGS=1 SIZE=67630 GEN=3 FNAME=CommandoSkins.utx
DevNet: PendingLevel received: USES GUID=B7B49CA611D38BCDE0006395BE341081 PKG=FCommandoSkins FLAGS=1 SIZE=82636 GEN=3 FNAME=FCommandoSkins.utx
DevNet: PendingLevel received: USES GUID=D4F6ABE111D385CAE0006295BE341081 PKG=SGirlSkins FLAGS=1 SIZE=117139 GEN=3 FNAME=SGirlSkins.utx
DevNet: PendingLevel received: USES GUID=24E5A72411D321104F006B8CDE9A0349 PKG=BossSkins FLAGS=1 SIZE=25774 GEN=3 FNAME=BossSkins.utx
DevNet: PendingLevel received: USES GUID=EAA28E794A3CD893E6F93FBA8C9A5510 PKG=NexgenCC FLAGS=1 SIZE=19394 GEN=1 FNAME=NexgenCC.u
DevNet: PendingLevel received: USES GUID=944205774B038989EFC5B58033549969 PKG=Nexgen112N FLAGS=1 SIZE=1698534 GEN=1 FNAME=Nexgen112N.u
DevNet: PendingLevel received: USES GUID=0763F2A147AB5C3F315A29B171A05B41 PKG=NexgenClientsideExtensions112NMHA FLAGS=1 SIZE=7036 GEN=1 FNAME=NexgenClientsideExtensions112NMHA.u
DevNet: PendingLevel received: USES GUID=2F33FCED4824B3F594DAF9B181D736DB PKG=NexgenPlus100N FLAGS=1 SIZE=579893 GEN=1 FNAME=NexgenPlus100N.u
DevNet: PendingLevel received: USES GUID=90D5ECA011D41DD7A00096B8257D044B PKG=BsodPackage FLAGS=1 SIZE=1520016 GEN=1 FNAME=BsodPackage.u
DevNet: PendingLevel received: USES GUID=EC4F2D9943A301112FA47BB605E188CB PKG=SiegeIV_0025 FLAGS=1 SIZE=2987127 GEN=1 FNAME=SiegeIV_0025.u
DevNet: PendingLevel received: USES GUID=627DAB834FAC01EBC5E278B4CB181480 PKG=sgUMedia FLAGS=1 SIZE=11184062 GEN=1 FNAME=sgUMedia.u
DevNet: PendingLevel received: USES GUID=517A7E0411D6B1FEE00098A02FA07B7D PKG=sgMedia FLAGS=1 SIZE=1366827 GEN=1 FNAME=sgMedia.u
DevNet: PendingLevel received: USES GUID=84DC68E448DAC3E9D38C6F9AF2949CC1 PKG=sgMedia2 FLAGS=1 SIZE=267187 GEN=1 FNAME=sgMedia2.u
DevNet: PendingLevel received: USES GUID=A3B94EE911D1ED674544E58A00005453 PKG=Extro FLAGS=1 SIZE=441 GEN=2 FNAME=Extro.uax
DevNet: PendingLevel received: USES GUID=9E4BDC8211D2B3904F007391ED2A004C PKG=DDay FLAGS=1 SIZE=820 GEN=2 FNAME=DDay.uax
DevNet: PendingLevel received: USES GUID=E10A72964718B5B1E08B409D4587C332 PKG=MVLA14UUb13C FLAGS=1 SIZE=99469 GEN=1 FNAME=MVLA14UUb13C.u
DevNet: PendingLevel received: USES GUID=7B29417A495AE03C3F5BCB8B41942FA5 PKG=LCWeapons_0017 FLAGS=1 SIZE=454260 GEN=1 FNAME=LCWeapons_0017.u
DevNet: PendingLevel received: USES GUID=6B89283B4B86C0DB9C57EEB0FA46361E PKG=FV_ColorShock FLAGS=1 SIZE=1709216 GEN=1 FNAME=FV_ColorShock.utx
DevNet: PendingLevel received: USES GUID=D597F03642F344F81443799725B18149 PKG=XC_Spec_r9 FLAGS=1 SIZE=68172 GEN=1 FNAME=XC_Spec_r9.u
DevNet: PendingLevel received: USES GUID=FBAC20AC4352B8D2D2EA309CC7C20320 PKG=CacusBetas0008 FLAGS=1 SIZE=366541 GEN=1 FNAME=CacusBetas0008.u

Into this:

Spoiler

DevNet: PendingLevel received: USES GUID=26DE69D44CE2B4F642F8E1B87DF72119 PKG=CTF-SGRestart_v1 FLAGS=1 SIZE=448871 GEN=1 FNAME=CTF-SGRestart_v1.unr
DevNet: PendingLevel received: USES GUID=D18A7B9211D38F04100067B9F6F8975A PKG=Engine FLAGS=1 SIZE=1149858 GEN=17 FNAME=Engine.u
DevNet: PendingLevel received: USES GUID=4770B88411D38E3E100067B9F6F8975A PKG=Core FLAGS=1 SIZE=59233 GEN=10 FNAME=Core.u
DevNet: PendingLevel received: USES GUID=4770B88811D38E3E100067B9F6F8975A PKG=Fire FLAGS=1 SIZE=15248 GEN=10 FNAME=Fire.u
DevNet: PendingLevel received: USES GUID=4770B88C11D38E3E100067B9F6F8975A PKG=UnrealShare FLAGS=1 SIZE=22124694 GEN=1 FNAME=UnrealShare.u
DevNet: PendingLevel received: USES GUID=A3B94EE411D1ED674544E58A00005453 PKG=Ambmodern FLAGS=1 SIZE=4638 GEN=2 FNAME=AmbModern.uax
DevNet: PendingLevel received: USES GUID=4770B88D11D38E3E100067B9F6F8975A PKG=UnrealI FLAGS=1 SIZE=18549361 GEN=1 FNAME=UnrealI.u
DevNet: PendingLevel received: USES GUID=1C69657611D38F44100067B9F6F8975A PKG=Botpack FLAGS=1 SIZE=39016791 GEN=14 FNAME=BotPack.u
DevNet: PendingLevel received: USES GUID=A3B94EE811D1ED674544E58A00005453 PKG=Doorsmod FLAGS=1 SIZE=2413 GEN=2 FNAME=DoorsMod.uax
DevNet: PendingLevel received: USES GUID=1942A47C11D1ED664544A4BF00005453 PKG=unreal4 FLAGS=1 SIZE=939568 GEN=1 FNAME=Unreal4.umx
DevNet: PendingLevel received: USES GUID=EAA28E794A3CD893E6F93FBA8C9A5510 PKG=NexgenCC FLAGS=1 SIZE=19394 GEN=1 FNAME=NexgenCC.u
DevNet: PendingLevel received: USES GUID=944205774B038989EFC5B58033549969 PKG=Nexgen112N FLAGS=1 SIZE=1698534 GEN=1 FNAME=Nexgen112N.u
DevNet: PendingLevel received: USES GUID=0763F2A147AB5C3F315A29B171A05B41 PKG=NexgenClientsideExtensions112NMHA FLAGS=1 SIZE=7036 GEN=1 FNAME=NexgenClientsideExtensions112NMHA.u
DevNet: PendingLevel received: USES GUID=2F33FCED4824B3F594DAF9B181D736DB PKG=NexgenPlus100N FLAGS=1 SIZE=579893 GEN=1 FNAME=NexgenPlus100N.u
DevNet: PendingLevel received: USES GUID=90D5ECA011D41DD7A00096B8257D044B PKG=BsodPackage FLAGS=1 SIZE=1520016 GEN=1 FNAME=BsodPackage.u
DevNet: PendingLevel received: USES GUID=EC4F2D9943A301112FA47BB605E188CB PKG=SiegeIV_0025 FLAGS=1 SIZE=2987127 GEN=1 FNAME=SiegeIV_0025.u
DevNet: PendingLevel received: USES GUID=627DAB834FAC01EBC5E278B4CB181480 PKG=sgUMedia FLAGS=1 SIZE=11184062 GEN=1 FNAME=sgUMedia.u
DevNet: PendingLevel received: USES GUID=517A7E0411D6B1FEE00098A02FA07B7D PKG=sgMedia FLAGS=1 SIZE=1366827 GEN=1 FNAME=sgMedia.u
DevNet: PendingLevel received: USES GUID=84DC68E448DAC3E9D38C6F9AF2949CC1 PKG=sgMedia2 FLAGS=1 SIZE=267187 GEN=1 FNAME=sgMedia2.u
DevNet: PendingLevel received: USES GUID=A3B94EE911D1ED674544E58A00005453 PKG=Extro FLAGS=1 SIZE=441 GEN=2 FNAME=Extro.uax
DevNet: PendingLevel received: USES GUID=9E4BDC8211D2B3904F007391ED2A004C PKG=DDay FLAGS=1 SIZE=820 GEN=2 FNAME=DDay.uax
DevNet: PendingLevel received: USES GUID=E10A72964718B5B1E08B409D4587C332 PKG=MVLA14UUb13C FLAGS=1 SIZE=99469 GEN=1 FNAME=MVLA14UUb13C.u
DevNet: PendingLevel received: USES GUID=7B29417A495AE03C3F5BCB8B41942FA5 PKG=LCWeapons_0017 FLAGS=1 SIZE=454260 GEN=1 FNAME=LCWeapons_0017.u
DevNet: PendingLevel received: USES GUID=6B89283B4B86C0DB9C57EEB0FA46361E PKG=FV_ColorShock FLAGS=1 SIZE=1709216 GEN=1 FNAME=FV_ColorShock.utx
DevNet: PendingLevel received: USES GUID=D597F03642F344F81443799725B18149 PKG=XC_Spec_r9 FLAGS=1 SIZE=68172 GEN=1 FNAME=XC_Spec_r9.u
DevNet: PendingLevel received: USES GUID=FBAC20AC4352B8D2D2EA309CC7C20320 PKG=CacusBetas0008 FLAGS=1 SIZE=366541 GEN=1 FNAME=CacusBetas0008.u
DevNet: PendingLevel received: USES GUID=1E90ACC711D1ED664544279700005453 PKG=Skaarj FLAGS=1 SIZE=57890 GEN=2 FNAME=Skaarj.utx
DevNet: PendingLevel received: USES GUID=1E90ACA811D1ED664544279700005453 PKG=Detail FLAGS=1 SIZE=22575 GEN=2 FNAME=Detail.utx
DevNet: PendingLevel received: USES GUID=1E90ACAF11D1ED664544279700005453 PKG=GenFX FLAGS=1 SIZE=131061 GEN=2 FNAME=GenFX.utx
DevNet: PendingLevel received: USES GUID=1E90ACCF11D1ED664544279700005453 PKG=xfx FLAGS=1 SIZE=23579 GEN=2 FNAME=XFX.utx
DevNet: PendingLevel received: USES GUID=C47BBD4011D38CFBC00084B50A1E604F PKG=DecayedS FLAGS=1 SIZE=55284 GEN=3 FNAME=DecayedS.utx
DevNet: PendingLevel received: USES GUID=1E90ACC111D1ED664544279700005453 PKG=Palettes FLAGS=1 SIZE=92697 GEN=2 FNAME=Palettes.utx
DevNet: PendingLevel received: USES GUID=1E90ACAE11D1ED664544279700005453 PKG=genfluid FLAGS=1 SIZE=104123 GEN=2 FNAME=GenFluid.utx
DevNet: PendingLevel received: USES GUID=93CC0A8111D3888FE0006295BE341081 PKG=SoldierSkins FLAGS=1 SIZE=102233 GEN=3 FNAME=Soldierskins.utx
DevNet: PendingLevel received: USES GUID=86A1D119408C6873A5F66CB4E2D5F703 PKG=SoldierSkins_XC_ FLAGS=1 SIZE=1814938 GEN=1 FNAME=SoldierSkins_XC_.utx
DevNet: PendingLevel received: USES GUID=E96BC96311D31D2F4F006B8CDE9A0349 PKG=CommandoSkins FLAGS=1 SIZE=67630 GEN=3 FNAME=CommandoSkins.utx
DevNet: PendingLevel received: USES GUID=B7B49CA611D38BCDE0006395BE341081 PKG=FCommandoSkins FLAGS=1 SIZE=82636 GEN=3 FNAME=FCommandoSkins.utx
DevNet: PendingLevel received: USES GUID=D4F6ABE111D385CAE0006295BE341081 PKG=SGirlSkins FLAGS=1 SIZE=117139 GEN=3 FNAME=SGirlSkins.utx
DevNet: PendingLevel received: USES GUID=24E5A72411D321104F006B8CDE9A0349 PKG=BossSkins FLAGS=1 SIZE=25774 GEN=3 FNAME=BossSkins.utx

But more could be done, in this case the player skins would get messed up because they come after the map textures.
So one possible way to do this is to reverse the UTX file order, could work, could be a disaster.

[MrLoathsome]

Re: Lifespan.

If I understand you right setting a very low lifespan is probably the best option in cases such as a mutator processing things slowly
on a timer.

But destroy() would be better for something happening at tickrate speeds. (effects, pawn state code, weapons etc...)

Does it even matter? Any performance difference? Am I wasting time doing that different?

Re: ST3C.

If I read that correctly what I have been saying since the very first time this ever happened on my servers is the right answer.
(Which was a LONG LONG time ago....)

Don't put ST3C textures on your server.
(If they happen to reappear after moving the server to a different OS or something stupid like that, replace the damn textures..... )

I am certainly not placing an "order" for a ST3C textures fix. Don't waste your time on that.
Put a line in the readme telling server admins not to be stupid.

[sektor2111]

I don't have well terms for explanations. Why I was oriented to LifeSpan. I think on a slower machine, processing PostBeginPlay and all starting crap takes many resources. Then I destroy an actor while engine still interates through them ? I believe will screw up iterator and I'm not sure if won't ruin array. So by using LifeSpan iterator works with NO Destruction operated, but it shedules a later destruction (... or depends on how many are ignited to removal like that).
Old case was setting up bDeleteMe for BlockMonsters - bad consequences. You have suggested to use the traditional "Destroy()" - oh well, I used that ugly shit because destroy was doing sucks TOO. That Map is huge - a lot of actors and finally has some transient content inside (screen craps), then NULL animations running, all these together made a proper crash. That object type confusion I found when I used a tool to reject player with a name containing characters which I don't like. Destroying player traditionally using Destroy only was doing the same crap. I have changed player deal with your XC recommendations so problem of a kick is now improved, But still attacking bad actors and operating a bNodelete removal was causing ugly as crap consequences and I won't ever forget those words "Do not risk destroying". Probably on a powerful machine these will work due to execution speed (between ticks being more free time or such) but I could figure these corruptions by compiling UNUSUAL, YES, Barbie, I hope you don't have memory corruptions in your Linux by assigning constants - LOOL, you have (already mentioned in CONS problems at "Good MonsterHunt" thread) previously said somewhere (cannot recall thread) compiled with "Brain-08.15".
https://www.ut99.org/viewtopic.php?f=15&t=6600#p77905
Good luck with such compilations sooner or later they get a revenge and perhaps that "Brain-08.15" is another useless thing as that decompiler generating a trash never compilable back.
So what do we have ? Core's properties things, ConsoleCommand, Lifespan for delay a job - get over "Begin" things, perhaps enough to no more mess with compiling stupidly. Everything has started for me trying to solve SuperWebAdmin's stupid pawnlist issues - looks nasty to deal with that - it does the same compiling errors: "Can't assign constants" - Now I know what I have to do: DELETE SUCH THINGS - aside, Good luck with maps "protected" mooing with constants, you won't find any of them in my yard.
My trash AIBreak works but I see some... "changes" - mutate command seems to get stuck which is another bad sign predicting a crash, never mind I'll fix it another time compiling it normally and without to remove PathNodes.
___
Chapter noob insanity.
I believe that in high loaded Levels with an insane number of actors things are hard to be managed. Running actor internal timers for long time (Lifespan of a deco, Movers, all shit) leads in unpredictable crashes too as long I feel some miss-executions which have only 2 consequences: Level Broken, Level Crash.
I could see 2 stupid SteelBoxes somewhere being set with a default LifeSpan 1000000 or such retarded idea. Oh well, a dumb-ass won't ever have a cure. Why the heck do we need to count those stupid things running another 2 clocks and consuming CPU for an ass ? Who keeps that thing loaded so much ? We speak about 10-11 days or less depending on time factors. Only a fool will keep server loaded with the same map for 5 days - some of them are crashing if you run them too long - generators and such.
___