API Question Preventing "ATTACHED" scenario writing on savegame

[N_Molson]

Hello, :hello:

I'd like to prevent Orbiter to write [ATTACHED 0:0, xyz] in the scenario file (in the attached vessel section) when I save my game with a custom vessel I made. The idea is that I don't want the attached vessel to "remind" the attachment. So I'd like to destroy and recreate the attachment at each Save/Load cycle.

But that doesn't seem so simple. I've tried to place the DetachChild(...) instruction in "clbkEndSession", which according to the API guide is :

Called before the end of a simulation session. At the point of call, logical objects still exist (OBJHANDLEs valid), and external modules are still loaded.

:facts:

So it seems it is the perfect place to put DetachChild(...). But that doesn't work, in the (Current state).scn file, the passive (child) vessel still has that [ATTACHED 0:0, myship] line.

:compbash:

So, any suggestions ? Thanks ! :tiphat:

 

[jedidia]

But that doesn't seem so simple. I've tried to place the DetachChild(...) instruction in "clbkEndSession", which according to the API guide is :

This is way too late. Your ship has been saved a "long time" (computer time anyways) before that. You need to detach the vessel before the vessel gets written to the scenario file, which happens in clbkSaveState. Detach your vessel at the beginning of that function, and you should be fine.

 

[N_Molson]

I tried that, even using ClearAttachments(), but that doesn't work. In fact, the line is written by the attached (child) vessel in it's own subsection. The problem seems to be that that ship (child) has the "priority" when the simulation is saved.

So now I wonder, how does Orbiter determines which vessel runs it's SaveState function first ? I think that if my ship (parent) was first to run it's SaveState, the Detach command would be executed at this point, and the other ship (child), running it's SaveState function after, would not write the "ATTACHED" line. Of course that's a theory. :hmm:

ANSWER : elementary, the order is defined by the position in the scenario file... So by moving my ship subsection at the end, I solved the problem. :facepalm: I just will have to warn the user not to mess with that order (parent THEN child).

Unwanted side effects : StateSaver and QuickSave kill the fun...

 

[jedidia]

The problem seems to be that that ship (child) has the "priority" when the simulation is saved.

Hmm yes, if the attached ship gets saved first, there's not much you can do about that... tricky!

I assume the order of saving is arbitrary, most probably order of creation (as I'd expect the orbiter save function to walk through the array and call every callback).

The question now would be, what exactly do you want to achieve? I can think of several courses of action, but they really depend on what exact effect you want in the end.

 

[N_Molson]

I found an easy trick : I just put "saved = 1" at the end of ClbkSaveState, then a

"if (saved == 1) {redo the attachment stuff and reset saved = 0}" in ClbkPostStep.

It works fine.