Linux playground

Matias Saibene

Well-known member
Hi @Gondos
I have a question for you, let's suppose that I want to install the G42-200 which is free software and can be found in this repository: https://github.com/abdullah-radwan/G42-200
What I have to do?
Excuse my ignorance on this but just starting to get familiar with programming.

Gondos

Member
Hi @Gondos
I have a question for you, let's suppose that I want to install the G42-200 which is free software and can be found in this repository: https://github.com/abdullah-radwan/G42-200
What I have to do?
Excuse my ignorance on this but just starting to get familiar with programming.
Hi, you need to sort out different issues :
• case in filenames
• "\\" vs "/"
• embedded bmps needs to be loaded as textures now
• add a CMakeLists.txt file containing instructions for building
• add UCSO beforehand since it looks like it's a dependency of G42-200
• fix everything that does not compile and that'll show up when you do it
I just forked the two projects and I'll see what I can do ; since it's using XRSound and sketchpad instead of OrbiterSound/GDI, it shouldn't be a big deal to make it work?

Edit : got some UCSO stuff working but I don't really know how to test it...

Edit2 : pushed some stuff on github

I have no idea how to fly this bird though?
Note : there are lots of graphical glitches in the VC...

Last edited:

Matias Saibene

Well-known member
Hi, you need to sort out different issues :
• case in filenames
• "\\" vs "/"
• embedded bmps needs to be loaded as textures now
• add a CMakeLists.txt file containing instructions for building
• add UCSO beforehand since it looks like it's a dependency of G42-200
• fix everything that does not compile and that'll show up when you do it
I just forked the two projects and I'll see what I can do ; since it's using XRSound and sketchpad instead of OrbiterSound/GDI, it shouldn't be a big deal to make it work?

Edit : got some UCSO stuff working but I don't really know how to test it...
View attachment 28807
Edit2 : pushed some stuff on github
View attachment 28809View attachment 28810
I have no idea how to fly this bird though?
Note : there are lots of graphical glitches in the VC...
I had not seen your edit, I will try it as soon as I have internet that is not metered (I am using mobile internet).
Thank you for doing me the favor of including the G42-200, I love that bird.

Matias Saibene

Well-known member
Orbiter failed to build. Maybe it's my mistake, but I'm sure I followed all the steps correctly. I'll try again later.

Attachments

• Orbiter_build_fail.txt
171.4 KB · Views: 6

Jordan

Member
Orbiter failed to build. Maybe it's my mistake, but I'm sure I followed all the steps correctly. I'll try again later.

The problem may be the compiler.
You are using the compiler v12.1.0
I had the same problem with v10.x.x

My solution was to edit the line 417 in the file

from

if (time >= 0)

to

if (time >= (void *) NULL)

Recently I have reinstalled my Linux and now I have the old compiler version 9.4.0 with which it works without editing the code.

Gondos

Member
The problem may be the compiler.
You are using the compiler v12.1.0
I had the same problem with v10.x.x

My solution was to edit the line 417 in the file

from

if (time >= 0)

to

if (time >= (void *) NULL)

