Factorio Forums

I have a custom input
{
type = "custom-input",
name = "RTClick",
key_sequence = "",
linked_game_control = "open-gui",
hidden = true
}

I use this to detect when the player clicks certain entities to toggle the visibility of a RenderObject. In normal game view this fires the toggle for visibility once as I expect. However from remote view the input fires once when I click down and once when I let go, meaning it toggles twice and ends up back to what it was originally in the course of one full click. This always happens unless I drag the map while the mouse button is down, in which case the custom input will not fire when I let go of the mouse button.

To reproduce:
1. Make a custom input with the game control linked to open-gui like shown above.
2. In control.lua make the custom input do something like print the game tick.
3. In normal game view, click down and let go, the event will fire once no matter how long you hold the click down for.
4. Go to remote view, click down, the event will fire once, then without dragging the view let go and the event will fire again.
5. In remote view, click down, the event will fire once, then if you do drag the map view around and let go the event will NOT fire again.

None of my other custom inputs fire twice like this, they only fire once in both views as normal.

While I'm on the topic it would be cool to have a way to intentionally set the release of a key be a custom input like this

Thanks for the report. The current way custom inputs linked to game controls works does not distinguish between "the game control did anything" and "it didn't do anything". It simply fires when ever the same key sequence is triggered.

That's to say, I don't see any sane way to make this work how you're wanting - sorry.

Hey Rseding91 (or whoever manages to pick this up again), I'm experiencing this as well but I don't think the ask here is quite the correct one.

On the map, an event tied to the mouse fires once when down, and once when up. However, if you click (and trigger an event), then drag (e.g. to pan the map), then you do not get an event on mouse up. There is no event for drag started, or drag ended. There is no way to determine that the second action has occurred.

If a second event was always emitted, then it would be reasonable to latch actions such that they fire on the first event, release on the second event, and be ready to fire again. If there were an event for drag-end, then we could latch on the first event and release on the second event OR drag end, and be ready to fire again.

However, as it stands, there is no reliable way to guarantee that clicks on the map are deduplicated. Any action will always trigger at least once, or at most twice, with a mouse click, which means we cannot reliably make any mouse tools for the map. At least, as far as I can determine.

What is the expected means to detect a single mouse event on the map? How would I, say, implement the "Add tag" feature that the map has already built in without resulting in clicking on the tag after it's placed? How could I make a line-drawing tool that doesn't add one or two vertices to every point?

Thank you for your time, and sorry about the necromancy!

Edit:

thelordthygod on Discord wrote:a dev might take additional interest if this were presented without the use of linked_game_control, which is a red herring here. I just repro'd it binding key_sequence = "mouse-button-1"
Rseding seems to have thought in that thread it was a linked_game_control thing but it isn't.

I do believe there is a perhaps greater bug here than the original report would indicate.

Linked input control is a red herring. The bug is that `custom-input` events linked to `mouse-button-1` (and possibly other mouse buttons or bindings though I have not explicitly tested those), exhibit inconsistent behavior as to whether they trigger on press or release:

(1) In normal player view, the events trigger only once on-press.
(2) In remote view, the event will trigger on press AND release, IF the mouse cursor is not moved between the press and the release.
(3) In remote view, the event will trigger only once on-press if the mouse cursor IS moved between the press and the release.

If the intent is that custom inputs fire only on press, then scenario (2) is bugged. If the intent is that they fire on press and release, then (1) and (3) are bugged.

Remote view specifically send a simulated "mouse click" on mouse-release in remote view so time-short but literal-distance-long mouse drags work, but time-short but literal-distance-short drags do not get lost to tiny drag actions.

That is: if you click, move the mouse 2 pixels, and release the mouse button within a short period of time it pretends that the drag didn't happen and instead does the click action. This is where you see the second custom input coming from: the original click did not send a normal game event because it "started dragging" but then the short period logic decided that it wasn't an intended drag and instead re-sent the click as an action - sending the game event and second custom input.

This is all working correctly and goes back to my first statement: custom inputs are not tied to "did the game logic do its thing, or not do its thing" and are purely "did the event handling process a key-sequence that matches the custom inputs". In the map drag case it's true for both the initial mouse down and the 2nd simulated mouse down.

Why does the second "mouse click" event get sent if it determines it isn't a drag? The existence of that second event prevents any reliable detection of clicks on the map.

Per the statement "did the event handling process a key-sequence that matches the custom inputs", the input did not happen and the game is conditionally synthesizing an event, which makes it unreliable.

If remote view needs to perform the click action, that's fine, but allowing the synthetic event to also be handled by custom input handlers with no way to distinguish that it is synthetic becomes problematic. I think user expectation would be one of:
- There is no second event
- If there is a second event, it's reliably received (regardless of drag or no drag)
- If there is a synthetic event, it's flagged as such so that it can be handled as a synthetic event

Because I still don't know how to answer the question of "how do I reliably detect a click on the map?"

Edit: An alternative take here is, if the map needs to catch the first event to check if it's a drag or not, then the event needs to stop at the map until that decision is made. It's outside of the responsibility of the map to determine if an event is a click or a drag - it has already received a click, thus a click has happened as far as the rest of the program is concerned. It's choosing to determine whether it is or is not a click (which makes sense given the concept - click-and-drag primarily happens on the map so that's where it gets determined). Thus, it would make sense to send a synthetic event if the map determines that it is a click, but only if the rest of the program doesn't already know that. Ultimately the problem is that the map is making an input-domain decision and outputting input-domain events, and the rest of the program has no way to distinguish that they're not from the input system.

Perhaps the solution is to move the click-or-drag determination upstream and emit those events instead.

How does the "Add ping" tool know to react only on mouse up, and only when there was no map drag? How can a mod emulate that behavior?

Mods can’t emulate or react to fire on mouse up. Custom inputs only fire on mouse down.