Update TransX development

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
Can I haz TransX for KSP plz? :idea:
If me getz teh moneyz for developing for a non-free host software :cool:
Seriously though, TransX' disclaimer states that it cannot be used outside Orbiter, although the attached license states otherwise (it's the so called MIT license)

That aside I am glad to see progress being made. The auto-min function tempts me to install Orbiter again. Send data to Launch MFD makes me want to play with the Velcro rockets again.
And I like how you've always supported my addons :)
 

Zachstar

Addon Developer
Addon Developer
Donator
Joined
May 1, 2008
Messages
654
Reaction score
0
Points
0
Location
Shreveport, Louisiana
Website
www.ibiblio.org
If me getz teh moneyz for developing for a non-free host software :cool:
Seriously though, TransX' disclaimer states that it cannot be used outside Orbiter, although the attached license states otherwise (it's the so called MIT license)


And I like how you've always supported my addons :)

It is a bit overkill for KSP anyway. I just like to plan my missions without 8k of wasted DV and had thought "If only we had TransX for KSP" Ah well KSP has a good set of navigation mods.

And I love your addons. It is like you can read my mind from years ago when I messed with Orbiter on a near daily basis and provide tools to make the experience better. For that I am thankful.
 

aldarion

Member
Joined
Oct 20, 2007
Messages
46
Reaction score
0
Points
6
Location
Gdansk
Enjo, I thought that targetting the transX in Launchmfd will also target the proper alt value.

I understand that you have additional button in launchmfd but it may cause some problems.

For example:
I target the trnasx and set the alt to transx and then take off and after that I often adjust the Ej orientation and do the transx retargeting in launchmfd. This way launchmfd also changes the alt value to standard 220 km. Assuming I retarget many times it becomes really annoying when I have to retarget the transx and to set the proper alt value each time. :)

Possible solutions:
1. Targeting transx will also target the alt value or
2. Targeting transx will not change the alt value.
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
No, I disagree, as this is going too far. I've spent a lot of time on trying to code a consistent targeting system and the changes that you propose would break it.

On top of that, the Pe Distance variable has no influence on the orientation of the parking orbit whatsoever, therefore can be completely ignored. You should reach the orbit with altitude as low as possible (still above the atmosphere), and then, after Launch MFD's job is done, you can raise the apoapsis to as high as you want, as due to Oberth Effect, this is more energy-efficient than just reaching the final altitude upon orbit insertion. The Pe Distance only has influence on the shape of the ejection hyperbola, and should rather be adapted to the altitude which you've reached and stabilized, to get a good Angle To Pe readout and not the other way around. Nothing more.

If you're still not convinced, then just don't re-target. Sorry.
 
Last edited:

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
If me getz teh moneyz for developing for a non-free host software :cool:
Seriously though, TransX' disclaimer states that it cannot be used outside Orbiter, although the attached license states otherwise (it's the so called MIT license)

I noticed that you put ModuleMessaging under the GPL. If future versions of TransX are going to link with ModuleMessaging, and ModuleMessaging is under the GPL, then as soon as someone other than you starts maintaining TransX, TransX has to be GPL'ed. The fact that the disclaimer says one thing and the license something else makes it rather ambiguous, but assuming the disclaimer prevents the legal use of TransX outside of Orbiter, the effect would be to prevent TransX from being GPL'ed (seeing as the GPL would require TransX to be usable for any purpose, while the disclaimer would require it not to be used outside of Orbiter). That could be prevented by putting ModuleMessaging under the LGPL, so that copyleft didn't carry over into modules linked with MM.
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
as soon as someone other than you starts maintaining TransX, TransX has to be GPL'ed.
That's what I used to believe myself, but actually it is enough if it's licensed under a GPL-compatible license. MIT is one of them. The contradicting disclaimer makes it GPL-incompatible anyway, but the logic does apply to BTC MFD, which is LGPLed, ergo can still be linked with MM without a license violation [EDIT] Not true.

