Eliminate all static variables and methods

[VictorPhilipp]

As a developer I want my application to be hot-swappable to allow for a faster development time.

Assumptions/Preconditions

• Static variables and methods prevent the mod from being modified and updated while the game is running: C:S cannot fully unload old instances.
• Other features relevant for hot-swappability, like loading/saving custom data or deployment/removal of method detours are triggered at specific OnLoad/OnUnload events.

Tasks

• Remove as many static fields/methods as possible. Convert them into instance-level members.
• If not everything can be converted, collect remaining members and put them at a central place.
• Extend OnLoad/OnUnload event handlers such they take care that any remaining static members are unset/set.
• Check if the mod can be hot-swapped. If any further problems arise that were not foreseen create an issue on GitHub.

Acceptance criteria

• Static members are gone, except for a limited amount
  • Remaining static members are instantiated/invalidated at mod loading/unloading time
• Mod functionality remains unchanged
• Mod loading/unloading still works

[originalfoo]

As a novice learning C#, may I ask why? (it will be useful knowledge of a mod I'm writing).

[originalfoo]

Also, could we get a linter (or whatever) set up to help us with this task?

[FireController1847]

I don't see the purpose in this. There's always a need every once in a while for a static variable and/or method. Just look in Colossal Order's code; They use them often for things that don't require an instance.

[originalfoo]

Ah, I think I get it - if user has 2 copies of TMPE installed (eg. Labs and Stable, or one of those and local build, or one of those and pcfantasy mods that replicate chunks of TMPE), it's all using the same namespaces so the static stuff from one is overwriting that of the other?

[VictorPhilipp]

@aubergine10 Exactly, issue #210 proofs that C:S is unable to handle multiple mod instances correctly regarding static variables/methods. The second instance of TMPE (the one from the AJR mod) tries to access a static variable (Options.turnOnRed) that is present in AJR's TMPE but not in the other instance.

By removing all static members (except for a very limited & controlled set, in case we need it) we also can make the mod 100% hot-swappable. Then, we would not have to restart the game on every code change.

[VictorPhilipp]

Also, could we get a linter (or whatever) set up to help us with this task?

Could you add an issue for this? Maybe also add a linter / rule scheme that we can use.

[FireController1847]

I have never had to restart the game on a code change, I've only had to exit and re-enter the world. If you want I could start work on this while you guys work on Harmony integration, and then once that's done I can work on EVE

[originalfoo]

Remaining static members are instantiated/invalidated at mod loading/unloading time

I assume instantiation occurs automatically due to classes / members being defined as static?

How would such things be invalidated when unloading?

[FireController1847]

@aubergine10 Probably setting them as null in the classes, giving them a value at load, and setting them back to null and unload

[VictorPhilipp]

Another reason: I would like to use a mocking framework (probably Moq since it's free) for unit testing. However, it does not support mocking static methods.