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

A few more findings today:

If I set TileFormat = 1 in the Earth.cfg, Moon.cfg and Mars.cfg files, Orbiter starts successfully in console mode. But running with the D3D9client causes the program to CTD after the scene has initialized. I.e. the last lines in Orbiter.log look like this:

Code: 
000025.669: D3D9: [Scene Initialized]
000025.888: Finished initialising panels
I'm guessing this is because those surface textures simply do not support TileFormat = 1? Removing the planet folders in Textures does not cause a CTD.

Some stepping through the code allowed me to narrow down the location where the access violation seems to occur:

Code: 
Orbiter.exe!ZTreeMgr::Inflate(const unsigned char * inp, unsigned long ninp, unsigned char * outp, unsigned long noutp) Line 207
    at S:\Orbiter-build\orbiter\Src\Orbiter\ZTreeMgr.cpp(207)
Orbiter.exe!ZTreeMgr::ReadData(unsigned long idx, unsigned char * * outp) Line 191
    at S:\Orbiter-build\orbiter\Src\Orbiter\ZTreeMgr.cpp(191)
[Inline Frame] Orbiter.exe!ZTreeMgr::ReadData(int) Line 97
    at S:\Orbiter-build\orbiter\Src\Orbiter\elevmgr.cpp(167)
Orbiter.exe!ElevationManager::LoadElevationTile(int lvl, int ilat, int ilng, double tgt_res) Line 167
    at S:\Orbiter-build\orbiter\Src\Orbiter\elevmgr.cpp(167)
Orbiter.exe!ElevationManager::Elevation(double lat, double lng, int reqlvl, std::vector<ElevationTile,std::allocator<ElevationTile>> * tilecache, Vector * normal, int * reslvl) Line 372
    at S:\Orbiter-build\orbiter\Src\Orbiter\elevmgr.cpp(372)
Orbiter.exe!Planet::Elevation(double lng, double lat) Line 984
    at S:\Orbiter-build\orbiter\Src\Orbiter\Planet.cpp(984)
Orbiter.exe!Base::Setup() Line 340
    at S:\Orbiter-build\orbiter\Src\Orbiter\Base.cpp(340)
Orbiter.exe!Planet::Setup() Line 700
    at S:\Orbiter-build\orbiter\Src\Orbiter\Planet.cpp(700)
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]
[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]
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]

Specifically, line 372 in elevmgr.cpp is the elevation tile loading loop, and the exception only occurs after the value of lvl falls to 6 (down from the initial value of 14). I'm guessing this points to some heap corruption that only kicks in after a certain number of tiles have been loaded.
 
  • Like
Reactions: GLS
TyraXoS said:
A few more findings today:

If I set TileFormat = 1 in the Earth.cfg, Moon.cfg and Mars.cfg files, Orbiter starts successfully in console mode. But running with the D3D9client causes the program to CTD after the scene has initialized. I.e. the last lines in Orbiter.log look like this:

Code: 
000025.669: D3D9: [Scene Initialized]
000025.888: Finished initialising panels
I'm guessing this is because those surface textures simply do not support TileFormat = 1? Removing the planet folders in Textures does not cause a CTD.

Some stepping through the code allowed me to narrow down the location where the access violation seems to occur:

Code: 
Orbiter.exe!ZTreeMgr::Inflate(const unsigned char * inp, unsigned long ninp, unsigned char * outp, unsigned long noutp) Line 207
    at S:\Orbiter-build\orbiter\Src\Orbiter\ZTreeMgr.cpp(207)
Orbiter.exe!ZTreeMgr::ReadData(unsigned long idx, unsigned char * * outp) Line 191
    at S:\Orbiter-build\orbiter\Src\Orbiter\ZTreeMgr.cpp(191)
[Inline Frame] Orbiter.exe!ZTreeMgr::ReadData(int) Line 97
    at S:\Orbiter-build\orbiter\Src\Orbiter\elevmgr.cpp(167)
Orbiter.exe!ElevationManager::LoadElevationTile(int lvl, int ilat, int ilng, double tgt_res) Line 167
    at S:\Orbiter-build\orbiter\Src\Orbiter\elevmgr.cpp(167)
Orbiter.exe!ElevationManager::Elevation(double lat, double lng, int reqlvl, std::vector<ElevationTile,std::allocator<ElevationTile>> * tilecache, Vector * normal, int * reslvl) Line 372
    at S:\Orbiter-build\orbiter\Src\Orbiter\elevmgr.cpp(372)