Back to TransX - yes, the LGPL license would be a solution, but it's not my final goal to LGPL my stuff. What I could do on the other hand, as the SDK's author and license issuer, is granting an explicit exception for TransX, in a similar way as TransX makes an exception to its MIT license - I could grant the LGPL licencing rules for TransX only.
 
Last edited:

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
That's what I used to believe myself, but actually it is enough if it's licensed under a GPL-compatible license. MIT is one of them. The contradicting disclaimer makes it GPL-incompatible anyway, but the logic does apply to BTC MFD, which is LGPLed, ergo can still be linked with MM without a license violation.

The disclaimer's non-GPL compatibility is what I'm concerned about. Without the disclaimer, TransX would still have to be GPL'ed (GPL compatibility means that a work under a given license can be relicensed under the GPL when it incorporates GPL code without causing legal issues, see http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean), but it could be GPL'ed without trouble.

Back to TransX - yes, the LGPL license would be a solution, but it's not my final goal to LGPL my stuff. What I could do on the other hand, as the SDK's author and license issuer, is granting an explicit exception for TransX, in a similar way as TransX makes an exception to its MIT license - I could grant the LGPL licencing rules for TransX only.

I've got some things I'd like to say about this, but I'm out of time for the moment.

EDIT: EDIT2: Decided to put my further thoughts in a new post rather than modifying this one.
 
Last edited:

blixel

Donator
Donator
Joined
Jun 29, 2010
Messages
647
Reaction score
0
Points
16
Enjo, can you load this scenario with the newer versions of TransX? On my system, all versions of TransX after, and including, 2014.01.07-auto-center causes Orbiter to stop responding as soon as I load this scenario. The sim time is 0s and never counts up. After a few moments, Windows reports that Orbiter is not responding.

Can others try this scenario to see if it hangs on your system too?

The 2013.12.13-auto-min version of TransX does not hang, but it doesn't load the TransX plan properly either. And of course, if I delete TransX out of the scenario file, it loads just fine as well. (So it's not some other thing in the scenario that's causing it to hang. It's definitely TransX.)

Code:
BEGIN_DESC
Orbiter saved state at T = 2444
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 56581.2782895858
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-01
END_FOCUS

BEGIN_CAMERA
  TARGET GL-01
  MODE Cockpit
  FOV 50.00
END_CAMERA

BEGIN_HUD
  TYPE Orbit
  REF AUTO
END_HUD

BEGIN_MFD Left
  TYPE User
  MODE TransX
  Ship  GL-01
  FNumber 4
  Int 1
  Orbit True
  Vector  791998.026031 -625200.766727 1439248.63808
  Vector  804.671526408 -1128.49563557 -932.432819448
  Double  4.90279493298e+012
  Double  56581.2755528
  Handle Moon
  Handle NULL
  Handle NULL
Select Target
 0 Escape
Autoplan
0 0
Plan type
0 0
Plan
0 1
Plan
0 0
Plan
0 0
Select Minor
 0 None
Manoeuvre mode
0 1
Auto-Center™
0 1
Base Orbit
0 0
Prograde vel.
 6  843.205
Man. date
 7  56581.2790753
Outward vel.
 1  0
Ch. plane vel.
 1  0
Intercept with
0 0
Orbits to Icept
0 0
Graph projection
0 1
Scale to view
0 0
Advanced
0 0
Pe Distance
 1  1758000
Ej Orientation
 1  0
Equatorial view
0 0
Finvars
  Finish BaseFunction
  Int 1
  Orbit True
  Vector  372929409.621 15412264.0053 -99907748.4745
  Vector  18.7222669506 13.2054376881 187.885105017
  Double  4.03503234902e+014
  Double  56581.2790697
  Handle Earth
  Handle Moon
  Handle NULL
Select Target
 0 Escape
Autoplan
0 1
Plan type
0 0
Plan
0 1
Plan
0 0
Plan
0 1
Select Minor
 0 None
