Engine Feature needed: RunOnMapChange #2
Description
One of the central parts since the inception of the Community Edition code refactor is the new game loop that controls several core features and monitors the current map the player is on at any moment, which then triggers its own "OnMapChange" logic whenever a teleport has been detected.
This was a neccessary new feature for the revised "Loot" system: Every loot event has two pages: The first one is a parallel process that calls a CE for its loot type and the second page is a normal event that can be activated by the user.
There's a short "Wait" command in OnMapChange that is used to let these parallel processes run for a moment and set the "TESTED" flag right after. These CommonEvents register information about the loot events in Variable ranges way above anything most developers are using and also implement a sort of "SelfSwitch".
This was fine until recently and had little side effects (Some minor visual glitches whenever no proper fade-out/fade-in was done before and after a teleport -- Nothing game-breaking!).
After implementing the revised Troop system, which uses the same approach to register up to 30 Troop-events per map, the caveats of this pattern became very noticable, very quickly:
- There is no guarantee, that the OnMapChange event is triggered before any other AutoRun or ParallelProcess logic
- This results in the troop states "bleeding" over to the next map, which, because of the way the Troop-Controller is relying on calling Map events, causes many unintentional side effects.
- Often this leads to the game randomly freezing
Because of this, the games code has been refactored to include an AutoRun event on every map, that then deletes itself after it is executed. It only executes "OnMapChange" manually before erasing itself. Also, the Troop-Controller startup is delayed by a few frames to stop it right away on entering the map and let nothing "bleed" over.
This breaks one of the core design philosophies: To implement the game logic in a way, so that code duplication is minimized and no special tools (Code generation scripts) would be required. The main idea is to make modding of this game as easy as possible.
With this approach, it is very easy to "miss" some required procedures when creating any new content and create bugs that would be very hard to debug for any inexperienced designers.
To re-achieve this goal, a new feature would be required for the engine:
- A process type that is run excactly once when a map is loaded AND is guaranteed to run before any other ParallelProcess or AutoRun.