Problem LTMFD = Orbiter App Crashes

[LTrotsky]

Hello :

Downloaded the Lunar Transfer MFD, along with the IMFD. Only LTMFD and BurnTimeCalc add-ons are installed and in use, however.

I have a "training" mission set up where I begin from Brighton Beach. It is relevant to add that getting to BB involved using LTMFD for the first time, and it worked beautifully - the moon orbit was dead on the BB plane, so it was a real relief to get into a low orbit on the same plane as BB and not having to do a ridiculous amount of burn to align plane. Landing on Pad 1 was 7.62 meters from center.

Attempted the Earth Return portion of the mission, but the application has crashed twice, at more or less the exact same time of the mission. This is the first time that Orbiter has crashed on my system, and the only difference is that I am now using an add-on.

I believe there is a bug or some kind of addressable incompatibility. I am not sure what to do to assist in the process of discovering the problem with the add-on, if that is the issue, so some guidance is needed.

---------- Post added at 03:45 PM ---------- Previous post was at 03:07 AM ----------

Here is the log file from the scenario.

**** Orbiter.log
Build Aug 30 2010 [v.100830]
Timer precision: 5.39902e-007 sec
Found 0 joystick(s)
Devices enumerated: 6
Devices accepted: 5
==> RGB Emulation
==> Direct3D HAL
==> Direct3D T&L HAL
==> Direct3D HAL (AMD Radeon HD 7640G)
==> Direct3D T&L HAL (AMD Radeon HD 7640G)
Module AtlantisConfig.dll .... [Build 100830, API 100830]
Module AtmConfig.dll ......... [Build 100830, API 100830]
Module DGConfigurator.dll .... [Build 100830, API 100830]
Module OrbiterSound.dll ...... [Build 121120, API 100830]
Module transx.dll ............ [Build 110130, API 100830]
Module ScnEditor.dll ......... [Build 100830, API 100830]
Module ScriptMFD.dll ......... [Build 100830, API 100830]
Module ExtMFD.dll ............ [Build 100830, API 100830]
Module LuaMFD.dll ............ [Build 100830, API 100830]
Module LunarTransferMFD.dll .. [Build 100621, API 100603]
Module BurnTimeCalculator.dll  [Build 110301, API 100830]
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: oapiRegisterMFDMode
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
Module AeroBrakeMFD.dll ...... [Build ******, API 100830]

