Vinka's spacecraft2/3.dll on Orbiter2006P1: payload mass bug on quick save (?)

[simcosmos]

Hello all

I know that the best course of action would be to try to contact Vinka but, before doing it, could someone please confirm if what will write next happens in other computers other than mine?


Problem Description / Step by Step Replication:

a) spacecraft powered by either spacecraft2.dll or spacecraft3.dll, implemented on Orbiter2006P1

b) spacecraft has payload / a number of payloads defined in its INI

c) press CRTL+I to see total mass of such spacecraft

d) press J (as needed) to release payloads and confirm that their mass is properly subtracted from the mother spacecraft

(until this point all works as expected)

e) make quicksave (CTRL+S) and / or exit scenario (CRTL+Q), exit Orbiter launchpad

f) start Orbiter and either try to load the quick saved scenario or the 'current scenario'

g) select the 'mother vessel', press CTRL+I and check that spacecraft's mass


What I'm getting, in g) step (after loading the quick saved or 'current scenario'), is that the 'mother vessel' has the payload(s) mass(es) assigned again to its own total mass, despite the payloads were / are released.

This seems to happen with spacecraft2/3.dll on Orbiter2006P1. Beyond my custom addon implementation managed to replicate it with using Vinka’s provided demo scenario called 'Atlantis.scn' with description:

"Demonstrate the ability to define parameters
of space shuttle atlantis through ini file and
define multiple payloads with various speeds and
rotation speeds for jettison. Use of the FOCUS
parameter to set focus to specific payload."



Confirmation (?) / Extra Comments

Would it be possible for someone to please verify if the same is happening there? If this can be replicated it has considerable impact when trying to make a realistic (dV budget constrained) addon powered by generic spacecraft dlls on Orbiter2006P1 and if wanting to use quick saves.

Not sure but I seem to remember a thread in M6 forums about a similar topic (can't confirm because M6's search function returns error and also not having luck with google).

On the other hand, if I'm writing nonsense and if the issue is not replicated in other computers it would also be good to know, before bothering Vinka with an eventual non generically replicated issue (and that is the only reason why posting this here first).

Thanks in advance,
António

 

[Usonian]

You aren't dreaming and it isn't nonsense. It's a bit of a bug in Spacecraft2 and 3.

It appears that Spacecraft_.dll totals up a ship's mass by ONLY reading the .ini file each time it is loaded, including all of its payloads. It does not read the current payload state from the scenario file and make reductions in mass accordingly. I am fairly certain that Vinka is aware of this problem.

This bug is not a problem with "conventional" expendable spacecraft arrangements (like MER, for instance) where you are only following the payload - it doesn't matter if in subsequent saves and loads the previous string of "motherships" are overweight because you never go back to them.

I haven't found a work-around for the problem. Attachment is the only alternate to Payload, but (as I understand it) Orbiter does not combine the masses of attached vessels.

Basically, you're screwed if you do not run the scenario continuously, without saves, exits and reloads.

 

[Cale]

Hey Antonio,

I was talking to a buddy awhile back who had the same issue you're talking about. The only work-around he was able to come up with was to do a separate .ini file that didn't include the payload..

Example: If you're first .ini file is a Jupiter 120 with CEV, called "J120", then make a .ini file called "J120E" (for Empty!) without the CEV. Then use the J120E ini file in the Scenario file.

Hope this was helpful..least I can do to return the favour with all the advice you've given me over the last month

Cheers,

Cale

 

[simcosmos]

Thanks for the input Usonian, Cale:

Until now this was not a big issue here because have been using spacecraftX.dll to power things like:
- single spacecraft (no payloads)
- or SM+CM configuration (where SM would destructively enter atmosphere)
- or to simulate configuration changes in entry vehicles (no really need to quick save)
- or to implement 'dummy' (invisible) interfaces between multistage2.dll and custom dll vessels, etc
- or to implement Sci-Fi ‘mother vessels’ with ludicrous dV budget / mass (when comparing with much smaller payload masses).


