Board index FlightGear Support Hardware

Just a comment

Joysticks, pedals, monitors.

Just a comment

Postby macnab » Wed Jul 03, 2013 3:31 pm

Has anyone noticed how few questions there are these days about joystick programming? I wonder how much it has to do with Stuart's in-sim joystick programming utility.
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby sim » Sat Jul 06, 2013 9:15 pm

Suspect quite a lot to do with it Macnab! Sure makes it easier for newcomers to get their
joystick functioning though.
It'll have to get a whole lot better before I throw away the codes built into my joystick xml
especially those recent additions from yourself and philosopher. "Slewprop" for example
was a quantum leap!
Shame if it means there is less incentive to program each button and axis to meet one's own
joystick preferences. Mind bogling how many things one button will do using easy to learn
xml script. Streets ahead of X-Plane, FSX etc formatting, where one button can only be allocated
one function! :roll:
Stuart's is a welcome simple system akin to X-Plane, FSX etc. Advanced sim flyers will already
have their own joystick set up covering far more controls and functions. :wink:

See how many buttons you'd need to get all the X-Plane controls on your joystick! Shiver me' timbers! :shock:

Image

Image

........and axes!
User avatar
sim
 
Posts: 1442
Joined: Tue Jun 30, 2009 2:13 pm
Location: Shropshire England
Callsign: Fly4Fun
Version: 0.9.10 up
OS: 64 Win 10 HD6450

Re: Just a comment

Postby macnab » Sun Jul 07, 2013 2:19 am

I have the Saitek Yoke, throttle quadrant and pedals. Using the Mode switch on the yoke (3 position) and a button on the yoke as a modifier, including the hat switch I have 102 functions. That is excluding the reverse-thrust positions on the quadrant, which are of limited use due to the fact that you need to move the lever past 0. And without using the keyboard Ctrl, Alt and Shift.

I put all my code in a nas file, the xml file just calls a function named after the switch number, passing the Mode switch position and the modifier state.

Needless to say, I have some button combinations that I don't have a use for yet. :D
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Hooray » Sun Jul 07, 2013 5:18 am

sim wrote in Sat Jul 06, 2013 9:15 pm:It'll have to get a whole lot better before I throw away the codes built into my joystick xml
especially those recent additions from yourself and philosopher. "Slewprop" for example
was a quantum leap!
Shame if it means there is less incentive to program each button and axis to meet one's own
joystick preferences. Mind bogling how many things one button will do using easy to learn
xml script. Streets ahead of X-Plane, FSX etc formatting, where one button can only be allocated
one function! :roll:
Stuart's is a welcome simple system akin to X-Plane, FSX etc. Advanced sim flyers will already
have their own joystick set up covering far more controls and functions. :wink:


Actually, while I can't seem to find the original thread at the moment, we once talked about integrating the various Nasal capabilities added by Macnab and Philosopher right into Stuart's new JS config dialog - back then, Stuart & Zakalawe actually seemed supportive of the idea. And it would indeed not require many configurations to allow bindings to become fully runtime-configurable, including Nasal bindings and a standard library of general-purpose Nasal/JS APIs. UI-wise, we could simply reuse/integrate the existing Nasal console, so that bindings can be dynamically added and edited. At the end of the day, it's all XML, Nasal and the property tree, and some fgcommands to reinit stuff - so if people still think, that'd be useful, please speak-up and share your feature requests / ideas.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Just a comment

Postby macnab » Sun Jul 07, 2013 5:44 am

To me the first step would be to have the UI include at least one "Modifier" button and/or keyboard modifiers. Then the UI can have the option of switching views between modified/not modified. This will give more available actions.

Between us we can come up with the "actions" and code. If we can get "on the fly" switching between repeatable/non-repeatable that would make a great addition/change for Version 3.

Without on-the-fly switching between repeatable/non-repeatable switching to modified view would have to limit the available actions to repeatable/non-repeatable based on the unmodified action.

Being able to edit the generated code would be nice for those who are capable of tweaking it. (Such as a personal preference for slew-rate.) Dynamic re-inits would also be good.

The UI can be worded carefully so that less-experienced users can understand the concept of doubling-up on button actions.
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Hooray » Sun Jul 07, 2013 6:39 am

making the repeatable flag runtime configurable should be pretty straightforward for anybody familiar with the JS code and property tree listeners (SGPropertyChangeListener).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Just a comment

