Description
Details
- Committed
bb Dec 17 2020, 11:54 PM - Reviewer
- wraitii
- Differential Revision
- D2837: Stop dodging arrows by spamclicking or patrol: Waste time turning
- Parents
- rP24414: Using same value for unit and terrain ambient colors for scenarios and tutorial…
- Branches
- Unknown
- Tags
- Build Status
Buildable 14452 Build 30635: Trigger Windows Autobuild Build 30634: Post-Commit Build Jenkins Build 30633: Post-Commit Build (macOS) Jenkins
Event Timeline
| /ps/trunk/source/simulation2/components/CCmpUnitMotion.cpp | ||
|---|---|---|
| 1018 | The fact that it breaks kind of breaks L910 that resets FailedPathComputation to 0, because we can't be obstructed while turning, but it's also not really an indicator that the unit managed to move. It's theoretically possible to get units stuck in a "vibrato" motion that never ends because of this, though I've only reproduced it with D3203 so far. | |
Is it possible to reduce this "delay" a little? Cavalry mainly seems to have been very slow.
Not sure what you mean with "delay". Cavalry indeed turns slower than infantry, which seems very realistic to me.
Shift Clicking will give several orders, so if you shift click on closeby locations, your unit will move between these locations, and this indeed takes some time. But that isn't changed by this patch...
Shift Clicking will give several orders, so if you shift click on closeby locations, your unit will move between these locations, and this indeed takes some time. But that isn't changed by this patch...
I'm not talking about shift + click. Slowness occurs with normal clicks repeatedly anywhere on the map, units reduce movement speed in half.
hmm ok, see the issue: clickspam around a unit to another side of an obstruction. The problem here is that we don't know the actual path yet when we start to move. For the first turn we just try to move in the correct direcion, which can be wrong. Hence we try turning there too, which wastes some time, and thus we move slower/not at all.
Making a ticket https://trac.wildfiregames.com/ticket/5896.
Me and borg had a quick test game on r24446 and encountered some issues. The biggest one was with formation and unit rotation. In the fight starting at min 5 the archers entered a formation. Whenever a soldier from the formation was killed the archers went to regroup and due to the rotation often lost out on multiple seconds of attacking. Over a fight this adds up to a huge amount and was probably the deciding factor in him losing that battle.
Secondly, I had an issue in get my wardog unstuck from between the berry gatherers. The reason is probably what borg mentioned earlier that spam clicking doesn't work and considering that, at least in my case, the method for getting units unstuck is to spam click small distances ahead I was unable to free it. So I had to move my berry gatherers away for a second.
In general, we both came to the conclusion that the current amount of rotation feels too much and too clunky. I think a bit of rotation is good, but it needs to not interfere with gameplay too much and keep it feeling smooth. Now whether that is achievable without leaving dancing alive I don't know but it could also be tried in combination with the units have some bit of 'aimbot'.
In Second game, my dog cant attack valirhant Priest.
With rotation, game does not keep up with the speed of reasoning. when I click to attack, unit still comming back, it is impossible to attack and run.
I think MP long turns make the problem worse than in SP. I would raise the turn rate of infantry from 6 to 10.
Yeah formations are failing on member death. This patch only highlights the issue, see D3236. We should fix that.
The spamclick issue, found by borg is fundamentally different compared to any slowdown on shift spamclicking. I guess the latter can be somewhat reduced by the acceleration patch.
| /ps/trunk/binaries/data/mods/public/simulation/components/Formation.js | ||
|---|---|---|
| 865 | parameter is totally redundant and confusing now | |