Orbiter 2024 Launch readiness

[patio]

So far. I haven't been able to reproduce the problem with stock vessels.

I just tried the stock scenario DG docked at ISS

see the attached screen shots


are you getting the same render differences (just vessel markers enabled or disabled) ?

 

[jarmonik]

are you getting the same render differences (just vessel markers enabled or disabled) ?

Not the same but something is wrong in there, I can see a major difference, Thanks. Will look into it...

 

[patio]

Not the same but something is wrong in there, I can see a major difference, Thanks. Will look into it...

I just tested to add a separate loop for markers
and it solves all the problems


while (RenderMarkerList.empty() == false) {

RenderVesselMarker(RenderMarkerList.front(), pSketch);
RenderMarkerList.pop_front();
}

so the problem seems to be mixing vessel and vessel markers rendering

 

[Gondos]

Not sure if it's related to recent changes but I get a crash when loading several scenarios without restarting the launchpad.
To reproduce : Start a scenario then exit to the launchpad, then load another scenario (without restarting Orbiter)
It asserts here in Scene.cpp:3492 :

    if (Camera.vGravRef == NULL || Camera.vProxy == NULL || Camera.vNear == NULL) {
        assert(false); return;
    }

The 3 Camera.vXXX members are NULL at this point.
Anybody has the same issue?

 

[jarmonik]

The 3 Camera.vXXX members are NULL at this point.
Anybody has the same issue?

This is fixed in a coming PR.

I still see a display bug similar to the flicker bug you fixed some time ago

This should be fixed in a coming PR.

 

[n72.75]

This is fixed in a coming PR.


This should be fixed in a coming PR.

I'd that one ready for review?

 

[jarmonik]

I'd that one ready for review?

Yes

 

[jarmonik]

There is a new Pull Request about the SDK sample programs. I created a cmake scripts those can be used to create a Visual Studio solution and project files. Simple documentation included about how to do that. There is a small problem that cmake fails because lacking of debug libraries. Right now the debug libs are replaced by release libs to allow cmake to work.

If we can't upload binaries to GitHub then how do we manage binaries that are not build by GitHubs automated process ? Outside of version control ? Developer FTP access to a folder somewhere ? Maybe cmake-install could pull the binaries from there if not present in destination and assemble a working installation (without planetary textures of course) ?

 

[n72.75]

There is a new Pull Request about the SDK sample programs. I created a cmake scripts those can be used to create a Visual Studio solution and project files. Simple documentation included about how to do that. There is a small problem that cmake fails because lacking of debug libraries. Right now the debug libs are replaced by release libs to allow cmake to work.

If we can't upload binaries to GitHub then how do we manage binaries that are not build by GitHubs automated process ? Outside of version control ? Developer FTP access to a folder somewhere ? Maybe cmake-install could pull the binaries from there if not present in destination and assemble a working installation (without planetary textures of course) ?

GLS had proposed this solution, although I'll admit I don't know enough about cmake to help much.

One idea I had was to have 2 projects for each lib: one only builds Debug and the other Release, and they are always built... not sure if that is possible in cmake.
But apparently there are other ways to make this happen: https://cristianadam.eu/20191012/building-multiple-configurations-with-cmake-in-one-go/

If we can't figure out how to do this automatically in the next week or so, I would recommend the following alternative solution.

1. When we're ready to release, make a new branch called "Orbiter2024"
2. Make a single commit to Orbiter2024 adding the debug libs.
3. Create an official release/tag based on this "Orbiter2024" branch.
4. If any post-launch bug-fixes need to be made for minor little things:
   1. Make the fix in main.
   2. Merge main into Orbiter2024
   3. Create a new Orbiter2024p1 release
5. Figure out a better solution before the next release.

 

[jarmonik]

When trying to build the documentation, this error repeats a lot:

CMake Error at Src/Module/LuaScript/LuaInterpreter/CMakeLists.txt:44 (add_custom_command):
Error evaluating generator expression:

$<TARGET_FILE:lua::exe>

No target "lua::exe"

What is this syntax supposed to mean $<TARGET_FILE:lua::exe> ?

 

[Gondos]

When trying to build the documentation, this error repeats a lot:

CMake Error at Src/Module/LuaScript/LuaInterpreter/CMakeLists.txt:44 (add_custom_command):
Error evaluating generator expression:

$<TARGET_FILE:lua::exe>

No target "lua::exe"

What is this syntax supposed to mean $<TARGET_FILE:lua::exe> ?

Wouldn't it be the lua interpreter (lua.exe)? Looks like the documentation build is trying to use ldoc, which is a lua program.

 

[jarmonik]

