# New ReleaseD3D9Client Development

#### kuddel

##### Donator
Donator
[,,,] I have never used NDEBUG flag [...]
Maybe not intentionally, but as mentioned by several people now it is used for many compile-dependent things.
When you create a Debug project/solution with Visual Studio it adds the _DEBUG definition per default[*]
and a Release project/solution adds the NDEBUG definition accordingly.

[*] Visual Studio defines _DEBUG when you specify the /MTd or /MDd option

#### n72.75

Tutorial Publisher
Donator
What exactly does the "Enable absolute animation handling" option do, and is there any good reason for it to not be enabled by default?

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
What exactly does the "Enable absolute animation handling" option do, and is there any good reason for it to not be enabled by default?
By default Orbiter uses incremental animations meaning that for each frame the previous animation state is incremented by small amount, which includes some errors, over time these errors accumulate and the animation is no longer in the orientation it's supposed to be. (3-10 mins in worst cases)

Absolute animations updates the animation state from a default state for each frame. Which doesn't suffer from the error mentioned. But the absolute animations can fail if an add-on alters the order of operations (rotations), so, it's not 100% backwards compatible. But so-far no add-on is known to fail.

#### JMW

Absolute animations updates the animation state from a default state for each frame. Which doesn't suffer from the error mentioned. But the absolute animations can fail if an add-on alters the order of operations (rotations), so, it's not 100% backwards compatible. But so-far no add-on is known to fail.
Hi jarmonik.
Well, hate to be the first (n hopefully the last) but Absolute setting gives mega problems on my F-35B
It dumps the wheels about 2 metres below the gear on lowering.

It uses the original mesh and gear sequence (with permission), of Kev Shannow's F-35B.
Can you tell from code what I need to change to get the "order of operations" right?

Thanks n keep up the excellent work on this client please.

C++:
 // Gear anims

//Front Gear
static UINT GGrp1[9] = {6,7,8,9,10,11,12,13,125};

static MGROUP_ROTATE gear1 (0,GGrp1, 9, _V(0,-0.9227885,3.099234), _V(1,0,0), (float)(-115*RAD));

//Rear Gear Left
static UINT GGrp2[4] = {14,15,16,126};

static MGROUP_ROTATE gear2 (0,GGrp2, 4, _V(-1.15901,-0.4520788,-2.172986), _V(1,0,0), (float)(-99*RAD));

//Rear Gear Right
static UINT GGrp3[4] = {18,20,21,127};

static MGROUP_ROTATE gear3 (0,GGrp3, 4, _V(1.15901,-0.4520788,-2.172986), _V(1,0,0), (float)(-99*RAD));

//Front Gear Cover
static UINT GGrp5[1] = {5};

static MGROUP_ROTATE gear5 (0,GGrp5, 1, _V(0.2282761,-0.870366,3.679197), _V(0,0,1), (float)(-93*RAD));

//Rear Cover Left
static UINT GGrp12[2] = {173,174};

static MGROUP_ROTATE gear12 (0,GGrp12, 2, _V(-1.199155,-0.3544314,-1.368714), _V(0,0,1), (float)(99*RAD));

//Rear Cover Right
static UINT GGrp13[2] = {175,176};

static MGROUP_ROTATE gear13 (0,GGrp13, 2, _V(1.199155,-0.3544314,-1.368714), _V(0,0,1), (float)(-99*RAD));

//Rear Gear Left2
static UINT GGrp20[5] = {14,15,16,17,126};

static MGROUP_ROTATE gear20 (0,GGrp20, 5, _V(-1.15901,-0.4520788,-2.172986), _V(0,0,1), (float)(15*RAD));

//Rear Gear Right2
static UINT GGrp21[5] = {18,19,20,21,127};

static MGROUP_ROTATE gear21 (0,GGrp21, 5, _V(1.15901,-0.4520788,-2.172986), _V(0,0,1), (float)(-15*RAD));

//Rear Gear Left3
static UINT GGrp23[1] = {17};

static MGROUP_ROTATE gear23 (0,GGrp23, 1, _V(-1.15901,-0.4969712,-1.226534), _V(1,0,0), (float)(50*RAD));

//Rear Gear Right3
static UINT GGrp24[1] = {19};

static MGROUP_ROTATE gear24 (0,GGrp24, 1, _V(1.15901,-0.4969712,-1.226534), _V(1,0,0), (float)(50*RAD));

anim_gear = CreateAnimation (0);

AddAnimationComponent  (anim_gear, 0.2, 0.5, &gear24);

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
I can't see anything wrong in there. Although, my knowledge on creating animations is not that high. Could there be animation is somewhere that moves the entire mesh ? Also do you have a download link so that I could have a look (to see what happen inside the client) ?
Also we could have something like oapiEnableAbsoluteAnimations(VISHANDLE hVisual, bool bSetEnabled) so that absolute animations could be disabled by default and then enabled for vessels those depend on it. The error accumulation isn't a problem in landing gear but it does create problems with robotic arms and ADI balls.

