[VX Ace] Technical info on the native gamepad support? I'm having compatibility issues.

[serp]

Here's some context:


 -I am currently testing my game on two different windows 7 machines. The built-in gamepad support works on one, but not the other, and I'm not sure why.


 -I am already using a modified version of LoneWolf's game pad extender script. I have mine set up to listen for both keyboard and gamepad input so you don't have to unplug your gamepad to use the keyboard.


 -The machine that doesn't work with the built-in gamepad support works perfectly with the script, but since gamepad support works fine on the other computer, the modified script double-listens to the controller and messes things up (I can go into detail on how if desired).


Yes, I wouldn't have this problem if I just ignored the keyboard input whenever a gamepad is plugged in, but I'd really like to avoid that. What I would really like to do is simply disable native controller support and have LoneWolf's script be the only gamepad listener while the built-in stuff handles the keyboard input. Unfortunately, the Input module isn't one of the files that's available in the script editor so I can't even look at it to see how I might alter it to ignore gamepad input. I also have no idea why the gamepad support works on one machine and not the other. If anyone knows any nitty gritty details on how RGSS3 listens for input and if it's configurable beyond what's in the F1 menu, that would be a big help and a good place to start. Thanks in advance for any advice!

 

[Engr. Adiktuzmiko]

This is a bit weird, normally when you make an Input script, you overwrite the default methods such that the game will be using only your edited method to capture those button presses (hence avoiding double input processing). 


I'm not well versed with using gamepads, but by default if you use a gamepad you cannot use keyboard input while the gamepad is plugged (without his script)?


Also what edits did you make to the script? 

 

[serp]

This is a bit weird, normally when you make an Input script, you overwrite the default methods such that the game will be using only your edited method to capture those button presses (hence avoiding double input processing). 

LoneWolf's script overwrites the input module methods, but it does it in such a way as to still call them if there is no gamepad plugged in. My edited version will check for keyboard input if no gamepad input is detected, this way you can switch back and forth between keyboard and gamepad without unplugging your gamepad.

I'm not well versed with using gamepads, but by default if you use a gamepad you cannot use keyboard input while the gamepad is plugged (without his script)?

The opposite actually. Default VX Ace functionality allows you to use either IF the gamepad is working normally (more on this later). LoneWolf's script adds  more advanced gamepad functionality, but it prevents you from using keyboard when the gamepad is plugged in - at least that seems to be the intended functionality to me, apologies to LoneWolf if I'm incorrect. My edits to the script allow you to use either, as in the default functionality. I should clarify that much of the reason I used this script in the first place is because I didn't realize at first that RPG maker would work with a 360 controller natively until recently, and I only just figured out why that didn't work on my computer last night (details later).

Also what edits did you make to the script? 

I made it so that you can map several gamepad buttons to a single RPG maker input (so that you can use both L-Stick and D-Pad), but the more important change was for it to listen to both keyboard and gamepad. I did this because I really don't want to make players unplug their gamepad in order to use a keyboard. I suspect LoneWolf may have prevented this functionality in order to avoid the exact bug I'm dealing with.


In any case, I did at least figure out why the native gamepad support wasn't working on my computer. The issue was discovered in this thread by LoneWolfDon (a different LoneWolf, evidently) :





I just needed to choose a preferred device in the Windows settings. Of course this is the opposite of what I wanted, since I wanted to prevent the native gamepad input from working on the machine where it worked, not enable it on the machine where it didn't. At this point, I think my best solution may be to use the native support for Lstick and the primary buttons, while using the script for other functionality (d-pad, bumpers, vibration) so that I'm not double listening.

 

[Engr. Adiktuzmiko]

I suspect LoneWolf may have prevented this functionality in order to avoid the exact bug I'm dealing with.

I think so too, in which case it's better to ask LoneWolf himself if that's really the case. 

 

[Sixth]

It is not possible to get input keys read multiple times in the same frame, if you use the Input.trigger?(button), Input.press?(button), Input.repeat?(button) checks (and you should only use these in your scripts).


The Input module is only refreshed once on each frame, unless you call the update method for that module directly, and if it gets an input check (by using the above mentioned methods), it always returns a single boolean value (true if it is pressed, false if it's not). This is true regardless of which other scripts you use to extend the default Input module.


This prevents any possibilities of triggering anything twice or more times with the same button press unless you coded something wrong.


In short, your issue must lie elsewhere, incorrect way of checking for triggers, bad coding somewhere else or incompatibility issues from other scripts.

 

[serp]

The Input module is only refreshed once on each frame, unless you call the update method for that module directly, and if it gets an input check (by using the above mentioned methods), it always returns a single boolean value (true if it is pressed, false if it's not). This is true regardless of which other scripts you use to extend the default Input module.


This prevents any possibilities of triggering anything twice or more times with the same button press unless you coded something wrong.

Yes, for the reasons you describe, one button press will not result in multiple copies of the same event, but that's not what I mean by "double listening."


A single button press can result in two different events firing in cases where the native gamepad mapping isn't the same as my custom mapping. Basically one piece of code asks if "A" is being pressed and another asks if "C" is being pressed and both calls return "true" because two different mapping schemes are being honored.


Another annoying problem is that the native code and the custom code don't share a "repeat delay" for the lstick. This makes menu navigation a pain, because simply pressing the lstick up a little will result in two quick events firing, one frame after the next.


None of that is really important though, I understand how and why all of that is happening. Now that I know why gamepad support was behaving differently between my two computers (discussed in previous my comment) all I really need to know is how to disable native gamepad support, and if that's even possible. If it's not possible, or if nobody knows, I'm probably just going to go with the solution described in my last comment. Either way, thanks all for your responses.

 

[Sixth]

That means you have an incorrect configuration/input check.


A and C should both trigger the same thing if you don't want errors, otherwise it will mess your code up, as expected.


If you really want to allow players to play with keyboard even if they got a gamepad plugged in, you should make a global setting (stored in a setting file, NOT in a save file) for switching between keyboard and gamepad control.


Once you have that, you can change the WolfPad.plugged_in? check to see which control type the player has chosen instead (at the configuration area where you make new "buttons" for your game).


That is the whole reason for that configuration area, to prevent what you described. For now, it fixes it by preventing keyboard inputs while a gamepad is plugged in (this is what the WolfPad.pluggen_in? check does), but change that to a control type check which can be set in the game by the player itself, and you remove the need to unplug the gamepad for keyboard control.


This is what I would do, at least.


It is highly unlikely that any sane person would use a gamepad together with keyboard to play a game, so allowing both checks at the same time is pretty much pointless.

 

[serp]

Yeah, that's a reasonable option. I'll probably try that if my other solution doesn't work out. I don't anticipate anyone playing with both keyboard and gamepad at the same time, but I'm thinking of scenarios more like maybe somebody's controller isn't working with my game for some arbitrary reason. I don't want to make them unplug it whenever they open my game. It's a minor annoyance, sure, but most games allow you to switch back and forth seamlessly, and I'd like to follow that standard if I can.