Manoeuvre mode
0 0
Auto-Center™
0 0
Base Orbit
0 0
Prograde vel.
 1  0
Man. date
 1  56581.2782884
Outward vel.
 1  0
Ch. plane vel.
 1  0
Intercept with
0 0
Orbits to Icept
0 0
Graph projection
0 0
Scale to view
0 2
Advanced
0 1
Pe Distance
 1  6571000
Ej Orientation
 5  -0.0869215855395
Equatorial view
0 0
Finvars
  Finish BaseFunction
  Int 2
  Orbit False
  Handle Sun
  Handle Earth
  Handle Venus
Select Target
 0 Venus
Autoplan
0 1
Plan type
0 2
Plan
0 0
Plan
0 0
Plan
0 1
Select Minor
 0 None
Manoeuvre mode
0 0
Auto-Center™
0 0
Base Orbit
0 1
Prograde vel.
 1  0
Man. date
 1  56581.253921
Outward vel.
 1  0
Ch. plane vel.
 1  0
Intercept with
0 0
Orbits to Icept
0 0
Graph projection
0 0
Scale to view
0 0
Advanced
0 1
Prograde vel.
 1  -2841.02207677
Eject date
 1  56586.6307584
Outward vel.
 1  964.559645579
Ch. plane vel.
 1  0
Finvars
  Finish BaseFunction
  Int 5
  Orbit True
  Vector  -1740827508.04 -2615571853.52 5347325415.56
  Vector  1375.55108109 2066.00231607 -4225.29708808
  Double  3.2485863e+014
  Double  56744.1491251
  Handle Venus
  Handle NULL
  Handle NULL
Select Target
 0 None
Autoplan
0 0
Plan type
0 1
Plan
0 0
Plan
0 2
Plan
0 0
Select Minor
 0 None
Manoeuvre mode
0 0
Auto-Center™
0 0
Base Orbit
0 0
Prograde vel.
 1  0
Man. date
 1  56581.2515609
Outward vel.
 1  0
Ch. plane vel.
 1  0
Intercept with
0 0
Orbits to Icept
0 0
Graph projection
0 0
Scale to view
0 0
Advanced
0 0
Draw Base
0 0
Finvars
  Finish BaseFunction
END_MFD

BEGIN_MFD Right
  TYPE User
  MODE TransX
END_MFD

BEGIN_SHIPS
GL-01:DeltaGlider
  STATUS Orbiting Moon
  RPOS 960768.44 -874090.94 1184447.09
  RVEL 616.815 -967.804 -1213.639
  AROT -144.58 -19.48 -52.37
  AFCMODE 7
  PRPLEVEL 0:0.034170 1:0.040735
  THLEVEL 8:0.000002 9:0.000002 12:0.000022 13:0.000022 16:0.000298 17:0.000298
  NAVFREQ 94 524 84 114
  XPDR 0
  PSNGR 2 3 4
  AAP 0:0 0:0 0:0
END
END_SHIPS

BEGIN_ExtMFD
END

--EDIT--

I did some experimenting with the scenario file to see if I could figure out what line(s) was causing it to hang. So far I have found that if I delete the last two "Select Target" sections out of the plan, then Orbiter does not hang. So by removing the 3rd and 4th stages, I can load the scenario.

This scenario works (same as above, but with the last two "Select Target" sections removed):

Code:
BEGIN_DESC
Orbiter saved state at T = 2444
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 56581.2782895858
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-01
END_FOCUS

BEGIN_CAMERA
  TARGET GL-01
  MODE Cockpit
  FOV 50.00
END_CAMERA

BEGIN_HUD
  TYPE Orbit
  REF AUTO
END_HUD

BEGIN_MFD Left
  TYPE User
  MODE TransX
  Ship  GL-01
  FNumber 4
  Int 1
  Orbit True
  Vector  791998.026031 -625200.766727 1439248.63808
  Vector  804.671526408 -1128.49563557 -932.432819448
  Double  4.90279493298e+012
  Double  56581.2755528
  Handle Moon
  Handle NULL
  Handle NULL
