LuaPlayer:current_inputs [R]

[raiguard]

Something I have been thinking about is a way to detect when a player quits dragging something. For example, in Even Distribution, the mod just waits a certain amount of time after the last entity was highlighted to execute the distribution. It would be much more intuitive and nice if it distributed when you stopped holding down the mouse.

So, here's my suggestion: Since straight-up drag support has been rejected in the past, I propose that a current_inputs class be added to LuaPlayer. This would simply be an array of all of the inputs that are currently being used by that player during that tick. They would use the same syntax as one would use when defining a custom input. For example, it might return {'mouse-button-2', 'CONTROL', 'A', 'W'}.

In the case of even distribution, the usecase would be this: The mod detects when someone starts an even distribution, then registers a conditional on_tick event to read the current_inputs table. When the on_tick no longer sees that CONTROL and mouse-button-2 are being held down, it knows that the player has stopped dragging and distributes the items, then deregisters itself.

This is merely one usecase, I'm sure modders out there could find many uses for something like this. Thanks!

[boskid]

This is not likely to ever happen. Input keys are not part of game state, every player can have different key mapping. During MP, each factorio instance will map inputs for given player into InputActions that are then sent to server and synchronised and sent to all players before they enter game state. Sending every input change would mean a lot of extra InputActions, and there would be a lot of different issues like handling inputs under latency state.

[raiguard]

That's a shame, but it makes sense. Thanks anyway! I guess this can be moved to "won't implement".

[eradicator]

Sending every input change would mean a lot of extra InputActions

Aren't you kinda mixing hardware inputs with input actions here (albeit the OP mixes them too)? Mods do not know and do not need to know what hardware inputs are associated to what input actions. To solve the problem in the OP (and many others) it would be sufficient if the corresponding custom-input event contained info about if the input was pressed "down" or released "up". Albeit a mixed up-or-down event would cause non-aware mods to see every input twice, so the alternative solution would be the ability to subscribe linked_game_control prototypes only to the "up" event of an action. This might be better also because in many cases mods only care about the "down" event.

As for the synching... the game already has to sync all input actions "up" events at least for vanilla controls right, otherwise how would one ever stop walking?

[boskid]

Sending every input change would mean a lot of extra InputActions

Aren't you kinda mixing hardware inputs with input actions here (albeit the OP mixes them too)?

I may since i am still learning how everything works from inside. Using

Code: Select all

/toggle-action-logging

will show what actions are sent from "UI" to "Game" and so it is easily verified there are no explicit "button pressed" actions.

my simplified model

My simplified (not verified) model is that keyboard and mouse belongs to UI, UI handles them with key mappings and other things and if something affects game state, must produce InputAction that is sent from UI to Game. This InputAction may go to server and then back to all Game instances (MP) so their state is same for everyone. Since InputAction may go through network, some UI actions will not give instant feedback so there is poor user experience during lag, this is why there is latency state: not perfect extrapolation of game state in assumption that given InputAction was performed with some order but that can be easily reverted in case server would order actions differently or some actions would become invalid because of other players actions.