I had the problem of constantly flickering FTL/save button. After reading cactusdoodad 's post about this bug, I did some decompiling of the game (with DotPeek) and, yup, the save blocking (and by extension FTL blocking) is hardcoded. I then read the decompiled code for the hit effects, and then examined your code on the autoloaders. The autoloaders are triggered by RepeatingTriggers, so I read the source code on that as well. Nope, red herring, I was still lost as to what caused the bug.
Reviewing the code for the power "un-draining" though gives some insight about this mostly game-caused bug.
In auto_loader.txt:
HitEffects
[
{
Type = PartAreaAmmoDrain
AmmoType = battery
AmountPerPart = -1000
Radius = 0.1
Falloff = 0
Delay = 0.05
AllowFriendlyDrain = true
}
]
And in auto_loader_adv.txt:
HitEffects
[
{
Type = PartAreaAmmoDrain
AmmoType = battery
AmountPerPart = -1000
Radius = 1.4
Falloff = 0
Delay = 0
AllowFriendlyDrain = true
}
]
After I edited the HitEffect's Delay for the directional autoloader to 0.0, I loaded up the game, and then set up an FTL jump. This time, the "Jump" button no longer flickers. It seems that the bug is caused by the autoloader's area ammo "drain" being delayed, which is the source of the save game blocking. (Interestingly, only four hit effects, including the aforementioned area ammo drain, do this.) And since FTL is tied to a game's ability to save itself, well...
I restarted the game with the delay removed, and so far the FTL button provably no longer locks up. And I get to hear the ding from a readied jump. Yay...
EDIT: There's apparently a function for blocking the game from saving, and another for unblocking it. I think that in the save/FTL flickering craze, the jump completes before the directional autoloader completes its delay, so the function to unblock saving is never called, hence the perma-disabling of jump or FTL.
