OHM TransX 2018.05.06 MMExt2 for Orbiter 2016

[downloaderfan]

Hi Enjo.

If there are not special reasons to keep it, could a future update disable the possibility of moving the "Man. date" parameter "in the past", that is, before actual MJD?

To be frank, I wouldn't recommend doing something like that. Why? Simply because it makes TransX unnecessarily less flexible without adding any advantages.

There is nothing wrong with the ability to plan starting from a past date, because this is a simulator, not real life. Lot of times when I plan multiple inner planet slings, I feel that a date in the near past might work & that date might be multiple earth orbits in the past. Having to go to the scenario editor every time I feel like going in the past is an annoyance. I would rather use the scenario editor once after I've finished my planning to perform the burn rather than using it multiple times while planning in TransX to go to the past.

Besides, we need to realise that TransX is not made specifically for one person, it's made for everyone who use Orbiter & most of them don't hang around here in O-F. I don't think we should change the way TransX currently works, because doing so will surely annoy & confuse many, especially when we are adding a limitation with no advantages.

Even if somebody plans a trajectory in the past without noticing the date, he'll realize that soon enough because, you'll have to look at the date once before beginning the burn & at that point, when the person realizes his mistake, he could use the scenario editor to go to the past & complete his burn.

The only thing I've demanded is DSM support, which is addition of a feature. I'm not asking Enjo to change the way TransX currently works. Otherwise, I'm pretty sure a lot of people would want TransX to behave completely like the IMFD target intercept program so that they don't have to fiddle around with different parameters just to get near their target, killing most of the flexibility & learning curve of TransX, which would be a nightmare.

Just so that there's no misunderstanding, I'm not saying IMFD is bad, in fact I use 50% of it's features for almost all my trips to the outer solar system & it's really good at doing some things which TransX just can't. :tiphat:

 

[Ripley]

...There is nothing wrong with the ability to plan starting from a past date, because this is a simulator, not real life...

Ok, fair point.
I'm not such an advanced user or planner, but I see that going in the past can be useful to others to find special transfers, or rare alignments.
That's why I wrote "If there are not special reasons to keep it".

---------- Post added at 20:08 ---------- Previous post was at 16:33 ----------

I just found this anomaly.
This scenario is a quicksave from Flytandem's "Lunar return" scenario, found here:

http://flytandem.com/orbiter/tutorials/lunar_return/index.htm

The save is just after the burn from Moon to Earth, so we're going to switch Manoeuvre Mode OFF.

To reproduce what I mean (use left MFD)
- in stage 1 bring up View Target
- select Manoeuvre Mode (-VR) and turn it off
- now the 2 MFDs show different labels (view target, while in fact it is view setup)
- if you click VW on left MFD, you get the right labels

BEGIN_DESC
Orbiter saved state at T = 598
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 52006.8630790052
  Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-01
END_FOCUS

BEGIN_CAMERA
  TARGET GL-01
  MODE Cockpit
  FOV 50.00
END_CAMERA

BEGIN_MFD Left
  TYPE User
  MODE TransX
  Ship  GL-01
  FNumber 2
  Int 1
  Orbit True
  Vector  -1661737.82584 -46204.0573946 -661317.359146
  Vector  -611.245511828 -38.4904155866 1538.2479261
  Double  4.90279493298e+012
  Double  52006.7920867
  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 0
Base Orbit
0 0
Prograde vel.
 1  830
Man. date
 1  52006.8623
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
Pe Distance
 1  2085600
Ej Orientation
 1  0
Equatorial view
0 0
Finvars
  Finish BaseFunction
  Int 0
  Orbit True
  Vector  -376695297.873 31103824.1173 -65619038.4125
  Vector  121.43856362 -17.2112013549 -216.865019878
  Double  4.03503234902e+014
  Double  52006.8623022
  Handle Earth
  Handle Moon
  Handle NULL
Select Target
 0 None
Autoplan
0 0
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 0
Prograde vel.
 1  0
Man. date
 1  52006.8630782
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
Finvars
  Finish BaseFunction
END_MFD

BEGIN_MFD Right
  TYPE User
  MODE TransX
