Software Why the heck isn't TransX2 working in Orbiter 2016?

MichaelMarz

New member
Joined
Jan 21, 2018
Messages
8
Reaction score
0
Points
0
Location
Eugene
Well, it's Day 2 with Orbiter 2016 and I haven't been able to get Transx 2 to install. D3D9 Client is installed and working. Orbiter Sound is installed and sounds great.

The files I used are ModuleMessagingExt v1.1 and TransX-2016.04.04-MMExt-2016.

I've followed Tex's instructions at
. The Modules section shows TransX2 and I selected it, so clearly something installed, but when I launch the Delta-glider "Docked at ISS" scenario, the same one Tex used, TransX does not appear on the MFD, exactly unlike what Tex demonstrated.

This is a real puzzle to me because I can't see what I could have done wrong. Does anyone have any ideas? I'd like to try a different module to see if it would work, but I'm not familiar with them so fear I might just screw something up.

Michael
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,404
Reaction score
581
Points
153
Location
Vienna
Does anyone have any ideas?

A first analysis of the orbiter.log could help in these cases. Could you post it here, please? It is located in the root folder and contains human-readable text.

Do you use pristine Orbiter 2016 or beta versions from SVN?
 

Ripley

Tutorial translator
Donator
Joined
Sep 12, 2010
Messages
3,135
Reaction score
409
Points
123
Location
Rome
Website
www.tuttovola.org
...TransX does not appear on the MFD...
Could it be that you have more modules installed then Tex, and your TransX2 is on the MFD's second page?
...then, why TransX2, and not just TransX?


Ah, sorry! Scratch what I said.
You only see TransX2 and not TransX.

Orbiter includes a very old TransX module by default.
The OH TransX download includes 2 newer TransX modules, one obviously called "TransX.dll" - which overwrites the default - and another "TransX2.dll", to be used (IIRC from the old release post) "only in some special cases, when just one TransX is not enough", and using 2 "combined" TransXs is intended for advanced Orbinauts indeed.
Keep in mind that the two modules are identical, so as a last resort, you can just use TransX2 as you would use TransX.

But check in your Orbiter_ROOT\Modules\Plugin folder if you have both. You definitely should.
 
Last edited:

MichaelMarz

New member
Joined
Jan 21, 2018
Messages
8
Reaction score
0
Points
0
Location
Eugene
TransX2 issue

Thank you all for your suggestions. I would make no progress if it wasn't for your helpfulness.

Orbiter2016 is pristine. No mods, no betas.

Before TransX2 installation the only Trans*.dll in Orbiter2016 folder and subfolders was TransX.dll and it was located in the Orbiter root directory C:\Orbiter2016\Modules\Plugin.

After TransX2 installation both TransX.dll and TransX2 exist and are located in the Orbiter root directory C:\Orbiter2016\Modules\Plugin.

I've attached the log, or I have if I've done it properly. There are several errors but I don't know what to make of them.

Many thanks. - Michael
 

MichaelMarz

New member
Joined
Jan 21, 2018
Messages
8
Reaction score
0
Points
0
Location
Eugene
Another wrinkle - TransX2 works in XP

Evidently the admin person hasn't posted my last update from early this morning, which basically just said that I installed TransX2 per instructions and used the original Orbiter 2016 program, in answer to helpful inquiries.

There were no problems with installing TransX2 in an XPSP3 machine. I followed the same process, of course.

The system I want Orbiter to work on is Win 10, or did I not mention that? Does anyone know of Win 10 issues?

Thanks again for all your help. I hope the admin will stop stepping on the hose so I can post and get a reply without having to wait a day.

Michael
 

MichaelMarz

New member
Joined
Jan 21, 2018
Messages
8
Reaction score
0
Points
0
Location
Eugene
Missing post

Here's an approximation of the post I thought was sent this morning, but had to wait for admin, and somehow got lost, I guess. The log is attached.

Orbiter2016 is pristine. No mods, no betas.

Before TransX2 installation the only Trans*.dll in Orbiter2016 folder and subfolders is TransX.dll and it is located in the Orbiter root directory C:\Orbiter2016\Modules\Plugin.

After TransX2 installation both TransX.dll and TransX2 exist and are located in the Orbiter root directory C:\Orbiter2016\Modules\Plugin.


--- In case the attachment didn't work, here's the beginning of the log:

**** Orbiter.log
000000.000: Build Aug 28 2016 [v.160828]
000000.000: Timer precision: 2.55489e-007 sec
000000.000: Found 1 joystick(s)
000000.000: Module AtlantisConfig.dll .... [Build 160828, API 160828]
000000.000: Module AtmConfig.dll ......... [Build 160828, API 160828]
000000.000: Module DGConfigurator.dll .... [Build 160828, API 160828]
000000.000: Module D3D9Client.dll ........ [Build 170705, API 160828]
000000.000: Module ScnEditor.dll ......... [Build 160828, API 160828]
000000.000: Module OrbiterSound.dll ...... [Build 121120, API 100830]
============================ ERROR: ===========================
Failed loading module Modules\Plugin\TransX2.dll (code 126)
[Orbiter::LoadModule | .\Orbiter.cpp | 600]
===============================================================
000000.000:
000000.000: **** Creating simulation session
 