**** Creating simulation session
DirectDraw interface OK
Direct3D interface OK
Graphics: Viewport: Fullscreen 1600 x 900 x 32
Graphics: Hardware T&L capability: Yes
Graphics: Z-buffer depth: 32 bit
Graphics: Active lights supported: 8
Loading 15382 records from star database
Module Sun.dll ............... [Build 100830, API 100830]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll ........... [Build 100830, API 100830]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll ............. [Build 100830, API 100830]
Module VenusAtm2006.dll ...... [Build 100830, API 100830]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll ............. [Build 100830, API 100830]
Module EarthAtmJ71G.dll ...... [Build 100830, API 100830]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
Module Moon.dll .............. [Build 100830, API 100830]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 100830, API 100830]
Module MarsAtm2006.dll ....... [Build 100830, API 100830]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll ............ [Build ******, API 060425]
Module Deimos.dll ............ [Build ******, API 060425]
Module Galsat.dll ............ [Build 100217, API 100215]
Module Jupiter.dll ........... [Build 100830, API 100830]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Module Io.dll ................ [Build 100217, API 100215]
Module Europa.dll ............ [Build 100217, API 100215]
Module Ganymede.dll .......... [Build 100217, API 100215]
Module Callisto.dll .......... [Build 100217, API 100215]
Module Satsat.dll ............ [Build 100215, API 100212]
Module Saturn.dll ............ [Build 100830, API 100830]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
Module Mimas.dll ............. [Build 100215, API 100212]
SATSAT Mimas: Terms 113
Module Enceladus.dll ......... [Build 100215, API 100212]
SATSAT Enceladus: Terms 33
Module Tethys.dll ............ [Build 100215, API 100212]
SATSAT Tethys: Terms 101
Module Dione.dll ............. [Build 100215, API 100212]
SATSAT Dione: Terms 59
Module Rhea.dll .............. [Build 100215, API 100212]
SATSAT Rhea: Terms 68
Module Titan.dll ............. [Build 100215, API 100212]
SATSAT Titan: Terms 100
Module Iapetus.dll ........... [Build 100215, API 100212]
SATSAT Iapetus: Terms 605
Module Uranus.dll ............ [Build 100830, API 100830]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
Module Miranda.dll ........... [Build ******, API 060425]
Module Ariel.dll ............. [Build ******, API 060425]
Module Umbriel.dll ........... [Build ******, API 060425]
Module Titania.dll ........... [Build ******, API 060425]
Module Oberon.dll ............ [Build ******, API 060425]
Module Neptune.dll ........... [Build 100830, API 100830]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
Finished initialising world
Module DeltaGlider.dll ....... [Build 100830, API 100830]
Module LuaInline.dll ......... [Build 100830, API 100830]
---------------------------------------------------------------
>>> ERROR: Missing texture: DeltaGliderEX\DGex_strobe.dds
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 750]
---------------------------------------------------------------
---------------------------------------------------------------
>>> ERROR: Missing texture: DeltaGliderEX\DGex_strobe2.dds
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 750]
---------------------------------------------------------------
---------------------------------------------------------------
>>> ERROR: Missing texture: DeltaGliderEX\DGex_strobe3.dds
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 750]
---------------------------------------------------------------
---------------------------------------------------------------
>>> ERROR: Missing texture: DeltaGliderEX\DGex_light.dds
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 750]
---------------------------------------------------------------
Module Delta4M4.dll .......... [Build 110318, API 100830]
Module Lpad.dll .............. [Build 101001, API 100830]
Finished initialising status
Finished initialising camera
Finished initialising panels
Finished setting up render state
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: oapiGetStationCount
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
ERROR: DDraw object is still referenced: 342
---------------------------------------------------------------
>>> ERROR: Destroy framework objects failed
>>> [OrbiterGraphics::Exit3DEnvironment | .\OGraphics.cpp | 1034]
---------------------------------------------------------------
**** Closing simulation session

I should note that the LunarTransferMFD is referencing a 100603 API, while all the others are referencing the later API.

I installed the DeltaGliderExperimental ship, which is a heavy lift glider that I am "working up" to using, but am not sure why the textures are missing from that.

The app crash on the Earth Return in this scenario, after following all the LunarTransferMFD instructions, happens around mid-point to Earth Return, perhaps when the MFD is going to switch to a new "stage" or something. Not sure.

I can post more info, and if necessary the scenario for testing. I am attempting to get a video maker working to enable people to view the flight, the use of the MFD, and in this instance the application crash.

 

[dgatsoulis]

I have never used LTMFD, since I can do pretty much anything I want with TransX and IMFD, so I am not sure how much help I can be here.

To narrow down the possibilities do this:

Delete all the other ships in the scenario (if you have any) and replace the DeltagliderEX with the standard DeltaGlider. Fly the mission again and make a quicksave right after the Trans Earth Injection burn.

Exit and run that quicksave scenario.

Advance the time forward and keep a reference for when the crash happens (if it happens again this time). For example:

The crash happens when OrbitMFD referenced to Earth says "G 0.40"

or

The crash happens at simtime (upper right corner) ~80000

Post the quicksave scenario with the reference for when to wait for the crash and you Orbiter.log file (again).

If the crash doesn't happen this time, it means that the problem was with the DGEX or some other vessel/addon present in your scenario.

 

[LTrotsky]

I will do that. But it seems odd to me that a vehicle that is parked on KSC would cause an application crash, especially when the takeoff from KSC, where the vehicle is parked, and lunar transit worked fine. Thanks again Dgatsoulis.