However, in the latest times, I have been playing with configurations which involve a SM with CM + MM (Mission Module) defined as payloads and where the MM needs to be released (becoming an independent vessel + automatically docking with SM) to allow the whole ([CM+SM]+MM) to dock with other targets (via docking port on MM).

(If then quick saving this would mean that would have the mass of the mission module being accounted twice: one from the INI, another from the meanwhile made independent docked vessel)

The spacecraft design would also be able to make a deorbit burn, release the CM (for entry) and then ([SM]+MM) would be able to go back to stable orbit and have good propellant amount to act as a capable TUG, etc… Which is kind of problematic (in terms of remaining dV budget) if, after saving scenario, the SM still includes the default original CM+MM ‘payload’ masses, beyond the docked MM mass).


Despite several eventual workarounds might exist, having to manually edit scenarios or do / recommend extra steps might return a bit complicated for some final users and detracts from the overall experience. It would be nice if there could exist the perspective of a fix for the cool spacecraftX.dll!

Just to make sure (for eventual future reference purposes), will then email the current thread’s link to Vinka. Maybe this can be fixed - on the source code - in a later occasion, if real life / time permits.

Thanks,
António

 

[MajorTom]

Similar issue with Multistage2

Hello Antonio and company,

Glider is the developer of the big Falcon launcher & dragon spacecraft addon (still being worked on, with some input from me). He has noticed something I had not seen before:

Discarded multistage2 stages, using the default "stage" dll, have a much higher mass than one would expect. The masses of discarded stages are not anywhere close to the stages' "empty masses."
​

This has not bothered me, since such stages are no longer "in play" but it's a bit strange that the masses do not add up. So I'd say our multistage2 questions to Vinka would be:

1. Why are the discarded stage masses higher than expected? Does this issue have any affect upper stage performance?

2. Does anybody know how to get discarded stages...falling gracefully to earth...to disappear on demand, i.e., before they hit the earth's surface?

Again, these are probably not serious issues, but they do cause minor concern.

Cheers all!

Tom

 

[simcosmos]

Tom, about the *multistage2.dll* questions:

a) As far as remember (would need to check), stage.dll is just a generic dll that spent launcher components use (except last active stage): there is no direct relation with the true dry / burnout masses. People can however create such 'connection' by using the feature "Module=" (please see multistage2.dll doc) and pointing to a specific cfg file (just as example, a simple cfg with proper PMI, masses, etc)

b) About making stages / components to "disappear on demand" and with specific conditions / options: also if remembering well, Urwumpe made a module called 'MayFly.dll' (another thing that need to check, I think it is available at Orbit Hangar Mods). I agree that it would be nice if something like that could be integrated by default within the multistage.dll packages.

Regarding spacecraft / multistage.dll perspectives: Vinka made a few posts some time ago at Dansteph's forums (I have made a few suggestions by then). But you know, sometimes real life gets in between. Will try to find the link.

EDIT (about eventual future spacecraft / multistage releases)

Starting on page 3, 4, 5:
http://orbiter.dansteph.com/forum/read.php?f=5&i=7900&t=7632&page=2

Also (Suggestions pour Multistage3 de Vinka):
http://orbiter.dansteph.com/forum/read.php?f=5&i=8075&t=7940&page=0

António

 

[Cale]

Hmm, wondering which addon you're working on right now, Antonio

Cheers,

Cale

 

[Usonian]

Does anybody know how to get discarded stages...falling gracefully to earth...to disappear on demand, i.e., before they hit the earth's surface?

This can not be done in Multistage. Being able to program a limited "life span" for spent boosters would be Number 2 on my request list for the next versions of Multistage and Spacecraft. (Number 1 on the list being the mass problem brought up by Simcosmos). The only "fix" I know for spent stages is to save the scenario, then go in with a text editor to delete the debris.

I don't think that the Multistage mass problem you described effects a BOOSTER or STAGE before it is jettisoned. I have worked with a couple of historical boosters (Delta II and Saturn V) and they perform just as one would expect.