Select Target
 0 Escape
Autoplan
0 0
Plan type
0 0
Plan
0 1
Plan
0 0
Plan
0 0
Select Minor
 0 None
Manoeuvre mode
0 1
Auto-Center™
0 1
Base Orbit
0 0
Prograde vel.
 6  843.205
Man. date
 7  56581.2790753
Outward vel.
 1  0
Ch. plane vel.
 1  0
Intercept with
0 0
Orbits to Icept
0 0
Graph projection
0 1
Scale to view
0 0
Advanced
0 0
Pe Distance
 1  1758000
Ej Orientation
 1  0
Equatorial view
0 0
Finvars
  Finish BaseFunction
  Int 1
  Orbit True
  Vector  372929409.621 15412264.0053 -99907748.4745
  Vector  18.7222669506 13.2054376881 187.885105017
  Double  4.03503234902e+014
  Double  56581.2790697
  Handle Earth
  Handle Moon
  Handle NULL
Select Target
 0 Escape
Autoplan
0 1
Plan type
0 0
Plan
0 1
Plan
0 0
Plan
0 1
Select Minor
 0 None
Manoeuvre mode
0 0
Auto-Center™
0 0
Base Orbit
0 0
Prograde vel.
 1  0
Man. date
 1  56581.2782884
Outward vel.
 1  0
Ch. plane vel.
 1  0
Intercept with
0 0
Orbits to Icept
0 0
Graph projection
0 0
Scale to view
0 2
Advanced
0 1
Pe Distance
 1  6571000
Ej Orientation
 5  -0.0869215855395
Equatorial view
0 0
Finvars
  Finish BaseFunction
  Int 2
  Orbit False
  Handle Sun
  Handle Earth
  Handle Venus
END_MFD

BEGIN_MFD Right
  TYPE User
  MODE TransX
END_MFD

BEGIN_SHIPS
GL-01:DeltaGlider
  STATUS Orbiting Moon
  RPOS 960768.44 -874090.94 1184447.09
  RVEL 616.815 -967.804 -1213.639
  AROT -144.58 -19.48 -52.37
  AFCMODE 7
  PRPLEVEL 0:0.034170 1:0.040735
  THLEVEL 8:0.000002 9:0.000002 12:0.000022 13:0.000022 16:0.000298 17:0.000298
  NAVFREQ 94 524 84 114
  XPDR 0
  PSNGR 2 3 4
  AAP 0:0 0:0 0:0
END
END_SHIPS

BEGIN_ExtMFD
END

--EDIT 2--

Well I don't know what the problem was, but it has magically fixed itself. I tried to narrow down the problem by disabling all modules except for OrbiterSound, TransX and TransX 2. With just those 3 modules enabled, the scenario loaded. So I then re-enabled my other modules 1 by 1, but after re-enabling all of them (all that I had loaded before anyway), the scenario was still loading.

I don't even begin to understand how unchecking a bunch of modules and then rechecking them could fix it, but in this case, it did. Weird.

--EDIT 3--

And now that scenario is causing Orbiter to hang again. That's not surprising though. I didn't really believe that unchecking and re-checking the modules had actually fixed anything. It was just a fluke that it started working I guess. The hunt for the solution continues.
 
Last edited:

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
I've got some things I'd like to say about this, but I'm out of time for the moment.

I had originally edited my previous post to add my further thoughts, but decided to put them in a new post instead.

Without further ado:

I don't really like the idea of putting library code under the GPL rather than the LGPL, especially in an environment like the Orbiter community that's centered around a product under a non-FOSS license, and where the commerical use restriction in the Orbiter license is going to protect against a lot of the kinds of abuses copyleft is meant to protect against (commercial use restrictions have their own problems, but I'm not going to try very hard to change Martin's mind on that, nor am I really going to try to hard to change your mind about GPL vs LGPL).