Edit : As you probably figured out already: I looked through the DeltaEx install package, and there are no dds files for the strobe or vehicle lights. This would account for those entries in the log. I suppose the fix for that is to somehow refer the DgEx to the default lighting dds files. (working).

Edit2 : Looking at various config files. Am deleting reference to DGEx (the ship with no lighting dds files) from the training scenario. I notice that the status of the DG landed at BB pad1 is "orbiting moon". Question : is a ship landed at BB pad1 supposed to be status orbiting moon or something else?

 

[dgatsoulis]

Question : is a ship landed at BB pad1 supposed to be status orbiting moon or something else?

The status of a landed ship should be ...ehm landed. :lol:
For that to happen the ship needs to be completely stopped, with all the autopilots switched off.

If you have forgotten an autopilot on (KILLROT, HLEVEL) or sometimes when you run Orbiter with a very high frame-rate you may leave the ship in "Orbiting" Status when you exit the scenario.

I don't think the problem is from the textures. A missing texture wouldn't cause a CTD half way to Earth. But when you run into this kind of trouble, it is best to strip the installation and the scenario to the default and then add them one by one until you detect where the problem is.

 

[LTrotsky]

Ran the same scenario with the following changes, to within 1 hour of Earth Periapsis (well beyond the previous application crash point).

1. Eliminated reference to DGex vessel (so nothing from the DGex install loads).

2. Changed status of DG-S at KSC from "Orbiting Earth" to "Landed Earth". I am not sure why this DG-S had that status, as in the environment scenario and other saves it is Landed Earth.

5 Quicksaves during flight were made.

Abbreviated Flight Telemetry (for grins)

Sim Time	Flight Time	G	Hud	OrbitMFD (ref Earth)

39845		11:00:53	nr	Sun	nr
50524		14:02		0.40	"	PeA = -113.3k; PeT = 125.2k
72055		20:00:52	0.48	"	+42.63k; 	104.0k
74023		20:33:46	0.49	Earth	50.73k; 	102.2k	
90041		25:00:42	0.55	"	96.70; 		86.27k
108169		30:02:50	0.63	"	121.90k; 	68.20k
144078		40:01:16	0.83	"	135.6k; 	32.33k
172837		48:05:38	0.99	"	135.3; 		3571s

	Additional Telemetry final capture 
	OS = 5.810km/s	Alt = 17,180km

Conclusion :

1 of 2 possibilities : 1) the scenario had corrupted information regarding the status of the DG-S landed at KSC, and was reporting it as status Orbiting Earth even though it was on the runway at KSC. 2) Something about the fact that the DGex lacking dds files for vessel lighting causes a CTD, when the status of the in-flight vessel changes from Orbiting Sun to Orbiting Earth during the Earth Return. Note this landed vessel has lights turned on as well.

Edit : It seems possible that my method for creating scenarios and environments may be messed up. To create an environment, I load various add-ons, then get the vessels or other stuff in the positions I want for that environment, and do a quicksave. Then I rename the quicksave to a filename that describes the scenario (and I may add text to the description section of the scn file). And, that's it. This method does not rename any other folder or file, and I am thinking that the data in the "flights" folder related to the original scenario (from whence the environment is made) no longer references the newly created scenario file - and may thereby cause problems when using the new file. Am I on the right track here? So far I have only created 1 environment - which I call the training environment, which upon launch uses whatever the current datetime (from my system), has two additional ships (the DGex and one of the Delta4 rockets (with the necessary launch pad at KSC) and has the following MFD add-ons : LunarTransfer, AeroBrake, BurnTimeCalc, and the UMmu and UCGO package (which I haven't really figured out how to incorporate usefully into a created environment).

 

[dgatsoulis]

Another thing to do now is to run the scenario that was causing the crash
(DGEX etc) without LTMFD. Disable it from the modules tab in the Orbiter launchpad. If the scenario doesn't crash then it was an LTMFD problem.

A few general instructions for more stable scenarios:

