Page 1 of 1

[1.1.61] Zooming in/out breaks at higher game speeds

Posted: Mon Jul 25, 2022 6:30 pm
by Honktown
(All testing in single-player, I use page-up / page-down to zoom)
Zoom controls stop working when zoom reaches 1 at higher game speeds. While the autosave gui is open, the controls work again, allowing "freedom" from the stuck zoom, but then it will get stuck again if it becomes 1.

Reproduction:

Code: Select all

/c game.speed = 5.15243092666500057674738854985
/c game.speed = 5.15243092666500146492580824997
The upper speed allows full zoom in/out. The second speed causes zoom out to get stuck at 1 while zooming from very close to further out [edit: while still allowing zoom closer than 1, limiting zoom range to 1 and nearer].

Code: Select all

/c game.speed = 5.20447568350003564319194993004
/c game.speed = 5.20447568350003653137036963017
The first speed is still within the previous case, the second speed causes zooming in and out to stop working, getting stuck at zoom 1. If 2x zoom is pressed, it works, allowing zooming in/out a little bit until zoom out reaches 1, and while the zoom isn't stuck, reset zoom works (when zoom is at 1, it is not a surprise resetting zoom appears to do nothing).

Re: [1.1.61] Zooming in/out breaks at higher game speeds

Posted: Thu Sep 08, 2022 8:30 am
by boskid
I see where this behavior comes from: there is a piece of logic which snaps the zoom to value of 1 when condition abs(zoom - 1) < 0.01 is true. Since zoom uses geometric series, zoom in and zoom out will reach this condition during different coefficient values which as you already noticed are affected by the game speed when using the keyboard smooth zooming. When a speed is high enough and the zoom has value of 1, next zoom has a value that also satisfies this condition (from 0.99 to 1.01) which makes it snap back to value of 1. This zoom behavior is already fixed for 1.2.

Re: [1.1.61] Zooming in/out breaks at higher game speeds

Posted: Thu Sep 08, 2022 10:38 am
by boskid
Ok there was a decision to update this behavior in 1.1.x so it is now fixed for 1.1.69.