Gamepad Extender (v1.1, 2/20/2015)

[Lone Wolf]

I keep playing with the numbers to no avail

If you mean the @keys hash, it says not to change those! That hash just tells the module how to translate the raw controller data. Making Y something other than button 0 won't change that Y is button 0 on your controller.

There is no section of this script that will change any of the default mappings. Have you read through the header? Changing bindings is really as easy as going to the section of the default classes (or another add-on script) you want to change (like Window_Selectable, method process_handling), and replacing Input.trigger?C) with Input.trigger?A) (for example). To use a binding defined in the PadConfig module, you'd need only replace Input.trigger?C) with Input.trigger?(PadConfig.confirm). I see no point in making it any easier than it already is.

I don't provide any default re-bindings because this is a Module, not an ordinary add-on script, and I wanted to avoid conflicting with changes made directly to the default classes.

 

[Abi]

I don't provide any default re-bindings because this is a Module, not an ordinary add-on script, and I wanted to avoid conflicting with changes made directly to the default classes.

I love you already. This is exactly the way I feel code should ALWAYS be done.

I'm planning a rather complex mod to have Star Ocean/Tales Of Phantasia like gameplay mechanics and this script will be indispensible for this.

I also don't believe in reinventing wheels I don't have to. But try as I might I can not find anyone else who's truly managed to implement SO/ToP like gameplay. Well... tell the truth I actually plan to go even further and make some very complex mappings in order to completely eliminate menu's entirely without losing any of the battle complexity afforded from menu's. It'd be like... SO meets ToP meets Legaia meets Fighter games... But enough about that here. I'll describe it much more thoroughly when I'm actually getting close to completion and ready to post the project up.

Right now it's about gathering together useful modules so I don't have to write things I don't need to write and lots and lots of studying because this'll be my first REAL Maker project whenever I can get working on it. For now... prep work. Get to know the VX Ace system. Gather materials. Y'know, the easy part.

So yeah... thanks for doing some of my work for me!

 

[Internetakias]

I tested your script with an official X360 controller on an empty project and it doesn't seem to work too well, the player keeps walking even when I'm not touching the control stick at all, and some of the mappings seem to be wrong (ie C is set to the X button, and A is set to the A button) and I couldn't find a way to change them, even changing the gamepad button IDs didn't do much.

 

[notwelshman]

If you start the game itself (F12 or the playtest option, or I guess the .exe file) and then press F1, it'll take you to a config menu. You can adjust the individual button settings there (just swap A and C around). As far as I can tell, that pretty much fixes some of the queries above (which was the same problem I was having). I think the game 'saves' the preferences too--no need to edit any of the scripts any further!

For script idiot like me, this module has the beautiful effect of activating the D-pad on my controller, which was the only bit of the controller that wasn't working for me before. Thanks Lone Wolf for this! Funnily enough, I actually didn't know the controller worked at all until I started mucking around tonight!

EDIT: I was wrong; it doesn't remember the playtest settings when you load the game from the .exe. However, players can still press F1 to configure their own buttons, which is good enough, I think.

EDIT EDIT: Or, wait, it might remember. I'm confused, and past caring. Either way is a win!

 

[Internetakias]

If you start the game itself (F12 or the playtest option, or I guess the .exe file) and then press F1, it'll take you to a config menu. You can adjust the individual button settings there (just swap A and C around). As far as I can tell, that pretty much fixes some of the queries above (which was the same problem I was having). I think the game 'saves' the preferences too--no need to edit any of the scripts any further!

For script idiot like me, this module has the beautiful effect of activating the D-pad on my controller, which was the only bit of the controller that wasn't working for me before. Thanks Lone Wolf for this! Funnily enough, I actually didn't know the controller worked at all until I started mucking around tonight!

EDIT: I was wrong; it doesn't remember the playtest settings when you load the game from the .exe. However, players can still press F1 to configure their own buttons, which is good enough, I think.

EDIT EDIT: Or, wait, it might remember. I'm confused, and past caring. Either way is a win!

Well, changing the controls on one game will change the controls for every RMVXAce game you play on your PC, so it doesn't seem like that good of a solution to me.

 

[Grev]

