[Request] - Gamepad ID expression

0 favourites
  • 13 posts
From the Asset Store
Total customisation of the input! You can combine inputs from all peripherals. Make your game accessible for everyone!
  • It would be awesome if there was an expression that would give you the ID number of the gamepad after pushing a button, so that we could easily tell which gamepad initiated that button press.

    Thanks!

  • I 100% percent agree with you. The way it is very annoying and counter intuitive.

    Either

    A. Create an Input for each controller

    or

    B. Iterate through each controller and check for state.

    both are not the best way to handle input.

    It would be a lot nicer to do

    OnControllerButton A

    --FunctionCall("FireAction", GamePad.ID)

  • Ashley - would this be something easy to add plz?

    thx

  • Seconded. While I'm unsure the reason for which there are no unique gamepad IDs, it would be so nice to have the ability to have something built in.

    It's not difficult to work around, though, like Jay noted above, but yeah, having to cycle through each gamepad is strange.

  • Firstly I think you are asking for a "LastGamepadIndex" expression? The gamepad ID is a string describing it, which doesn't sound especially useful to this case.

    Secondly I don't see how it helps by itself: currently you have to always specify a gamepad index when using a trigger like 'On button pressed', so the expression would be redundant, it would always be the same as the number you already provided in the trigger. So are you in addition to that asking for new triggers which don't specify a gamepad index and provide it by an expression instead? That did not appear to be specifically outlined.

    Thirdly the way conditions work, that could not really be extended to the non-trigger 'Is button down'. If you have 'Is button A down' that is true for any gamepad, then if two gamepads press A simultaneously, then the condition still runs its actions once with a LastGamepadIndex for just one of the gamepads, since that's just how the event system works. So we could extend new gamepad-neutral triggers, but not non-trigger conditions, which then makes a sort of weird inconsistency between what you can do without a gamepad index and what you can do with one.

    This is why you should always describe feature requests in as much detail as possible, a bit like the approach with bug reports. The suggestion just raises more questions and has implications you probably didn't foresee.

  • Ashley - Thanks for the reply, I will try and explain in more detail.

    When working with a local "couch co-op" type game with 4 players, it seems like the easiest solution right now to support setting up a reusable input system for all 4 players is to create a master group that listens for whatever button is being pressed, for all 4 inputs then passing it to another function that picks the related player and initiates that players attack etc.

    For example:

    On gamepad 0 button A pressed -> call function "Jump" ("0")

    Function "Jump"

    Pick by evaluate player = function.param(0) -> Jump

    But this now means that you need create 4x the number of input checks * the number of buttons on the controller

    So i was thinking perhaps if there was some way of being able to read which gamepad initiated the button press you could replace all of that with...

    On Any gamepad button A pressed - Call function "Jump" ("Gamepad Number that initiated that input")

    Function "Jump"

    Pick player function.param(0) -> Jump

    Thus only having the 16 events at the beginning setting up what every button on your controller does.

    But there's also probably another awesome way of doing it that I've never though of.

    How would you approach handling all inputs for a 4 player "couch co-op" type input system?

    Thanks for all of your help!

  • OK, so that sounds like what I assumed, but you realise that doesn't work with 'Is button down' for the reasons I described, right? So you'd still need to do those conditions over. But then I guess you can also check that in a loop, which you can't do with triggers.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Ashley

    Yes. That would be fantastic middle solution

    Trigger Button is down

    --loop through all to find who is down THEN function.call with controller info

    because right now it's

    Loop through all controllers

    -- check fro button A down

    -- check for button b down

    -- check for button c down

    -- check for analog x

    -- check for analog y

    ....

    With the top version I'm not constantly having too loop through all possible controller input every tick. Now it only checks the whom on the input when an input occurs. I like this way much better.

  • Ashley Any chance this will be in the next beta? The current way calls for A LOT of copy paste code with slight variations for each gamepad..

  • jayderyu You mention being able to loop through the gamepads to retrieve the gamepad index when a button is pressed. Can you elaborate? I tried a for loop every tick with loopindex as the gamepad index but it didn't work. Maybe I missed something. Anyhow, I 'd definitely prefer to do this than have a set of input events for each gamepad...that will be a major pain in the ass with complex player mechanics.

  • Tokinsom, I had the same issue as you, and after applying some helpful advice from some forumites, this is how I handle multiple gamepads and/or keyboard input in my game. Everything is assigned dynamically before this, and then to read the controls, I simply loop through each player (the PlayerBlocks family in my case), check their ControllerNumber variable against the gamepad number, and take it from there. In my case, "Gamepad 10" is considered to be the keyboard.

    [attachment=0:1mpv3fmj][/attachment:1mpv3fmj]

  • Nope. I can't fine the gamepad index in a loop. I absolute the loopindex as the gamepad id then do the poll input request. However I do map index to a controller input slot. Let's just say it's a pain.

    I don't know the exact names at the moment

    Repeat gamepad.count

    -- check for button down then callback function("controller.DOWN", loopindex, gamepad.lastbutton)

    -- check for button release then callback function("controller.UP", loopindex, gamepad.lastbutton)

    -- check for xAxis !=0 then callback function("controller.axis_x_change", loopindex, gamepad.xaxis )

    ... repeat for each input type.

    and I do that for every input type I need. And it's annoying, because then i'm polling for every possible change every tick rather than just letting the even occur then finding which one it occured on.

    GeometriX

    That works too. While I do some more dancing with mine to map the gamepad.id /loopindex count. I prefer controller input agnostic. So the input does not tie immediately to the player. But that's me.

  • Subscribing to topic for updates.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)