I have tested 4.23 within my Linux/WINE configuration and it works so far...like the previous version.
However, one question I have in mind since years...
This is Linux/WINE specific, so...I know not the supported OS/env....
This is what happens many times over the last couple of years in Orbiter 2016 using various WINE/D3D9-client and different (native and WINE-built-in) version of DirectX:
-starting Orbiter with D3D9Client = Orbiterng seg-fault right before see the rendered scenario, loadingscreen was fine
-happens mostly with newer Add-Ons like the SpaceX or Delta-rockets addons
-workaround (not allways helpfull, but much more stable loading): chnaging the SCN-file to have a camera-focus to empty space.
-if then the SCN loads fine, I (mostly) switch back to vessel-view, and have a lower chance to run in a CTD.
So my question/idea:
Could there be a race-condition during initial SCN-rendering, like i.e. in WINE where we have to deal with delayed caused by "translated" SYS-CALLS.
If this might be the cause of the issues, maybe a D3D9-client "start-render-delay-in-ms" could be a cheap dirty workaround for such emulated environments ?
Maybe I am complete wrong, but there is nothing in the logs, just "loaded fine" and CTD.
I have seen this issue now on three different machines over the last years, both INTEL and AMD CPU's....and AMD and NVIDIA graphics cards.
The fact, that this problem might be easier to repro using recent addons, might be related that newer addons are using more recent texture and mesh features ?