Only if it comes with a parking space and a government expense account!
I can't even get that for me. :lol:
---------- Post added 05-05-16 at 03:19 AM ---------- Previous post was 05-04-16 at 08:12 PM ----------
I just removed a lot of old crap, so if something doesn't work, please complain.
---------- Post added at 09:25 PM ---------- Previous post was at 03:19 AM ----------
Here's a tough cookie to crack. I was tracking the source of the wrong mass being displayed in the MNVR displays, and noticed that:
a) the mass value (WT in the OMSBurnSoftware block) read from the scenario file seems to never be used, as it is overwritten in OnMajorModeChange() when it is called at the beginning of the simulation;
b) the value used is always the result of GetMass();
c) GetMass() returns the now famous low value, which I noticed was 1000Kg above the current prop mass;
d) check what GetEmptyMass() returns and surprise surprise.... 1000Kg;
e) check how/where/why are we setting 1000Kg as empty mass, and find that we are not setting
any empty mass before that OnMajorModeChange() call, so Orbiter probably defaults to 1000Kg;
f) empty mass is only set in the first clbkPostStep();
There was a loophole in the mass/c.g. logic on the first time step for the OV-alone configuration. The current logic is limited by Orbiter not providing correct values for the c.g. of payloads in the first time step... I don't know if this is fixed (or fixable) in the 2016 version. And because of this, the payload mass isn't used, and this seems to have introduced the loophole where we all fell.
For now I made a small change so the payload mass is always used, still leaving the faulty c.g. out for the first time step. I'm pretty sure this generates a (small) c.g. error in the first time step.... what it does I'm not sure.
This still leaves the redundant WT scenario file parameter....