Recently I have reinstalled my Linux and now I have the old compiler version 9.4.0 with which it works without editing the code.
Yep, NASSP is riddled with warnings and recent compilers will treat some as errors
Looking at the code I guess there is a real bug because I don't see the point in comparing against the time function
Code:
void ApolloRTCCMFD::Angle_Display(char *Buff, double angle, bool DispPlus)
{
double angle2 = abs(round(angle));
if (time >= 0)
should more likely be
Code:
void ApolloRTCCMFD::Angle_Display(char *Buff, double angle, bool DispPlus)
{
double angle2 = abs(round(angle));
if (angle >= 0)
Maybe the NASSP guys can confirm this...

Currently working on Deepstar since it's a nice FOSS project but it triggered some bugs in my module loading code that I had to fix, and now I still have some NaN issues that may or may not happen also on the official version.
Also it requires GeneralVehicle that does not come under a compatible license so I'm in the process of recoding it?
The Deepstar vessel is quite buggy for now, hopefully it'll help me troubleshoot issues with the OpenGL client...

Edit: if you don't want the pollution from NASSP compilation, you can comment the line "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory

Last edited:

n72.75

Tutorial Publisher
Donator
Yep, NASSP is riddled with warnings and recent compilers will treat some as errors
Looking at the code I guess there is a real bug because I don't see the point in comparing against the time function
That would be a question for @indy91. A lot of our RTCC code is patterned after fortran IV and IBM360 assembly routines (or in most cases their flowcharts. Not sure about this one specifically. We do have code from circa 2002 in other parts of the addon so there are probably plenty of things that need a ln update to pass for modern C++ styles.

indy91

Oh yes, that's a bug. I guess I just copied and pasted the GET_Display function, which is just below Angle_Display, and modified it. But I forgot about the "time" variable which somehow didn't give a build error when I didn't change that to "angle". Thanks for finding that!

Matias Saibene

Well-known member
Hi @Gondos, Turns out I've tried Orbiter again and sometimes it compiles and segfaults. And other times it doesn't even compile.

I will detail:
Case 1: If I apply the patch you mentioned but don't comment "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter starts but produces a segfault. View the orbiter-build-log1 and orbiter-run1 logs.

Case 2: I apply the patch you mentioned and comment out the line "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter compiles but doesn't start, again produces a segfault. More details in orbiter-build-log2 and orbiter-run2.

And I have a question: is it necessary to download everything from scratch (by running git clone https://github.com/TheGondos/orbiter.git... etc) if I have already run time make -j$(nproc) install? I recently started deleting just the build directory and running the commands: mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=$HOME/orbiter_test ..
time make -j$(nproc) install and the results were the same. And sorry for the delay in answering, it turns out that I have a very bad internet connection (~200kB/s). Attachments • orbiter-run2.txt 245.6 KB · Views: 4 • orbiter-build-log2.txt 243.4 KB · Views: 3 • orbiter-run1.txt 2.2 KB · Views: 1 • orbiter-build-log1.txt 245.3 KB · Views: 6 Jordan Member Hi @Gondos, Turns out I've tried Orbiter again and sometimes it compiles and segfaults. And other times it doesn't even compile. I will detail: Case 1: If I apply the patch you mentioned but don't comment "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter starts but produces a segfault. View the orbiter-build-log1 and orbiter-run1 logs. Case 2: I apply the patch you mentioned and comment out the line "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter compiles but doesn't start, again produces a segfault. More details in orbiter-build-log2 and orbiter-run2. And I have a question: is it necessary to download everything from scratch (by running git clone https://github.com/TheGondos/orbiter.git... etc) if I have already run time make -j$(nproc) install?

I recently started deleting just the build directory and running the commands:
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$HOME/orbiter_test .. time make -j$(nproc) install

and the results were the same.

And sorry for the delay in answering, it turns out that I have a very bad internet connection (~200kB/s).It's a bug.

Code:
.....
Error creating directory "/home/matias/orbiter_test/Orbiter/orbiter/build/Orbitersdk/include/UCSO".
.....

There is a file with the name "USGO" in this folder and so no folder "USGO" can be created in that directory. This file is a C++ source code. Rename it to "UCGO.cpp" and try again.

Edit: I did everything from scratch and it worked without any errors.

Last edited:

Gondos

Member
Hi @Gondos, Turns out I've tried Orbiter again and sometimes it compiles and segfaults. And other times it doesn't even compile.

I will detail:
Case 1: If I apply the patch you mentioned but don't comment "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter starts but produces a segfault. View the orbiter-build-log1 and orbiter-run1 logs.

Case 2: I apply the patch you mentioned and comment out the line "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter compiles but doesn't start, again produces a segfault. More details in orbiter-build-log2 and orbiter-run2.

And I have a question: is it necessary to download everything from scratch (by running git clone https://github.com/TheGondos/orbiter.git... etc) if I have already run time make -j$(nproc) install? I recently started deleting just the build directory and running the commands: mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=$HOME/orbiter_test ..
time make -j\$(nproc) install

and the results were the same.

And sorry for the delay in answering, it turns out that I have a very bad internet connection (~200kB/s).
Damn, my mistake, I added the NASSP modules by default in Orbiter.cfg so it'll assert if you don't compile them ?
You can remove ApolloRTCCMFD and ProjectApolloMFD from the Orbiter/Orbiter.cfg.in to fix it.
To synchronize you don't need to clone everytime, you should do :
Code:
git pull
to get the latest repository and then
Code:
git submodule update --recursive --remote
to update the submodules.
Regarding the UCSO directory issue, you're not supposed to have the cpp files deployed during the installation so it's quite strange, most likely a bug in one of the CMakeLists.txt files...

Jordan

Member
@Gondos

1st. I have these wireframed faces. Is there a solution for this?
2nd. Parts in the LUT mesh are missing. Is there a limit number of vertices or faces?

Gondos

Member
@Gondos

1st. I have these wireframed faces. Is there a solution for this?
2nd. Parts in the LUT mesh are missing. Is there a limit number of vertices or faces?

What graphic card are you using? I'm on an old 9800GTX and I don't have this kind of visual artifact.
The OpenGL client uses 16bit indices for index arrays, the same as the D3D7 one

Jordan

Member
@Gondos
NVIDIA GTX 1060 6gb
D3D9 also uses 16bit, which should be enough and Orbiter in Windows has no problems with it.

Gondos

Member
@Gondos
NVIDIA GTX 1060 6gb
D3D9 also uses 16bit, which should be enough and Orbiter in Windows has no problems with it.
I found it, I was mixing using 16bit indices and using 16bits for the number of indices in draw calls... I'm so bad at this OGL stuff it's not even funny...
It fixed my deepstar visual issues so it should fix yours too :

I'll push the fix soon.
Edit : fix pushed

Last edited:

Jordan

Member
I'll push the fix soon.
Edit : fix pushed
Doesn't work. Parts of the LUT are still missing.

By the way, in the file "orbiter_test/Orbiter/Config/ProjectApollo/Earth_VirtualAGC/Base/Canaveral_VirtualAGC.cfg" you can delete the part at the end between BEGIN_SURFTILELIST and END_SURFTILELIST or the whole part, then the black areas at Cape Canaveral are gone.

Gondos

Member
Doesn't work. Parts of the LUT are still missing.
That's bad luck :/ What parts are missing exactly? I can't tell clearly from the image...
The seams between faces are strange, the vertices should be identical since we're using index buffers. Maybe it's a UV problem...
By the way, in the file "orbiter_test/Orbiter/Config/ProjectApollo/Earth_VirtualAGC/Base/Canaveral_VirtualAGC.cfg" you can delete the part at the end between BEGIN_SURFTILELIST and END_SURFTILELIST or the whole part, then the black areas at Cape Canaveral are gone.
Thanks for the info

Jordan

Member
That's bad luck :/ What parts are missing exactly? I can't tell clearly from the image...
The seams between faces are strange, the vertices should be identical since we're using index buffers. Maybe it's a UV problem...

Here is a screenshot comparison D3D9 and OpenGL

Edit: The seams between the faces appear to be transparent.

Gondos

Member
Here is a screenshot comparison D3D9 and OpenGL

Edit: The seams between the faces appear to be transparent.
Thanks, perfect montage
I'll look into it

Gondos

Member
OK, I think I finally got it, there was still a uint16_t remaining somewhere...
I can't push a fix now, if you want to test it, it's in OGLMesh.h in class OGLMesh, struct GROUPREC definition.
There is a :
Code:
        uint16_t nIdx;           // number of indices
that needs to be changed to :
Code:
        uint32_t nIdx;           // number of indices

Replies
99
Views
6K
Replies
74
Views
3K
Replies
22
Views
3K
Replies
1
Views
1K
Replies
15
Views
2K