ID:2097597
 
I've decided to hold off on the next 510 release for a little longer yet, mainly because I haven't gotten to the webclient side of that yet as planned. Several bug fixes however are already in the can; they'll be closed in the bug tracker soon.

This week has been a real struggle to get the gamepad stuff playing nicely, but I finally figured out the easiest system for gamepad controls and customization: The macro system. It was a bit of a slog to get right, but my decision paid off (any other system would have been more work), and now things are going pretty well. While I have to make some UI adjustments, most of the macro mapping is working now. Some of it still needs testing, but so far so good. Here's an overview of how this will work:

First, the macro skin element has been updated to include a new parameter: map-to. For control_freak cases, local macros will only be added to the list if they're a map-to from a gamepad macro; otherwise they'll be ignored. The map-to value is another key/gamepad/mouse name, like for instance "A" or "F1"; I'm planning to allow mapping to two keys at once for some cases, like for instance when you want a diagonal to act as though two different arrow keys are held down. A typical case might look like this:

macro "macro"
elem
name = "GamepadFace1"
map-to = "Center"

The gamepad buttons supported are as follows; they are not valid as mapping targets, but can map to keys or mouse buttons, and can also be verbified:

GamepadFace1    // Bottom of diamond; A (Xbox), X (PS)
GamepadFace2 // Right of diamond; B (Xbox), Circle (PS)
GamepadFace3 // Left of diamond; X (Xbox), Square (PS)
GamepadFace4 // Top of diamond; Y (Xbox), Triangle (PS)
GamepadL1 // Top left shoulder
GamepadR1 // Top right shoulder
GamepadL2 // Left bottom shoulder/trigger
GamepadR2 // Right bottom shoulder/trigger
GamepadSelect // Select / Back
GamepadStart // Start / Forward
GamepadL3 // Left analog click
GamepadR3 // Right analog click

Two buttons can be combined, e.g. GamepadL3+GamepadR3, to map to a key or verb. When using these for regular verbs, the standard behavior with +REP and +UP applies. In a verb, use [[*]] to substitute the button/combo's current value.

There are also directional "buttons".

GamepadUp
GamepadDown
GamepadLeft
GamepadRight
GamepadUpLeft
GamepadUpRight
GamepadDownLeft
GamepadDownRight

The first four correspond to actual buttons on many controllers. The combos are basically built-in ways of handling two of the cardinal directions together, and it's more or less a cheat so that you can also combine it with a gamepad button, e.g. GamepadUpLeft+GamepadFace1.

Then we have the analog sticks:

GamepadLeftAnalog
GamepadRightAnalog

They can be mapped to a dpad or a mouse, or they can be used in verbs. Verbs will fire regardless of +REP or +UP, and [[x]] and [[y]] will substitute the X and Y axes; [[*]] will substitute x,y. The Y axis is inverted from gamepad norms so that up is positive, fitting with BYOND's coordinate system. (Developers, take note now: It's up to you to check that the x,y values have a total distance no more than 1 plus a fudge factor. The macro will never lie to you, but players will, and you don't want them sending commands for super speed.)

GamepadDpad
GamepadDpad4

These special values can be used for verbs, or can be used as mapping targets. (I didn't have the heart to allow Dpad-to-mouse mapping, because there'd be no fine control.) For instance, GamepadLeftAnalog can map to GamepadDpad for full 8-dir movement, or it can map to GamepadDpad4 to only use the nearest cardinal direction. It does so by "pressing" one the buttons like GamepadUp, or GamepadUpLeft, etc. When you use one of the Dpad values as a verb macro, [[*]] will substitute the direction as a number, and 0 for no direction; +UP is meaningless there but +REP is allowed.

Mouse
MouseLeftButton
MouseRightButton
MouseMiddleButton