END_MFD

BEGIN_PANEL
END_PANEL

BEGIN_SHIPS
GL-01:DeltaGlider
  STATUS Orbiting Moon
  RPOS -1030173.909 -15890.493 -1467935.772
  RVEL -2098.6122 -84.3281 1317.8591
  AROT -3.956 60.181 176.239
  AFCMODE 7
  PRPLEVEL 0:0.877896 1:0.995353
  NAVFREQ 0 0 0 0
  XPDR 0
  HOVERHOLD 0 1 0.0000e+000 0.0000e+000
  AAP 0:0 0:0 0:0
END
END_SHIPS

BEGIN_ExtMFD
END

 

[GodAtum]

Hi all, i dont get the auto-min option on this?

 

[Enjo]

Hi all, i dont get the auto-min option on this?

What do you mean exactly? It's there:
https://sourceforge.net/p/enjomitch.../tree/TransX/doc/TransX/TransX readme.txt#l96

 

[GodAtum]

Sorry im being stupid, it was not on going to the moon, only to planets.

 

[Enjo]

Ah right... Manouevre mode is excluded from Auto-Min, because it's hard to determine an optimum, which is within reasonable dv values in such case.

 

[PeterRoss]

Is it working under the latest beta?

I've downloaded all the latest ModuleMessagingExt, TransX and BTC for 2016, and here what it shows in the Orbiter.log now:

============================ ERROR: ===========================
Failed loading module Modules\Plugin\TransX2.dll (code 193)
[Orbiter::LoadModule | .\Orbiter.cpp | 606]
===============================================================
============================ ERROR: ===========================
Failed loading module Modules\Plugin\transx.dll (code 193)
[Orbiter::LoadModule | .\Orbiter.cpp | 606]
===============================================================
============================ ERROR: ===========================
Failed loading module Modules\Plugin\BurnTimeMFD.dll (code 193)
[Orbiter::LoadModule | .\Orbiter.cpp | 606]
===============================================================

I\m running Win7 x64, all the goddamn possible VC redistributables are installed.

 

[ADSWNJ]

Error 193 usually means that you are trying to load a 32-bit DLL into a 64-bit process, or vice versa. In our case, as Orbiter is 32 bit, the whole ecosystem is also 32 bit, including these plugins. I suspect that you have overwritten some required 32-bit redistributables with their 64-bit brothers, and therefore the module cannot load.

Can you explain how you downloaded and installed each of these redistributables? E.g. did you get them as individual files and just copy the DLL's into the working directory (bad), or did you download them from microsoft.com and run the respective vcredist_x86.exe, etc, to install them cleanly?

We can do some further digging as needed (e.g. using the depends.exe utility to examine the dependencies). We will fix it

 

[PeterRoss]

Can you explain how you downloaded and installed each of these redistributables? E.g. did you get them as individual files and just copy the DLL's into the working directory (bad), or did you download them from microsoft.com and run the respective vcredist_x86.exe, etc, to install them cleanly?

Yes, I did some messing up with dlls. With msvcp80.dll, to be precise. Orbiter said at startup that it misses this library, and reinstalling Visual C++ 2005 Redistributable Package (x86) didn't help. So I downloaded the 32-bit msvcp80.dll and placed it into Orbiter folder. The error message has gone.

Now I uninstalled the VC++2005Redist(x86) package and tried to reinstall it from Microsoft site and it cancels the installation in the middle without any message or anything :hmm:

 

[ADSWNJ]

Ugh! Sounds like a mess. Whilst you technically *can* put those msvcrpXX.dll files in the Orbiter directory, things get can get messed up. Those files strictly should just be installed by the vcredist installers, into the right system directories, but if things are hanging than you do what go have to do.

Oh well, problem solved!

 

[PeterRoss]

Oh well, problem solved!

Uh, actually it's not TransX and BTC aren't working still. Default TransX isn't there anymore as well since it was overwritten.

What should depends.exe show for transx.dll (hope I do it right, just opening transx.dll in depends.exe)? For me it shows it can't see Orbiter.exe, and that most of dependencies are 64-bit versions. I can attach a screenshot in a couple of hours.

 

