MouseQuery interacts with automaterial in a weird way: up one zlevel occasionally on mouse use.

[Rumrusher]

Ok so popping in here to report that using the mouse while constructing with boxes enable in fort mode will cause the screen to shift up one z level. You can recreate this if you set it to planning mode if you don't have enough resources to rapidly place down a bunch of walls. It might also be from the mouse also panning around the map interacting with auto material. Filing this issue because someone else who heavily uses mouse brushed up on this problem and I figured I better report this.

notice this in r4 of dfhack but the person who found it out first was using PyLNP so it might be more recent.

GIF:

[lethosor]

Can't reproduce in 0.47.05-r6-118-gce7bc4cd, unfortunately

Edit: oh, I can, if I click really fast (a triple-click while moving the mouse can generally reproduce it ~50% of the time for me)

[myk002]

This can be reproduced with just mousequery. Looking into it.

[lethosor]

Are you doing anything in particular? I'm clicking in a circle ~5x a second and can't seem to reproduce it with mousequery alone (starting from the main fortress mode view).

[myk002]

I just tracked it down. I believe this is caused by inconsistent return values for Gui::getDepthAt(). mousequery calls it twice in quick succession, with the second call intended to undo the shift from the first call. if the return values from the two calls don't match, the "current" z level will be off.

I'm reproducing quite readily with TWBT and multilevel 2

[myk002]

I don't know what is causing this inconsistency, but with the short expected lifespan of TWBT, I'm not keen on diving too deeply. I plan to fix this by just calling getDepthAt() once and caching the return value. As long as we're self-consistent, this issue will disappear.

[myk002]

once fixing this repro case, I'll go back and test with automaterial, it is possible that there is a second cause for this problem, too.

[myk002]

(starting from the main fortress mode view).

It's easier to repro if you start clicking at least 1 z-level above ground

[lethosor]

Ah, I am not using TWBT, so I suspect the automaterial-related issue has a different cause.

[myk002]

ok, yes, different cause, same symptom. tracking down the other cause now.

[myk002]

I found a solution, though the root cause eludes me for now. Automaterial ignores input for a certain number of ticks after a box selection is complete. If the mouse is clicked on a different tile during that time window, then the z-level jumps up by one.

Automaterial ignores input for far longer than it needs to, though, and reducing the ignore interval to one tick solves the issue. Again, the actual root cause is not apparent to me without digging deeper, but I successfully cannot reproduce the issue after changing the ignore interval.