Split off from #341 for this specific problem.

Information is as follows:
This issue is related to Atmosphere Autopilot re-arranging the config nodes for parts. This causes errors as SSTUAnimateEngineHeat relies on config-specified module index in order to find the engine module. Will likely also cause errors for any other modules that relies on gimbal or engine module index.

https://github.com/Boris-Barboris/AtmosphereAutopilot/blob/master/AtmosphereAutopilot/GimbalRearranger.cs#L40-L75

Potential workaround is:
Rather than use a raw index to find the engine module, instead use the index of the module in the sub-list of engine modules. This will ignore all other modules, and -could- clean up issues caused by other mods' plugin code re-arranging modules.

Thus if a part only has one engine module, the index will always be zero (0). If a part has two engine modules, the index would be 0 or 1 depending on if it was the first or second engine.

I know stock does this a lot, but I think it leads to things being brittle when multiple mods try to modify the same part and puts and adds a lot of extra work to make patches. Especially with engines, there's already a way to uniquely identify them (engineID) so I'd highly recommend using that.

It's defined on ModuleEngines, so it works for both.

Indeed, you are correct; engineID does exist on the regular ModuleEngines. I guess I've just never used it as it was only needed with EnginesFX (and really only used by MultiModeEngine in a stock setup).

I'll see what I can do about adapting to that system; using a string-based identifier is far more robust than any sort of indexing could ever be, and easier to read in the configs as well.

I don't believe engineID is available on regular ModuleEngines, but only with ModuleEnginesFX?

Updated the heat and deploy-able engines modules last night to use engineID rather than any form of indexing.
Fix will be available with the next update (probably on Sunday or Monday).