Multiple Joysticks OR Joy API extensions request

Havner

New member
Joined
Jan 18, 2011
Messages
23
Reaction score
0
Points
0
Hi, not sure where to go with it, because this isn't only about Orbiter SDK as one might think. I have a feature request.

I would really like to request a feature to be able to use multiple joysticks. Nowadays people use several controls, and they aren't always on the same USB device (even if it's virtual). So in general to be able to define where every function of Orbiter (Pitch, Roll, Yaw, Thrust) is defined. What device and what axis. Additionally defining hover and retro thrust would be nice.

Now before you go and tell me there is such a plugin (Fly By Wire) or that one can implement one himself (I did, it only solves the problem partially),
I know that and I've ended up doing my own custom plugin. And it still isn't possible to do this fully. Let me explain.

Look at the rudder axis. Something that orbiter by default assigns to Z Rot axis (not configurable) of your joystick (if it has one). What this axis is doing? 4 different things depending on various other things.

1. Rudder control surfaces -> depends on the state of the Airfoil control switch and/or your ship internals.
2. Rotational RCS (Yaw) -> depending on RCS switch and/or your ship internals.
3. Linear RCS (left-right) -> depending on RCS switch and/or your ship internals
4. Nosewheel steering -> depending on ship internals

I would just like to re-assign rudder control to another device. With current OrbiterSDK I have to implement it to mimick the above. And it's not 100% possible. It isn't always possible to get ship internal state (except for RCS in simple ships, there is an API, but in DGIV it's not that simple anymore). And I don't see a way to get a state of Airfoil Control switch at all using the SDK.
Additionally it isn't possible at all to programmatically set the nose-wheel value.

So my request would be to either add support for multiple configurable joysticks/axis so I can choose myself what controls what.
OR add some high-level OrbiterSDK functions like: setYaw, setRoll, setRudder that would do exactly the same what internal joystick functions do now so I could fully implement joystick plugin that would be 100% functional.

Thanks.
 

kamaz

Unicorn hunter
Addon Developer
Joined
Mar 31, 2012
Messages
2,298
Reaction score
4
Points
0
[/COLOR]
1. Rudder control surfaces -> depends on the state of the Airfoil control switch and/or your ship internals.
2. Rotational RCS (Yaw) -> depending on RCS switch and/or your ship internals.
3. Linear RCS (left-right) -> depending on RCS switch and/or your ship internals

You lost me here. At SDK level, RCS groups are controlled independently of switch settings. Do you want your joystick control to be affected by the RCS switch or not?

(And BTW, the RCS switch is evil: it's a confusing, unnecessary hack.)
 
Last edited by a moderator:

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
What about refining your proposal (e.g. give function signatures) and posting it in the beta threads? Maybe Martin can still do something about it before the beta becomes official.
 

Havner

New member
Joined
Jan 18, 2011
Messages
23
Reaction score
0
Points
0
You lost me here. At SDK level, RCS groups are controlled independently of switch settings. Do you want your joystick control to be affected by the RCS switch or not?
That's exactly the problem. I can control them from SDK independently. I can control them together (except nosewheel). I don't always know if I _should_ control them because I don't know the state of the switches. So yes, I'd like the joystick to be affected by the state of RCS (where I mostly can get its state) and other switches (where I can't). The same way the default joystick implementation is.

(And BTW, the RCS switch is evil: it's a confusing, unnecessary hack.)
Agree :-(

What about refining your proposal (e.g. give function signatures) and posting it in the beta threads? Maybe Martin can still do something about it before the beta becomes official.
That's a good idea. I just don't know whether he'll even read my post. As I don't know if he'll read this one. And still, maybe actually a faster and better idea is to just add extended joystick configuration. Hence this post.
 
Last edited:

Havner

New member
Joined
Jan 18, 2011
Messages
23
Reaction score
0
Points
0
What about VESSEL::GetAttitudeMode and VESSEL::GetADCtrlMode ?
The first one I know about, the RCS switch, I mentioned it above. The other one I didn't. I'll test it, whether it works with DG and DGIV properly. Thanks.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
That's a good idea. I just don't know whether he'll even read my post. As I don't know if he'll read this one. And still, maybe actually a faster and better idea is to just add extended joystick configuration.

I think you have a better chance of him reading it if you post it in the beta thread.
 

Havner

New member
Joined
Jan 18, 2011
Messages
23
Reaction score
0
Points
0
I think you have a better chance of him reading it if you post it in the beta thread.
Ok, thanks for info. Will extensively test the new function mentioned above with different ships and decide what to do about that.

Thanks guys for help.

---------- Post added at 05:23 PM ---------- Previous post was at 02:42 PM ----------

Ok, this VESSEL::GetADCtrlMode() seems to work very nicely. With both deltagliders. Seems DGIV uses this to implement its control switch (probably the only way, I just couldn't find this function myself).

It seems that with I'll be able to implement almost everything.

The last problem is nosewheel steering. Default rudder from the joystick implementation also seems to control the nosewheel of deltaglider independently from control surfaces. And I cannot replicate that with SDK.
Surprisingly, the DGIV uses rudder control surface for nosewheel steering, they are connected. So SetControlSurfaceLevel(AIRCTRL_RUDDER, ...) also steers the wheel. And the rudder bit is being set by the DGIV code whenever the craft is on the ground. So with DGIV I can do everything. With DG almost.
 

Ripley

Tutorial translator
Donator
Joined
Sep 12, 2010
Messages
3,133
Reaction score
407
Points
123
Location
Rome
Website
www.tuttovola.org
...I just don't know whether he'll even read my post. As I don't know if he'll read this one. And still, maybe actually a faster and better idea is to just add extended joystick configuration. Hence this post.
Why do you think so? Martin is a nice guy, he's very often on the forums, he listens to new ideas and he EVEN replies!!!
Please post a new issue/feature at the correct subforum, so Martin can keep track of it, and maybe one day the whole community will benefit from your ideas.
 

kamaz

Unicorn hunter
Addon Developer
Joined
Mar 31, 2012
Messages
2,298
Reaction score
4
Points
0
The last problem is nosewheel steering. Default rudder from the joystick implementation also seems to control the nosewheel of deltaglider independently from control surfaces. And I cannot replicate that with SDK.

You realize that the source code of deltaglider is in SDK samples?
 

Havner

New member
Joined
Jan 18, 2011
Messages
23
Reaction score
0
Points
0
You realize that the source code of deltaglider is in SDK samples?

I do. I actually tried to find the Airfoil switch implementation before starting this thread, but failed miserably. My OrbiterSDK knowledge is still too low. And I assumed that some things are just defined by the ship's code, but it's up to Orbiter itself to control them. And it seems it is at least partially true.

About the nosewheel steering, the docs state that:
"With nose-wheel steering active, the yaw controls will apply a lateral force on the front touchdownpoint when in ground contact."
And that's exactly what happens with DGIV.

But not with DG.
vessel->SetControlSurfaceLevel(AIRCTRL_RUDDER, val);
doesn't work, while the default rudder axis implementation (ZRot on the selected joystick) does. Strange.

EDIT: To some moderator: maybe with the direction this thread is going it would be good to move it to OrbiterSDK section?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
EDIT: To some moderator: maybe with the direction this thread is going it would be good to move it to OrbiterSDK section?

Report your own post with a request to do so. I think you will get their attention easier this way than with a casual in-post remark.
 

micro_g

Donator
Donator
Joined
Oct 29, 2013
Messages
8
Reaction score
0
Points
0
Location
UK
Multiple Joystick support

Hi All-

I actually have developed a plug-in for supporting multiple joysticks, with the ability to switch the mapping on the fly according to what you are doing (orbital maneuvers vs atmospheric flight). I use it all the time for my own amusement.

It was almost done, with manual and all and had announced it 2yrs ago to start running some beta testing and collect feedback on features, but then I run out of time (even to play :(( ) and resumed working on it just two weeks ago.

If anyone is interested drop me a line, I'll try and post it somehow. In the mean time you can take a look at the draft manual, I have attached.

There are some limitations I run into with Orbiter and some of the vessels that could be resolved with API changes but I think what I got to is quite useful anyway.
 

Havner

New member
Joined
Jan 18, 2011
Messages
23
Reaction score
0
Points
0
Report your own post with a request to do so. I think you will get their attention easier this way than with a casual in-post remark.
Done, thanks.

If anyone's interested this is what I came up with. It works very well for me (except this damned nosewheel). Not a plug-n-play (configuration is in the code), but maybe someone will find it useful:

https://github.com/Havner/orbiter-joy-ext
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
I actually have developed a plug-in for supporting multiple joysticks, with the ability to switch the mapping on the fly according to what you are doing (orbital maneuvers vs atmospheric flight). I use it all the time for my own amusement.

Judging by the manual, that looks quite sophisticated for your "own amusement". :thumbup:
 

micro_g

Donator
Donator
Joined
Oct 29, 2013
Messages
8
Reaction score
0
Points
0
Location
UK
I'll try and put something together during the week-end ...
 

micro_g

Donator
Donator
Joined
Oct 29, 2013
Messages
8
Reaction score
0
Points
0
Location
UK
Hi All-

I have uploaded the latest version of HOTAS on a Google Drive. Whoever is interested in giving it a go and provide feedback can drop me a line and I will send them a link.
The main reason why I am not uploading it to hangar mod is that I want to make sure it is in reasonable shape before opening it up to everyone.

Whilst the plug-in “works on my machine” (A Windows 7 SP1 with various version of Visual studio) I have not really invested a lot of time sorting out the installation and dependencies, I have only tried it out on a Windows 8 machine (set up for Java development, so no MS tools) that turned out not to really need the installation of the VS 2010 redistributables.

The known installations issues are:
  • - The link provided in the user manual for the VS2010 redistributables is broken (and the x64 version seems to have become unavailable)
  • - The windows 8 box, in spite of using a 64bit OS only worked using the x86 version of SDL, go figure!
I really would like to get the installation sorted; no one likes to mess around too much before starting to play.

On the main topic of the original post:
---------------------------------------------
The main issue that everyone is facing (and the plug in I wrote is running into the same problem) is that plug-ins have only access to the VESSEL interface which is interface to the simulation model and not the real ship being control which uses the simulation model. Any UI extension for joystick o keyboard support should talk to the ship built on top of VESSEL, in C++ language it should talk to the class derived from VESSEL.

In some case there is a close enough match and things work out, but this is not always the case.
A good example are the RCS and ADC control modes. The VESSEL interface allows to turn on control of each individual type of aero surface and set the RCS to either Lin, Rot or off in any combination (there are 21 in total) while individual ships only allow certain combinations.

Further to this some ships, like the DG-IV do not seem handle the notification events when the AttitudeMode is changed through the API (because they do not need to unless someone messes with it  ) so one is limited to send keystrokes and is limited to the available shortcuts.

A better option is the one provided by the XR fleet where there is an API that can be obtained from the VESSEL * by static_cast. I have not tried to use this approach yet, but it is what I am going to do next. (This is why a vessel_controller in a .hotas file uses an inheritance like notation to a StandardController, this is meant to allow the use of XRVessleController and target the XR API directly)
The XR fleet approach, which solves the problem, has some issues as well: it is specific to the XR fleet and if another vessel was to provide another API this would require a new version of the plug-in. Not scalabe.

The only alternative solutions I can think of is to either define a universal interface that accommodates every possible vessel HMI need which is a bit unlikely or to define a more generic interface based on some form of meta-data that can be loaded and processed at run time.
Such generic interface would necessarily require the collaboration of vessel developers (as they would need to implement it) but would make HMI-oriented plug-ins like HOTAS more powerful and make lots of sim-pit builders really happy as they could replicate any button or dial.

-----
As a closing note, I have been playing with Orbiter since almost its beginnings, but always kept to myself, so for me this plug-in is a way to give something back to the community and say thank you to all the contributors and Dr. Martin Schweiger (obviously) .
 

Havner

New member
Joined
Jan 18, 2011
Messages
23
Reaction score
0
Points
0
On the main topic of the original post:
---------------------------------------------
The main issue that everyone is facing (and the plug in I wrote is running into the same problem) is that plug-ins have only access to the VESSEL interface which is interface to the simulation model and not the real ship being control which uses the simulation model. Any UI extension for joystick o keyboard support should talk to the ship built on top of VESSEL, in C++ language it should talk to the class derived from VESSEL.

In some case there is a close enough match and things work out, but this is not always the case.
A good example are the RCS and ADC control modes. The VESSEL interface allows to turn on control of each individual type of aero surface and set the RCS to either Lin, Rot or off in any combination (there are 21 in total) while individual ships only allow certain combinations.

Well, my original issue was to only get the state of the ship, not to set it (speaking of RCS/ADC). Having said that I know there is no way to set it reliably through the VESSEL interface that would be compatible with all the ships, but there is a way to reliably get it and make the replacement joystick implementation behave like the internal one. And for this the VESSEL interface seems enough.

Setting the different things on various ships (if they don't provide API, shortcuts or whatever) is a different issue. I agree that this is impossible to do right now, but this was outside of my scope.

If you missed that I've managed to do just that. A simple plugin that does what Orbiter's implementation does, but is configurable (in the code for now):

http://www.orbiter-forum.com/showthread.php?p=525149&postcount=15
 
Last edited:
Top