Orbiter.exe!Planet::Elevation(double lng, double lat) Line 984
    at S:\Orbiter-build\orbiter\Src\Orbiter\Planet.cpp(984)
Orbiter.exe!Base::Setup() Line 340
    at S:\Orbiter-build\orbiter\Src\Orbiter\Base.cpp(340)
Orbiter.exe!Planet::Setup() Line 700
    at S:\Orbiter-build\orbiter\Src\Orbiter\Planet.cpp(700)
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]
[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]
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]

Specifically, line 372 in elevmgr.cpp is the elevation tile loading loop, and the exception only occurs after the value of lvl falls to 6 (down from the initial value of 14). I'm guessing this points to some heap corruption that only kicks in after a certain number of tiles have been loaded.
Click to expand...
Is this all with TileFormat = 1*, or is the call stack from the normal setup?


*) That is the old surface tile format, that should only have surface textures, so no terrain data.
 
What are the arguments of ZTreeMgr::Inflate() when it crashes there? I see nothing there that could cause problems, it only calls the zlib function uncompress(), so it could be a bad argument going to zlib.
 
Code: 
this
0x04b2abc8 {path=0x04ae4910 "S:/Orbiter-2024/Textures\\Earth" layer=LAYER_ELEV (2) treef=0x072a4f48 {...} ...}
    path: 0x04ae4910 "S:/Orbiter-2024/Textures\\Earth"
    layer: LAYER_ELEV (2)
    treef: 0x072a4f48 {_Placeholder=0x00bbe977 }
    toc: {tree=0x04b70840 {pos=0 size=134262 child=0x04b7084c {1, 587, 1480, 1879} } ntree=6201 ntreebuf=6201 ...}
    rootPos1: 4294967295
    rootPos2: 4294967295
    rootPos3: 4294967295
    rootPos4: 0x04b2abfc {0, 2522}
    dofs: 198480

inp
0x04ba1ef8  <Invalid characters in string.>

*inp
120 'x'

ninp
9431

noutp
67181

outp
0x04ba43d8  <Invalid characters in string.>

*outp
192 '�'

I just now realised that the CTD happens the first time ZTreeMgr::Inflate() is called. For previous iterations of the elevation tile loading loop (lvl > 6) this function is never reached. Instead, ZTreeMgr::ReadData returns on the first line (the "sanity check"). But when lvl = 6, ZTreeMgr::Inflate() is eventually called for the first time.
 
Hello,

GLS said:
Does it run ok in Orbiter_NG.exe with MOGE instead of D3D9?
Click to expand...
Orbiter_NG.exe in D3D7Client option get to a CTD, whatever the choice in 3D device frame (RGB Emulation, Direct3D HAL...).
I read in the Orbiter 2024 Release topic that resolution higher than 1920 x 1080 doesn't work in this mode. It's the native resolution of my screen, so i usually use it.

For my knowledge, what MOGE exactly means, please ? (GE = Graphic Engine seems right).


Milouse
 
GLS said:
What are the arguments of ZTreeMgr::Inflate() when it crashes there? I see nothing there that could cause problems, it only calls the zlib function uncompress(), so it could be a bad argument going to zlib.
Click to expand...
I'm unable to replicate the crash on my end, however, this is what I get break-pointing ZTreeMgr::Inflate() on the first call.

1736714835430.png

The only change I can see to ZTreeMgr.cpp in the git-blame since Orbiter was added to Git, was: https://github.com/orbitersim/orbit...9b98d771cb24d69d403e5c74399744410bc39c4e8fbb4

These should actually help with this sort of crash though:

1736715230766.png
 
Thanks @n72.75 I'll dig a little deeper on this tomorrow. Can I confirm that you are debugging the release build, or is this the debug build?

​

 
n72.75 said:
The only change I can see to ZTreeMgr.cpp in the git-blame since Orbiter was added to Git, was: https://github.com/orbitersim/orbit...9b98d771cb24d69d403e5c74399744410bc39c4e8fbb4

These should actually help with this sort of crash though:

1736715230766.png
Click to expand...
That change is actually useless, as the local pointer isn't used after freeing the memory. 🤷‍♂️
 
n72.75 said:
@CaptainSwag101 is this related in any way to the issue that /LARGEADDRESSAWARE fixes?

It's happening for at least 3(?) people.
Click to expand...
It's difficult for me to tell; this crash is occurring in a completely different place to where NASSP would encounter issues. This seems to be crashing while building the geometry/elevation map for the planet if I'm reading this right? We'd need to do some more deliberate and focused debugging to see if this is an out-of-memory issue.
 
