Problem UNABLE to get off the pad using Orbiter 2024 - ???

[CurlSnout]

What has the D3D9 log now?

Here is the new D3D9ClientLog:

 

[CurlSnout]

And, Orbiter.log looks like this:

**** Orbiter.log
000000.000: Build Dec 31 2024 [v.602931718]
000000.001: Timer precision: 1e-07 sec
000000.035: Found 0 joystick(s)
000000.240: ---------------------------------------------------------------
000000.245: BaseDir : C:\applications\simulations\ORBITER(s)\ORBITER 2024\
000000.249: ConfigDir : C:\applications\simulations\ORBITER(s)\ORBITER 2024\Config\
000000.252: MeshDir : C:\applications\simulations\ORBITER(s)\ORBITER 2024\Meshes\
000000.255: TextureDir : C:\applications\simulations\ORBITER(s)\ORBITER 2024\Textures\
000000.257: HightexDir : C:\applications\simulations\ORBITER(s)\ORBITER 2024\Textures2\
000000.261: ScenarioDir: C:\applications\simulations\ORBITER(s)\ORBITER 2024\Scenarios\
000000.264: ---------------------------------------------------------------
000000.266: D3D9 DLLs : C:\Windows\SYSTEM32\d3dx9_43.dll [v 9.29.952.3111]
000000.270: : C:\Windows\SYSTEM32\d3d9.dll [v 10.0.22621.4541]
000000.273: ---------------------------------------------------------------
000000.278: Module D3D9Client.dll ........ [Build 241231, API 241231]
000000.421: [D3D9] DX9 emulation via DX12
000000.427: [D3D9] DirectX9 Created...
000000.432: [D3D9] Initialize VideoTab...
000000.463: Loading module D3D9Client
000000.469: Module AtlantisConfig.dll .... [Build 241231, API 241231]
000000.473: Loading module AtlantisConfig (legacy interface)
000000.478: Module AtmConfig.dll ......... [Build 241231, API 241231]
000000.482: Loading module AtmConfig (legacy interface)
000000.486: Module DGConfigurator.dll .... [Build 241231, API 241231]
000000.490: Loading module DGConfigurator (legacy interface)
000002.702:
000002.712: **** Creating simulation session
000002.726: D3D9: [DirectX 9 Initialized]
000002.732: D3D9: 3D-Adapter.............. : NVIDIA GeForce RTX 3060 Ti
000002.738: D3D9: MaxTextureWidth......... : 16384
000002.743: D3D9: MaxTextureHeight........ : 16384
000002.748: D3D9: MaxTextureRepeat........ : 8192
000002.752: D3D9: VolTexAddressCaps....... : 0x3F
000002.757: D3D9: NumSimultaneousRTs...... : 4
000002.761: D3D9: VertexDeclCaps.......... : 0x3FF
000002.765: D3D9: MiscCaps................ : 0x2FCFF2
000002.769: D3D9: Separate AlphaBlend..... : Yes
000002.773: D3D9: Shadow Mapping.......... : Yes
000002.777: D3D9: D3DFMT_A16B16G16R16F.... : Yes
000002.781: D3D9: Vertex_A16B16G16R16F.... : Yes
000002.785: D3D9: Vertex_A32B32G32R32F.... : Yes
000002.789: D3D9: Vertex_R16F............. : Yes
000002.793: D3D9: Vertex_R32F............. : Yes
000002.797: D3D9: D3DFMT_A32B32G32R32F.... : Yes
000002.801: D3D9: D3DFMT_D32F_LOCKABLE.... : No
000002.805: D3D9: D3DFMT_A2R10G10B10...... : Yes
000002.808: D3D9: D3DFMT_L8............... : Yes
000002.812: D3D9: D3DDTCAPS_DEC3N......... : Yes
000002.817: D3D9: D3DDTCAPS_FLOAT16_2..... : Yes
000002.821: D3D9: D3DDTCAPS_FLOAT16_4..... : Yes
000002.825: D3D9: Runs under WINE......... : No
000002.828: D3D9: D3D9Build Date.......... : 0
000002.891: D3D9: Available Texture Memory : 4068 MB
000002.898: D3D9: [3DDevice Initialized]
000008.491: Loaded 41057 records from star database
000009.694: D3D9: [D3D9Client Initialized]
000009.786: Module Sun.dll ............... [Build 241231, API 241231]
000009.802: VSOP87(E) Sun: Precision 1.0e-06, Terms 554/6634
000009.818: Module Mercury.dll ........... [Build 241231, API 241231]
000009.826: GRAVITY MODEL: GravityModels\jgmess_160a_sha.tab LOADED, Terms 65/13040
000009.843: VSOP87(B) Mercury: Precision 1.0e-05, Terms 167/7123
000009.866: Module Venus.dll ............. [Build 241231, API 241231]
000009.872: GRAVITY MODEL: GravityModels\mod_shgj120p.a01 LOADED, Terms 65/7380
000009.876: Module VenusAtm2006.dll ...... [Build 241231, API 241231]
000009.880: Loading module VenusAtm2006 (legacy interface)
000009.884: VSOP87(B) Venus: Precision 1.0e-05, Terms 79/1710
000009.906: Module Earth.dll ............. [Build 241231, API 241231]
000009.942: GRAVITY MODEL: GravityModels\egm96_to360.tab LOADED, Terms 65/65340
000009.947: Module EarthAtmJ71G.dll ...... [Build 241231, API 241231]
000009.951: Loading module EarthAtmJ71G (legacy interface)
000009.957: VSOP87(B) Earth: Precision 1.0e-08, Terms 2564/2564

 

