Discussion Proposal: Generic Vessel Systems

[Hielor]

See http://www.orbiter-forum.com/showthread.php?p=115665#post115665 for part of the preliminary discussion. The problem for simpit builders and anyone wanting to set up advanced inputs to Orbiter is that there's no standardized way of handling systems in Orbiter. Look at FSX, for example--you set the "gear down" key to be whatever you want, and all vessels respect that keybinding, rather than needing to be sent a specific key.

I was thinking about a (potentially easy) addition to the VESSEL interface for common state-based things like landing gear. You could have a pair of callbacks in the vessel, one of which triggers the action and one of which gets the state.

So for example, you could have a "trigger system" method which you could pass ORBSYS_GEAR and ORBSYS_ACTION_EXTEND to, and the vessel would react accordingly. ORBSYS_ACTION_RETRACT and ORBSYS_ACTION_TOGGLE would act appropriately. You could then have a "get state" method which you could pass ORBSYS_GEAR and it would return ORBSYS_STATE_EXTENDED, ORBSYS_STATE_RETRACTED, or ORBSYS_STATE_MOVING as appropriate.

You could then have the Orbiter core manage keybinds for these actions, similar to how FSX does it. Rather than the vessel reacting to a key directly, it would react to a system action message. This would prevent different vessels having different keybinds for the same action (ie, speedbrakes, ctrl-b in stock DG but b in DGIV), and for backwards compatibility if the vessel ignored the system message it would just get passed the key.

Simpit builders could then query the "get state" method and use the "trigger action" method. You could have "systems" for all the common things--APU, gear, flaps, airbrakes, radiator, secondary-engine doors, etc.

Vessels would only need to tie this to the existing key-based actions, and the orbiter core would only need to convert keypresses to system messages according to the keybinds assigned to the user.

System and action ideas could be taken from sims like FSX or X-Plane, which have a very long list of standard keybindable systems in them.

Thoughts?

 

[ar81]

First you may need all old addons to attach to the new standard. Or you may have a mix between old and new standard.

 

[pattersoncr]

First you may need all old addons to attach to the new standard. Or you may have a mix between old and new standard.

He already addressed this issue:

...and for backwards compatibility if the vessel ignored the system message it would just get passed the key...

 

[Hielor]

First you may need all old addons to attach to the new standard. Or you may have a mix between old and new standard.

Well, this is always the problem with moving forward.

Obviously, updating all old addons is impractical. At some point you have to decide that the benefit of moving forward, even with a mix of old and new, far outweighs the disadvantage of having that mix.

With the proposal here, the default implementation for these functions would be to return a not-handled indicator, which indicates to the Orbiter core that the keypress should be passed directly to the vessel, as it may be a legacy vessel.

As time moves on, more and more vessels will support the system. Perhaps you could have some way of indicating to the user that the loaded vessel is a legacy craft and the craft's manual will need to be consulted in order to determine what the key controls are.

 

[yagni01]

KeyComm was an early attempt at this, and I think the same issues apply here. It would be simpler if the interface and protocol were part of the core, since its distributing the key strokes, but there also needs to be a standard for the messages that has to be maintained by someone. I've run into the same kind of thing with trying to get vessel devs to expose them using the XRVesselCtrl interface (which I think of as eXtended Remote Vessel Control) for us flight deck builders, I'm sure mostly because its additional work, but I'm not dismissing a little NIH in there too.

Anyway, at some point someone will want to send messages to the non-focus vessels, and then vessel-to-vessel. With 'getState' you've already moved beyond the realm of keybinding. We have other de facto standards, uMMU, OrbiterSound, etc., so its not necessary to have it as part of core, but even if it was we need a critical mass of vessel developers to support it. So there has to be some 'bang for the buck' for them.

 

[Hielor]

KeyComm was an early attempt at this, and I think the same issues apply here. It would be simpler if the interface and protocol were part of the core, since its distributing the key strokes, but there also needs to be a standard for the messages that has to be maintained by someone. I've run into the same kind of thing with trying to get vessel devs to expose them using the XRVesselCtrl interface (which I think of as eXtended Remote Vessel Control) for us flight deck builders, I'm sure mostly because its additional work, but I'm not dismissing a little NIH in there too.

Anyway, at some point someone will want to send messages to the non-focus vessels, and then vessel-to-vessel. With 'getState' you've already moved beyond the realm of keybinding. We have other de facto standards, uMMU, OrbiterSound, etc., so its not necessary to have it as part of core, but even if it was we need a critical mass of vessel developers to support it. So there has to be some 'bang for the buck' for them.

Making it part of the core (as functions in, say, a VESSEL3 type) would make it very easy for a developer to adopt it, and the proposals here are a lot "lighter" than the XRVesselCtrl interface. This is really just an alternate, more standard interface to the key commands that vessels already have.

As for messages being maintained, I think that this would be best as the sort of thing that's established once and then left. Obviously, no one can ever hope to cover all possible systems that people would want to simulate, so this would just cover all the major bases that many complex spacecraft would have, which would in itself be a great benefit to simpit builders and normal users alike--rather than having each ship have a long list of key commands specifically for that ship, it would make use of all the standard ones you've set up and a much smaller set of custom commands.

 

[yagni01]

Making it part of the core (as functions in, say, a VESSEL3 type) would make it very easy for a developer to adopt it, and the proposals here are a lot "lighter" than the XRVesselCtrl interface. This is really just an alternate, more standard interface to the key commands that vessels already have.

I'm sure its lighter, as I'll discover if I ever re-work the Shuttle-A :sos:

 

