SDK Question Is animation identifier constant?

[vchamp]

If I want to call the SetAnimation() method for a vessel outside of this vessel's module, is it safe to assume that the animation's id is always the same. I have not found a way to know this id outside of vessel's module. Supposedly it is just an index of animation and thus shouldn't change.

 

[Urwumpe]

If I want to call the SetAnimation() method for a vessel outside of this vessel's module, is it safe to assume that the animation's id is always the same. I have not found a way to know this id outside of vessel's module. Supposedly it is just an index of animation and thus shouldn't change.

Not sure if it is an index or a pointer. I wouldn't assume too much there for one important reason: It might break compatibility pretty soon.

 

[vchamp]

It can't be a pointer, because I called SetAnimation(0, 1) and it worked. I don't like the idea to hardcode animation ids too, but it seems there is no way to find a required animation id to pass it to SetAnimation().

 

[Urwumpe]

It can't be a pointer, because I called SetAnimation(0, 1) and it worked. I don't like the idea to hardcode animation ids too, but it seems there is no way to find a required animation id to pass it to SetAnimation().

Still your code could break badly if you have a different version of the vessel in question then.

 

[vchamp]

Yes, that's bad. Moreover an internal state of a vessel won't change accordingly and an animation status won't be saved to a scenario. I must find another way to alter moving parts of vessels. Maybe it is possible to load a predefined state in the same way as when scenario is loaded.

 

[Urwumpe]

Yes, that's bad. Moreover an internal state of a vessel won't change accordingly and an animation status won't be saved to a scenario. I must find another way to alter moving parts of vessels. Maybe it is possible to load a predefined state in the same way as when scenario is loaded.

What about defining a standard interface via clbkGeneric that any add-on developer can choose to implement?

 

[vchamp]

This function is a very nice addition to the API and may be used in many different ways. I already had situations when I needed such function before it appeared. However it can be used only by modules from the same developer or those who agreed on the meaning of its parameters. I need to animate any existing vessel.

 

[Urwumpe]

This function is a very nice addition to the API and may be used in many different ways. I already had situations when I needed such function before it appeared. However it can be used only by modules from the same developer or those who agreed on the meaning of its parameters. I need to animate any existing vessel.

That is a pretty large range of vessels that you want to support.

 

[Face]

If I want to call the SetAnimation() method for a vessel outside of this vessel's module, is it safe to assume that the animation's id is always the same. I have not found a way to know this id outside of vessel's module. Supposedly it is just an index of animation and thus shouldn't change.

What do you want to do? I'm asking because I once used an animation-mapping for OMP. It basically got a class-to-indexes database from the server, with mesh/group/vertex data for a reference point per index. It then calculated the state from this reference point to get the animation index' state value (basically a crude double GetAnimation(int) ). This value was then transmitted to receivers and applied there via SetAnimation.

So I can somewhat confirm that the index is constant per class over multiple Orbiter instances.

I even enhanced the MeshDebugger a bit to get the necessary database information from stock classes. If you're interested in that, drop me note.

regards,
Face

 

[vchamp]

I want to use it in the Plants add-on. When I send a command to expose a vessel it should appear on a ground with the correct landing gear status and probably some other parts should be in an appropriate position too.

Does your method changes the internal state of a vessel? I mean when you want to lower gear in XR2, for example, does it change the switch position at the 2D panel, and will the state be saved to scenario correctly?

At the moment I successfully used the clbkLoadStateEx() function to lower gear in TI ShuttlePB. But it is only one of hundreds of vessels, I can't be sure that this method will work for all.

 

[martins]

From an object-oriented point of view, it seems wrong to manipulate a vessel's animation states from the outside. Only the vessel should be responsible to keep its animations in sync with its 'logical' state, so the animation IDs and pointers are protected resources inside the vessel class.

For example, your "gear down" request not only affects the animations, but also the touchdown points, surface friction coefficients, cockpit switches, etc. All this has to be taken care of by the vessel, which you would bypass if you set the animation state directly from the outside.

If I understood correctly your plant is producing vessels, so the "gear down" problem arises at the point of vessel creation. Maybe some sort of intelligent vessel constructor method would be required, that allows the vessel to set its initial state according to the general situation it is placed in (e.g. "launch-ready").

 

[Urwumpe]

Well, I would suggest simply defining a common message number in clbkGeneric, and have it parse either a Lua code string or a JSON string containing state data. The first is already available directly in orbiter, but permits more damage, the second is still pretty light-weight and could be included cheaply in any add-on.

 

[vchamp]

If I understood correctly your plant is producing vessels, so the "gear down" problem arises at the point of vessel creation. Maybe some sort of intelligent vessel constructor method would be required, that allows the vessel to set its initial state according to the general situation it is placed in (e.g. "launch-ready").

Right, a plant creates (produces) new vessels. It would be nice to have some method of setting the required initial state in Orbiter API. I don't like the hacks I am doing now. It would be useful not only for my add-on. It is a common situation, when a user creates a vessel, it appears in orbit, but if he wants to start using it on a ground then gear should always be deployed manually first, if it is retracted by default.

I am not familiar with LUA scripting. Can it be used to solve my problem now without additions to API?

 

[Wishbone]

Lua in its current state is mostly unusable due to incompleteness and weird misalignment of interfaces with oapi, and hooking to Lua from C is akin to pulling one's right ear with a left hand over the head.

 

[Urwumpe]

Lua in its current state is mostly unusable due to incompleteness and weird misalignment of interfaces with oapi, and hooking to Lua from C is akin to pulling one's right ear with a left hand over the head.

I have to disagree... maybe not on the oapi, that is really a bit crude and could require some fine tuning. But programming Lua from C is really simple. No complex pointer structures used at all and if you know the important tricks, the stack model of Lua is easily tamed.

 

[Wishbone]

Simple - maybe. Efficient - no. The very reason of having an OO design is to call some method and deploy gear (asynchronously!), even if it would initiate a timed sequence (APU on - deploy - APU off).

 

[Face]

Does your method changes the internal state of a vessel? I mean when you want to lower gear in XR2, for example, does it change the switch position at the 2D panel, and will the state be saved to scenario correctly?

No, and I can only agree with Martin here:

From an object-oriented point of view, it seems wrong to manipulate a vessel's animation states from the outside. Only the vessel should be responsible to keep its animations in sync with its 'logical' state, so the animation IDs and pointers are protected resources inside the vessel class.

For example, your "gear down" request not only affects the animations, but also the touchdown points, surface friction coefficients, cockpit switches, etc. All this has to be taken care of by the vessel, which you would bypass if you set the animation state directly from the outside.

This is the reason why I left that path. I am now hooking the RecordEvent() call, transmit this information, and use the clbkPlaybackEvent() method to execute things like "GEAR DOWN".

Unfortunately, this is still not the silver-bullet, as some vessels like XR2 have internal logic that prevent playback-events from happening, like e.g. automatic APU shutdown.

regards,
Face