Firehammer Input
A downloadable system for Windows
Firehammer Input 3.1 is here!
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. 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 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.
- 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 Firehammer Input 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.
- Callback event system that can automatically call your methods instead of you needing to poll actions every step
- Many other features I don't have space to mention here.
3.1 Release Notes
- Added function to disable/enable the system in case you want to manually handle pausing everything
- Added a #macro setting to allow the system to automatically stop processing input if the window is not in focus. This currently only works on Windows and MacOS.
3.0 Release Notes
- Updated things for Feather
- Note that the below changes mean that if you do not have Feather enabled you will likely get lots of syntax errors for things like unused functions which you can ignore
- Removed code meant for working around unused functions, etc... that is no longer needed for Feather.
- Added lots of Feather ignore comments to ensure the system does not generate any Feather errors, warnings, or suggestions
- Added function definitions for use with Feather for all user functions
- Added New Callback Event system for responding to input via methods instead of direct polling
- Various documentation fixes including changes to the section on examples
Version 2.2 Release Notes
2.2 - This version adds a few new features and has a couple bug fixes as well.
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
2.1 Release notes
2.1 - 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.
Support is provided via the Yoyogames forums(user "kburkhart84"), via e-mail "admin@firehammergames.com," or on the Firehammer Games Discord server https://discord.gg/6VrZkP2
Download
Click download now to get access to the following files:
Comments
Log in with itch.io to leave a comment.
Does this have virtual controls that work with HTML5?
No, it doesn't have virtual controls included. If you are porting a game from PC to HTML5, then you can use your own controls and have them function as the inputs for the player's actions, and then your objects would not have to change code. I could consider in the future adding something like that but I didn't originally consider it because HTML5 games have pretty individual needs for each game.
Thank you for the quick reply. I may purchase this, regardless... I'll need something like this down the line, but if there aren't virtual controls (similar to a gamepad) than it doesn't solve the problem that I'm currently wrestling with.
Thanks for the consideration...sorry about the specific lack. Would you be willing to describe the issue you are having? If nothing else it would possibly give me an idea of a void I can fill in the package.
I know it has been quite some time, but I finally added support for virtual controls in version 2.2. It does work on HTML5, however I don't think that GM with HTML5 actually supports multitouch fully so it works with just a single touch. On mobile it certainly supports multitouch and this system takes advantage of that.