After some more digging, I'm confident that the crash is not occurring inside the zlib's uncompress function (though it may be contributing indirectly to it). One of the things I did was update zlib from v1.2.11 to v1.3.1, but I did not see any difference.

The crash occurs when ZTreeMgr::Inflate() returns, and it ultimately seems to be a corruption of the stack.

The error message indicates an access violation at 0x0001066D.

This is the same value as noutp (67181 = 0x0001066D). So the stack pointer holds this value when the ret instruction of ZTreeMgr::Inflate() is called.

I rewrote the Inflate function slightly to help me digest what's going on:

C++: 
DWORD ZTreeMgr::Inflate(const BYTE *inp, DWORD ninp, BYTE *outp, DWORD noutp)
{
    DWORD ndata = noutp;
    int x = uncompress(outp, &ndata, inp, ninp);
    if (x != Z_OK) return 0;
    return ndata;
}

Disassembled:

Code: 
--- S:\Orbiter-build\orbiter\Src\Orbiter\ZTreeMgr.cpp --------------------------
// ReadData()
DWORD ZTreeMgr::ReadData(DWORD idx, BYTE **outp)

...

    DWORD ndata = Inflate(zbuf, zsize, ebuf, esize);

00997ABC  mov         ecx,edi  
00997ABE  push        dword ptr [esp+1Ch]  
00997AC2  push        ebx  
00997AC3  push        ebp  
00997AC4  push        esi  
00997AC5  call        ZTreeMgr::Inflate (082484Fh)

    delete []zbuf;

00997ACA  push        esi                                        <------- esp should hold 0x00997ACA when Inflate is returned

...
// Inflate()
{
    DWORD ndata = noutp;
    int x = uncompress(outp, &ndata, inp, ninp);

00997780 push        dword ptr [ninp]
00997784  mov         eax,dword ptr [esp+14h]     <-------- the value of [esp+14h] is 0x001066D, so eax represents noutp here
00997788  push        dword ptr [esp+8]
0099778C  mov         dword ptr [esp+18h],eax
00997790  lea         eax,[esp+18h]
00997794  push        eax
00997795  push        dword ptr [esp+18h]
00997799  call        _uncompress (0114840Bh)

    if (x != Z_OK) return 0;

0099779E  mov         ecx,dword ptr [esp+20h]
009977A2  xor         edx,edx                                   <----- (1) at this point, esp holds the correct return address (0x00997ACA)
009977A4  add         esp,10h                                  <----- (2) esp gets the bad address (0x0001066D)
009977A7  test        eax,eax
009977A9  cmovne      ecx,edx
009977AC  mov         eax,ecx

    return ndata;
}

009977AE  ret         10h

In words then, the add instruction at address 0x009977A4 shifts esp from the correct return address to the wrong address. But it's not yet clear to me whether esp holds the correct value at (1) and the add instruction is erroneous, or whether the add is correct and the stack has already been corrupted. (My hunch is it's the latter).

In other words, at (1) the stack looks this:

Code: 
0x005BDEB0  000024d7  
0x005BDEB4  00997aca    <---- esp at (1)
0x005BDEB8  04de4e00  
0x005BDEBC  000024d7  
0x005BDEC0  04d93cc0  
0x005BDEC4  0001066d   <---- esp at (2)
0x005BDEC8  0000000a