When a company like Microsoft is involved and might embrace, extend, and extinguish the feature set provided by your code, then it's time to play hardball and force non-FOSS projects to code their own implementation of that feature set rather than using yours. In a friendly community like that around Orbiter, it's best not to force people to copyleft their code in order to interoperate with yours. If you're worried about your code being adapted for other environments than the Orbiter API and used outside the community, it might be good to consider what uses you would consider acceptable within the community and draw up a license that allows those uses as long as the code is used with Orbiter, and offer the code under a dual license, allowing people linking to or modifying the code to chose between your custom license for use with Orbiter or the GPL (for external projects or Orbiter addon developers who want to use the GPL).
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
The disclaimer's non-GPL compatibility is what I'm concerned about. Without the disclaimer, TransX would still have to be GPL'ed (GPL compatibility means that a work under a given license can be relicensed under the GPL when it incorporates GPL code without causing legal issues, see http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean), but it could be GPL'ed without trouble.
Key point here. Thanks.
However I'm not so sure if it can be GPLed without problems, as all of the previous authors and contributors would have to agree on it. As GPL means that you can sell the product for even beyond the costs of distribution, I doubt that Duncan would agree, as he's put the disclaimer there, which basically prohibits the whole freedom which GPL gives except code sharing, ie. monetizing and reuse outside Orbiter.

Why I prefer GPL over LGPL for my libraries:
It's mostly because I'd like to see more code sharing from the community, friendly or not. And that's because it helps everybody in the long run. TransX, and BTC are perfect examples how projects can grow in the right direction, thanks to their openness.
I have nothing against using my GPL/BSD-licensed stuff outside Orbiter and selling it, as long as the code is shared and copyrights are preserved.

To sum up:
I think that in this case, I will cease and re-release the SDK under LGPL, as I don't want to spend too much time on PR, trying to convince other authors how great it would be if they agreed on GPLing their old code. My hobby is programming, not lobbying.
Thanks again for bringing all these points.

---------- Post added at 08:34 AM ---------- Previous post was at 08:24 AM ----------

Blixel:
Thanks for experimenting with this bug. Let me guess: this happens on DX9 client but on inline client not? If so, then I had the same problem. It was hanging on DX9, then I launched the same scenario on DX7, which worked. Then I switched to DX9 and the same scenario worked again. Very weird.
The good thing is that since your PC has the same behavior as mine, then if I fix it at my end, it will work at yours. I think that it has to do with static initialization of the ModuleMessaging library. If this is the case, then I'll simply initialize it just like HUDDrawer, which so far exposed no such problems, but this will require enabling the MM in Modules tab, which I tried to avoid.

I'll get back to you during the coming weekend, when I find some time.
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
It's the so-called [ame="http://en.wikipedia.org/wiki/Undefined_behavior"]Undefined behavior - Wikipedia, the free encyclopedia[/ame] - program behaves differently under various machines. Therefore I'm happy that blixel's machine will be able to verify if my fixes are of any help.
 

aldarion

Member
Joined
Oct 20, 2007
Messages
46
Reaction score
0
Points
6
Location
Gdansk
Enabling the MM in Modules tab may actually be useful.

If anybody does not want to use this mechanism they will simply disable it - by a click. :)

I hope that the fact that it is not enabled will not crush the modules which use it. :)
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
I hope that the fact that it is not enabled will not crush the modules which use it. :)
It could, if at the receiver's end, the coder doesn't check for returned flag, for example:

PHP:
Result<double> divisor = ModuleMessaging().GetDouble("TransX", "divisor");
double result = 2 / divisor.value; // potential divison by 0
// use result
while it really should be:
PHP:
Result<double> divisor = ModuleMessaging().GetDouble("TransX", "divisor");
if (divisor.isSuccess)
{
    // division by 0 only if divisor.value == 0
    double result = 2 / divisor.value;
   // use result
} else {
   //  division by 0 guaranteed, as this is the default returned value on failure.
}