First off, thank you for this script. I am just making a game for the fun of it and wanted to be able to utilize my Xbox 360 wireless controller. But... for whatever reason the left stick's Y-axis doesn't respond properly. As soon as the game starts my "hero" moves down. If I put the stick all the way up it will go up, sometimes. If it is in the neutral position it will usually have the "hero" go down or the slightest touch of the stick in that direction will do so.

I have tested this with a different game and the controller works just fine so I am curious as to where I can adjust this in the script or in the game.

Thanks,

-Grev

 

[zidanemaxout]

I tested your script with an official X360 controller on an empty project and it doesn't seem to work too well, the player keeps walking even when I'm not touching the control stick at all, and some of the mappings seem to be wrong (ie C is set to the X button, and A is set to the A button) and I couldn't find a way to change them, even changing the gamepad button IDs didn't do much.

I am having the exact same problems as you, but since I have no need for the analog sticks, I typed "false" for MOVE_WITH_STICK under padConfig, and that allowed the d-pad to function properly. However, the only other functions that work are dash/menu/cancel and they are allocated to my xbox 360's A and B buttons. But I cannot in any fashion get the "confirm" function to work, as I cant change any functions in the script (just as you said). At this point, I'd just be happy having a confirm function working.

 

[raulf17]

i fixed the problem, changing the deadzone to 0.01, fixing constrain_axis, and fixing the angle formula, this scripts now works perfectly

find and replace:

def self.constrain_axis(axis)
                val = axis.to_f / 2**20 
                val.abs > PadConfig::DEADZONE ? val : 0
end

def self.axis_to_angle(axis)
                cy = -axis[1]
                cx = -axis[0]

                if cy == 0 && cx == 0
                  angle=-1
                else
                  angle = Math.atan2(cx, cy) * 180 / Math::PI
                  angle = angle < 0 ? angle + 360 : angle
                end

                return angle  
              end



# Please PM me if you have an easier way to write this.
def self.angle_to_dir8(angle)

                return 0 if angle == -1
                d = 0
                if angle < 22.5  || angle >= 337.5
                 d = 8
                elsif angle < 67.5
                 d = 7
                elsif angle < 112.5
                 d = 4
                elsif angle < 157.5
                 d = 1
                elsif angle < 202.5
                 d = 2
                elsif angle < 247.5
                 d = 3
                elsif angle < 292.5
                 d = 6
                elsif angle < 337.5
                 d = 9
                end
                return d
end
def self.angle_to_dir4(angle)
                return 0 if angle == -1
                d = 0
                if angle < 45 || angle >= 315
                 d = 8
                elsif angle < 135
                 d = 4
                elsif angle < 225
                 d = 2
                elsif angle < 315
                 d = 6
                end
                return d
end

I have to thank you Lone Wolf for this great script

 

[Abi]

i fixed the problem, changing the deadzone to 0.01, fixing constrain_axis, and fixing the angle formula, this scripts now works perfectly

Uhm. Why'd you change the "zero" angle to -1? Changing deadzone and constrain_axis makes sense, that's part of joystick calibration, but the other changes not so much. I mean. It's not "wrong" but I can't see why that should make any difference either.

 

[raulf17]

because angle 0 is the result when you press up on the stick, if you leave it as 0, will make the direction=0 instead direction=8 that makes your character go up.

you can change -1 to any number except one from 0 to 360, its just a check for nothing being pressed

i did this, because in my game, the stick is not working fine when i press up, with this change, works perfect.

Use this code change if you need it only.

PS: i made another change, a detection to change the character speed movement based on the stick movement, like in mario 64, when i finish i will post it.

 

[Abi]

Oooh. I hadn't even thought about that! Makes sense.

IMO character movement speed and such should be in a separate controls module specific for your game... Such things would most probably instantly break any additional add-on scripts if you aren't extremely careful with them.

 

[Lone Wolf]

I spent twelve hours divided among six different modes of transit today, so I'm going to sleep now. But before I do:

some of the mappings seem to be wrong (ie C is set to the X button, and A is set to the A button) and I couldn't find a way to change them, even changing the gamepad button IDs didn't do much.

I'll work on updating the FAQ tomorrow once the jet lag wears off, but for now, all I can really do is quote the documentation that clearly nobody read:

# (Replace direct button calls in your scripts (and the defaults) with

# PadConfig calls or these will do nothing.)

