Hotfixes and Overrules :: whatheck?

I had being asked (more than once) if this overrules and hotfixes of mine are definitive fixes, if they can be used safely, etc, etc, etc. So I though it could be a good idea to try to explain, better this time, what at heck are these stunts after all. :)

Overrules

An overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things "broken" in a deterministic way.

Rogue patches usually renders the GameDatabase in a unsafe state, but sometimes they just messes things without provoking crashes on the game. So, once these situations are detected (i.e.: messed up GameDatabases but that doesn't explodes under our noses), a overrule can be created to keep only some parts "broken" in order to keep ongoing savegames… ongoing.

This is needed because, now, savegames are intrinsically tied to the GameDatabase on the host installment. Modules preset on the GameDatabase that are not present in the savegame are injected while loading. It wasn't always this way - some KSP versions ago, and I tested it until 1.4.5, absent modules on the savegame would render parts in memory without that modules - so this is a relatively new problem.

Older KSPs probably don`t need this - but yet, rogue patches are undesirable anyway.

There're three problems on this approach:

  1. I brute force my way into the GameDatabase, disregarding everything else.
    1. This is bad because an additional Add'On would like to change something (as a new scale type), and the overrule will bluntly throw away everything and shove a recorded in stone configuration that used to work on the time I wrote the thing.
    2. So every time a new Add'On that patches something with TweakScale is installed, we need to make sure that the overrule are still valid.
  2. This keeps the GameDatabase in a unholy (besides controlled) state, and so every craft and savegame will only work on a broken installment.
    1. It's, indeed, only meant to prevent you from losing your savegame.
  3. It prevents the part to be checked by the Sanity Checks. Since the thing is essentially breaking the part, it would rise an "Houston" on TweakScale.
    1. So… if you mess up a Overrule, TweakScale will not detect the problem.

HotFixes

A HotFix is something like a Overrule, except that instead of breaking the part to keep an ongoing savegame alive, I effectively fix the part as it should be at first place. They are meant to be used while the Add'On Author/Maintainer doesn't applies a new Release with the fixes, or when the Add'On is stalled and cannot be adopted and fixed due Copyright reasons (as being ARR or CC-*-ND).

This is less worst than an overrule because crafts and savegames are now interchangeable between different (sane) KSP installments.

But there're two problems on this approach:

  1. I brute force my way into the GameDatabase, disregarding everything else.
    1. This is bad because an additional Add'On would like to change something (as a new scale type), and the overrule will bluntly throw away everything and shove a recorded in stone configuration that used to work on the time I wrote the thing.
    2. So every time a new Add'On that patches something with TweakScale is installed, we need to make sure that the overrule are still valid.
  2. It prevents the part to be checked by the Sanity Checks, as sometimes it will force a condition that the Sanity Check thinks it's bad, but it was found to be a false alarm.
    1. So… if you mess up a HotFix, TweakScale will not detect the problem.

Conclusions

Overrules and HotFixes are not final solutions for the problem. They are temporary workarounds that fix the problem under our noses, but can create new ones later, and are meant to be used as last resource only.

The only real and safe solution for the problem is reaching the offending Add'On Author/Maintainer for a new release with the problem fixed.

In the mean time, and as always, you can reach me here for help when things go through the tubes. No savegame will be left behind. :)