Let me tell a story trying to explain much shorter as possible.
Imagine two bugs: Bug A and B. In original format Bug A could not be very visible being bugged by B which also suffered from Bug A - things were working here. When one of them is solved, the other one shows up doing sudden reactions which nobody was expecting. As result if you don't have solved both bugs, things are getting ugly.
This is why I mentioned repeatedly that a fix should come with a "fallback" option added in a configuration INI file. Here I rewrote XC extensions with more Values in INI file that can be disabled/enabled. In other hand if a fix has benefits for 300 maps but damaging 10 maps, those 10 maps will need a separate deal. Values that can be changed are subject for some patch files - it's why NavAdder has been born. Some maps were using a similar string Event Tag for certain actor
- n00b cube drawer doesn't know a damn thing about how "triggering" works - and later map is happily ported "edited" elsewhere at once with original bugs - creating a duplicated garbage. I even found on YouTube a so called Tutorial about Triggered Movers which was delivering FALSE things and I reported it.
Another sample is that with PlayerStart finding. Since UT did not used some of those lousy things, by using XC stuff all PlayerStarts are now available dropping players away. New code in Finding PlayerStarts has no sanity check if these are really usable, returning new bugs which weren't there before. As you can see, the bugged original function did not do damage related to some lousy bugged PlayerStarts placed into void. By solving issue and bringing more spawn options, the second bug was entering in stage and annoying player. This was the reason for doing XC_SpawnFixer actor delegated to throw away these useless junks - as reward to my fix, in server has been fired a storm about voting the same maps - those lousy maps. It was only a normal reaction as long as players could no use such maps elsewhere because they were garbage - but administration went angry. And this was the stage when I decided to longer fix anything.
For Movers, investigations concerning events need to be done in two ways: #1 Looking what map is using and if setup is normal, #2 Editing "the XC fix" with other two options: #2.1 Adding another condition somewhere #2.2 Re-Configuring the fix condition -> In a fix can be multiple factors that need to be in account.
All XC operations must be configurable via INI file and NOT Hard-Coded. Hard-Coding fixes demonstrated not a single time as being a way no go.
Certain code which I see at EventChain previously was making me to look more time at that line. I could see later a crash-log somewhere here in forum related to a Mover which was never there - map was having ZERO movers - but the crash looks done by some "Assert" type stuff which to me was somehow 50% Great and 50% Hazard - you don't know if mapper was using a "LiftTrigger" or an useless event which is pointing nowhere - it was all about "guess" type mapping and not the "how to" type mapping. But... I cannot say more because I'm not an I.T. expert coder and then I want to minimize potential fake stories, I'm trying to stay in reality. For my DM matches a larger number of fixes were automated when I decided to add a very small delay at Movers - perhaps for BT Movers there could be simple things operated as default in similar format doing an unexpected improvement of the stage.
didn't work for me. I also tried to disable brush tracker completely and still not dice. If you think of anything else please let me know
and map looks identical with original minus 7 MB flushed out. Now I'm probing it for game-flow issues and perhaps I'll drop out an edit letting everyone to figure my points toward such an edit.