Orbiter 2024 Launch readiness

[gattispilot]

Thanks. How about d3d9?

 

[jarmonik]

Thanks. How about d3d9?

It's part of the OpenOrbiter. Comes with the package.

 

[gattispilot]

It's part of the OpenOrbiter. Comes with the package.

So open orbiter will be 2024?

 

[GLS]

One thing that has apparently changed in D3D9 is the handling of the HUD mesh group (the behavior in MOGE remained unchanged). In Orbiter 2016 it worked (i.e., mesh not visible, only the drawing) if the group had a material defined. Now, the material has to be set to 0 or the group will be visible.
This should be mentioned somewhere for future reference. In API_Guide.pdf there is a section "1.13.7 Defining the HUD in the virtual cockpit", but all it has is "< to be completed >".

I could write something about this, but looking at the rest of the pdf, it looks a bit dated, plus the source is binary, so keeping track of edits is pretty much impossible, and will cost storage space in github. Maybe the solution is to convert all the docs to LaTeX sources? Sometime ago I played a bit with having LaTeX sources converted to pdf via command line for SSV (although I never went thru with it... yet), so it should be possible to have this process automated in cmake, which would take care of the "building the documentation"problem. Yes, LaTeX can be a PITA sometimes, but the sources are plain-text, so they would be as "workable" as code.

Any thoughts?

 

[Buck Rogers]

I downloaded the X86 zip and copied over the orig. hi-res 2016 elev_mod & surf files for earth, moon and mars... and it loaded! but one very blue planet (purple?)?
I've added the elev.tree from 2016 but no change.
Shall I start a Orbiter2024 for Noobs thread or wait for an official debug/help thread?

 

[misha.physics]

Recently I made a clean installation of the last Orbiter build on GitHub. Then copied highly-detailed textures only of Earth, launched a scenario with Earth, and there was no problem. But I copied all five *.tree files (Surf, Mask, Elev, Elev_mod, Cloud) and put them into /Textures/Earth/Archive.

 

[Buck Rogers]

My bad, Missed a file (think I need the facepalm emoji)
Ok looks good! and smooth! So lets see what it can do!

 

[GLS]

One thing that has apparently changed in D3D9 is the handling of the HUD mesh group (the behavior in MOGE remained unchanged). In Orbiter 2016 it worked (i.e., mesh not visible, only the drawing) if the group had a material defined. Now, the material has to be set to 0 or the group will be visible.
This should be mentioned somewhere for future reference. In API_Guide.pdf there is a section "1.13.7 Defining the HUD in the virtual cockpit", but all it has is "< to be completed >".

I could write something about this, but looking at the rest of the pdf, it looks a bit dated, plus the source is binary, so keeping track of edits is pretty much impossible, and will cost storage space in github. Maybe the solution is to convert all the docs to LaTeX sources? Sometime ago I played a bit with having LaTeX sources converted to pdf via command line for SSV (although I never went thru with it... yet), so it should be possible to have this process automated in cmake, which would take care of the "building the documentation"problem. Yes, LaTeX can be a PITA sometimes, but the sources are plain-text, so they would be as "workable" as code.

Any thoughts?

Attached a demo, result of ~45 minutes of work (most of it spent setting up the code block), based on the SSV manual. I favor a simple style, which ends up being easier to maintain and probably has less dependencies, but the cover should be made prettier.

Currently there are several documents, but IMO we could organize everything into 2 documents: User Manual (how to install and use Orbiter, keys, MFDs, default vessels, etc) and Developer Manual (basic vessel design, mesh info, lua, bases, planets, cfg files, etc). If they grow too much, then perhaps splitting them is a better option.
For ease of edit, the sources would be split by chapters or sections. Fonts, styles, colors, cover, header, footer, etc should be standardized by somebody who knows what they are doing (not me ). I'm available to help with the copy-paste, reformatting, and upgrade (e.g., VESSEL2 should now be VESSEL4) of the existing material, as well as addition of missing material (if I know what to say).

 

[GLS]

Oh, there is still the part of making cmake build it...

 

[Buck Rogers]