Postby macnab » Sun Jul 07, 2013 6:52 am

It will need FGCommands to do it. Then the specific joystick code can set/clear it according to needs. If no FGCommand is sent it must stay the way it is for compatibility with existing joystick xml files.
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Philosopher » Sun Jul 07, 2013 12:48 pm

I disagree with macnab's last statement (I'm about 50% familiar with the JS code and agree with Hooray: either a listener or just reading it every frame; currently it just looks at a bool member of the class). Anyways, I believe that I can help reprogram Stuart's dialog (I've actually only taken a quick look at it, but it looks nice and especially organized), just give me a few days (to work through a Canvas js mode editor with my new 2.10!! :D :D) and some ideas, and then I can get started. I personally have ideas of my own that could allow near-complete configurability, but I'm not sure if I can accomplish all of that (I just wasted a whole day wrestling with dynamic content in my GUI window and it never quite worked :P -- I'm going to use Canvas now for that).

P.S. Yes, I'm actually on the forums...
P.P.S. Second reply in this topic dates back to a time when Hooray could find our previous discussion ;): viewtopic.php?f=18&t=18530 (sorry, can't link directly to posts with the mobile theme).
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Just a comment

Postby Hooray » Sun Jul 07, 2013 1:02 pm

yes there are obviously several ways to skin this cat - no matter if it's fgcommands or listeners - I just believe listeners to be more "direct", i.e. by simply replicating the whole config file through the property tree and just waiting for events that change things, and automatically reparsing/re-initializing things - that's after all, how the AP, AI system or the canvas work, without necessarily requiring fgcommands. On the other hand, Stuart -as the author of the JS dialog- seems to prefer fgcommands over listeners (see his clouds API). So at the end of the day it all boils down to who gets around to implementing it. It doesn't really matter if it's through listeners or fgcommands (or even something else).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Just a comment

Postby sim » Sun Jul 07, 2013 8:52 pm

I put all my code in a nas file, the xml file just calls a function named after the switch number, passing the Mode switch position and the modifier state.


Although searching FG nasal files has given some useful codes for my joystick xml, unlike you three experts, I'm not well versed in nasal.
@Macnab : What advantages are there to having stick codes in a nas file?

I do look forward to seeing how you guys enhance stuarts stick formatting. :)
Fear you may get head hunted by X-Plane if it improves on their system! :cry:
User avatar
sim
 
Posts: 1442
Joined: Tue Jun 30, 2009 2:13 pm
Location: Shropshire England
Callsign: Fly4Fun
Version: 0.9.10 up
OS: 64 Win 10 HD6450

Re: Just a comment

Postby macnab » Mon Jul 08, 2013 3:47 am

@sim Regarding using a nas file, one of the big advantages is readability, especially when editing/changing. You do the xml file just once, doing each button along these lines:
Code: Select all
  <button n="2">
    <!-- Labled as A1 -->
    <desc>Elevator trim down - View pitch down/Alt Inc - VS Inc/</desc>
    <repeatable>true</repeatable>
    <binding>
      <command>nasal</command>
      <script>saitekyoke.buttonA1(saitekAlter, 1)</script>
    </binding>
    <mod-shift>
      <binding>
        <command>nasal</command>
        <script>saitekyoke.buttonA1(saitekAlter, 2)</script>
      </binding>
    </mod-shift>
    <mod-ctrl>
      <binding>
        <command>nasal</command>
        <script>saitekyoke.buttonA1(saitekAlter, 3)</script>
      </binding>
    </mod-ctrl>
  </button>

  <button n="3">
    <!-- Labled as A2 -->
    <desc>Elevator trim up - View pitch up/Alt Dec - VS Dec/</desc>
    <repeatable>true</repeatable>
    <binding>
      <command>nasal</command>
      <script>saitekyoke.buttonA2(saitekAlter, 1)</script>
    </binding>
    <mod-shift>
      <binding>
        <command>nasal</command>
        <script>saitekyoke.buttonA2(saitekAlter, 2)</script>
      </binding>
    </mod-shift>
    <mod-ctrl>
      <binding>
        <command>nasal</command>
        <script>saitekyoke.buttonA2(saitekAlter, 3)</script>
      </binding>
    </mod-ctrl>
  </button>


saitekAlter is the modifier button.

