Before I make some full fledged feature requests I just want to make sure that I'm understanding how all of this gamepad stuff works so far and that I haven't missed anything:
Is there a command in the same vein as .options or .host (.gamepad?) that I can call to just open the "Gamepad Setup" window directly?
Am I forced to use the "Gamepad Setup" window to actually map buttons on the gamepad so that they're recognized by the Dream Seeker? Right now using the new "Any" key macro I can detect keyboard inputs, but it doesn't register gamepad button presses unless they've been mapped in this menu.
As it stands, Dream Seeker's built in process for setting up a gamepad and mapping controls strikes me as being very confusing for both developers and end-users alike. The difference between the "Gamepad Setup" and "Gamepad Mapping" menus isn't readily apparent; I've never played a game that required me to first map my gamepad buttons to internal pointers for each command, and then open a completely separate menu and map those pointers to the actual key presses that I want. Is there some sort of benefit in having this be this a two-step process that I'm missing?
***********************************
At any rate, what I'd really like to be able to do is to completely avoid using both the "Gamepad Setup" and "Gamepad Mapping" menus and just create my own gamepad mapping system. As far as I can tell, all that I'd need in order to be able to do that is to be able to detect the raw button press outputs from the attached gamepad. Even if I was only able to detect the raw outputs temporarily (via some sort of special winset command), it would allow me to create my very own version of the "Gamepad Setup" menu.
ID:2152554
 Sep 27 2016, 3:14 am
