Asset - Scripts Firehammer Input - Easy custom input mapping and then some(now free but NOT discontinued)

kburkhart84

Firehammer Games
I have finally gotten Firehammer Input ready for release. It is a ground-up re-write of kbinput, and is a free upgrade for those who have already purchased kbinput in the past.

Firehammer Input is your new way to manage your game's inputs. Under the hood it uses GML functions and so supports all the input devices currently supported in Gamemaker: Studio. But it then adds on easy to use custom input options, letting your game's players choose their own inputs with ease. They can choose keyboard keys, mouse buttons, or any inputs on XInput or DInput devices(as supported by GMS's gamepad functions). But you as the developer can code your game without worrying about what input is driving your game's actions, making your job much easier. That's right, your objects respond to actions, without needing to know if the action is being driven by the space bar or some gamepad's shoulder buttons. It then also includes a few helper scripts as well that are meant to make your input handling very simple.

*Player System-You can have a number of game players only limited by the available input devices and what is feasible(for example you could have 4 players have inputs assigned to the keyboard but can they actually play that way?). Firehammer Input has no limit on the number of players, letting you make "party" style games if you wish, adding and removing players on the fly, and loading and saving separate input profiles for each. *Action Response-The system keeps track of a few different pieces of information on the inputs behind your actions, which include(but not only) raw data(such as how far the axis is tilted), and a timer for how long the actions input's are being held down for. *Configuration Program-Here you will implement the possible settings for FHInput as well as create and test a default input scheme for your players. You can actually create more than one default scheme if you so desire.
*Many other features I don't have space to mention here.

I have now released version 2.0. It requires GMS 2.3 and up.

This topic will serve as both announcement and support. You can also PM me or shoot me an e-mail at [email protected] if you need support, as well as joining the Firehammer Games Discord Server here. Feel free to let me know of any issues you run across. Thanks in advance for your support!

edit****

I have now released version 2.1. It requires GMS 2022.1.0.609. It may work in a slightly older version, but certainly won't directly work in any version before optional argument syntax was added to functions. See the post below for details on the update.

edit****

I just released version 2.2.
  • Fixed a couple bugs with the XBOX axes
  • Fixed a couple bugs with automatic GP action remapping
  • Added basic rumble support
  • Added basic skinnable action mapper
  • Added Virtual device support including multi-touch
  • Various documentation updates and fixes
 
Last edited:

kburkhart84

Firehammer Games
FHInput now supports Gamemaker Studio 2!!!

A couple of changes were made due to this change, but it was all internal. There is no change required as far as using FHInput, and it works just as well on Gamemaker Studio version 2! So if you own it, go get it. If not, better input handling is waiting for you on the marketplace.
 

kburkhart84

Firehammer Games
I have upgraded Firehammer Input to version 1.3. I have also added an option to purchase it via itch.io here. If you have previously purchased it via the Yoyogames marketplace, I will be glad to get you an itch.io key if you would like to have access to it over there. See the release notes below. I also have created a Discord server if you need customer support of just want to hang out at https://discord.gg/6VrZkP2. I have also made the purchase price $4.99, and this is the same both on the Yoyogames marketplace and the itch.io site.

1.3

  • Deprecated any compatibility with GMS1(GMS2 is a few years old now)
  • Fixed a few documentation mistakes, and corrected other issues to make the documentation better overall.
  • Added "known issues" section to documentation
  • Added lengthy "Tips for Best Results" section
  • Added "quick and dirty" automatic configuration save/load.
  • Added a few functions to check in bulk whether actions have inputs set(single action, player wide, and system wide)
  • Added a few functions to check in bulk for "problems"(player wide and system wide). For now, "problems" consist of when actions have inputs assigned to them that are on gamepads that are not actually connected. This is reserved for if I find other "problems" that could be checked for.
  • Added information about Firehammer Games
  • Added customer support information, including discord server invite
  • Name change to Firehammer Input
  • Made sure the system cleans up after itself in case it wasn't shut down via the fhinputShutdown() function. This works as long as the game exits cleanly.
  • Changed all references to "scripts" into "functions." The upcoming GML release(planned for 2020 Q1 but already missed) will have all scripts be turned into "script resources" and the script resources be able to contain multiple functions, with actual function declarations.
  • Added release to itch.io - if you purchased on the Yoyogames marketplace, you can send me your confirmation e-mail and I'll be glad to send you an itch.io key if you have that preference.
 

kburkhart84

Firehammer Games
I have finally upgraded Firehammer Input to version 2.0. It is currently on itch.io in the same location here. And I will be adding it to the Yoyo marketplace assuming I can do it without issues(there were some reported but I don't know if they will affect me just yet).

This version was built with GMS 2.3. I have dropped support for previous versions, as I needed some of th enew GML features to make the system better in this re-write, which also opens the door for more features now and in the future.

The part I think I'm most proud of is that I removed the need for an external program to configure it all, which means I no longer depend on the Windows clipboard functions to get and store the settings. Instead, I have rooms that you simply set to run(or go to at the beginning of the game temporarily). You just run a build, and it loads the configuration. And now, since the datafiles folder is automatically integrated and updated as far as the IDE is concerned(the old "included files" thing was bad), I can just have the configuration system save some files there, and you no longer have to worry about transfering strings for settings or anything like that. I have the full release notes for this version below.

This upgrade is FREE to all current owners. I still offer an itch license to anyone who wishes to use it instead of the marketplace.

2.0 - This is a total rewrite of the system, and is only compatible with GMS 2.3 and later. I took advantage of some of the new language features so there isn't really an easy way to make it backwards compatible. Note that not only did some functions change, but the way configuration is handled is also completely different. Therefore, I cannot recommend you upgrade in the middle of a project unless you are right at the beginning.

Complete code rewrite, taking advantage of some of the new features of GMS 2.3 and making it easier to add features down the road.

Rewrite of much of the documentation

Add on to documentation due to the added features.

Reworked the configuration of the system. Global options(such as allowing conflicts, number of player and actions, and others), are now set up as GML #macros. See the #Macro Settings section for details.

Added #macro for Debug Mode(and added sanity checks all over). With Debug Mode on, sanity checks will execute, making sure you don't do something wrong, like checking non-existent players and actions. If you turn it off, that code is optimized out as part of GMS's compile process, which is exactly what you want for performance and final releases. See the Debug Mode section for details.

Added secondary "Ext" version of initialization, which can temporarily overwrite the settings. This allows me to have the examples work with the settings it needs completely separate from the settings your game has, but isn't really useful elsewhere.

Removed separate configuration program. All the configuration that isn't part of the #macros, such as default action maps and the exclusions, will be modified by running a build setting the __fhInputConfigRmStart room to be the first one in the room order setting. This allows things to work on all platforms the IDE works on. And instead of having you copy/paste strings from the program(which only worked on Windows), the configuration will automatically save settings to the datafiles folder(new 2.3 feature). It also lets you save multiple default maps into the settings files that you can then load in by index later.

Added #macro for pointing to the datafiles folder. This lets the configuration objects know where to look for the actual project files on disk in order to save the configuration to the datafiles folder in the project(and with 2.3, these files automatically get included as "included files" and no longer have to be manually added in the IDE).

Added tons of #macros(like FHINPUT_XINPUT_LeftStickUp), making it easier to manually set action mapping, and if you want to name your actions and players instead of just using numbers. See the User #Macros section for details.

Added functions to better handle action maps directly. You can now grab the map for an action into a variable, then use that to set a different action, or revert individually if you want(instead of having to reload the whole map). It is best used for handling conflicts if you choose to manually do so.

Reworked examples

Added example for conflict resolution(in this case switching inputs if you choose, or reverting the change if you choose not to).

Added functions and internals to store and retrieve conflicts, so each action knows what other actions it is conflicting with, making it easy for you to handle, switching them around, allowing them(if you need to due to multiple "modes" or something), or whatever you want to do with them, like simply keeping them and showing the player what is conflicting with what.

Added function to remove a mapping, essentially emptying the setting

Added function to swap mapping of two actions.

Added function to directly compare two actions' mappings.

Added Validation function to confirm if a gamepad assigned to an action map is disconnected(allowing you to pause the game and have the player reconnect or re-assign mapping).

Added Validation function to confirm if mapping is actually set for an action(allowing you to have the player set it).

Removed player adding/removing during runtime. It is actually easier to just set the max amount of players via the #macros(and doesn't hurt performance by any noticeable amount).

Organized assets into proper folders(since with 2.3 we no longer have to have each resource type in a specific folder).

Organized groups of the internal functions into single script resources where it made sense. Note that I left all externally called functions in single files so it is easier to read the help comments at the top of each function.

Renamed all internal functions to use prefix fhInput, and internal functions with prefix __fhInput, with the 'I' capital in both cases. I prefer that standard and really should have done it that way from the start.

Added direct support for DInput Gamepad POV hats(technically up to four though I don't know any devices that actually have more than one).

Reworked some things where function arguments should be optional, making them optional and using defaults where needed. Any optional arguments will use a single underscore prefix to differentiate them.

Added the player selection system, letting you choose a player in advance of action usage functions, allowing for code re-use. It also serves to save typing in single-player games where you never need to worry about more than just the one player.

Added a GML friendly variant for every single user-called function

  • Made the time held in seconds status use actual delta timing instead of just depending on the room speed, which is better both in case the game lags or if you are using delta time instead of room speed to control timing.
 

kburkhart84

Firehammer Games
I found that the marketplace seems to be in good working shape at this time. I upgraded the system there as well. It is here.
 
Hi, I'm thinking about purchasing this to integrate into a couple of projects but I have a few questions first about what it can do...
  • Does it work on Macs?
  • In one of my projects that I'm about to re-code from scratch, I have 1 player who needs to be using a twin-stick gamepad. I currently have it hardcoded for GP0 which works fine for the pad that I have (Dualshock4) so obviously I'd like it to work with as many as possible.
  • The second project I have in mind but not yet started is a game for 1-4 players but players can jump in at any time by picking up a pad and hitting start, and regardless of which pad is used the first player in is always player 1.
I hope all of this makes some kind of sense.
 

kburkhart84

Firehammer Games
Thanks for the interest!

Does it work on Macs?
In all honesty, I don't have a Mac to test on, so I don't want to say that 100% it will work. However, it is 100% GML code, so as long as the GML code work the same on Mac as it does on Windows, there is no reason it should not work.

In one of my projects that I'm about to re-code from scratch, I have 1 player who needs to be using a twin-stick gamepad. I currently have it hardcoded for GP0 which works fine for the pad that I have (Dualshock4) so obviously I'd like it to work with as many as possible.
The way the extension works is similar to in many games, where you have the player press the input they want to assign to an action. So they click on a button you have created, and you tell them to press the button they want to use for the "jump" action, and then so on to the rest of the actions your game has. So you don't hard code anything at all, rather your game's objects just check the system to see if the action is being activated. Behind the scenes, FHInput updates that action based on whatever input is assigned to it, whether it is a key on the keyboard or one of the gamepad buttons, whichever index the gamepad has. This means your objects don't know or care what is actually driving the thing, they only care if the jump action is activated.

The second project I have in mind but not yet started is a game for 1-4 players but players can jump in at any time by picking up a pad and hitting start, and regardless of which pad is used the first player in is always player 1.
This sounds more like an arcade game where you have actual standardized inputs than a PC game. What if a player wants to use the keyboard? What if the gamepad they want to use doesn't even have a start button?!?! I've never liked the idea of putting limitations on what inputs players can use. In fact, I specifically set FHInput up to not impose any limits like this. The player is free to use the left side of a gamepad for movement while having the right hand on the keyboard for other actions if they so choose. They technically could have two players use the same gamepad(not that its viable). I put no limits on how the player chooses to set their inputs up. There is no "assigning" gamepads to players or anything like that.

So, in general, for it to work with your game, you would just need to have the players configure the inputs for each gamepad ahead of time for the 4 players(or you can do it in a pause menu if the game is already started). Then, you can simply look for any action of the other players(or a specific one if you wanted), at which point the additional player could jump in. But using my system, the "start" action could be assigned to any gamepad, or even to the keyboard.

Remember, though XInput devices like XBOX gamepads have a nice set standard for what buttons there are, where on the gamepad they are, etc... many gamepads people have do not follow these standards. I designed my system so that those gamepads can be supported just as easily as XINPUT devices, without any additional work on your part. It does force a bit of a mold as far as how you handle input though, which is why you would need to re-think a little bit as far as that second project.

I hope all of this makes some kind of sense.
No worries, it makes perfect sense.
 

kburkhart84

Firehammer Games
To all who are following this topic, I'm currently working on an update. Among other features, I'm adding direct support for virtual joysticks(a couple different types), and virtual buttons. These will interface automatically with the same input system, so your game's objects will be able to easily be ported to mobile much more simply. I'm also going to do some needed modifications to make sure things work correctly on Linux and Mac, considering that the gamepad IDs on those systems aren't standardized as they are on Windows(and Yoyo never did give me an answer about that). There are some other features I'm looking at adding as well.

Finally, I created a quick(and very simple) test program for checking gamepad support in Gamemaker. This one is using GMS 2.3.2.560 currently. It is only checking gamepad IDs 0 - 11(the 12 standard ones on Windows) at this moment. However, it picks up when gamepads are connected and disconnected, and shows the values of the X/Y axes and the first 4 buttons. The main point of this is just to show if your gamepads are working correctly as far as Gamemaker is concerned. If they work fine in this tester, they will work fine in Firehammer Input, as it is all the same native GML code. This tester is available for free on the Firehammer Input itch page. Note that once my system supports the full spectrum of gamepad IDs, I will revamp this program as well(and it will still be available for free).
 

kburkhart84

Firehammer Games
I have decided to get out of the middleware game and start doing more of what I love, actually making games. I haven't been able to stay motivated on middleware because it has gotten boring to be honest. To this end, I have made this system completely free, both on itch and the yoyo marketplace. I thank everybody who has supported me. I would consider offering refunds to people who recently purchased, but there actually haven't been any recent purchases, and the last ones I gave for free in the recent game jam.

I hereby give permission to use these assets freely, commercially, including repackaging and reselling with updates. I would appreciate it be known that I did the original work, but I'm not opposed if someone creates and sells the system as their own. In other words, it is open source, CC0 license, public domain, whatever you feel like :)

Of course, I'll still be hanging out here. This community has been great over the years and I'm not leaving it even if I eventually stop using Gamemaker completely. It's been fun, and this is certainly not goodbye.

EDIT*************

So I'm not changing licensing or anything, but I WILL be doing updates to this system. It will still be free to all who care to use it.
 
Last edited:

kburkhart84

Firehammer Games
So, at some point between GMS2.3 and now(GMS2.3.7), Yoyo has got keyboard key keycode 1 as something like the "anykey" key. Previously it was not that value. The mapping/searching part of the system therefore was returning that keycode no matter which key you actually pressed, which caused issues with it not being willing to map any keys because they were all showing up as keycode 1.

There is a really easy fix you can apply until I get a chance to issue an update. I'm actually working on other features as well, so I can't just apply a to the release because other parts are broke while I'm doing updates. However, if you open up the script __fhInputActionSearching and look at what should be line 46(inside the __fhInputSearchKeyboard() function, you can change that for() statement to start 'i' at 2 instead of 1. So the line would look like the following.
Code:
    for(var i = 2; i < 256; i++)
This will cause it to skip the "anykey" thing and only check actual individual keys as before. The rest of the system should then work as normal. Feel free to let me know if anybody has any issues.

**********************

As far as this slow to happen update I'm doing...besides that bug fix, I'm doing changes to how gamepads work. For XINPUT gamepads, I will have a way to automatically move mappings between them, so if the player has things mapped to #0(player 1), and their PC for some reason changes it to player 2(it has happened to me), you can have the system automatically switch the mapping over instead of the player having to manually redo it. I'd plan to do something similar for DirectInput/Legacy devices. For those devices, I'm planning to use the actual GUIDs to automatically assign the gamepad correctly to the actions. This would normally work fine, but in cases where there are multiple of the same kind, it won't work as well, so I still need to figure out some details for that. Since I'm also grabbing the GUIDs, I'm going to make available descriptions based on that instead of you having to only use the generic names that don't help much.

I also have done some optimization of internal code here and there, and I'm going to make the callbacks from mapping/searching be just a single function/method that receives an argument for what actually happened(timeout, conflict, success).

Finally, I'm wanting to add a sort of event system, where the system would call functions/methods for things happening, instead of you having to poll using the functions. That would include things like keys being pressed, as well as system events like gamepads being disconnected. I'm still working out details so I don't know if that will get into this update.
 

kburkhart84

Firehammer Games
Version 2.1 is now live both in itch and the Yoyogames marketplace.

This version adds several new features. It now used gamepad GUIDs instead of just gamepad IDs, and automatically remaps gamepad inputs to the correct ID if it somehow changed, using the GUID to know what gamepad it actually was. You can also directly access this remapping functionality to make it easier for your players if you choose. Finally, it no longer uses Gamepad IDs 0 - 11 directly. On Windows, those IDs are the ones that work, but on other OSs, the IDs could be higher. So I changed the system to use the async event's gamepad connect/disconnect events to know what the correct IDs are. The only disadvantage here is that you have to initialize Firehammer Input in the very first frame of the game so it creates the objects and they receive those async events. Note that there is the fhInputRefreshGamepads() function which will attempt to search for connected gamepads using GML's gamepad_is_connected() function, but depending on the actual IDs and your settings, this may not work perfectly, so best practice is to ensure you initialize the system on the first frame of the game.

  • Requires GMS 2022.1.0.609 - It may work with slightly older versions, but since it uses the new optional arguments for functions syntax it will give errors if you use it in a version before that feature was added.
  • Added GUID Database
  • This includes the listing of manufacturers and gamepad models
  • This ties in to the description system now, showing brand/model names instead of something generic like Gamepad #1
  • fhInputPlayerActionGetDeviceName() and fhInputActionGetDeviceName() also use the GUID database instead of GML's gamepad_get_description().
  • Added storage of GUIDs for actions that use DInput gamepad inputs
  • Added fhInputPlayerActionMapGamepadRemap() and fhInputActionMapGamepadRemap() which are for attempting an automatic remapping of actions from one gamepad to another.
  • Added code that will automatically remap to the correct gamepad ID if it somehow changes between game runs. The correct gamepad is determined using the GUID, which won't change for a gamepad even if the ID from the GML gamepad functions does somehow change.
  • In the case of XInput devices, if the player number for the XInput gamepad is changed(for example, player 1 turns to player 2), it will also remap that automatically.
  • Note that any automatic remapping fails typically if either the gamepad is simply not connected or if it is currently in use by another player's actions.
  • Added fhInputGetNextGamepadTouched() which will detect the next gamepad the player touches(moves an input for). This can then be used for the automatic remapping.
  • Added a room to the example showing usage of the remapping functions and fhInputGetNextGamepadTouched()
  • Added option to override current searching to fhInputActionMapSearch() and fhInputPlayerActionMapSearch()
  • Changed description system to use the vendor and model of gamepads for DInput devices(where data is available)
  • Optimized some under the hood code
  • Changed fhInputPlayerActionMapSearch() and fhInputActionMapSearch() to take only a single callback argument
  • The callback now receives an argument that uses one of the new result #macros
  • FHINPUT_RESULT_SUCCESS - the new input was detected and set to the action
  • FHINPUT_RESULT_TIMEOUT - no input was detected before the timer expired
  • FHINPUT_RESULT_CONFLICT - the new input was detected, but NOT set to the action because it conflicts with another action and the #macro FHINPUT_SETTING_AllowConflicts is set to false
  • Added fhInputSetGamepadEventCallback() which sets a method to be used to let you know when a gamepad is connected or disconnected allowing you to notify the player.
  • Added workaround code that removes all syntax errors from unused #macros and unused function names
  • Internally changed the system to store directly if a gamepad is XInput or DInput, and the GUID if it is DInput.
  • This changed also forced a change to the arguments of the fhInputPlayerActionMapDirectSet() and fhInputActionMapDirectSet() functions.
 

kburkhart84

Firehammer Games
Just to make anybody who follows this topic aware, I'm almost done with this update. It adds rumble support(if the players are using XInput devices on Windows anyway, that's all GM supports currently). It also has a basic skinnable action mapper, and lastly will have all the virtual device stuff for mobile platforms. It is just about feature complete as far as code and then it is on to the documentation.

That all said, unless something comes up, this is likely the last update for a time. Yoyo recently announced that they are finally going to better support input in their recent announce video. I'm going to wait until later this year when they are supposed to release their new system to see what all it does. Then, I can see if my system can just fill in some gaps, or if their system does things in a way I like even. At that point I'll decide what to do with my system. I may just keep updating it if I don't like the way Yoyo is doing things or if it is still too limiting. Or I may update my system to just fill in the gaps of things theirs is missing. Or finally, I may just abandon my system as obsolete if theirs ends up doing all the things mine does. I really don't know yet. I just put this out there in case people are wondering.
 

kburkhart84

Firehammer Games
Version 2.2 is now available, both on the itch.io site and the yoyo marketplace!

  • Fixed a couple bugs with the XBOX axes
  • Fixed a couple bugs with automatic GP action remapping
  • Added basic rumble support
  • Added basic skinnable action mapper
  • Added Virtual device support including multi-touch
  • Various documentation updates and fixes
 

kburkhart84

Firehammer Games
I'm currently finishing up an update for Firehammer Input. It fixes some things up so it should work well with Feather(though not perfect, since feather is still buggy). It also adds a callback system so instead of polling every frame for input you can just send it a callback method and it will call it for you once the input happens. This wont' be as useful IMO for action things like moving and jumping since those happen consistently and the response depends on the current state of the object, but for things like changing weapons, toggling radar modes, and other similar things it will come in handy.

I've also updated the separate gamepad tester. It is now available on the itch page with FHInput. It now handles checking for gamepad IDs correctly instead of manually checking all 12 of the ones available on Windows. I've made a package with it so that someone can easily make their own project and export/test it on whatever platform they have access to. Both of these are up and ready for download.
 

kburkhart84

Firehammer Games
Firehammer Input 3.0 is now released. This release now integrates with the Feather IDE feature. The workarounds for the old system were removed and the needed jsdoc(and @ignore directives) were added. FHInput also now features a callback event system. For where it makes sense, you can now have the system call your instance methods in response to inputs instead of you having to poll the system manually. This makes the most sense for things that don't happen constantly, like weapon selection and similar things.

I've also officially discontinued the marketplace support for this release. Anyone who purchased there will still be able to download previous versions. And since the asset is available for free on itch nobody is losing anything either.

As always, I'm open to feedback and suggestions. Let me know how things go and if you get good usage out of it.

edit*******

I just uploaded version 3.1. It adds support for manually disabling and enabling the system in case you want to handle pausing things yourself. It also adds a setting to allow the system to automatically stop processing input if the window loses focus, but it only works on Windows and MacOS.
 
Last edited:
Top