[GLS]

Here is the new D3D9ClientLog:

Thanks!
THe next thing you'd be loading is this
TextureLoaded [VAB_TL1.dds] PLAIN Mips=7 Format=827611204 (64,32) Flags=0x1001, 0x10C42660

Do you have the file "Textures/vab_tl1.dds", size 1152 bytes?

 

[CurlSnout]

Thanks!
THe next thing you'd be loading is this
TextureLoaded [VAB_TL1.dds] PLAIN Mips=7 Format=827611204 (64,32) Flags=0x1001, 0x10C42660

Do you have the file "Textures/vab_tl1.dds", size 1152 bytes?

Yes, I have Textures\vab_tl1.dds - Size = 1.12 KB (1152 bytes)

 

[TyraXoS]

Just chipping in to say that I have the exact same problem. I'm on Windows 10 with an NVIDIA GeForce RTX 4070 Ti, AMD Ryzen 9 3900X.

Orbiter 2016 works no problem. But with Orbiter 2024 I'm getting the same CTD and the log file ends at the same place that was posted by CurlSnout. Identical behaviour with Orbiter 2024-rc1 as well.

I just tried building from source using VS2019, but though I'm a software developer I'm not a C++ developer and am having trouble figuring out all the CMake stuff etc. I'll do what I can to help though.

 

[TyraXoS]

So I managed to build from source (using the code under the 2024 git tag) using the debug configuration windows-x64-debug and Orbiter is working perfectly.



Now what I'm trying to do is package the code as if I were making a release, with the ultimate goal being to perform a diff between my "local" release (if it still works) vs. the official release.

Unfortunately CMake is failing when generating the cache for the windows-x64-release:

1> [CMake] CMake Error at Src/Module/LuaScript/LuaInterpreter/CMakeLists.txt:27 (add_dependencies):
1> [CMake]   The dependency target "XRSound_assets" of target "LuaInterpreter" does not
1> [CMake]   exist.
1> [CMake]
1> [CMake]
1> [CMake] CMake Error at Src/Module/LuaScript/LuaInterpreter/CMakeLists.txt:27 (add_dependencies):
1> [CMake]   The dependency target "XRSound_lib" of target "LuaInterpreter" does not
1> [CMake]   exist.

Not really sure what to do here, but I'll have another look tomorrow.

By the way I don't think this is an issue with D3D9Client, or loading textures, because the issue exists even in console mode. And if you look at the Orbiter.log of a working Orbiter installation, there's a ~1s gap between loading that Earth atmosphere model and the Moon, where no doubt all sorts of unlogged/secret things are going on...

 

[CurlSnout]

So I managed to build from source (using the code under the 2024 git tag) using the debug configuration windows-x64-debug and Orbiter is working perfectly.

Now what I'm trying to do is package the code as if I were making a release, with the ultimate goal being to perform a diff between my "local" release (if it still works) vs. the official release.

Unfortunately CMake is failing when generating the cache for the windows-x64-release:

1> [CMake] CMake Error at Src/Module/LuaScript/LuaInterpreter/CMakeLists.txt:27 (add_dependencies):
1> [CMake]   The dependency target "XRSound_assets" of target "LuaInterpreter" does not
1> [CMake]   exist.
1> [CMake]
1> [CMake]
1> [CMake] CMake Error at Src/Module/LuaScript/LuaInterpreter/CMakeLists.txt:27 (add_dependencies):
1> [CMake]   The dependency target "XRSound_lib" of target "LuaInterpreter" does not
1> [CMake]   exist.

Not really sure what to do here, but I'll have another look tomorrow.