[EDIT] In a professional world, the Result<T> would throw an exception, if the caller tried to access the value, while the isSuccess == false. In Orbiter though nobody catches exceptions. However I'll think about implementing this mechanism anyway. Improper handling would CTD, but would also print a meaningful message, so that the caller can check the flag next time.
 
Last edited:

blixel

Donator
Donator
Joined
Jun 29, 2010
Messages
647
Reaction score
0
Points
16
Blixel:
Thanks for experimenting with this bug. Let me guess: this happens on DX9 client but on inline client not? If so, then I had the same problem. It was hanging on DX9, then I launched the same scenario on DX7, which worked. Then I switched to DX9 and the same scenario worked again. Very weird.
The good thing is that since your PC has the same behavior as mine, then if I fix it at my end, it will work at yours. I think that it has to do with static initialization of the ModuleMessaging library. If this is the case, then I'll simply initialize it just like HUDDrawer, which so far exposed no such problems, but this will require enabling the MM in Modules tab, which I tried to avoid.

I'll get back to you during the coming weekend, when I find some time.

Thanks for testing it on your end. I also tested it with the DX7 inline client and got the same result as you. That is, the scenario loaded and did not hang Orbiter.

I also found that if I disable BTC, the scenario will load in DX9. But it may just be the case that it loads once or twice, and will then hang. I haven't tried loading it over and over and over again. But being the case that it loads after disabling BTC, then I suspect you're on the right path with assuming that it has something to do with ModuleMessaging.

Let me know if you get a potential fix and I'll gladly test it.
 

agentgonzo

Grounded since '09
Addon Developer
Joined
Feb 8, 2008
Messages
1,649
Reaction score
4
Points
38
Location
Hampshire, UK
Website
orbiter.quorg.org
Let's say that I'll think about the Auto-Min in Manoeuvre mode later then. I only see that it can be done.


That's because I only pass the Time to Manoeuvre, and not the Time to Burn. The latter is calculated by both MFDs independently. The question is which one is right. Some close code inspection is needed here.
From what I can remember, I took a look over the original BTC code before putting this functionality into TransX. In short, the answer is 'neither is exactly correct', but one is more accurate than the other. From what I can remember, TransX is more accurate (otherwise I'd just have copied BTC verbatim).

I think that I posted a message about BTC when I did the transx changes but can't find that one. I found this message that I think accounts for the disparity between transx and BTC, notably that BTC assumes that the acceleration (or is it rate-of-change-of-acceleration (jolt or jerk) is constant, whereas TransX does not. I remember assuming a constant rate of change of acceleration throughout the burn (which is not actually the case, but close enough) then working backwards from that.

The original code commit is here

---------- Post added at 13:56 ---------- Previous post was at 13:54 ----------

Found the original post
 

Ripley

Tutorial translator
Donator
Joined
Sep 12, 2010
Messages
3,133
Reaction score
407
Points
123
Location
Rome
Website
www.tuttovola.org
...I also tested it with the DX7 inline client and got the same result as you...
If you need it, I can test that scenario on my XP with inline client (which I forgot to do before just because I...never use it anymore!).
That will happen NET tonight (UTC+1).
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
Blixel:
I might have found the solution... Please do the following:
1) By retrying the to load the scenario, try to bring your machine to the state where it hangs in a repeatable way.
2) Open Orbiter_NG.cfg and from the active modules list remove the line:
BurnTimeCalcMFD
3) Test if it still hangs on reloading of the scenario.

The background is that I examined the Orbiter.log, which read that BurnTimeCalcMFD.dll wasn't loaded and produced an error code. This was the previously chosen MFD's name, as opposed to how it should have been named: BurnTimeMFD.

Agentgonzo:
3rd order equations? Neat! Mind if I copy this to BTC?
 
Top