HomeWildfire Games

Wheel-adjustable batch size
Concern RaisedrP21497

Description

Wheel-adjustable batch size

Reviewed by: bb
Fixes #4767
Differential Revision: https://code.wildfiregames.com/D1034

Details

Auditors
elexis
Committed
ImarokMar 10 2018, 9:15 PM
Reviewer
bb
Differential Revision
D1034: Wheel-adjustable batch size
Parents
rP21496: properly indent json data in Multiplayer_demo
Branches
Unknown
Tags
Unknown
Build Status
Buildable 5472
Build 9247: Post-Commit BuildJenkins

Event Timeline

(03:28:40) fpre: ctrl+shift+scroll batch training size to much possible by resources stock?
(03:28:57) fpre: always get beyond possible to build
(03:29:11) fpre: to train
(03:29:30) fpre: or shortcut batch to max possible train units
(03:29:35) fpre: by res stock

elexis added a subscriber: elexis.Mar 13 2018, 3:48 AM
elexis added inline comments.
/ps/trunk/binaries/data/mods/public/gui/session/selection_panels.js
1026

Now the button is enabled / clickable even if one doesnt have enough resources.
In theory it shouldn't.

(Theres also the other issue that the rightclick should still be possible even if left click is disabled, especially in observermode. But that's a separate issue.)

Imarok added inline comments.Mar 13 2018, 10:21 PM
/ps/trunk/binaries/data/mods/public/gui/session/selection_panels.js
1026

Must be that way, cause we can't scroll back as soon as we reached a forbidden value by clicking...

elexis added inline comments.Mar 13 2018, 10:23 PM
/ps/trunk/binaries/data/mods/public/gui/session/selection_panels.js
1026

Unless we save a boolean that remembers if the mousewheel thing is active or if its the first click?
(If lucky, the boolean could be avoided somehow by saving the state in the GUI object.)

elexis raised a concern with this commit.EditedApr 20 2018, 1:13 PM

When changing the batchtrainsize in the options dialog in a running game, it is not reloaded anymore (until the user uses the moueswheel), while that was the case in alpha 22.
Also incrasing the batchsize should not be possible if one can't afford that (or at least the current resources).

You might want to add an options.json callback entry.

This commit now has outstanding concerns.Apr 20 2018, 1:13 PM

A second concern is that the display of the batch count is only updated once per turn, whereas the value is updated instantly.
In mulitplayer this means at least 0.5 seconds (up to to multiple seconds in a laggy game) delay until the user sees the currently selected batchcount!

A second concern is that the display of the batch count is only updated once per turn, whereas the value is updated instantly.
In mulitplayer this means at least 0.5 seconds (up to to multiple seconds in a laggy game) delay until the user sees the currently selected batchcount!

Wasn't that also the case before?

Dunno, figuring out more details would imply coming up with the fix and then doing archeology on top of it.

I just mentioned that here because it was the issue that prevented me from using this feature, because when I wanted to train 18 females with the mousewheel and then train 3 men afterwards, I had to wait 15 turns (7.5 seconds) to reduce it back to 3 with the mousewheel.

There's probably just a missing update call in OnTrainMouseWheel (which would mean that if it was an issue with the click based batchtraining, then it was an issue in both a previous commit and in this commit?).

Also incrasing the batchsize should not be possible if one can't afford that (or at least the current resources).

That would require a quite big rewrite...
Also what about that use case:
User has batch size 9 and batch count 3. They increase the batch size to 10, but have too less resources for that. So they decrease the batch count.
This won't be possible anymore. (With sane numbers this might make sense, especially cause you then might have the correct batch size set for the next unit production.) (To be honest, I'm not sure, if that is an applicable usecase ^^)

elexis added inline comments.Jan 13 2019, 4:39 PM
/ps/trunk/binaries/data/mods/public/gui/options/options.json
418

Perhaps Ratio <-> Sensitivity, as one might expect that using high values will result in a high number of units trained per scroll

/ps/trunk/binaries/data/mods/public/gui/session/selection_panels_right/training_panel.xml
15

I didn't read D1034 again, so maybe there was a reason;

But couldn't the hardcoding be removed by introducing a hotkey that is (only by default) assigned to the mousewheel?

KeyName.cpp contains

	{ MOUSE_WHEELUP, "Mouse Wheel Up", "WheelUp" },
	{ MOUSE_WHEELDOWN, "Mouse Wheel Down", "WheelDown" },

It's already used for a hotkey:

zoom.wheel.in = WheelUp                       ; Zoom camera in (stepped control)
zoom.wheel.out = WheelDown                    ; Zoom camera out (stepped control)

allowing people with input devices other than the bidirectional mousewheel, for instance people with 2 mousewheels, a mousewheel with 2 directions, people who want to assign it to a key on the keyboard, touchpads, trackballs, joysticks, ...

Imarok marked 2 inline comments as done.Jan 13 2019, 5:51 PM
Imarok added inline comments.
/ps/trunk/binaries/data/mods/public/gui/options/options.json
418

If we'd call that sensitivity, that would mean a high value causes much change per scroll. But it is the other way around.

/ps/trunk/binaries/data/mods/public/gui/session/selection_panels_right/training_panel.xml
15

Had to read D1304 again:
https://code.wildfiregames.com/D1034#53950
tldr: it will always be triggered, even if the button is not hovered.