Good work (!) and congratulations on getting it to go. I will be very interested in learning more. I have downloaded/unzipped/installed Orbiter 2024 many times at this point and have not gotten any closer to resolving the issue(s) that is/are confounding me - though I thoroughly appreciate all of the suggestions and help that have been offered up by the members here.

Peace,

Sam

 

[GLS]

windows-x64-debug

You should use the x86 (32 bit) build, as that is the released version. The x64 still has some issues to work.

 

[n72.75]

So I managed to build from source (using the code under the 2024 git tag) using the debug configuration windows-x64-debug and Orbiter is working perfectly.

View attachment 41684

Now what I'm trying to do is package the code as if I were making a release, with the ultimate goal being to perform a diff between my "local" release (if it still works) vs. the official release.

Unfortunately CMake is failing when generating the cache for the windows-x64-release:

1> [CMake] CMake Error at Src/Module/LuaScript/LuaInterpreter/CMakeLists.txt:27 (add_dependencies):
1> [CMake]   The dependency target "XRSound_assets" of target "LuaInterpreter" does not
1> [CMake]   exist.
1> [CMake]
1> [CMake]
1> [CMake] CMake Error at Src/Module/LuaScript/LuaInterpreter/CMakeLists.txt:27 (add_dependencies):
1> [CMake]   The dependency target "XRSound_lib" of target "LuaInterpreter" does not
1> [CMake]   exist.

Not really sure what to do here, but I'll have another look tomorrow.

By the way I don't think this is an issue with D3D9Client, or loading textures, because the issue exists even in console mode. And if you look at the Orbiter.log of a working Orbiter installation, there's a ~1s gap between loading that Earth atmosphere model and the Moon, where no doubt all sorts of unlogged/secret things are going on...

Did you do:

git submodule init

After you cloned?

 

[misha.physics]

EnableDX12Wrapper = 1.

I was going to ask about this. Sorry if it's a wrong place here and I should ask it in another thread/create the new one.

Orbiter 2024 works perfectly for me with the default settings, namely "EnableDX12Wrapper = 0". I just wanted to try this option to look how this works, namely what the difference in performance I will get. So, I set "EnableDX12Wrapper = 1" and launched a scenario. I immediately get a black screen, but the game is loading since after a few secons I hear all game sounds. I can enable engines and hear engine sounds. But all the time I see the black screen. I can attach all needed files (logs) and make tests to try understand the problem. It's just interesting why it doesn't work for me. What should I do?

 

[GLS]

The CTD happens without a graphics engine, so it is not graphics. It is probably some file access issue or some bug that only sometimes results in a CTD (the worst kind of bug).

 

[TyraXoS]