1. If you are not going to use it, lose it.
There is no reason to load meshes, textures and .dlls for something that you are not going to use during the scenario. It saves loading time and bug-hunting time when something goes wrong.

2. In case of a bug or CTD, don't change many things at once. It makes hunting the bug more difficult. Try changing things one by one and always keep a reference for when the bug occured so you (and others) can reproduce the exact same conditions.

For example in your situation you should have followed this line of actions.

a. Got a crash.
b. Repeat the scenario and get a crash again. This time make a note of a specific reference when the crash occured. (simtime, orbitMFD, when I press x button, etc)
c. Disable all non-stock MFDs in Orbiter Launchpad and repeat the scenario.
c1.If the crash still occurs it wasn't an MFD. (Move to "d")
c2.If the crash doesn't occur it was an MFD. Add the non-stock MFDs one by one and repeat the scenario until you detect which MFD causes the problem.
d. (from c1) It wasn't an MFD so it must be a ship. Delete all the ships except the one you are flying and repeat the scenario. If the crash occurs again, the problem is that ship. If it doesn't the problem is one of the other ships in the scenario. Add one more ship and repeat until you find the one causing the problem.

There is always the case that you won't be able to find what is causing the problem even if you follow these steps. Don't worry, you have a whole community of people who can and will help you.

But you need to help them help you. Some of the things below you already did, but it would be best if you did them all from the first post:

Provide a clear description of the problem.

Provide the Orbiter.log file. Many of the experts here can tell you what's wrong just by looking at that. Especially for scenarios that don't start. Crashes during a scenario are a bit more difficult to catch, so we need more info.

Provide links to the addons you were using when you got the problem. Others shouldn't have to search for them, it's your job to provide a quick and easy way to reproduce the problem.

Provide the scenario during which the problem occurs, with a specific reference of when the problem occurs. This is very important, since it's the only way others can reproduce the same conditions you have and see if the problem persists on their end.

Hope this helps

 

[LTrotsky]

Your above post is an excellent guide to bug replication, reporting, and analysis. Unfortunately, the original scn file in which the crash occurred at roughly the same sim time (about the mid-point of the flight from moon to earth) no longer exists. I made the changes above without saving an unmodified copy. However, it would be very easy to manually re-create the suspect scn file with a cut and paste from the environment file.

The scenario in which the crash occurred was a scn file derived from an environment file. What this means is : I load a scn file I call "the environment file", and then save it as a specific mission (or training) scenario - I might set up some MFD views, and for example enter coms data into the com/nav MFD, then save, and take that file and rename it, and move it into the custom scenario folder under a specific training mission folder. The environment file is, as I mentioned above, something I created : I wanted to have a real world environment with a few additions, and the possibility of 'building' a space program out of KSC. So, after my training, I will run 'real' missions with the object of building a space station, a base, assembling long range vessels in orbit or on the moon with the capability of interstellar travel - but I want this all to be the result of my own flights. With each successful 'real' mission, the main environment scn file will reflect the additional capability, vehicles, bases, and so on (I may have to cut and paste data from various files to the environment file to accomplish this). In short, it is kind of like my own space program. (Incidentally, I was a huge fan of the Buzz Aldrin Race Into Space game. Possibly, that is obvious :lol.

The point however, is that I may be trying to do something that causes crashes in otherwise stable code.

I will attempt to re-create the scn file state that existed when the two app crashes occurred, run it, report it, and if there is a crash post the file. Not sure how useful this will be for others unless they have the same add-ons.

 

[dgatsoulis]

Not sure how useful this will be for others unless they have the same add-ons.

That's why you also need to provide the links to the addons needed to run the scenario you are going to post. Not just the names of the addons but the links.
Do this only after you have narrowed down the possible sources of the problem.
If you have a scenario with 10 different addons required to run it, nobody is going to download all of them just to help you and it will be difficult to find someone that already has that particular combination of addons.
That's why you need to first narrow down the possible sources of the problem and only then post the scenario with as few addons as possible.