You actually need to go to Window_Selectable's input handling method (for example) and tell it to use PadConfig.confirm instead of Input.press?C) (for example). It's such a basic override I didn't think I needed to explain further (I also can't right now for reasons). I'm still not going to add any (other) overrides to the main script because that would kind of kill any hopes for compatibility with other scripts. The base scripts are there to be edited, so you really don't need to passively wait for someone else to write an entire override script just to replace a single boolean test (per button mapping). It's really not that hard.

PS: i made another change, a detection to change the character speed movement based on the stick movement, like in mario 64, when i finish i will post it.

That's exactly what you're supposed to do: use this as a basis to add your own functionality to the engine. Just don't post it in this thread, because that's your own original code and completely separate from the purpose of this script.

 

[Bethins]

I have an issue that I can't solve.  My UP joystick command isn't being accepted by the game and I'm not sure why. All other directions work with "MOVE_WITH_STICK" set to true.  I can move up if I press a little to the right or left with the stick, just not directly up.  All tests lead me to believe that my joy is working fine.  If I disable the script, I can move in-game properly, all directions work.  If I set move to stick to false, the up direction pad works properly.  Down works fine, so I have to have the axis set correctly in x360ce.exe, correct?  Any ideas would be appreciated!

Thanks!

**EDIT**

  Looks like raulf17 in post #28 fixed the problem.  Thanks!

**EDIT again**

How do i define the second controller?

"When using multiple pads, send calls to WolfPad with pad number (0...3)
#     as the final parameter."

Can you give me an example as to what it would look like if I sent a call to wolfpad with a number as the final parameter?

Thanks again!!

 

[Lone Wolf]

How do i define the second controller?

"When using multiple pads, send calls to WolfPad with pad number (0...3)

#     as the final parameter."

Can you give me an example as to what it would look like if I sent a call to wolfpad with a number as the final parameter?

Thanks again!!

It's pretty obvious if you scroll down to the method definitions, but it works like this:

Input.press?A) would become WolfPad.press?A, 1) to check the second controller (possible IDs are 0, 1, 2, and 3, because that's how programming works ). You can also add that ID to methods that don't normally take parameters, so Input.dir8 can be replaced with WolfPad.dir8(1) to check another pad's directional movement.

I've also gone ahead and posted an updated version with the above bugfix (integrated properly), some groundwork for addons, and some documentation revisions.

 

[Bethins]

Thanks : )

 

[orochii]

I've been using an old XInput script all this time (one year or so) in my game, and I just realized it was pretty laggy. Glitchfinder's Gamepad Input, so to speak. Thing is, I'm looking for a replacement, but since I use analog values to determine running/walking and 8 direction, there is quite some things I have to redo in order to work with this (fortunately all my input calls already do a call to my own custom functions, so I don't need to go and check every Input.press? on every class).

My little, minor question is, have you tested it about how much lag it produces? Because, seriously, just some days ago I removed the gamepad module I had and I regained like 10fps lol (if you try and tell me "maybe you have something else that's causing so much lag" I'll bite you to death because I'm touchy on that aspect =D and depressed, mostly depressed "OTL).

Anyway, I'll try it out. I want to compare both. See if this one gives me better performance.

Also, does this module need any DirectX version in particular? Like, 10 and up or something? Would be nice to know, to better inform users.

(Props to you for not using extra custom DLLs because of swag).

 

[Lone Wolf]

Lag? Why would it lag? I'm using Microsoft's own libraries and the most bare-bones state checking possible with Ruby. Also not polling the controller more than once per frame, because the VXAce engine is locked to 60FPS. There's really not much going on here besides the minimum required functionality.

I'm just going to assume that you're talking about the lag the other script gave you, and say, yeah, you should get that replaced. This one is about as lightweight as the VXAce input module itself, because they work the same way. It will probably work better for you, but test it for yourself.

 

[Mireneye]

A friend of mine, in testing my game got this error: 

Looking at line 344 (i'm no programmer by any means) that it's making a Windows api call. My Friend does not have a controller connected at the moment so we don't really understand what could be wrong. 

Appriciate any help with this!

Thank you for an awesome script ^-^

 

[Kane Hart]

Darn I hope Lone Wolf checks by to fix that. Going to see if I can replicate it also today. It would suck if it crashed if you don't ever have a gamepad or software installed. 

 

[Mireneye]

We confirmed that it's only a problem if you don't have DirectX installed. Which a majority of people (especially gamers) do. Easy fix!