JMW

#### JMW

Also we could have something like oapiEnableAbsoluteAnimations(VISHANDLE hVisual, bool bSetEnabled) so that absolute animations could be disabled by default and then enabled for vessels those depend on it. The error accumulation isn't a problem in landing gear but it does create problems with robotic arms and ADI balls.
Excellent idea, thank you.
I've opened a "conversation" with you as result of your questions.

#### DDasng1352

Strange, for me my D3D9 client wont save the advance settings. I'm using Orbiter Beta with the lates D3D9 client version for Beta.

#### DDasng1352

Strange, for me my D3D9 client wont save the advance settings. I'm using Orbiter Beta with the lates D3D9 client version for Beta.
It seems as if every time I exit out of Orbiter with my settings it just reverts back to default.

#### Max-Q

##### 99 40
Strange, for me my D3D9 client won't save the advance settings. I'm using Orbiter Beta with the latest D3D9 client version for Beta.
My Orbiter Beta with D3D9 does the same thing. I have to manually edit the configuration file to make the settings stick.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Perhaps this saving bug has something to do with the process termination hack. Check if it works with the shutdown options set to "deallocate" instead of "respawn".

#### DDasng1352

Perhaps this saving bug has something to do with the process termination hack. Check if it works with the shutdown options set to "deallocate" instead of "respawn".
Can't find that setting on my Hp laptop.

#### Max-Q

##### 99 40
I tried all three shutdown options. Still no luck, in won’t save the settings.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Can't find that setting on my Hp laptop.
It is an Orbiter setting. You can find it on the "Extra" tab.

#### DDasng1352

Perhaps this saving bug has something to do with the process termination hack. Check if it works with the shutdown options set to "deallocate" instead of "respawn".
Mine is already set to deallocate.

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
Where is your Orbiter installation ? If it's in a C:/Program Files/ then it might suffer some access rights issues. Also is the D3D9Client.cfg write protected somehow ?

Anyway, I have moved the state save from the end of the program to a start of it. So, next version should save it when simulation starts. I did suffer about the same problem my self couple of days but the problem disappeared as suddenly as it had appeared. So, the cause remained a mystery.

I wonder, would it be possible for an add-on to change working directory and getting the file misplaced as a result somehow.

#### Max-Q

##### 99 40
The only add on I use in my beta install (other than D3D9, obviously), is NASSP.
The location is not protected, and my Orbiter2016 D3D9 saves the settings just fine.
I don’t think D3D9client.cfg is write protected, because I can edit it using Notepad++ just fine.

#### kuddel

##### Donator
Donator
@DDasng1352 : I would then recommend to add the "write" right to the User account at that folder:
1. Right-click on the folder (C:/Program Files/Orbiter or what its name is);
2. select the "Security" Tab;
3. then click the "Edit..." button and confirm the windows UAC prompt;
4. select the User account (something like "Users (YOUR-LAPTOP\Users)") in the dialog that appeared;
5. now tick the "Write" checkbox and confirm (you can click "Apply" before "OK" if you wish ).

P.S.: I hope I got the naming of the dialogs/buttons/entries right, as I am using a German locale Windows.
P.P.S: I used to have one folder under C:/Program Files/Orbiter, that contained all my different Orbiter installations (like C:/Program Files/Orbiter/D3D9DevTrunk, C:/Program Files/Orbiter/NASSP or C:/Program Files/Orbiter/D3D9Dev2016). That way you only have to give the write-right to that one folder (C:/Program Files/Orbiter) and all subsequently added folders will automatically inherit the write-right in the future.
Giving the write-right for users to C:/Program Files folder however is not recommended! It's after all a security feature.

Last edited:

#### DDasng1352

@DDasng1352 : I would then recommend to add the "write" right to the User account at that folder:
1. Right-click on the folder (C:/Program Files/Orbiter or what its name is);
2. select the "Security" Tab;
3. then click the "Edit..." button and confirm the windows UAC prompt;
4. select the User account (something like "Users (YOUR-LAPTOP\Users)") in the dialog that appeared;
5. now tick the "Write" checkbox and confirm (you can click "Apply" before "OK" if you wish ).

P.S.: I hope I got the naming of the dialogs/buttons/entries right, as I am using a German locale Windows.
P.P.S: I used to have one folder under C:/Program Files/Orbiter, that contained all my different Orbiter installations (like C:/Program Files/Orbiter/D3D9DevTrunk, C:/Program Files/Orbiter/NASSP or C:/Program Files/Orbiter/D3D9Dev2016). That way you only have to give the write-right to that one folder (C:/Program Files/Orbiter) and all subsequently added folders will automatically inherit the write-right in the future.
Giving the write-right for users to C:/Program Files folder however is not recommended! It's after all a security feature.
Just did it, but I got some failures.