Just want to say, very impressed so far, on all levels, GUI, gfx, performance, also microtex. is way better! (don't like the lens flare options though).
DG needs normal maps etc. (I think somebody made some?) stock bases need flattening.

 

[jarmonik]

One thing that has apparently changed in D3D9 is the handling of the HUD mesh group (the behavior in MOGE remained unchanged). In Orbiter 2016 it worked (i.e., mesh not visible, only the drawing) if the group had a material defined. Now, the material has to be set to 0 or the group will be visible.
This should be mentioned somewhere for future reference. In API_Guide.pdf there is a section "1.13.7 Defining the HUD in the virtual cockpit", but all it has is "< to be completed >".

The changes in the HUD are not intentional. I'll compare the code to O2016 and try to fix it.

The LaTeX demo looks very good. I used LaTeX to make IMFD and LTMFD manuals but haven't touched it past 10 years. It is one option to consider but would require wider discussion about documentation plan. It could be helpful if all the documentation is build by LaTeX + Doxygen combo. Are there any LaTeX editors those would allow to create documents without needing to write the source code ?

 

[jarmonik]

Just want to say, very impressed so far, on all levels, GUI, gfx, performance, also microtex. is way better! (don't like the lens flare options though).
DG needs normal maps etc. (I think somebody made some?) stock bases need flattening.

There's no lens flare, just the sun glare which can be tuned in realtime from D3D9Graphics Controls, you can also customize it by editing Glare.hlsl in /Modules/D3D9Client/

 

[GLS]

The changes in the HUD are not intentional. I'll compare the code to O2016 and try to fix it.

I have no problems with the new implementation: it works and it's one less material. The default vessels are also not using a material in the HUD mesh, so that seems to be the standard, so there is nothing to fix. It just should be indicated somewhere how it works.

 

[GLS]

Are there any LaTeX editors those would allow to create documents without needing to write the source code ?

What do you mean, to document the API functions?
For the demo above, I used TeXworks. I might have an old version by now, but it has a basic editor and one button conversion to pdf. The source .tex files can be edited there, or in any text editor.

 

[Gondos]

What do you mean, to document the API functions?
For the demo above, I used TeXworks. I might have an old version by now, but it has a basic editor and one button conversion to pdf. The source .tex files can be edited there, or in any text editor.

I used lyx a looong time ago, it's WYSIWYG. Don't know how it fared with time though.

 

[gattispilot]

So I made a new folder Orbiter2024 and downloaded the x86 and extracted.

I noticed the start screen says Orbiter 2016?

I recompiled the MMSEV and kinda works. The MFD's work in the VC. But I have a panel that I write on and the numbers don't appear. Is there a mesh setting to fix that?

 

[n72.75]

For documentation, if we can't get the documentation to build as part of the regular build process, we can always do it manually (for this release at least).

I know there are a few new things in the API reference that need to be documented.

The API guide needs work too. I fully support the use of LaTeX, especially since it makes the git diffs better.



I can transcribe the API Guide into LaTeX if no one else wants to.

 

[Thunder Chicken]

So I made a new folder Orbiter2024 and downloaded the x86 and extracted.

I noticed the start screen says Orbiter 2016?

Did you install it over Orbiter2016 for the textures? If so, there might be two Orbiter executables, orbiter.exe and Orbiter.exe. Orbiter.exe is the Orbiter2024 version.

 

[gattispilot]

I dont think so. It seems to be good now. Just need to figure out why my hud is not working. The code is the similar to shuttle A which works?

 

[GLS]

I know there are a few new things in the API reference that need to be documented.

That is the doxygen-generated pdf, and that should "just" be pointing doxygen to the source files (easy), and have the code documented (not easy).

The API guide needs work too.

They all do.
My idea is to combine "3DModel.pdf", "API_Guide.pdf", and (parts of) "Orbiter2DGraphics.pdf" into a single pdf called, e.g., "Orbiter Developer Manual", which would have all the info needed (except for the function list, which would remain in "API_Reference.pdf") for a developer to create an addon. Currently this document would have ~130 pages, and even with some additions, plus a chapter for lua (I see lots of activity in there, so there should also be some pen put to paper), IMO it would still end up with a manageable size.

After a bit more thinking, it's probably better to have 3 docs:

• "Orbiter User Manual" which would cover basics, included MFDs and vessels, etc, and it should end up having less than 200 pages, so still manageable;
• "Orbiter Developer Manual" described above;
• "Orbiter Technical Reference" with the stuff in the Technotes folder plus some some equations and constants that are currently spread in other docs, basically serving as a reference of how Orbiter works.

I can transcribe the API Guide into LaTeX if no one else wants to.

A possible implementation for the "code block" is already provided in my demo above.
Again, the first thing to do should be define styles and such, so there is a common base for the docs. Then, IMO, a 2-step process is probably easier to handle: first a "conversion phase", when the current docs are converted to LaTeX, split into source files and combined into the final product with +/- the final structure, and then a "correction phase", when the updates and corrections are made, already having the overall final product in view.
LaTex supports comments, so TODOs can be added during the conversion phase, as early signals that some area needs work. This approach allows us to isolate the "LaTeX problems" from the "documentation problems": when checking and correcting the text we'll easily fire up Orbiter to confirm something and find something not working properly, and battling that and LaTeX at the same time would not be good.

Also to consider is where do the files go?
Does the "Orbiter Developer Manual" remain in the Orbitersdk/doc folder, or does it join the other in the Doc folder?
Do the sources stay inside Doc (and Orbitersdk/doc), or do they go in the Src folder, and only the pdf products end up in the Doc folder?
In any case, each pdf product should have its own folder with the .tex sources and an images folder... for the images (duh).