Wouldn't it be the lua interpreter (lua.exe)? Looks like the documentation build is trying to use ldoc, which is a lua program.

Yeah, probably. The error also appears on /Deltaglider/Help/CMakeList.txt and many more... After reverting the root CMakeList.txt to
e7477e610ff74ec5b80092437554f52b31b1f416 (Dated late 2022) it started to work. So, the problem is due to more resent modifications likely 05/02/2023, I don't know why these changes been made so can't comment on it. I sent PM to DarkWanderer, let's see if he got time to look into it.

 

[gattispilot]

So not sure if the right area. But 2 things. On the MMSEV for 2016. I recompiled for 2024. Using the same textures and meshes. In 2024 the buttons and speed angle is not drawn?

The other weird thing. Is the eagle doesn't show up in the scenario editor?

If it matters both D3D9

 

[jarmonik]

So not sure if the right area. But 2 things. On the MMSEV for 2016. I recompiled for 2024. Using the same textures and meshes. In 2024 the buttons and speed angle is not drawn?
The other weird thing. Is the eagle doesn't show up in the scenario editor?
If it matters both D3D9

There's been some clean-ups in a Surface API and it may effect to some add-ons if something's done very incorrectly. Is there anything in D3D9ClientLog.html with debug level 2 ?
I have no idea what's going on with the scenario editor. To look into the problems I would need binaries and source code. But nothing here is indicating a problem in the Orbiter.

From D3D9Client development thread:
And Yes, the Sketchpad should be used instead of GetDC. The next-gen Vulkan client wont provide DC support beyond MFD screens.

 

[Mr Martian]

Not sure if this is the best place to ask/mention this, so I apologise in advance, but just wondering if there were any plans for the final release of Orbiter 2024 to include any kind of ‘revamp’ of any of the classic default vessels, like the ShuttleA/ShuttlePB/Wheel station? I only ask because I have made some remodels of some of these craft. My plan was to release these as part of a project I’m currently working on alongside ISV Pegasus v3, but if updated models of some of these classics is something that is appropriate I’m happy to share the meshes earlier. Is there anyone who is overseeing this part of development who would be interested? Happy to DM the mesh and texture files. Again, a bit late to the party with this, but I only just thought of it.

 

[jarmonik]

Not sure if this is the best place to ask/mention this, so I apologise in advance, but just wondering if there were any plans for the final release of Orbiter 2024 to include any kind of ‘revamp’ of any of the classic default vessels, like the ShuttleA/ShuttlePB/Wheel station? I only ask because I have made some remodels of some of these craft. My plan was to release these as part of a project I’m currently working on alongside ISV Pegasus v3, but if updated models of some of these classics is something that is appropriate I’m happy to share the meshes earlier. Is there anyone who is overseeing this part of development who would be interested? Happy to DM the mesh and texture files. Again, a bit late to the party with this, but I only just thought of it.

Graphics updates are planned for the default vessels after removal of DirectX 7 dependency. Which should happen soon after Orbiter 2024 launch. It would be great the have better meshes and textures. Also the ISS would need an update, there are some high poly ISS add-ons but they are way too demanding for hardware. Medium poly ISS with PBR textures would be really nice. (200k - 400k triangles) The current one is somewhere around 20k - 40k triangles.

 

[misha.physics]

When such updates for the default vessels will be done maybe we could save the legacy models (meshes) and textures of default vessels too, just moving them into a special folder like "Legacy default ships" just to preserfe an oportunity to use them in new Orbiter versions. I mean some kind of retro style (like in some other game remakes), but that's just a suggestion, I don't insist on this

 

[Fabri91]

When such updates for the default vessels will be done maybe we could save the legacy models (meshes) and textures of default vessels too, just moving them into a special folder like "Legacy default ships" just to preserfe an oportunity to use them in new Orbiter versions. I mean some kind of retro style (like in some other game remakes), but that's just a suggestion, I don't insist on this

A monument of sorts, like the parts from KSP's very first public version scattered on a nearby airfield or as a statue.

 

[misha.physics]

Yes. Actually I mean the presaving of some authentic Orbiter style (graphics). Honestly I'm a little worried that new graphics might look a bit cartoonishly colorful, but I think I'm wrong and new textures (and meshes) will look just as realistic and serious and even better By the way the old textures could be used as one of the skins.

 

[Marg]

I just wanted to post an "idea": in Orbiter 2016 vessels which did not have landing points defined, or incorrectly defined, behaved like they are on the water, going upside down, overturning, floating "submerged"... I had it with B-747 when its landing points were too close too each other (or relative to CoG?).
Maybe it can be used to simulate water?