Question Multi-Joystick

[Robb Bates]

I'll start some work on it during lunch. Moach, can I get a copy of the config file? I'm assuming you'll still want to use the config file as is, just have a GUI to modify it, right?

Robb

 

[Moach]

i'm still working on how it should look like....

but i think i might have it down in a bit... hang on, i'll post the whole thing

 

[Robb Bates]

OK, got a working dialog box ready for the setup utility... not exactly hard... just cleaned up the DialogTemplate sample.

Moach, any ETA on posting the files? No rush if they're not ready. Just curious.

Robb

 

[Moach]

i think i have a good format for the config file...

its pretty straightforward, but i haven't tested it yet, since i'm at work and i don't think it would look very good for me if i were to pull out my little gamepad, right? :hmm:


it looks kinda like this:

#
# FlightControls Configuration  -- JUST AN EXAMPLE
#
#   device axes:
#   |  1 : x  |  2 : y  |  3 : z  |  4 : rX |  5 : rY  |  6 : rZ  |  7 : a1  |  8 : a2  |
#

OPEN_CTRLR 0

axis pitch 3
axis yaw 1
axis roll 6
axis main 2

button main+ 4
button main- 6
button rcsmode 2
button killrot 1

a # or ; sign marks a line as comment... it should be case-insensitive and discosider leading and trailing whitespaces from each line....

it doesn't like end-line comments, as it will always read the entire line, unless the first character is one of the two above


but the basic syntax is simple, you have a main key, to determine whether to use the button or axis-mapping function, then a feature identifier, which determines what game command is being set, then the last number is the id of the physical axis or button being mapped...

i might add a few optional trailing numbers to set sensitivity, deadzone and calibration for axes, and repeat-rate and hold/tap modes for buttons

mappings always apply to the last device that was opened, so you can map all your devices this way


hold on, i'll post a features list in a bit...


what do you think?

 

[Robb Bates]

How about swapping the function and number. It'll read a little nicer.

button 1 main+
button 2 retro
button 3 rcsmode

Another feature, which could be added later, would be configuration profiles.

Profile Docking

button 1 transx+
button 2 transx-

Profile Descent

button 1 prograde
button 2 retrograde


Format can be determined later. Let's get the main functionality working first.

What do you think about using XML? Just exploring options here. I think there's some XML reading/writing functions built into VC++.

<Controllers>
<Controllername = "OPEN_CNRLR">
<axis 1 = "Pitch">
<axis 2 = "Roll">
<axis 3 = "Yaw">
<axis 4 = "Main">
</Controller>

<Profile>
<Profilename = "Docking">
<button 1 = "transx+">
<button 2 = "transx-">
<button 8 = "Profile Descent">
</Profile>

<Profile>
<Profilename = "Descent">
<button 1 ="prograde">
<button 2 = "retrograde">
<button 8 = "Profile Docking">
</Profile>

Just might make it easier to read/write using the built in functions rather than having to re-invent the wheel, but it'll still be user-readable.

Edit : The indenting of the XML doesn't show up in the forum posting.

Robb

---------- Post added at 03:05 PM ---------- Previous post was at 02:39 PM ----------

From digging through the SDK docs, here's some of the things we should be able to incorporate rather easily. Of course, add all the functionality that already exists via keyboard key presses. Also, add onto this any of the XR API functions.

Remember vessel
Switch to vessel
Set Engine level
Toggle/Set RCS mode
Toggle/Set Int/Ext Camera mode
Zoom in/out/set camera
Move in/out/set camera distance
Rot left/right/up/down/set camera angle
Time +/-/1/set acceleration
Pause on/off/toggle
Execute a script
HUD on/off/toggle
HUD cycle/set mode
HUD color
HUD +/-intensity
MFD buttons (including power, menu, sel)
MFD on/off/toggle
MFD mode
2D Panel switch/set
Scenario save

Some of these will require a parameter. That shouldn't be too hard.


Robb

 

[Moach]

i guess i could have gone with XML... but it already works the way it is... no point in going back at this point...
but i do like your idea of switching the control and input ids, it does read nicer :thumbup:


profiles would be cool too!, but i guess i'll save that for the next version... gotta get this one working first

 

[Moach]

Ok, i've packed up the project... here it is! :thumbup:


not sure if my code is too easy to understand, but i did leave a bunch of comment lines in...

last time i checked, it compiled just right... but i didn't get to check if the axes work or not... the mappings seem ok, tho... (i hope)



well, reading throuugh it you may get a good idea of how it goes from cfg through directinput and into orbiter... i tried to have it as straightforward as i could while still being flexible

cheerz!

 

[n122vu]

VEEEERRRY Cool, Moach. Glad you are working on this. :headbang:

...This would work for RCS but mainly allow us to configure a throttle for XR scram engines.

The thought of this has me salivating already. This is the one thing I have been longing for when using FlyByWire with my X52. I was flying an ascent in the XR2 last night and wishing I could map the scram engine control to the slider on the throttle quadrant, which currently controls my hover engines.

Looking VERY forward to the release of this one.

 

[Moach]

update...


