Asset - Scripts FHInput is finally here to solve your input needs


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 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!

I have added a purchase option on here. If you have previously purchased on the Yoyogames marketplace, I will be glad to set you up with an key if you email your purchase confirmation.
Last edited:


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.


Firehammer Games
I have upgraded Firehammer Input to version 1.3. I have also added an option to purchase it via here. If you have previously purchased it via the Yoyogames marketplace, I will be glad to get you an 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 I have also made the purchase price $4.99, and this is the same both on the Yoyogames marketplace and the site.


  • 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 - if you purchased on the Yoyogames marketplace, you can send me your confirmation e-mail and I'll be glad to send you an key if you have that preference.


Firehammer Games
I have finally upgraded Firehammer Input to version 2.0. It is currently on 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.


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.


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.