SDK Question Do GetMachNumber() and GetDynPressure() work correctly in Orbiter 2016?

[fausto]

void antares::DefineAnimations (void)
{
UINT midx = 6;

static UINT airspeedindGrp[1] = {70};
static MGROUP_SCALE airspeedind (midx, airspeedindGrp,1, _V(0,2.14390,0), _V(1,8.9,1));
anim_airspeedind=CreateAnimation(0.0);
AddAnimationComponent (anim_airspeedind, 0, 1, &airspeedind);

static UINT GindGrp[1] = {69};
static MGROUP_SCALE Gind (midx, GindGrp,1, _V(0,2.14390,0), _V(1,8.9,1));
anim_Gind=CreateAnimation(0.0);
AddAnimationComponent (anim_Gind, 0, 1, &Gind);


static UINT DYNPindGrp[1] = {67};
static MGROUP_SCALE DYNPind (midx, DYNPindGrp,1, _V(0,2.14390,0), _V(1,8.9,1));
anim_DYNPind=CreateAnimation(0.0);
AddAnimationComponent (anim_DYNPind, 0, 1, &DYNPind);


static UINT scudotermicoindGrp[1] = {68};
static MGROUP_SCALE scudotermicoind (midx, scudotermicoindGrp,1, _V(0,2.14390,0), _V(1,8.9,1));
anim_scudotermicoind=CreateAnimation(0.0);
AddAnimationComponent (anim_scudotermicoind, 0, 1, &scudotermicoind);

}

I'm trying doing it via clbkAnimate. But it does not work at all... does it work in virtual cockpit?

Antares is a VESSEL2 class vessel. Should it be VESSEL3 or VESSEL4 maybe?

 

[Urwumpe]

Yikes... its a scale animation. :hide: And that with a very obscure magnitude. _V(1, 8.9, 1) ... I am seeing this correctly and this is NO bug?

 

[fausto]

It's a scale animation with a big magnitude because I need to transform a small line into a long one..

 

[martins]

I just came across this topic, and I'm confused:

Do GetMachNumber() and GetDynPressure() work correctly in Orbiter 2016?

I can say that GetMachNumber() and GetDynPressure() return a correct value, because i tested it via OapiDebugString...

It seems that you answered your own question in your initial post. Is there anything for me to investigate, or is this purely an addon issue?

 

[Urwumpe]

It seems that you answered your own question in your initial post. Is there anything for me to investigate, or is this purely an addon issue?

There is also a question about a possible problem with scale animations and SetAnimation. The behavior changed compared to Orbiter 2010P1, which suggests it is no trivial add-on issue, but a change in Orbiters semantics.

 

[fausto]

I have to report another strange behaviour of these scale animations:

If I quit the simulation and restart it via current state, animation levels are all right.. they remain freeze but exactly on the right position where they should have been in the moment when I reload the scenario.

It seems thet animation works just for the first time step and then freezes...

 

[Urwumpe]

I have to report another strange behaviour of these scale animations:

If I quit the simulation and restart it via current state, animation levels are all right.. they remain freeze but exactly on the right position where they should have been in the moment when I reload the scenario.

It seems thet animation works just for the first time step and then freezes...

You are still using MOGE and no other graphics client, right?

 

[fausto]

I'm using the inline graphic client, the default Orbiter one.

 

[martins]

I'm trying doing it via clbkAnimate. But it does not work at all... does it work in virtual cockpit?

clbkAnimate is a nonstandard place to put your SetAnimation calls (if that is what you are saying):

virtual void VESSEL2::clbkAnimate ( double simt )
[...]
This callback allows the module to animate the vessel's visual representation (moving undercarriage, cargo bay doors, etc.) It is only called as long as the vessel has registered an animation request (between matching VESSEL::RegisterAnimation and VESSEL::UnregisterAnimation calls) and if the vessel's visual exists. This callback is not used for the "semi-automatic" animation mechanism (VESSEL::CreateAnimation, VESSEL::AddAnimationComponent)

