# Orbiter beta 121129

#### kuddel

##### Donator
Donator
oapiGetGbodyCount() & oapiGetBaseCount() return strange values

Hi again,

I would not be much concerned about the zero-sized files. I just wanted to know if they are meant to be 'to be deleted' files...

Another more serious issue is when I try to run the external graphic client on the new release.
After re-compiling it against the (changed?) API-headers I found that these two methods return very unusual high values:
oapiGetGbodyCount()
oapiGetBaseCount()
The values returned are way to high!
Out of curiosity, I tried to cut the lower half of the result via HIWORD( ... ) and I was able to start with the D3D9Client...
For example:
PHP:
    DWORD npl = HIWORD( oapiGetGbodyCount() );
DWORD npl = oapiGetGbodyCount();// <= _very_ high values!!
I did not (yet) check whether those 'cut' values are reasonable (or all zero), but I think there is something fishy there.

Thanks for looking at this,
Kuddel

#### martins

##### Orbiter Founder
Orbiter Founder
I get 32 from oapiGetGbodyCount() in my installation - how many do you get?? Does this also happen with the inline client or the D3D7 client?

#### kuddel

##### Donator
Donator
I get 32 from oapiGetGbodyCount() in my installation - how many do you get?? Does this also happen with the inline client or the D3D7 client?
It was something like over 300 thousand!
But currently I can't even run the scenario (I always test with "Delta-glider\DG Mk4 in orbit.scn") which did run after my previous changes....hmmm

Maybe it's some of those "VisualStudio needs to rebuild sometimes" problems.
Unfortunately I don't have any more time to look any deeper into it, but be assured that I will report back as soon as I have any news.

Ah by the way: I was debugging the D3D9Client.

I will re-start from scratch tomorrow and report what happens here.
For now I can not even get the "uncut" values of oapiGetGbodyCount(). It crashes somewhere else now. I think it's best to do a complete re-compile and fresh start tomorrow.

Thanks for the quick response and good night,
Kuddel

---------- Post added at 01:59 ---------- Previous post was at 01:40 ----------

Hi again,

I couldn't go to sleep with this

The oapiGetGbodyCount() does indeed return 32!

But oapiGetBaseCount() returns 1098137279 !

This is the basic code I ran:
PHP:
    DWORD npl = oapiGetGbodyCount();
for (DWORD p=0;p<npl;p++) {
OBJHANDLE hPl = oapiGetGbodyByIndex(p);
if (hPl) {
DWORD nbs = oapiGetBaseCount(hPl); // this returns 1098137279 !
for (DWORD b=0;b<nbs;b++) {
OBJHANDLE hBs = oapiGetBaseByIndex(hPl, b);
; // do something
}
}
}
Nevertheless, I go to bed now ... really!

/Kuddel

#### martins

##### Orbiter Founder
Orbiter Founder
Well, the first Gbody is the sun, and oapiGetBaseCount() is only supported for planets and moons. I'll put a safeguard into oapiGetBaseCount for the next beta to catch this.

However, this shouldn't have worked with previous orbiter versions either. Did you use this code before?

#### shangding

##### New member
Still getting CTD, even with full default settings. Maybe it's my four years old notebook...

"Orbiter.exe stopped working."

The log:
I also have this CTD,and I don't know how to fix it.

#### dansteph

Beta Tester
Bug confirmed: CallBack order

In previous Orbiter Version "clbkPostCreation" was called before "clbkLoadPanel" in anyway.
In the latest beta if the ship have the focus at start of Orbiter the call order is inverted.