So I managed to do some further investigation and this is what I found (on the main Orbiter 2024 installation, let's call it 2024-release):

• If I delete Textures/Earth, the log file makes its way further down to Modules/Moon.dll.
• If I delete Textures/Moon, the log file makes its way further down to Modules/Mars.dll.
• If I delete Textures/Mars, Orbiter loads and I can enter the game loop, just without the planetary textures.

Now, I installed locally three more "builds" of Orbiter by building from source with different build configurations and running cmake --install. I set PlanetTexDir to the main Orbiter 2024 folder and found that:

• x86-release DOES exhibit this behaviour (not surprising as this is the most similar build to 2024-release)
• x86-debug does NOT exhibit this behaviour
• x64-debug does NOT exhibit this behaviour

The issue is the same whether or not I have EnableDX12Wrapper set to 1.

I also tried setting the PlanetTexDir in 2024-release to my Orbiter 2016 textures folder, in case there was something wrong with the 2024 textures, but this didn't fix anything.

One other thing I found is that if I take the Modules/Server/GDIClient.dll from 2024-release and paste it in x86-debug, I get the same CTD behaviour in x86-debug. However I don't know how useful this is, as even though the issue might appear identical, the cause might be completely different. Taking the GDIClient.dll from x86-debug and pasting it in 2024-release does not fix the issue there unfortunately.

What could be the issue then? It seems that there's something present in the 2024 release builds causing the issue. As mentioned before, Orbiter 2016 continues to work fine so this has to have been introduced in 2024.

One thing I haven't tried yet is building from an earlier snapshot like 2024-rc1 (or even the current main branch). Might try that tomorrow.

I guess for now I'll run x86-debug and see how it goes. If there's anything else I can do to help solve the issue then let me know. It is annoying though that the debug builds do not show this behaviour, otherwise I could have tried debugging! Unless there's some way I can debug the release builds?

 

[CurlSnout]

I also tried setting the PlanetTexDir in 2024-release to my Orbiter 2016 textures folder, in case there was something wrong with the 2024 textures, but this didn't fix anything.

I tried this early on, hoping the issue had to do with the textures packaged with the 2024 release. And, I wanted the high-resolution textures that I'm using in Orbiter 2016 (without eating additional hard drive space). When aliasing the 2024 textures to the 2016 directory didn't work I simply copied the 2016 textures into 2024. None of that got me anywhere.

 

[GLS]

The results of the folder deletion exercise point to terrain loading, plus Earth, Moon and Mars are "the big ones" in terms of those files. At least the elevation files should be needed in a non-graphics configuration (where the problem still occurs), for surface/altitude calculations, so the "Elev" and "Elev_Mod" archive loading is probably a good place to start digging.
The problem happening (for some) in the release build and not in the debug build, points to uninitialized variables.

 

[TyraXoS]

After successfully building x86 using the RelWithDebugInfo build type option, I got this exception traceback when loading a scenario via Modules/Server/Orbiter.exe (with heap profiling enabled):

0001066d()
[Frames below may be incorrect and/or missing]
[External Code]
Orbiter.exe!Planet::Setup() Line 698
    at S:\Orbiter-build\orbiter\Src\Orbiter\Planet.cpp(698)
Orbiter.exe!Planet::Planet(char * fname) Line 427
    at S:\Orbiter-build\orbiter\Src\Orbiter\Planet.cpp(427)
Orbiter.exe!PlanetarySystem::Read(char * fname, const Config * config, void(*)(const char *, int, void *) outputLoadStatus, void * callbackContext) Line 193
    at S:\Orbiter-build\orbiter\Src\Orbiter\Psys.cpp(193)
Orbiter.exe!PlanetarySystem::PlanetarySystem(char * fname, const Config * config, void(*)(const char *, int, void *) outputLoadStatus, void * callbackContext) Line 28
    at S:\Orbiter-build\orbiter\Src\Orbiter\Psys.cpp(28)
Orbiter.exe!Orbiter::InitializeWorld(char * name) Line 285
    at S:\Orbiter-build\orbiter\Src\Orbiter\Orbiter.cpp(285)
Orbiter.exe!Orbiter::CreateRenderWindow(Config * pCfg, const char * scenario) Line 785
    at S:\Orbiter-build\orbiter\Src\Orbiter\Orbiter.cpp(785)
Orbiter.exe!Orbiter::Launch(const char * scenario) Line 714
    at S:\Orbiter-build\orbiter\Src\Orbiter\Orbiter.cpp(714)
Orbiter.exe!orbiter::LaunchpadDialog::DlgProc(HWND__ * hWnd, unsigned int uMsg, unsigned int wParam, long lParam) Line 350
    at S:\Orbiter-build\orbiter\Src\Orbiter\Launchpad.cpp(350)
[External Code]
Orbiter.exe!orbiter::LaunchpadDialog::ConsumeMessage(tagMSG * pmsg) Line 149
    at S:\Orbiter-build\orbiter\Src\Orbiter\Launchpad.cpp(149)
Orbiter.exe!Orbiter::Run() Line 1084
    at S:\Orbiter-build\orbiter\Src\Orbiter\Orbiter.cpp(1084)
Orbiter.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * __formal, char * strCmdLine, int nCmdShow) Line 246
    at S:\Orbiter-build\orbiter\Src\Orbiter\Orbiter.cpp(246)
[External Code]

The actual exception is:

Exception thrown at 0x0001066D in Orbiter.exe: 0xC0000005: Access violation executing location 0x0001066D.

Removing Elev* files does seem to bypass this particular exception...but I end up with another CTD later on...

How cooked am I?

 

[Milouse]

Hello,

I don't post here a lot. I'm mostly on the francophon forum. But i have the same issue like CurlSnout and TyraXoS, on a lower specs system (Windows 10, Nvidia Geforce GTX 1060, i5-3500 @ 3.2 GHz).

What TyraXos did is over my knowledge, but i'm able to load a scenario successfully with a limited Sol System with Orbiter_ng.exe from the public release archive.
It seems all files are presents (Orbiter-2024.zip - 2 872 278 397 bytes).

; === Configuration file for solar system ===
Name = Sol

Star1 = Sun
Planet1 = Mercury
Planet2 = Venus
Planet3 = Saturn
Saturn:Moon1 = Titan
Saturn:Moon2 = Hyperion
Planet4 = Uranus
Uranus:Moon1 = Miranda
Uranus:Moon2 = Ariel
Uranus:Moon3 = Umbriel
Uranus:Moon4 = Titania
Uranus:Moon5 = Oberon
Planet5 = Neptune
Neptune:Moon1 = Triton
Neptune:Moon2 = Proteus
Neptune:Moon3 = Nereid