For clbkAnimate to be called at all you need to sent a request with VESSEL::RegisterAnimation somewhere (and not unregistered it subsequently). You _did_ make sure that clbkAnimate is called. (just checking).

Does the problem affect only scale transforms. Are rotations ok when called from the same spot?

 

[fausto]

Does the problem affect only scale transforms. Are rotations ok when called from the same spot?

Rotation animations are ok. I created an angle of attack indicator based on GetAOA() and it works well.

The problem affects scale transform.. but not all of them. The fuel indicator (based on GetFuelMass()) is a scale, exactly the same as the one used to animate Dyn pressure and Mach indicators.. and it works perfectly!!

It seems that this issue is related to planetary and atmospheric values.

An evidence that this is not an addon bug is that on Space Plane Eridanus I have excatly the SAME indicators and they worked perfectly on O2010P1. They freeze on O2016 with the same behaviour I saw on Antares capsule. The code is the same one (never touched it)....

My numerous attempts to make them work poorly failed..:shrug:

 

[martins]

Sorry, still confused. Aren't those statements contradictory?

I can say that GetMachNumber() and GetDynPressure() return a correct value, because i tested it via OapiDebugString...

It seems that this issue is related to planetary and atmospheric values.

Can you confirm that the values you get from GetMachNumber and GetDynPressure are correct even at the point when your animations don't work (statement 1) or are incorrect (statement 2)?

When you use those same numbers to drive a rotational animation it still works (i.e. the problem is related to scale animations, not to the reported physical values)?

I just try to get an understanding to home in on the problem at least marginally ...

 

[fausto]

Can you confirm that the values you get from GetMachNumber and GetDynPressure are correct even at the point when your animations don't work (statement 1) or are incorrect (statement 2)?

When you use those same numbers to drive a rotational animation it still works (i.e. the problem is related to scale animations, not to the reported physical values)?

I just try to get an understanding to home in on the problem at least marginally ...

Yes, it's strange but it's exactly what happens. Values I got from GetMachNumber and GetDynPressure are right, but when I try to put them into SetAnimation(indicator_anim, value) animations don't work correctly. I put them in clbkPostStep and clbkPreStep both.. no way... I repeat that as I quit the simulation and restart it via current state animation seems to be on the right position, but it's freezed. It seems working just for the first time step, and after that nothing happens...

Rotation animation doesn't seem to be affected. I tried it with getAOA and it works, but I did't try to apply a rotation animation to GetMachNumber and GetDynPressure.. I'm gonna do it and I let you know..

I hope it's clearer..

I compiled it with visual c++ 2010.. could it be the problem? or something inside project configuration? I'm trying to explore all possibilities..

 

[martins]

So to summarise:

- scale animations sometimes stop reacting to input from SetAnimation, and somehow this is correlated with the atmospheric environment the vessel is in
- rotation animations are not affected

This is such a weird combination of circumstances that I am a bit at a loss of where to look for the problem. I'll try to implement my own scale animation to test it.

But in the meantime
- can you please run your code in the debugger, put a breakpoint on the SetAnimation call and make sure that this is still reached when the animation freezes, and that the value passed to SetAnimation is correct?
- is there anything else in your code that changes the state of your vessel in some way, and that is correlated to the moment the animation freezes? (mesh reconfiguration, switching camera views, docking/attachment events, anything?)

 

[fausto]

- is there anything else in your code that changes the state of your vessel in some way, and that is correlated to the moment the animation freezes? (mesh reconfiguration, switching camera views, docking/attachment events, anything?)

BINGO!
I was checking my code once again and I realized that when Dynamic Pressure reaches 1000 a function inserts an heat shield mesh with alpha texture manipulation. The reason I dont' manipulate main heat shield texture is because it compromises D3D9 compatibility..

I was concentrated on virtual cockpit and I did't see (and remember, until now) this mesh to be added.

I forced the funcion to insert that mesh just in external view and it did the trick!

It's not a SetAnimation issue but it's related to this mesh insertion.

Now the question is: Why it did't happen on O2010P1?