The mouse values exist solely as mapping targets. So for instance, you could map GamepadFace3 to MouseLeftButton, GamepadFace4 to MouseMiddleButton, GamepadFace2 to MouseRightButton, and GamepadRightAnalog to Mouse. (Fair warning: mouse movement looks really crappy at low FPS, because the gamepad is only checked on every client tick. But for an action game with a higher framerate, that won't be an issue.) I haven't worked out yet how I want to specify mouse speed, so for the moment it's hard-coded.

With all that in mind, this is what you'd be looking at for the default gamepad setup:

macro "macro"
elem
name = "GamepadUp"
map-to = "North"
...
elem
name = "GamepadDownRight"
map-to = "Southeast"
elem
name = "GamepadFace1"
map-to = "Center"
elem
name = "GamepadLeftAnalog"
map-to = "GamepadDpad"

I'm still working out the details of how and when to apply those defaults; the system I'm using now is acceptable but not great.

BTW, there's also a new joystick.txt file in the cfg dir that will handle mapping, so you can tell your system that the joystick you use has its buttons in a different order. Like for instance, the gamepad I'm testing with has all its face buttons in a weird order. Eventually I'll have a UI for that.

So some pretty exciting things are in the future for 511, and I'll soon be able to move on to other items on the list. This week I added variadic macros to the to-do list, because it looks like that'll be feasible to add without a lot of trouble.

I'm working hard for a better BYOND, so if you appreciate where this is going, don't forget to hit up the donation box. And now that summer is here, albeit unofficially, enjoy the sunshine and warmth while you can--except you guys in the southern hemisphere, to whom I say: keep warm and dream of salt potatoes (look it up), and use your shut-in time to make an awesome game.
Great job, Lummox. Can't wait to try this stuff out, but more importantly, I can't wait to see how other developers will manage their button layouts!
Thanks for your good work
This and client framerate are my most anticipated features
OOOH Can't wait to try this out!!
This is great news!

I'm curious about this map-to parameter. Is it going to work with or replace the command parameter? How exactly are they related, and will map-to also apply to keyboard macros?

Also, what is this mysterious double bracket syntax: [[*]], and how do you actually use it? It looks like some kind of escaped embedded expression.

While unrelated, variadic macro support will be something really special, and I'm looking forward to using this. It will let us automate more things, with greater efficiency, which can be more important than you might think.
In response to Ishuri
I'm looking forward to how you folks over at LoF will take advantage of gamepad support.
In response to GreatPirateEra
GreatPirateEra wrote:
I'm looking forward to how you folks over at LoF will take advantage of gamepad support.

It's gonna be AWESOME!
In response to Multiverse7
Multiverse7 wrote:
I'm curious about this map-to parameter. Is it going to work with or replace the command parameter? How exactly are they related, and will map-to also apply to keyboard macros?

It's separate, so you can have both.

At this time I have no plans for keyboard macros to do mapping to anything else.

Also, what is this mysterious double bracket syntax: [[*]], and how do you actually use it? It looks like some kind of escaped embedded expression.

That's already used in some skin event commands like on-size, so this choice was for consistency.

While unrelated, variadic macro support will be something really special, and I'm looking forward to using this. It will let us automate more things, with greater efficiency, which can be more important than you might think.

Glad to hear it. It looks easy to add, which is why I added it to the list.
In response to Lummox JR
Lummox JR wrote:
Multiverse7 wrote:
Also, what is this mysterious double bracket syntax: [[*]], and how do you actually use it? It looks like some kind of escaped embedded expression.

That's already used in some skin event commands like on-size, so this choice was for consistency.

is this even documented lums
Super Saiyan X wrote:
Lummox JR wrote:
That's already used in some skin event commands like on-size, so this choice was for consistency.

is this even documented lums

...Are you seriously right now?



...Srsly?
All this gamepad talk is making me so hot right now. Any update on when the public will be able to test drive the gamepad support Lummox?
In response to Ter13
Ter13 wrote:
Super Saiyan X wrote:
Lummox JR wrote:
That's already used in some skin event commands like on-size, so this choice was for consistency.

is this even documented lums

...Are you seriously right now?



...Srsly?

http://www.byond.com/forum/?post=1699922

this should really be in the documentation lol
mfw BYOND can achieve 3D, it's just not documented.
In response to Flame Guardian
Flame Guardian wrote:
All this gamepad talk is making me so hot right now. Any update on when the public will be able to test drive the gamepad support Lummox?

It'll be the first 511 release. But no word yet on when that will be. I have lots of other features to push in before we get there, but I really want it out as soon as possible (for many reasons).

Push those features in, Lummox. Make 'em fit.
In response to Nadrew
;)