|
|
Silk Games wrote:
Before I make some full fledged feature requests I just want to make sure that I'm understanding how all of this gamepad stuff works so far and that I haven't missed anything: I added undocumented commands .gamepad-setup and .gamepad-mapping for this. I might change the latter to just .mapping or support it as an alias. Am I forced to use the "Gamepad Setup" window to actually map buttons on the gamepad so that they're recognized by the Dream Seeker? Right now using the new "Any" key macro I can detect keyboard inputs, but it doesn't register gamepad button presses unless they've been mapped in this menu. The Any macro ought to still be able to register gamepad buttons that haven't been mapped explicitly, because--if your gamepad isn't recognized as one already mapped--the default mapping should still kick in. I'll have to run some tests with all the mapping disabled to see if I missed something crucial there. As it stands, Dream Seeker's built in process for setting up a gamepad and mapping controls strikes me as being very confusing for both developers and end-users alike. The difference between the "Gamepad Setup" and "Gamepad Mapping" menus isn't readily apparent; I've never played a game that required me to first map my gamepad buttons to internal pointers for each command, and then open a completely separate menu and map those pointers to the actual key presses that I want. Is there some sort of benefit in having this be this a two-step process that I'm missing? The reason these are separate is that Gamepad Setup is for configuring the controller so that it conforms to a standard. In browsers, the gamepad API relies on this sort of thing, converting the gamepad's inputs into a standard layout, except they're just expected to know all these gamepads already. That's what the cfg/joysticks.txt file is for in the main installation directory, to hold a list of common gamepads. The mapping dialog is the user- and author-configurable portion where once the gamepad setup info is known, the inputs from a standardized layout can be mapped to keys and/or the mouse. *********************************** I'd be okay with this. Do you have any specific suggestions on how that sort of thing could be made to work easily? Also if your game allows for its own gamepad setup window, that isn't something I'd really wanted games to be able to set since it's a BYOND-wide user config thing and it could be abused, so I'd want it to be stored on a per-game basis. In the case of the standalone, that info would have to be stored with the standalone installation itself. | |
Thanks to both of you for the replies!
Lummox JR wrote: The Any macro ought to still be able to register gamepad buttons that haven't been mapped explicitly, because--if your gamepad isn't recognized as one already mapped--the default mapping should still kick in. I'll have to run some tests with all the mapping disabled to see if I missed something crucial there. This wasn't my experience last night with the latest compile. The default mapping apparently didn't have the R2 button mapped correctly on my controller (Xbox One controller), and absolutely no key presses registered via the Any macro until I properly mapped R2 in the Gamepad Setup menu. Lummox JR wrote: I'd be okay with this. Do you have any specific suggestions on how that sort of thing could be made to work easily? Really just being able to detect a keypress from the full range of potential gamepad buttons via the Any macro is all that I'd need. For example, last night my R2 button was mapped by default to "Axis 6" when it really needed to be "Axis 2". If I had simply been able to detect any of the potential Axis inputs then I could have mapped the R2 key myself without the Gamepad Setup menu. Lummox JR wrote: Also if your game allows for its own gamepad setup window, that isn't something I'd really wanted games to be able to set since it's a BYOND-wide user config thing and it could be abused, so I'd want it to be stored on a per-game basis. In the case of the standalone, that info would have to be stored with the standalone installation itself. That makes perfect sense. Really, assuming that the DS was just always sending along the raw gamepad input to the Any macro I wouldn't need to have BYOND save any settings for me at all - I could just save that data myself in the user's savefile. That would probably actually be preferable to allow for maximum flexibility on the development side. | |
I don't think Any is the appropriate choice for truly raw gamepad input, but I think I can come up with something. Ideally it seems like there should be a command that outputs all of the currently detected buttons/axes as a parameter list any time something changes.
| |
Awesome, thank you!
| |
as a parameter list =( | |
Please god deadzones.
| |
Seteron14 wrote:
Please god deadzones. Dead zones are built into the regular gamepad code already. The raw output won't have them. | |
Necroing this thread with information about my gamepads to hopefully find some better way of setting them up than using the device name, because it's not unique and the setups across the same name can differ greatly.
 Retrolink Gamecube USB gamepad. Driver name: Generic USB Joystick Button1 - Y Button2 - X Button3 - A Button4 - B Button5 - LTrigger Button6 - RTrigger Button7 - Z Button9 - Pause X axis - Left analog X Y axis - Left analog Y POV Hat - Dpad (8-dir) Z Axis - C analog X Z Rotation - C analog Y Gamepad setup: Generic USB Joystick (Using Z button for select)  Retrolink N64 USB gamepad Driver name: Generic USB Joystick Button 1 - C up Button 2 - C right Button 3 - C down Button 4 - C left Button 5 - B Button 6 - A Button 7 - L Button 8 - R Button 9 - Z Button 10 - start X axis - analog X Y axis - analog Y POV hat - Dpad (8dir) Gamepad setup: Generic USB Joystick Unbranded SNES USB controller reproduction:  Driver name: 2Axes 11Keys Game Pad Button 1 - X Button 2 - B Button 3 - A Button 4 - Y Button 5 - L Button 6 - R Button 9 - Select Button 10 - Start X axis - Dpad X Y axis - Dpad Y Gamepad setup: 2Axes 11Keys Game Pad Unbranded $4 chinese NES USB gamepad reproduction that Probably leeches GHB and lead into my bloodstream while I use it and/or will eventually cause my house to burn down in the near future.  Driver name: USB Gamepad Button 2 - A Button 3 - B Button 9 - Select Button 10 - Start X axis - Dpad X Y axis - Dpad Y USB Gamepad First generation XBox 360 controller Driver Name: XBOX 360 Controller for Windows Button 1 - A Button 2 - B Button 3 - X Button 4 - Y Button 5 - L1 Button 6 - R1 Button 7 - Select Button 8 - Start Button 9 - L3 Button 10 - R3 X axis - left analog X Y axis - left analog Y Z axis - LT-/RT+ X rotation - right analog X Y rotation - right analog Y POV hat - DPAD (8dir) Gamepad setup: XBOX 360 For Windows (Controller)  Xbox 360 Afterglow controller Driver name: controller (Afterglow Gamepad for Xbox 360) Button 1 - A Button 2 - B Button 3 - X Button 4 - Y Button 5 - L1 Button 6 - R1 Button 7 - Select Button 8 - Start Button 9 - L3 Button 10 - R3 X axis - left analog X Y axis - left analog Y Z axis - LT-/RT+ X rotation - right analog X Y rotation - right analog Y POV hat - DPAD (8dir) Gamepad setup: Controller (Afterglow Gamepad for Xbox 360) I dunno, I've had the most fucking trouble getting gamepads to work properly. I've finally figured out the interface and stuff, but the NES controller refuses to be read at all by the gamepad setup window, and I've got dozens of duplicate profiles in joypads.txt. Plus, several of my controllers register as having the exact same name, despite their profiles being completely incompatible. There's just gotta be a better way to identify the devices. I don't know. | |
I don't suppose you have vendor ID or GUID info for any of those, do you?
| |
I'll get back to you when I've had more time to think about this problem and poke the information behind it.
I think though, the crux of my problems is that the idea of abstracting controller inputs as something different than macro keys in the first place is the root of the problem with the implementation. Controller capabilities are deliberately abstract by design, and BYOND is trying to make an abstract design concrete by creating a second abstraction from the raw data. I mean, look at the current levels of abstraction we already have: Raw keypress: 0 degrees of abstraction. raw keypress -> macro: 1 degree of abstraction. raw controller input: 0 degrees of abstraction. raw controller input -> gamepad bind: 1 degree of abstraction. gamepad bind -> macro: 2 degrees of abstraction That second area of abstraction makes gamepads unnecessarily difficult to work with. Especially since when I wrote code, I implement keybinds like this: raw input -> any macro -> abstract bind The reason I use the abstract bind is so that players can use an interface that I have designed to change what keys are bound to what behavior. In order to make this code gamepad aware, I'd basically have to not only de-associate macros from keyboard keys completely, but then tie them into the abstract binds I'm already writing for handling keyboard input. It's just a really ugly, reach-around-the back implementation that I can't even begin to understand why anyone would want to use. | |
Since we're kind of committed to the setup at this point, is there a way I can make it easier to work with? If you want to use GamepadRaw, perhaps a way to make the setup info available?
| |
I genuinely can't wrap my head around the problem. I see it. I just can't articulate it fully. I'm sorry.
| |
No problem. Take your time on it; if you have any ideas just let me know.
| |
Thanks for mapping the Afterglow controller, Ter - one of our players uses that kind and I cba to ask her to configure it and send me her joysticks.txt. :p
| |
Would STRONGLY prefer the expansion of [[*]] args for macros, and treating gamepad presses/releases as keybinds.
For instance:
Face buttons would feed to Any macro with their button name as a key name.
Axis and Analog would be new macro registers that record movement of the analog sticks. The second column there is the deadzone for the action. The client will not communicate any changes of the analog both starting and ending within the deadzone threshold.
Information about the keypress could be fed through named [[]] parameters.
Axis ids:
XAxis1 (left analog)
YAxis1 (left analog)
XAxis2 (right analog)
YAxis2 (right analog)
ZAxis (left/right trigger)
Analog ids:
LeftAnalog
RightAnalog
Analog parameters:
[[id]] (LeftAnalog or RightAnalog)
[[input.x]] -1 - 1 floating point value indicating how far the stick is held on the x axis
[[input.y]] -1 - 1 floating point value indicating how far the stick is held on the y axis
Axis parameters:
[[id]] (X/YAxis1/2, ZAxis)
[[input]] -1 - 1 floating point value indicating how far the stick is being held on its particular axis
Additionally, the above IDs as well as IDs for D-pad, shoulder, and face buttons should be able to be bound via the existing macro menu.
At the moment, the addition of a separate joypad configuration menu is just completely not viable. The lack of fine control and customization it offers developers makes it pretty much useless. Hooking the existing macro system to include gamepad support was always, and will always be the better solution.
As for it being somewhat confusing for users to customize their macros in a BYOND game via the menu if it is all jammed into the skin under normal macros, I really don't think that's an issue. Building your own keyboard options menu via a custom ui built into the game is a better solution and ATM the existing gamepad implementation makes that much, much harder to pull off.