I think there's a problem with the saving/loading with the latest trunk revision. I have confirmed this with a totally clean Orbiter/SSU installation.

It's very easy to replicate. Just load the Testing scenarios\Atlantis in orbit scenario, then quit and then reload the (Current state) scenario and you'll find that the PLBDs are closed, Ku band antenna stowed and the RMS in the cradled but deployed configuration.
This is totally different from the state it should have been which is PLBDs open, with the RMS deployed and in the pre-cradle position.

I think there's a problem with the saving/loading with the latest trunk revision. I have confirmed this with a totally clean Orbiter/SSU installation.

It's very easy to replicate. Just load the Testing scenarios\Atlantis in orbit scenario, then quit and then reload the (Current state) scenario and you'll find that the PLBDs are closed, Ku band antenna stowed and the RMS in the cradled but deployed configuration.
This is totally different from the state it should have been which is PLBDs open, with the RMS deployed and in the pre-cradle position.

I'm not in the trunk so I could be missing something, but it all works as it should here. There are no changes in the PLB block between the original and the current state scenarios. Could you post both the first (after the initial run) and the second (after you see things go weird) current states?

I'm not in the trunk so I could be missing something, but it all works as it should here. There are no changes in the PLB block between the original and the current state scenarios. Could you post both the first (after the initial run) and the second (after you see things go weird) current states?

Each program declares a "template" of the COMPOOL it wants to access, but the "definition" is somewhere else.

But not all variables have to be in a COMPOOL. Also, some variables are not memory locations, but hardware registers. And I am pretty sure to have seen, that components of a structure are also not always declared with a source, the structure itself does though.

Switched to the trunk... still can't reproduce this.
If you start the second scenario, what happens?

I get what I reported in the original post, the animations being messed up. Also launch scenarios are very unstable. I can fire one up but exiting the sim and loading the resulting (Current state) scenario results in a hard freeze.
I have tried cleaning and rebuilding the sources multiple times with the same result.

But not all variables have to be in a COMPOOL. Also, some variables are not memory locations, but hardware registers. And I am pretty sure to have seen, that components of a structure are also not always declared with a source, the structure itself does though.

I think only variables that need to be shared between modules are "COMPOOL'ed".
I got a few more docs for my eyes to scan, so the learning process has just begun.

What I want to know is if you have a scenario with the doors closed (like the one you get after you load the original scenario), do they show up open?

Negative but everything else was in their default positions. Could that be the issue? Since something is off with either saving or loading, everything is set to the default state (closed and latched for the PLBDs, Ku stowed, RMS deployed but cradled etc). This includes the switch positions in the VC.

OK, now things are happening! I didn't use your modules, but by their size I see that they are a Release build (which are much smaller), so I did one and indeed there is something wrong. Let's me have dinner and I'll look at this afterwards.

OK, now things are happening! I didn't use your modules, but by their size I see that they are a Release build (which are much smaller), so I did one and indeed there is something wrong. Let's me have dinner and I'll look at this afterwards.

Compiling in Debug mode I get the same as you, no issues whatsoever. But switching back to Release mode, the issues are back.

Bug found! Surprise surprise, it was my fault... When I added the _DEBUG preprocessor stuff a few weeks ago, I had one line too many inside it, so when not in debug mode, the @ENDSUBSYSTEM line was never written, and when loading = kaput every single subsystem parameter.