[DaveS]

You need the 32-bit (x86) versions of the dependencies as that’s what TransX and BTC are linked against. It has nothing to do with the operating system you’re using.

 

[PeterRoss]

You need the 32-bit (x86) versions of the dependencies as that’s what TransX and BTC are linked against. It has nothing to do with the operating system you’re using.

I do realize that. I also have all the VC++ redistributable packages (both 32- and 64-bit) installed. Well, except of 32-bit VC++2005Redist now, obviously. Why could TransX be linked against 64-bit versions in that case?

 

[ADSWNJ]

TransX *can't* be linked against 64 bit runtimes, else it would not load. The .EXE (i.e. Orbiter.exe which is 32 bit) governs the architecture for any DLL to load, so you cannot load a TransX linked against 64 bit runtimes. (Sadly ... as I would love to have more than 4GB of RAM to play with!)

 

[PeterRoss]

So what should I do?

---------- Post added at 13:35 ---------- Previous post was at 13:33 ----------

TransX *can't* be linked against 64 bit runtimes,

Let me rephrase myself: Why TransX on my system can't access x86 runtimes?

 

[Enjo]

Could you try replacing the current MMExt with this one?

Long story:
The currently distributed MMExt has been compiled with newer VC, leading to dll-hell. I propose the good old 2005 VC, whose redists are available for every Windows. I assume that the TransX dependencies are exposed through the MMExt, not through the MFD itself.

 

[ADSWNJ]

I thought this link was interesting. We have had our discussions in this forum on the benefits and evilness of static linking. Enjo and I saw it first-hand trying to pass something as simple as a std::string across different versions of runtimes (i.e. things break weirdly because there is no guarantee of binary compatibility across different runtimes).

Back to the link though ... my interpretation of what the author says is that if you are keeping your interface clean into and out of your DLL, then static linking is just fine (apart from preventing your customer from patching a critical bug without you re-releasing, that is!). Weird things happen if you try to create objects in one VC runtime regime, and destroy in another, so don't do that please!

My issue with forcing a legacy version of C++ is that it prevents you from using any modern language features (i.e. C++ 11 or later). For a common library like ModuleMessagingExt.dll, I get it, and one could argue that's a great place for static linking as well, but for standalone code, then I want to use modern features.

Anyway - interested to see if Enjo's compiled version works out for you, Peter. @Enjo - we can recompile and statically link to the oldest possible version if you want?

 

[Enjo]

My issue with forcing a legacy version of C++ is that it prevents you from using any modern language features (i.e. C++ 11 or later). For a common library like ModuleMessagingExt.dll, I get it, and one could argue that's a great place for static linking as well, but for standalone code, then I want to use modern features.

And that's my point. Do what you want in your own end-user modules, but don't force your rules on everybody by binding them into an overly basic library.

we can recompile and statically link to the oldest possible version if you want?

That's already done with the zip I provided. Do you recall, that I gave it to you 1.5 year ago? And we're still in this deep ****

But still, let's at least wait and see if it helped.

 

[Face]

I guess you could also put an argument like Torvalds did regarding security hardening that breaks user space:

Because without users, your program is pointless, and all the development work you've done over decades is pointless.

If you keep users away with all these linking problems, all the well-meant efforts in modularity are just for building up know-how for the developers. This is all fine if it is some niche of the community, but interaction of MFD modes and other plugins is important for all aspects of Orbiter.

If this is kept up, another platform might show up, which would make things even more complicated for end-users. Please don't go down that route.

 

[ADSWNJ]

That's already done with the zip I provided. Do you recall, that I gave it to you 1.5 year ago? And we're still in this deep ****

But still, let's at least wait and see if it helped.

Well yes, and my views have changed since then (i.e. from dynamic to static linking to avoid conflicts in my distributions).

I see your .zip in this thread is still dynamically linked, but I assume if you go back to an ancient enough version then the OS should have shipped with it.

Eh ... I just hope Peter can get it working. Happy to re-release this package down-compiled to the oldest version if that helps. We made it very backwards-compatible after all. (I remember the NULL vs nullptr discussion, for example!).