This is all I have for the moment. Apologies for the wall of text/code, I'm only pasting this in the hope that someone with far more C++ experience than me might "catch on" to what's going on, because my debugging takes at least 5x longer than it would for an experienced C++ developer. Nevertheless, I plan to continue with the hunt... (in the next post you'll see me looking at transistors under a microscope :))
 
Last edited:
TyraXoS said:
This is all I have for the moment. Apologies for the wall of text/code, I'm only pasting this in the hope that someone with far more C++ experience than me might "catch on" to what's going on, because my debugging takes at least 5x longer than it would for an experienced C++ developer. Nevertheless, I plan to continue with the hunt... (in the next post you'll see me looking at transistors under a microscope :))
Click to expand...

I applaud your effort and hope that you will endeavor to persevere. This is all Greek to me; I am for sure NOT a software developer/engineer. Rather, I am a biologist. I have spare microscopes if you find yourself in need of such.

Peace,

Sam
 
CurlSnout said:
I applaud your effort and hope that you will endeavor to persevere. This is all Greek to me; I am for sure NOT a software developer/engineer. Rather, I am a biologist. I have spare microscopes if you find yourself in need of such.

Peace,

Sam
Click to expand...

Haha thank you. Do you have any electron microscopes? :)

Yeah I'm really hopeful we'll figure it out, if we keep digging at it. I have very fond memories of playing Orbiter 2006 as a child, patiently reading and digging through "Go Play in Space", making my first dock with the ISS etc. but I never would have imagined that one day I would be digging through the assembly code trying to fix a CTD, haha. In a way it's all I can do to give back for the many hours of entertainment this simulator has given me. Martin and the OpenOrbiter/2024 team deserve the utmost praise.
 
How many threads are there running when that code is executing? Could there be more than one thread loading the surface and their data doesn't get along?
There is a setting in the Launchpad > Extra > Visualisation parameters > Planet rendering options > Load tiles in separate thread, which is on by default... does the crash still happen with it off?
 
GLS said:
How many threads are there running when that code is executing? Could there be more than one thread loading the surface and their data doesn't get along?
There is a setting in the Launchpad > Extra > Visualisation parameters > Planet rendering options > Load tiles in separate thread, which is on by default... does the crash still happen with it off?
Click to expand...
The top-level Orbiter.exe runs fine whether or not that option is selected.
I can't find that option in Modules/Server/Orbiter.exe.

Threads:
Code: 
Not Flagged        9708    0    Worker Thread    msvcrt.dll thread    mshtml.dll!6cc13903
Not Flagged    >    36280    0    Main Thread    Main Thread    Orbiter.exe!ZTreeMgr::ReadData
Not Flagged        27052    0    Worker Thread    winmm.dll thread    win32u.dll!754f106c
Not Flagged        37764    0    Worker Thread    mshtml.dll thread    mshtml.dll!6cc693fe
Not Flagged        13216    0    Worker Thread    mshtml.dll thread    mshtml.dll!6cc411d3
Not Flagged        27356    0    Worker Thread    ntdll.dll!TppWorkerThread    ntdll.dll!_NtWaitForWorkViaWorkerFactory@20
Not Flagged        35764    0    Worker Thread    mshtml.dll thread    win32u.dll!754f586c
Not Flagged        37044    0    Worker Thread    msvcrt.dll thread    mshtml.dll!6cc148b5
Not Flagged        29972    0    Worker Thread    msvcrt.dll thread    mshtml.dll!6cc148b5
Not Flagged        34480    0    Worker Thread    msvcrt.dll thread    jscript9.dll!56e2d110
Not Flagged        31528    0    Worker Thread    ntdll.dll!TppWorkerThread    ntdll.dll!_NtWaitForWorkViaWorkerFactory@20
Not Flagged        35044    0    Worker Thread    ntdll.dll!TppWorkerThread    ntdll.dll!_NtWaitForWorkViaWorkerFactory@20
Not Flagged        24664    0    Worker Thread    ntdll.dll!TppWorkerThread    ntdll.dll!_NtWaitForWorkViaWorkerFactory@20
Not Flagged        30976    0    Worker Thread    combase.dll thread    ntdll.dll!_NtWaitForMultipleObjects@20
Not Flagged        27444    0    Worker Thread    InputHost.dll thread    CoreMessaging.dll!6e8909ec
Not Flagged        36944    0    Worker Thread    ntdll.dll!TppWorkerThread    ntdll.dll!_NtWaitForWorkViaWorkerFactory@20
Not Flagged        29052    0    Worker Thread    ntdll.dll!TppWorkerThread    ntdll.dll!_NtWaitForWorkViaWorkerFactory@20
Not Flagged        37060    0    Worker Thread    ntdll.dll!TppWorkerThread    ntdll.dll!_NtWaitForWorkViaWorkerFactory@20
Not Flagged        4268    0    Worker Thread    ntdll.dll!TppWorkerThread    ntdll.dll!_NtWaitForWorkViaWorkerFactory@20
Not Flagged        37844    0    Worker Thread    Orbiter.exe!orbiter::ScenarioTab::threadWatchScnList()    Orbiter.exe!orbiter::ScenarioTab::threadWatchScnList
Not Flagged        27532    0    Worker Thread    Orbiter.exe!InputProc    Orbiter.exe!InputProc
 
  • Like
Reactions: GLS
I've discovered that disabling optimization across the entire project fixes the CTD (i.e. setting the /Od compiler option).

Disabling optimization only on ZTreeManager.cpp does fix console mode, but the D3D9client will fail to load. So there's probably a bug hiding in another location as well.

I'm going to take a break for a few days, but I suppose next steps might be:
1) Looking through the Git history, undoing some changes and seeing if that makes any difference.
2) Creating a minimal reproducible example.

I think it might also be useful to compare stacks around the point uncompress is called. I'd be curious to see what the stack looks like on systems where the public release build does work. It might give a clue as to what's going wrong.