[computerex]

Seems like an OK idea, but with Orbiter there is far too much flexibility making it rather difficult to come up with some standardized messaging system.

But this definitely does not need to be implemented in the core. It doesn't make sense to potentially compromise the core's stability with something that is already easy to implement using the plug-in interface.

 

[Hielor]

Seems like an OK idea, but with Orbiter there is far too much flexibility making it rather difficult to come up with some standardized messaging system.

But this definitely does not need to be implemented in the core. It doesn't make sense to potentially compromise the core's stability with something that is already easy to implement using the plug-in interface.

In the Orbiter community, ideas that aren't implemented in the core, regardless of how excellent they are, don't become widespread.

Moreover, I thought that generic plugins couldn't accept keyboard input? ovcConsumeBufferedKey is marked as obsolete. Anyway, a primary point here is standardization of vessel keyboard interfaces, which would best be done in the core.

I'm not really sure how much this would "compromise the core's stability" seeing as it's really no different than the existing clbkConsumeBufferedKey, but rather than sending the vessel a key it sends a "system event".

 

[computerex]

In the Orbiter community, ideas that aren't implemented in the core, regardless of how excellent they are, don't become widespread.

Not really. UMMU is a good example. So is orbiter sound. I don't like the idea of forcing the developer to follow some standard.

Moreover, I thought that generic plugins couldn't accept keyboard input? ovcConsumeBufferedKey is marked as obsolete. Anyway, a primary point here is standardization of vessel keyboard interfaces, which would best be done in the core.

The plug-ins have no keyboard interface provided by Orbiter, but there are ways around that. In any case an SDK that can implement what you are asking is trivial to implement.

I'm not really sure how much this would "compromise the core's stability" seeing as it's really no different than the existing clbkConsumeBufferedKey, but rather than sending the vessel a key it sends a "system event".

Well if it can be implemented already with existing tools I don't see why it has to be in the core. If there is appeal for the thing people will use it, even if it's an add-on.

 

[Hielor]

Not really. UMMU is a good example. So is orbiter sound. I don't like the idea of forcing the developer to follow some standard.

No one is forcing developers to do this, but it will be much easier to adopt than requiring *yet another* dependency for users. Plus, part of the point here is to make a variety of vessels easier to use for a lesser-experienced user (since all vessels using this method will use the same user-defined keys for any given system), and requiring *another* dependency is not going to help that.

This would also allow actions to be bound to joystick buttons directly, similar to the way FSX does it.

The plug-ins have no keyboard interface provided by Orbiter, but there are ways around that. In any case an SDK that can implement what you are asking is trivial to implement.

So it requires an unsupported workaround, but is trivial to implement?

If it's so trivial, why hasn't it been done?

Well if it can be implemented already with existing tools I don't see why it has to be in the core. If there is appeal for the thing people will use it, even if it's an add-on.

Does it have to be in the core? No.
Would it experience wider adoption and be easier for both users and developers if it were in the core? Yes.

 

[computerex]

No one is forcing developers to do this, but it will be much easier to adopt than requiring *yet another* dependency for users. Plus, part of the point here is to make a variety of vessels easier to use for a lesser-experienced user (since all vessels using this method will use the same user-defined keys for any given system), and requiring *another* dependency is not going to help that.

Well it doesn't really matter. Considering the feedback in this thread it doesn't seem as if many people are interested. But in any case, if it is implemented in the core I don't have an issue with that, I just think it would be better done if implemented as an add-on. Orbiter is based on add-ons, the core is nothing but a skeleton. Installing add-on is no big deal and is essential for good experience. Dependencies are not an excuse for adding things in the core. As far as the user interface is concerned, Orbiter already is several years behind as compared to today's standard. But we are just talking here. It boils down to what martin thinks about it (for adding the thing in VESSEL3). The conservative developers could always make their vessels with VESSEL2 if the thing is added in VESSEL3 anyway.

This would also allow actions to be bound to joystick buttons directly, similar to the way FSX does it.

Possible with a plug-in.

So it requires an unsupported workaround, but is trivial to implement?

By workaround I don't mean a hack. I suppose that was a bad word to use no? Gives a very negative connotation for some reason. But ya, fairly trivial to implement.

If it's so trivial, why hasn't it been done?

Just because something is trivial it doesn't mean there is appeal for it. I have noticed people here are all about talking and 'proposals' but hardly anyone takes action and actually does something. It's as if people have more fun talking about the design then actually making the thing. Why don't you make a prototype ?

Does it have to be in the core? No.
Would it experience wider adoption and be easier for both users and developers if it were in the core? Yes.

Dude just because it'd be more convenient if it was in the core it doesn't mean it should be in there. Personally I would like orbiter sound to be in the core, I would also like UMMU in there, as well as the mid-res KSC. I would also like the Shuttle Fleet to come with the core as well as the NASSP+AMSO add-ons. They take time to install and having them come pre-configured will be excellent. And of course they'll also have a 'wider adoption'. The possibility of that happening however is very, very small.

 

[Urwumpe]

Subsystems could be better done with a framework, and it wouldn't even matter which framework you use. Orbiter itself does the external stuff for you, how you do the internal stuff is your problem.

Having some standard key-bindings would be nice, but you couldn't solve all interaction with the keyboard. Better support of input devices would be nice, but Fly-By-Wire is already pretty far in the development.

I think sound should be a standard client feature, OrbiterSound is already pretty good at it, but it would be nicer if you could switch different sound plug-ins on personal preference. But I know of only one other sound engine, that was ever developed.