Problem Unable to start any scenario in Orbiter 2016 after migrating to new computer on Windows 11

[Cosmic Penguin]

Hi, I have been out of the Orbiter loop for several years due to my old laptop not keeping up with latest developments and that I developed some other interests elsewhere (last I touched the Orbiter folders was like late 2018, an eternity ) (+), but now I just finally built my own computer I'm now back tweaking around.

I didn't touch the folders while transferring from the old laptop to the new computer, but I did just noticed OrbiterSound got an upgrade so it was patched to 5.0.

Then I tried starting any of those scenarios and...somehow the window just exits before finishing loading the scenario (stopped at "Loading SceneTech.fx"). Here's an example of the # Welcome to Orbiter 2016.scn in the O2016 folder:

**** Orbiter.log
000000.000: Build Aug 28 2016 [v.160828]
000000.000: Timer precision: 1e-007 sec
000000.000: Found 0 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 200811, API 160828]
000000.000: Module transx.dll ............ [Build 160216, API 160214]
000000.000:
000000.000: **** Creating simulation session
000000.000: D3D9: [DirectX 9 Initialized]
000000.000: D3D9: 3D-Adapter = NVIDIA GeForce RTX 3060 Ti
000000.000: D3D9: MaxTextureWidth........: 16384
000000.000: D3D9: MaxTextureHeight.......: 16384
000000.000: D3D9: MaxTextureRepeat.......: 8192
000000.000: D3D9: VolTexAddressCaps......: 0x3F
000000.000: D3D9: NumSimultaneousRTs.....: 4
000000.000: D3D9: VertexDeclCaps.........: 0x30F
000000.000: D3D9: XNA Math Support.......: Yes
000000.000: D3D9: Vertex Texture.........: Yes
000000.000: D3D9: Shadow Mapping.........: Yes
000000.000: D3D9: D3DFMT_A16B16G16R16F...: Yes
000000.000: D3D9: D3DFMT_A32B32G32R32F...: Yes
000000.000: D3D9: D3DFMT_D32F_LOCKABLE...: Yes
000000.000: D3D9: D3DFMT_A2R10G10B10.....: Yes
000000.000: D3D9: D3DDTCAPS_DEC3N........: No
000000.000: D3D9: D3DDTCAPS_FLOAT16_2....: Yes
000000.000: D3D9: D3DDTCAPS_FLOAT16_4....: Yes
000000.000: D3D9: Runs under WINE........: No
000000.000: D3D9: Available Texture Memory = 4025 MB
000000.000: D3D9: [3DDevice Initialized]
000000.000: D3D9: [Loading Constellations]
000000.000: D3D9: [D3D9Client Initialized]

Feel free to ask for other logs if necessary.
Thank you!

Cosmic Penguin

(+) As you can see from my Twitter account, my spaceflight life is busier than I have ever been while covering spaceflight news on O-F. You can also see what my new interest is easily from my Twitter. ?

 

[Cosmic Penguin]

EDIT: I myself found the solution! It was again the default date-and-other-format issue at stake, which I met with my old laptop almost 4 years ago:

Guess what? It worked! I had to change my region format (date/time etc.) settings to English (from Traditional Chinese as my laptop uses) and Orbiter works instantly.

Given my case, this old one (Simplified Chinese) and then this new case (Korean) all share the same characteristics, it seems that there is something new from the "O2015 beta" times that breaks the program start sequence for system of at least various far eastern Asian languages. This looks like a bug for me so hopefully someone can file this for Martin et al. to look at.

https://www.orbiter-forum.com/threads/orbiter-2016-with-d3d9-ctd-in-all-scenarios.35786/post-545443

I wonder if this has been fixed in the newest Beta version...

 

[Sbb1413]

@Galactic Penguin SST, to Orbiter-Forum! I had seen you in Wikipedia back in 2019 when I was dealing with various spaceflight-related articles there. Now I am blocked in English Wikipedia for more than a year since January 2021, and I have maximised my focus in Orbiter since then.

 

[kuddel]

I havn't looked at the current source-code od Orbiter (Beta), but it might be easy to implement/fix:

Each method / function that opens a filestream (input or output) should set the locale to "C"

A simple test-code I've put together should work to output/input decimals always 'nice' (no grouping separators, and a dot as decimal separator)

    const double my_pi = 3.1415926535;
void anyFunction ()
{
    {
        std::ofstream os("./tmp.txt");
        os.imbue(std::locale("C"));
        os.precision(12);
        os << my_pi;
    }
    {
        std::ifstream is("./tmp.txt");
        is.imbue(std::locale("C"));
        double value{};
        is >> value;

        double dummy_brk{ value }; // to inspect value at beakpoint ;)
    }
}

[*] The extra scopes are just to make sure the streams are closed automatically

Just for info (not really applicable to Orbiter):
The standard input / output / error streams must be imbuesed each:

std::cout.imbue(std::locale("C"));
std::cin.imbue(std::locale("C"));
std::cerr.imbue(std::locale("C"));