Gamepad elements are from now on automatically added from the CSS file.

[medape]

I'm sorry for merging from the master branch this time. I've got to learn how to use well the git command.

I've made some more changes to the web interface:

New control type: gas pedal. You press the pedal with the finger, and you can slide it higher to increase your pressure, or lower to decrease it. (Internally, it works like a joystick with no X-asis, but it goes from 0 to 1 and rests at 0.)

• There is also commented code to react to the real finger pressure. I was about to make it the default, but not every touchscreen supports this; the ones which do are very differently calibrated from device to device. Also, "zero-pressure" touch events (like hovering a stylus over a screen) and touch events without pressure information (like the ones in a simple, cheap touchscreen) are both reported the same way; I'm not sure if this is something to worry about.

Controls are now changed in the CSS file, no JS editing needed. The script now reads the grid-areas in the CSS file, guesses the intended controls from the first letter of the abbreviation (j for joystick, b for button, etc.), and attaches them to the joypad in these order: joysticks, motion sensors, pedals, buttons. Both CSS files are bundled with basic instructions.

• A motion sensor are only added when included in the grid-areas, but it's not polished yet, or guaranteed to work, and it still needs to be configured by changing the script itself.

For the moment, to prevent errors in the Python code for the moment, the web interface expects exactly four analog axes to be registered in the CSS file (counting joysticks, pedals, and motion sensors). If there are more (or less) than 4, it warns you, but doesn't stop you.

• If there are less than 32 buttons, instead of warning you, it adds dummy controllers which always report 0 as their state. These dummies don't cover any area or create more event listeners.

[pzmarzly]

Seems okay to me, thanks for taking over the development of this part of Yoke.

There are some styling inconsistencies (e.g. lack of semicolons), I'll merge your PR and then fix it on master here. Update your fork or delete it and recreate it.

If you accidentally commit on master, you can move commits by:

git checkout -b some-branch # creates some-branch branch
git checkout master # switches back to master
git reset --hard origin/master # restores old master state

[pzmarzly]

I didn't notice you made unnecessary commit (Merge pull request #2 from rmst/master). In the future, you can get rid of them by updating the fork using the method I described above.

[medape]

Thank you very much for your help with everything, I really needed those two tips.

I didn't notice you had replied to this PR. I had fixed the motion sensor problem and made some other changes, but my code is even more inconsistent, so for the moment I'm going to follow your example: recreate the fork, learn a bit more about Git, and fix those styling issues.

I'll make a new PR tomorrow or in a couple of days. In the meanwhile, I want to ask your opinion on something:

    /* The map below must match the number of rows and columns specified above: */
        ".   .   .   .   .   .   .   mag mag .   .   .   .   .   .   .   "
        ".   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   "
        ".   p1  p1  p1  .   b1  .   .   .   .   b2  .   p2  p2  p2  .   "
        ".   p1  p1  p1  .   b1  .   .   .   .   b2  .   p2  p2  p2  .   "
        ".   p1  p1  p1  .   .   .   .   .   .   .   .   p2  p2  p2  .   "
        ".   p1  p1  p1  .   b3  .   .   .   .   b4  .   p2  p2  p2  .   "
        ".   p1  p1  p1  .   b3  .   .   .   .   b4  .   p2  p2  p2  .   "
        ".   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   "
        ".   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   "
        ;
        /* Possible values:
         * j1, j2, j3... for joystick;
         * m_ for motion detector, where _ is one or more of these letters:
              * x for acceleration in the X-axis (left to right)
              * y for acceleration in the Y-axis (bottom to top)
              * z for acceleration in the Z-axis (back to front)
              * a for α (alpha) angle -- rotation around the Z-axis
              * b for β (beta) angle -- rotation around the X-axis
              * g for γ (gamma) angle -- rotation around the Y-axis
         * p1, p2... for pedals;
         * b1 to b32 for buttons;
         * dbg for debug messages;
         * a period for empty space. */

This is an excerpt from the latest CSS for racing. (I don't have much practice with racing simulators).

• Is the layout acceptable?
• Is the motion detection configuration easy to understand and use?
• If so, I'm thinking about using s as a mnemonic for a locking joystick, instead of j. That way, it would be easier to change, we could delete the easy-to-missanimation-name: locking code and all the code below the grid-areas would actually be only for styling. Do you think this is a good idea or would you do some improvement?

(Edited for clarity.)

[pzmarzly]

I'm all for getting rid of animation-name: locking, it was an ugly hack.

Motion detection config seems okay, it's going to be trial and error anyway. Though if nothing is displayed, I'd prefer not to have letter combinations (mxyzabg), as so far every field was 3 character-long or shorter. I don't think anyone will make such a crowded layout that they won't be able to fit 6 invisible tiles anywhere.

[medape]

For the moment, it displays a pale gray, lighter than the default button colour. Just to have some indication that there is motion detection.

But I agree on the letter combinations. Several tiles are more convenient to type.