Attachments

  • Orbiter.log
    11.1 KB · Views: 2

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,953
Reaction score
2,971
Points
188
Website
github.com
Here's an approximation of the post I thought was sent this morning, but had to wait for admin, and somehow got lost, I guess. The log is attached.

Orbiter2016 is pristine. No mods, no betas.

Before TransX2 installation the only Trans*.dll in Orbiter2016 folder and subfolders is TransX.dll and it is located in the Orbiter root directory C:\Orbiter2016\Modules\Plugin.

After TransX2 installation both TransX.dll and TransX2 exist and are located in the Orbiter root directory C:\Orbiter2016\Modules\Plugin.


--- In case the attachment didn't work, here's the beginning of the log:

**** Orbiter.log
000000.000: Build Aug 28 2016 [v.160828]
000000.000: Timer precision: 2.55489e-007 sec
000000.000: Found 1 joystick(s)
000000.000: Module AtlantisConfig.dll .... [Build 160828, API 160828]
000000.000: Module AtmConfig.dll ......... [Build 160828, API 160828]
000000.000: Module DGConfigurator.dll .... [Build 160828, API 160828]
000000.000: Module D3D9Client.dll ........ [Build 170705, API 160828]
000000.000: Module ScnEditor.dll ......... [Build 160828, API 160828]
000000.000: Module OrbiterSound.dll ...... [Build 121120, API 100830]
============================ ERROR: ===========================
Failed loading module Modules\Plugin\TransX2.dll (code 126)
[Orbiter::LoadModule | .\Orbiter.cpp | 600]
===============================================================
000000.000:
000000.000: **** Creating simulation session

There's your problem. I recall some users had this or a similar issue... I don't know if/how it was solved, but you should search the forum for that "code 126".
 

MichaelMarz

New member
Joined
Jan 21, 2018
Messages
8
Reaction score
0
Points
0
Location
Eugene
Solved

Searching the forum for code 126 was futile, but a Google search for Orbiter + 126 found some posts that pointed me back to ModuleMessagingExt for Orbiter 2016 v1.1.zip. I had been using ModuleMessagingExt v1.1.zip, which I had been sure was the correct version. I also learned a little about the error code and it means that something the dll needs is missing. So, another look at Hangar Mods revealed that I'd been overlooking a requirement: VS2015 redist. So, I installed that and ModuleMessagingExt for Orbiter 2016 v1.1 in the Win 10 64 bit PC. Now TransX2 is where it belongs.

Thank you all. I hope this helps someone else if the need arises.

Michael:)
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
Hi MichaelMarz ... our old Error 126 strikes again. So glad to see you fixed it.

This has been an active discussion for us developers for a while, and we have a plan to eliminate it.

As you correctly found out, your module's code (TransX2.dll) was linked in such a way to require the Visual C++ runtime redistributable to be there. (What's a runtime? It's common code to implement C and C++ standard calls we all use in C++ apps). You are required to install each runtime yourself (as we have no common installer), and then it all works. If not, you get an Error 126 on the LoadLibrary() windows call, and you lose the module from the simulator.

Why do developers compile like this? Two reasons: (1) if you ever create a standard template library object from one module and delete from another, and you have different runtimes, then bad things will typically happen. And (2) if there's a security bug in a runtime such that you need to release an urgent Microsoft patch to fix it, then you can replace the runtime with the updated one, and fix the issue.

There's an alternative, and this is where we are all ending up: you can statically link the runtime before release. This makes the DLL files bigger (by 100-200K .. i.e. not a problem), but eliminates the problems with runtimes. As for other modules using and trying to delete my standard template library objects ... well that's where Module Messaging jumps in to allow such things to be transferred and deleted safely.

So basically - on behalf of the developer community: sorry for the error 126. We know how to fix it, and in a few years' time we will eliminate it! (Why years? Because all DLLs need to be recompiled and re-released, and then the static dependencies on the utility DLLs like Module Messaging all need to be updated too.) We could all do it tomorrow, but this is not our day jobs!
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,404
Reaction score
581
Points
153
Location
Vienna
So basically - on behalf of the developer community: sorry for the error 126. We know how to fix it, and in a few years' time we will eliminate it! (Why years? Because all DLLs need to be recompiled and re-released, and then the static dependencies on the utility DLLs like Module Messaging all need to be updated too.) We could all do it tomorrow, but this is not our day jobs!

Erm. I think this statement paints a picture to a newcomer that is not true: the one of the coherent developer community. There is none.
It sounds like there is a council or somesuch that decides which direction to go. There is none.
Every developer in the Orbiter community is free to go his own way, and many do, even if some manage to form teams to shoulder bigger projects.

So chances are that some addons will never be recompiled, simply because the original author chose to make them "all rights reserved" and headed off to greener pastures.
Chances also are that some addons are recompiled the next day, simply because the original author is still enthusiastic regarding Orbiter, or because the addon is open-sourced and another developer carries on with the torch.
 
Top