Null refs with combination modulecommand moduleengine parts

[raidernick]

I decided to put this here and ping both you @sarbian and @Starwaster as these issues are too similar to be unrelated with both smokescreen and realfuels.

Basically what happens is that if you have any part where you have an engine module and command module on it, then switch vessels or scenes and return to the original vessel is permanently breaks the plume of that vessel. It will throw errors in the logs. I also just found out that opening the smokescreen menu after this plume breaking occurs causes null ref spam.

This issue is EXTREMELY similar to what happens when you have a part with a combination modulecomand and modulercsfx where if you exit the physics range of that vessel then get within range again it breaks the rcs, although in this case instead of the plume not working at all, it's on all the time. This will also throw null ref spam in the log about the shuriken system, exactly the same as smokescreen does but about realfuels instead.

@Starwaster told me it was a misconfigured part that was missing the runningeffectname but that is not the case. He looked at a part that happened to be missing that and had the issue. There are other parts that aren't missing it and the same thing happens. I just tested this using the galileo_mb probe I made where I combined modulecommand, modulercsfx and moduleengine to see if I can get both of the issues to occur at the same time(they both happen separately with only a combination of command and rcs or command and engine though before you ask). They both happened. It broke the plume on the vessel that didn't stay active then I exited and entered the physics range and also broke the rcs. It caused log spam from both smokescreen and realfuels talking about the shuriken particles.

Here are both the output logs and the mm cache from this test: https://www.dropbox.com/s/lrxxtz48jf18dck/logs2.zip?dl=0

EDIT: I would like to point out you can easily replicate this issue on a stock part by adding an rcs and engine module to an existing part with a command module. RO actually does this with the stock command pods. It adds built in rcs to them by adding transforms through a model node and this same problem occurs, so I know it's not part specific to only the things I made.

EDIT2: I would also like to mention that these issues didn't exist before the shuriken-only system was implemented after ksp 1.3.1.

[Starwaster]

Ok, so galileo_mb is missing runningEffectName in ModuleEnginesFX as I said, but the field does have a default in the class and it defaults to "running" (which should be looked at because that may not be the right effect for the engine portion of the part)

Regarding Real Fuels and log spam and Real Fuels 'talking about shuriken particles' - I don't see that happening in either of the logs you mention. RF does not itself do particles at all, shuriken or otherwise.

I see ModuleEnginesRF mentioned twice with regards to your error but only because it was the topmost class where OnStart and OnAwake are being traced from. The actual errors happen in the stock code in AudioMultiFX.CreateSource when it goes looking for a transform throws trying to access the transform's GameObject. (initially I had thought it was throwing looking for the transform itself)

But Real Fuels itself can't be said to be generating 'log spam'

[raidernick]

@Starwaster if it needs runningeffectname than all of the parts, even the basic stock engines are configured incorrectly. Every single engine in RO is configured using powereffectname, I see no mention of runningeffectname anywhere for any engine part. The only places I see it used are in rcs.
For instance liquidEngine1-2 doesn't even have runningeffectname defined in the stock config, the RO config doesn't change this and the realplume config for it only adds powereffectname

[raidernick]

OK I figured out the real problem with some help from others in discord. It has nothing to to with the part modules(this was just a coincidence) or the plume settings or anything. It has to do with the fact that something with moduleengine is set as the ROOT PART. You can now replicate this with any engine part in the game, including stock engines by simply making them the root part and voila, it breaks the plumes and causes the log errors.

This is still a big issue though as a lot of root parts in craft have engine part modules on them.