Here is what my (annotated) stack looks like just before calling _uncompress in the assembly code:
Code: 
0x00B3E2D8  0506fb10
0x00B3E2DC  00b3e2e8
0x00B3E2E0  00f699fe
0x00B3E2E4  05020560    <---- outp    <===== ESP
0x00B3E2E8  00b3e304  
0x00B3E2EC  0506fb10    <---- inp
0x00B3E2F0  000024d7    <---- ninp
0x00B3E2F4  00f47aca    <---- ret address to ReadData()
0x00B3E2F8  0506fb10    <---- inp
0x00B3E2FC  000024d7    <---- ninp
0x00B3E300  05020560    <---- outp
0x00B3E304  0001066d    <---- noutp
0x00B3E308  0000000a
0x00B3E30C  04fe71a8    <---- this
0x00B3E310  00010609
0x00B3E314  00000000
0x00B3E318  00e17b6c

Here it is after:
Code: 
0x00B3E2D8  00000001   
0x00B3E2DC  00b3e2e8
0x00B3E2E0  00f4779e
0x00B3E2E4  05020560     <---- outp
0x00B3E2E8  00b3e304   
0x00B3E2EC  0506fb10     <---- inp
0x00B3E2F0  000024d7     <---- ninp
0x00B3E2F4  00f47aca     <---- ret adress to ReadData()   <===== ESP
0x00B3E2F8  0506fb10     <---- inp
0x00B3E2FC  000024d7     <---- ninp
0x00B3E300  05020560     <---- outp
0x00B3E304  0001066d     <---- noutp
0x00B3E308  0000000a   
0x00B3E30C  04fe71a8     <---- this
0x00B3E310  00010609
0x00B3E314  00000000
0x00B3E318  00e17b6c
I don't really know why ESP shifts down after the call (compiler optimization?), but whatever the reason, a similar thing happens with /Od set so it can't by itself be the cause.

If anybody else would be willing to share their stack at the same location (in the 2024 release build, with default optimizations), that would be greatly appreciated.
 
Probably I can't help, but I just wanted to remind this strange thing:
CurlSnout said:
No - these files do not exist anywhere inside Orbiter 2024.
Click to expand...
If these files were really abcent, then I personally don't understand how it's possible. @CurlSnout, maybe you could try to unpack the Orbiter 2024 archive again and look if these files are present (maybe you might to disable the Windows Defender for that time). Also, earlier there was the following in your Orbiter.log:
misha.physics said:
Also, it says:
000010.984: Failed to load texture gridlabel.dds
Click to expand...

CurlSnout said:
Yes, I enabled the DirectX Wrapper in the D3D9Client.cfg. CTD persists.
Click to expand...
On the contrary, for me it doesn't work as I mentioned above:
misha.physics said:
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 seconds 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?
Click to expand...

TyraXoS said:
If anybody else would be willing to share their stack at the same location (in the 2024 release build, with default optimizations), that would be greatly appreciated.
Click to expand...
If I understand correctly, some compiler or additional application is needed for this (I don't know what the "stack" it is).
 
I discovered that I CAN run the newest release candidate for Orbiter 2024 (Orbiter 2024-rc4) as long as I don't add in any planetary textures. I even got one of my old home-made addons to work after adding in Multistage2015.
 

Attachments

  • cs_moonship.jpg
    cs_moonship.jpg
    50.1 KB · Views: 7
Could it be that a different version of zlib.dll is being loaded for some unknown reason. So, could you check the version from a loaded modules list in a debugger. In my case it's 1.02.11.0
EDIT: You got the same version.
EDIT2: Recheck the version from the loaded modules list in a debugger
 
Last edited:
You must log in or register to reply here.

Similar threads

rocketman293239138923
Problem i keep getting this issue
Replies
2
Views
1K
GLS
GLS
S
Problem Orbiter Crashing
Replies
3
Views
2K
Tiny_Bob
Tiny_Bob
rocketman293239138923
Problem I am having another issue were when i click the D3D9 module It disappears And the orbiter server launch pad crashes I am using orbiter2016.
Replies
2
Views
1K
jarmonik
J
space_guy1701
General Question Vanilla Obiter 2010 not working on windows 10. Help!
Replies
1
Views
1K
Buck Rogers
Buck Rogers
SpaceMarineXI
Problem USS Enterprise (StarTrekXI_First_installment_MrMartian_fixed)-Missing vess
Replies
9
Views
3K
SpaceMarineXI
SpaceMarineXI
Back
Top