When i add Earth, Mars, Vesta, Jupiter and other Saturn's moon (one at a time), i get a CTD. No prob with Hyperion.dll activated in the Hyperion.cfg file.
Tested with the ...\Scenarios\The Solar System\Venus.scn
Orbiting vessels or space stations around deleted planets/moons are floating in space, but the scenarios are working (but not with the landed vessels, that's normal).

When Vesta, Jupiter and other Saturn's moons are present, the scenario seems loading until the DeltaGlider.dll, and not just right at the celestial body.

Orbiter with built-in engine (Orbiter.exe) run without problem, without tweakings.

Thanks to all people for the help provided.


Milouse

 

[GLS]

Orbiter with built-in engine (Orbiter.exe) run without problem, without tweakings.

Does it run ok in Orbiter_NG.exe with MOGE instead of D3D9?

 

[n72.75]

@CaptainSwag101 is this related in any way to the issue that /LARGEADDRESSAWARE fixes?

It's happening for at least 3(?) people.

After successfully building x86 using the RelWithDebugInfo build type option, I got this exception traceback when loading a scenario via Modules/Server/Orbiter.exe (with heap profiling enabled):

0001066d()
[Frames below may be incorrect and/or missing]
[External Code]
Orbiter.exe!Planet::Setup() Line 698
    at S:\Orbiter-build\orbiter\Src\Orbiter\Planet.cpp(698)
Orbiter.exe!Planet::Planet(char * fname) Line 427
    at S:\Orbiter-build\orbiter\Src\Orbiter\Planet.cpp(427)
Orbiter.exe!PlanetarySystem::Read(char * fname, const Config * config, void(*)(const char *, int, void *) outputLoadStatus, void * callbackContext) Line 193
    at S:\Orbiter-build\orbiter\Src\Orbiter\Psys.cpp(193)
Orbiter.exe!PlanetarySystem::PlanetarySystem(char * fname, const Config * config, void(*)(const char *, int, void *) outputLoadStatus, void * callbackContext) Line 28
    at S:\Orbiter-build\orbiter\Src\Orbiter\Psys.cpp(28)
Orbiter.exe!Orbiter::InitializeWorld(char * name) Line 285
    at S:\Orbiter-build\orbiter\Src\Orbiter\Orbiter.cpp(285)
Orbiter.exe!Orbiter::CreateRenderWindow(Config * pCfg, const char * scenario) Line 785
    at S:\Orbiter-build\orbiter\Src\Orbiter\Orbiter.cpp(785)
Orbiter.exe!Orbiter::Launch(const char * scenario) Line 714
    at S:\Orbiter-build\orbiter\Src\Orbiter\Orbiter.cpp(714)
Orbiter.exe!orbiter::LaunchpadDialog::DlgProc(HWND__ * hWnd, unsigned int uMsg, unsigned int wParam, long lParam) Line 350
    at S:\Orbiter-build\orbiter\Src\Orbiter\Launchpad.cpp(350)
[External Code]
Orbiter.exe!orbiter::LaunchpadDialog::ConsumeMessage(tagMSG * pmsg) Line 149
    at S:\Orbiter-build\orbiter\Src\Orbiter\Launchpad.cpp(149)
Orbiter.exe!Orbiter::Run() Line 1084
    at S:\Orbiter-build\orbiter\Src\Orbiter\Orbiter.cpp(1084)
Orbiter.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * __formal, char * strCmdLine, int nCmdShow) Line 246
    at S:\Orbiter-build\orbiter\Src\Orbiter\Orbiter.cpp(246)
[External Code]

The actual exception is:

Exception thrown at 0x0001066D in Orbiter.exe: 0xC0000005: Access violation executing location 0x0001066D.

Removing Elev* files does seem to bypass this particular exception...but I end up with another CTD later on...

How cooked am I?

 

[n72.75]

The results of the folder deletion exercise point to terrain loading, plus Earth, Moon and Mars are "the big ones" in terms of those files. At least the elevation files should be needed in a non-graphics configuration (where the problem still occurs), for surface/altitude calculations, so the "Elev" and "Elev_Mod" archive loading is probably a good place to start digging.
The problem happening (for some) in the release build and not in the debug build, points to uninitialized variables.

Actually, this too. An intermittent access violation is a smoking gun here. Uninitialized pointer math or something horrifying like that...

 

[TyraXoS]

@CaptainSwag101 is this related in any way to the issue that /LARGEADDRESSAWARE fixes?

For what it's worth, adding that option (as done here) did not fix the issue for me.