Factorio Forums

TL;DR

Add a feature to the Lua API that allows scripts to get a player's current inputs/keypresses, or to listen for something like an on_input_released event.

What ?

I've just run into a brick wall trying to implement a mod feature that involves holding down RMB, because currently Factorio does not allow scripts to detect whether a button is being pressed in any way besides the initial press of a CustomInputEvent. As a result, many different kinds of features are impossible to mod in simply because they involve some kind of continuous input.
For example, it is impossible for this reason to implement a rightclick alt-fire mode for weapons that can be fired continuously just like the vanilla primary fire by holding down the button. There needs to be some kind of way to detect if the player is still holding down the alt-fire button (or alternatively to detect them releasing it) for this to work, but there isn't.

After some thought, I see two main possibilities for allowing scripts to detect if inputs are being held or released :
- Option 1: Add something like a player.get_inputs() method, which would return an indexed list of the custom inputs currently being made by that player.
Example script fragment using such a method:


- Option 2: Add some kind of on_custom_input_released event, which would trigger when a player stops making a custom input and would contain the index of that player and the name of the input they released.
Example script fragment using such an event:


Option 1 seems like the cleanest and most convenient approach to me.

Why ?

Adding a method to the Lua API for reading a player's current (custom) inputs would open up all those currently-impossible-to-implement ideas involving continuous or held inputs, giving modders a great new tool to work with for what from the outside seems like a comparatively minor development cost.

Just over the past couple weeks the Lua API has received some huge features I had been silently craving for ages (like EntityPrototype.indexed_guns and EquipmentGrid.unique_id) and these have made a huge difference for me. I really think something like a player.get_inputs() method would be a similarly fantastic addition/improvement for the API.
I hope to see it in the game some day :D

Do note that due to how the game and modding work, all clients will need to know this info. Meaning it being sent over the network. Meaning that reading key state isn't going to happen.

I think that your best bet is an extension of custom inputs to allow them triggering on key release.

That said, I could use this in my mod.

curiosity wrote: ↑

Wed Aug 03, 2022 9:27 am

Do note that due to how the game and modding work, all clients will need to know this info. Meaning it being sent over the network. Meaning that reading key state isn't going to happen.

I think that your best bet is an extension of custom inputs to allow them triggering on key release.

That said, I could use this in my mod.

Yeah I was imagining that as some kind of get() function that the script can just use to read from the one player specified, but I guess I dont know how scripts are actually run on servers... like, does only the server run it, in which case it seems alright, or is it run in some kind of distributed/parallel manner where indeed all clients need to read other players' inputs whenever the function comes up in the script execution...
Sounds like it could definitely be a problem depending on how things work.

I guess an extension to CustomInputEvents is what I intended with the second option, since that seems much cleaner than allowing scripts to subscribe to all input events and presumably having to add a bunch of filters and stuff to keep it sane. CustomInputEvents are already pretty concise in that way, so just adding an option to read something like a boolean property "event.key_up" to see if that particular custom input is a keypress or a key release seems like the tidiest way to handle this, even if it's marginally less convenient to script with.

All that would leave from my "wish list" for this feature is the bonus feature of reading cursor position, but that's basically a separate feature request in its own right anyway xD

I would really like this feature also.

We can trigger an event when a key is pressed, so optionally triggering a different event when a key is released is surely not going to complicate the code or significantly reduce performance, is it?

Bump! This would be super useful!