hmm, not sure about mapping the XR scrams... that would something to discuss with Doug about... i mean, i can offer you the axes, but if the ship doesn't read them, it doesn't make much difference...

it would be very cool... and assuming they could be mapped to the "user" thrustergroup, mapping an axis to that should be very straightforward...


and speaking of mapping axes - WE'RE ON!

the module has just stopped CTD'ing and now supports mapping of all 8 directinput axes on ANY of up to 16 devices as set by the CFG - it works! :thumbup:

unfortunately, it was conflicting with the default Orbiter joystick support, so that's gotta be disabled for proper use... which leaves me a bit stumped on mapping the view hat (its working, actually, just not "well" )


but yes, now i can fly using my rudder pedals - which is so very awesome...
i'll post the new version as soon as i get the POV hat issues sorted out


cheerz!

 

[Robb Bates]

I believe the scram engines are accessible via the XR API. But the 2010 version doesn't seem to include the SDK stuff. So, it may be broke in the 2010 or maybe Doug just hasn't gotten around to releasing it yet. But it shouldn't be too hard to include that feature. I'll play with that if I get a chance.

Robb

 

[Moach]

if that's in the SDK then we should be good!

i was thinking perhaps (once i get my C++ skills a bit sharper) i'd release my own Multi-Joystick SDK, so developers could tap into more advanced input options through it ... but for now, that's just a little brain fart... i'm not C++ savvy enough to pull out SDKs just yet


perhaps in a couple of months... my Visual C++ for Windows course begins in a few weeks :jiggy: can't wait!

 

[yagni01]

hmm, not sure about mapping the XR scrams... that would something to discuss with Doug about... i mean, i can offer you the axes, but if the ship doesn't read them, it doesn't make much difference...

it would be very cool... and assuming they could be mapped to the "user" thrustergroup, mapping an axis to that should be very straightforward...

Have you tried it to see if they're mapped to the default user thruster group? If not, you could try GetUserThrusterGroupCount, feed that into GetUserThrusterGroupHandleByIndex to give you the THGROUP_HANDLEs to set. Even the ability to simply set up additional axes by user thgroup index would be very flexible. Later on, someone could add more specific configs by vessel type.

I think there are a lot of us looking to use a TQ for those SCRAMs.

 

[Moach]

well, here's a updated version, sources included:thumbup:

this one now supports freely mappable axes via the CFG file... no buttons yet, but the POV hat is working, tho


and i haven't got around to the user thgroups and scramjets yet... have a look at the sources if you want



this zip now includes a ready-to-go module... just install it the regular way and woohoo
sources are in the orbitersdk/samples/FLTC folder:tiphat:

 

[Zilesio]

Hi there! I very happily red all you guys posted and I really wish I had any programming skills and knowledge... but I don't

so, please forgive me if you judge my question superficial, I just had enough sleepless nights torturing myself with this problem:

is it (or will it ever be) possible to use a joystick to also enjoy other minor things like GEAR, AIRBRAKE, WHEELS BRAKES... or even RETRO DOORS?

these would most likely just be buttons even on the joystick... but how do I "bind" , for example, the keyboard's "G" (for gear) to button number "whatever" on my rig?

Is this already possible in either Moach's "creature" or Joyride/FBW/or even orbiter's standard interface (and it's just me not knowing) or could it be a good hint on what direction to head for a possible next step?

I cant belive people are happy with having to look at the keyboard for finding "g", "ctrl" and "b", and then "," & "." while already being quite busy keeping damn flying school-bus Atlantis from smashing to the ground!

 

[Moach]

if you just wanna bind keys directly to joystick, you can use a generic program such as joy2key, it's simple, easy and free :thumbup:

orbiter has very shallow built-in support for joysticks... i use the saitek profiler to map my keys... most other joysticks, however, don't have such fancy things, so i recommend you get joy2key for that


my FlightControls module still doesn't support button-to-key mappings... instead, it controls Orbiter directly through the API in most cases...
but it does have functions for "injecting" key inputs - which i had to do so the POV hat would work properly... i guess it's easy enough to add a special mapping feature to have a button trigger a specific keyboard command :hmm:

this could also serve as an alternative to map buttons to axes...


that's a clever idea, actually - thanks!

 

[Zilesio]

thanks for your thanks, Moach!

I'm glad my low-end question might have triggered new ideas to improve your work :thumbup:

by the way, just tried joy2key and... yep! it can solve my problems thanks a million for the hint!

One last thing I could suggest is to possibly save one very good thing of FBW: option of sharing same axis for both main and retro boost.

 

[Moach]

ah, ok! i'll add an option to share for a combined main-retro axis -- noted :thumbup:

 

[Robb Bates]

I myself want to add button to function/key mapping because I'm using an MJoy16 on my SimPit. If I could ever find some free time, I plan on adding those features. Moach and I have been discussing that a small amount.

Harass me occasionally and I will be more inclined to add those features.

Robb

 

[Moach]

well, the key-injection code is there... but we need the key enums to be mapped so they can be set by the CFG... and then add code to the step function to actually fire those :hmm:

 

[Rex]

i have two joysticks and wold love it if there was a mod so a person could use both, one for rotation pitch roll and yaw and the other for linear foward back side to side