Then the nas file looks like this:
Code: Select all
var buttonA1 = func(alter, mode) {
      if (mode == 1) {
        if (alter) {
          controls.elevatorTrim(1)
        } else {
          controls.slewProp("/sim/current-view/goal-pitch-offset-deg", 15)
        }
      }
      if (mode == 2) {
          if (alter) {
            setprop("/instrumentation/flightdirector/Asel", getprop("/instrumentation/flightdirector/Asel") + 100)
          } else {
          }
      }
      if (mode == 3) {
        if (alter) {
            var vs = getprop("/autopilot/settings/target-vs-fpm");
            setprop("/autopilot/settings/target-vs-fpm", vs + 1);
            gui.popupTip(sprintf("VS = %d", vs + 1), 2)
        } else {
            var ias = getprop("/autopilot/settings/target-speed-kt");
            setprop("/autopilot/settings/target-speed-kt", ias + 1);
            gui.popupTip(sprintf("IAS = %d", ias + 1), 2)
        }
      }
}

var buttonA2 = func(alter, mode) {
      if (mode == 1) {
        if (alter) {
          controls.elevatorTrim(-1)
        } else {
          controls.slewProp("/sim/current-view/goal-pitch-offset-deg", -15)
        }
      }
      if (mode == 2) {
          if (alter) {
            setprop("/instrumentation/flightdirector/Asel", getprop("/instrumentation/flightdirector/Asel") - 100)
          } else {
          }
      }
      if (mode == 3) {
        if (alter) {
            var vs = getprop("/autopilot/settings/target-vs-fpm");
            setprop("/autopilot/settings/target-vs-fpm", vs - 1);
            gui.popupTip(sprintf("VS = %d", vs + 1), 2)
        } else {
            var ias = getprop("/autopilot/settings/target-speed-kt");
            setprop("/autopilot/settings/target-speed-kt", ias - 1);
            gui.popupTip(sprintf("IAS = %d", ias - 1), 2)
        }
      }
}


So much easier to maintain.
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Hooray » Mon Jul 08, 2013 4:22 am

one of the big advantages is readability, especially when editing/changing.

Note that the upcoming FG releases (beyond 2.12+) will include a new Nasal API for registering invididual Nasal functions as fgcommands, so that you can have very compact joystick bindings by making up new, joystick-specific, fgcommands: http://wiki.flightgear.org/List_of_Nasa ... mand.28.29
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Just a comment

Postby macnab » Mon Jul 08, 2013 4:36 am

a new Nasal API for registering invididual Nasal functions as fgcommands


How is this going to work? Presumably, at FG startup, "your" fgcommands will be registered from a nas file. And then you can call them from your xml file. But isn't this the same as calling functions from a nas file?
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Philosopher » Mon Jul 08, 2013 7:10 am

Yeah, it's basically the same, except obviously more universal (C++ code can use it too). It also looks better (to me) as it just used the <command> tag instead of a function call with all those tags around it (<command>nasal</command><script>call_function()</script>), and it of course requires "arguments" to be in the property tree (they can be retrieved using cmdarg() or the first argument passed to the callback function). For example, I could register a "Cyborg-X-axis" fgcommand and for each axis simply write something like this, which would be very convenient:

Code: Select all
<axis n="0">
    <binding>
        <command>Cyborg-X-axis</command>
        <settings>
            <!-- dead-band, power, etc. -->
            <control>aileron</control>
        </settings>
    </binding>
</axis>


The Nasal function running it behind the scenes would use the node as a virtual Nasal-object (except for methods, which would be held in Nasal space).
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Just a comment

Postby Hooray » Mon Jul 08, 2013 7:41 am

exactly, this is probably going to be what bindings will look like in the future, simply because we can easily maintain a generic standard Nasal library for joystick code, without individual bindings having to be aware of implementation details - so this is pretty much the "frontend", and what things will look like to end-users, or the joystick GUI, while the backend would be based on generic and unified Nasal snippets dealing with Joystick/Yokes, Pedals etc - that would allow us provide a "stable frontend API" through Nasal-based fgcommands, whereas the back-end could evolve as needed - and the front-end would be easily editable through a corresponding GUI dialog. It would then even be possible to merge the Nasal console into everything, so that backend snippets become also customizable at runtime.

Basically, more flexibility, with less coding required for people who do not want to look into scripting - also, no need for cdata or XML escaping
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Next

Return to Hardware

Who is online

Users browsing this forum: F-TLS13, MSN [Bot], Robertfm and 4 guests