As many ship count on the old call order to make initialisation this can cause a lot
of problems that we can't solve unless recompiling all the addons.
(Case of all ship compiled with OrbiterSound's SDK since years)

#### kuddel

##### Donator
Donator
Well, the first Gbody is the sun, and oapiGetBaseCount() is only supported for planets and moons. I'll put a safeguard into oapiGetBaseCount for the next beta to catch this.
Thanks! I will try a "isPlanet" security check once I get back home.
However, this shouldn't have worked with previous orbiter versions either. Did you use this code before?
Yes! It worked in both 100830 & 111105!

/Kuddel

#### jarmonik

Beta Tester
There is also an other callback order issue. If the "start paused" is checked then GraphicsClient::clbkUpdate() is called before GraphicsClient::clbkPostCreation()

---------- Post added at 11:59 ---------- Previous post was at 11:52 ----------

However, this shouldn't have worked with previous orbiter versions either. Did you use this code before?
I have used similar code as well since there are no oapiGetBasePlanet() function in Orbiter 2006.

PHP:
VECTOR3 GetBasePosition(OBJHANDLE hBase, double mjd)
{

OBJHANDLE hPlanet = NULL;

int g = oapiGetGbodyCount();

for (int i=0;i<g;i++) {
OBJHANDLE hP = oapiGetGbodyByIndex(i);
int b = oapiGetBaseCount(hP);
for (int j=0;j<b;j++) {
if (oapiGetBaseByIndex(hP,j)==hBase) {
hPlanet = hP;
break;
}
}
if (hPlanet!=NULL) break;
}

...

#### orb

Maybe there is something wrong in my install (Installed over previous beta which was installed on a fresh 2010+P1) but in all scenario the Atlantis ready on launchpad Sky rocket without any command turning like a mad at mach 3 as soon as I launch the scenario. Also many "old style" ground object start to slide or sky rocket.

{...}

UMmu slide on ground at 20km/h without stop on earth (2023 scenario) and sky rocket with any command. Cars make exactly the same. (2001 scenario slide without stop and sky rocket with any command issued)
The DeltaGlider and ShuttleA work fine.
I can reproduce a similar issue when the simulation was run sequentially (after the previous session was deallocated, not terminated), but with stock vessels, on Earth, and only when wind effects were enabled and simulation initially unpaused. This can be any other scenario with landed (on Earth) vessels, not just the same as in the previous session. Landed vessels start moving horizontally with initial speed making them fireballs. But they stop after a kilometer or so.

Another issue is that landed (inactive) vessels are saved to "(Current state).scn" as active, making them all unstable when the wind is enabled (even if the previous Orbiter session was terminated to prevent the fireball issue). For example Atlantis in launch configuration saved this way will on ~80% fall down from the pad after that scenario was loaded.

#### Ripley

##### Tutorial translator
Donator
Many empty folders too.
Doh!
After a few tries with Martin's 7-zip script, I found out that these empty folders are left (quite logically) by 7-zip's diff compare.
The folders with no difference between the two compared versions are copied, empty.

I wasn't able to find a switch to exclude them.

Last edited:

#### kuddel

##### Donator
Donator
oapiGetBaseCount() issue

Hello martins,

I have 'guarded' the suitable calls to oapiGetBaseCount() by a previous check that the OBJHANDLE is a planet with success!
Thank you for the hint!

So the code now looks like this:
PHP:
    DWORD npl = oapiGetGbodyCount();
for (DWORD p=0;p<npl;p++) {
OBJHANDLE hPl = oapiGetGbodyByIndex(p);
if (hPl && oapiGetObjectType(hPl) == OBJTP_PLANET) { // <= chanaged
DWORD nbs = oapiGetBaseCount(hPl);
for (DWORD b=0;b<nbs;b++) {
OBJHANDLE hBs = oapiGetBaseByIndex(hPl, b);
; // do something
}
}
}
This should always be save whether you include a guard or not.

Thanks again,
Kuddel

@jarmonik: I will post my changes in the D3D9Client development thread, so all fixes are at one place.

#### Ripley

##### Tutorial translator
Donator
...By the way, there are several 0-Byte sized files in the patch...
After even more tries, it turns out that 0-byte files in the diff patch are the deleted files.

Starting folder situation:

fileA
fileB
fileC

-----

After some time, same folder:

FileA
FileC
FileD
FileE

(FileB was deleted)

-----

DIFF file resulting:

FileB (0 bytes)
FileD
FileE

-----

Hope it's clear enough.

#### orb

After even more tries, it turns out that 0-byte files in the diff patch are the deleted files.
What archive manager / extractor are you using to apply the patch?

These "0-byte" files you see have "anti" flag set. If you use 7-zip to extract them, they will cause the target file deleted instead of being extracted from the archive. Other archive managers/extractors will delete the file only if they respect the "anti" flag, otherwise they will only truncate the target file to 0 bytes (by extracting the 0-byte file from the archive over it). (For example Midnight Commander simply doesn't display those "anti" files for me in the patch archive at all.)

Other 0-byte files which don't have the "anti" flag set should be extracted normally by creating 0-byte files in the target directory.

You can check which 0-byte files have that flag set in 7zFM (7-zip file manager) from 7-zip.

#### Ripley

##### Tutorial translator
Donator
What archive manager / extractor are you using to apply the patch?...
7-zip of course.

But I made this tries with dummy folders, with only a few files/folders in them, I didn't actually extract the real beta patch in my Orbiter install.

Anyway, now I see what you mean.
I "applied" my dummy diff patch to my test folder and in fact the 0-byte files actually deleted their corresponding files.
Awesome!

OF: the place where you learn something new every day!

#### kuddel

##### Donator
Donator
OF: the place where you learn something new every day!
Second that!

#### shangding

##### New member

i found orbiter 20100830 haven't that file.
how to fix it?

#### Attachments

• 62.9 KB Views: 287

#### martins

##### Orbiter Founder
Orbiter Founder

i found orbiter 20100830 haven't that file.
how to fix it?
Orbiter 100830 doesn't have it, but Orbiter121025 should have (in Textures subdirectory). It is used by the new main menu. Do you have that file? Did you install beta 121025 over a clean 100830 installation?

#### shangding

##### New member
Orbiter 100830 doesn't have it, but Orbiter121025 should have (in Textures subdirectory). It is used by the new main menu. Do you have that file? Did you install beta 121025 over a clean 100830 installation?
yes,I installed it,over a clean 100830,and I have that file in Textures subdirectory.