Page MenuHomeWildfire Games

Stop dodging arrows by spamclicking or patrol: Waste time turning
Needs ReviewPublic

Authored by bb on Jun 26 2020, 10:07 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Trac Tickets
#5106
Summary

When giving repeated movement orders or patrolling a short distance, one can dodge arrows (commonly called "dancing"). This patch makes the initial turn on a walk/patrol/walkandfight order cost time, and hence should stop dancing.
Compared to D2767, also repeated long walks do not dance anymore (one can only try repeated gather/attack commands maybe). Moreover giving repeated short walk commands in the same direction, is not nerfed much. However pulling out of a fight is made a little harder.

I would like to ask some players who know how to compile the game to test this and give some feedback. @Feldfeld @ValihrAnt @borg- please use this exe if you do not know how to compile the game (I think you also should apply the patch):

Test Plan

Note formation dance is still possible

Think whether it is worth to combine this with D2767 in some way

Diff Detail

Repository
rP 0 A.D. Public Repository
Branch
/ps/trunk
Lint
Lint OK
SeverityLocationCodeMessage
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:120ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:121ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:125ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:128ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:129ESLintBear (brace-rules/brace-on-same-line)ESLintBear (brace-rules/brace-on-same-line)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:129ESLintBear (no-else-return)ESLintBear (no-else-return)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:129ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:130ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:131ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:135ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:139ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:140ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:144ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:145ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:146ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:157ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:161ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:165ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:166ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:167ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:168ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:169ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:184ESLintBear (quote-props)ESLintBear (quote-props)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:188ESLintBear (object-curly-spacing)ESLintBear (object-curly-spacing)
Warningbinaries/data/mods/public/simulation/components/tests/test_UnitAI.js:188ESLintBear (quote-props)ESLintBear (quote-props)
Unit
No Unit Test Coverage
Build Status
Buildable 13264
Build 26512: Vulcan BuildJenkins
Build 26511: Vulcan Build (macOS)Jenkins
Build 26510: Vulcan Build (Windows)Jenkins
Build 26509: arc lint + arc unit

Event Timeline

bb created this revision.Jun 26 2020, 10:07 PM

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/2531/display/redirect

I have errors trying this patch

bb added a comment.Jun 26 2020, 10:24 PM

Did you rebuild the game?

I use svn on windows, did "apply patch". I think build is usually done automatically when updating so I don't know how to do it.

bb added a comment.Jun 26 2020, 10:28 PM

Yea, there is an autobuild in the repository, so everything that gets committed will be build. Not every patch will get a build. Though I will try to get a build for this revision from somewhere.

The interpolation of the rotation looks fairly bad (it's kind of jerk-y).

I think I prefer the slower movement, because this is introducing a lot more code (and unitMotion code too).

source/simulation2/components/CCmpUnitMotion.cpp
896–898

I'd rather you checked for angle here too.

965

?

bb edited the summary of this revision. (Show Details)Jul 1 2020, 11:26 PM
bb edited the test plan for this revision. (Show Details)
bb added a subscriber: ValihrAnt.
bb added a comment.Jul 1 2020, 11:29 PM

The interpolation of the rotation looks fairly bad (it's kind of jerk-y).

Yea I know, this can be improved fairly easily, however didn't want to waste time at it in case the idea doesn't work.

I think I prefer the slower movement, because this is introducing a lot more code (and unitMotion code too).

I find this a worthless argument, if this is better gameplay wise, we should take this. The amount of code is not really relevant then IMO. Though surely one could reduce the number of lines in this patch. But again, don't want to waste my time on that for now.

bb edited the summary of this revision. (Show Details)Jul 1 2020, 11:31 PM
bb added a subscriber: borg-.
borg- added a comment.Jul 2 2020, 12:49 AM

I will make tests

Feldfeld added a comment.EditedJul 2 2020, 10:28 AM

I think that this nerfs dance up to a reasonable point. Here are some details I got from my testing :
First note that when testing (for everyone that is interested in that) it's important to know the difference between singleplayer and multiplayer. In multiplayer, IIRC there is 1 turn every 0.5 seconds (which makes traditional dancing easier). In singleplayer, things are much smoother. When testing, you should go multiplayer -> Host game (even if no other human players will join you).

  • There is one variant of dancing i came up with trying to break this patch, however it works only in singleplayer, not in multiplayer (because somehow this requires perfect timing). It consists in clicking a resource and then repeatly hit the stop hotkey, then back to work hotkey, then stop hotkey again etc. Works a bit differently between attack stances and no attack stances. As i said it shouldn't be a problem but i say it just in case.
  • Even if formation dancing is not fixed this should be less of a problem (because it is easier to call out formation dancing) but some players that don't care could still do it i guess.
  • Other than that it is still possible to dance between resources (depending on the situation this can require good accuracy from the player though) but despite that it's still good to not waste time turning going for ressources / buildings for the gameplay I think. That also is made a bit easier to call out, and impossible to do for heroes, very situational for cavalry. Dancing with infantry citizen soldiers is harder due to low speed and HP. (But in the end still possible).

Now for the gameplay, well obviously it's a bit annoying to have your units waste time turning. I don't know to which extent, and the feeling of other players would help to know that. Typically, when you order units (and want to be efficient) you would click fast somewhere in the direction you want to go and then give the actual order. That is penalized here which could encourage players to either give the actual order directly (slow) or place a foundation in the direction you want to go (fast due to hotkeys), both situations being not ideal for gameplay, but maybe that won't actually turn out to be a problem depending how players adapt.
I think it's good that it makes pulling out of fights harder. However that can be nerf to cavalry rushing in general which would be a thing to look out for.
Note that repeatedly clicking in a same location makes the unit almost not move at all in singleplayer, but this looks fine in multiplayer.
A faster turning rate could possibly be tried.

Here is a small video that shows a bit how the patch looks like and shows dancing between resources (done in 'multiplayer' type of game which is probably easier than singleplayer, mind that if you want to test yourself)
Note that in team games with larger map sizes the wood lines will be thicker

After quick playtest I don't think it will have much impact on gameplay for everything not related to combat. For combat (raiding in particular) there might be a need for multiplayer testgames to get a better feel of it.

How hard would it be to implement proper turning from here? I mean one always needs turn time to change the facing. I tested some by removing the if (m_RotateTime) to make entities rotate whenever performing a move and it wasn't too bad IMHO.

bb added a comment.Jul 6 2020, 2:31 PM

Thanks for the extensive testing @Feldfeld, I will think about your comments and see if some things can be fixed somehow (no promises here). Regarding formation dance issue: I know this patch does not fix it, but (correct me if I am wrong) this dance can only be achieved with a patrol command. So that is relatively easy to fix, without major gameplay influence one can simply disallow patrol commands on those short distances).
If you happen to have the replay from that video around, I did be interested (saves me recreating it ;) )

How hard would it be to implement proper turning from here? I mean one always needs turn time to change the facing. I tested some by removing the if (m_RotateTime) to make entities rotate whenever performing a move and it wasn't too bad IMHO.

removing m_RotateTime should do turning at/during every move. I have wrote this patch a while ago like that, but when testing big masses of units, it became total hell.

In D2837#122927, @bb wrote:

it became total hell.

Peformance-wise or behaviour-wise?

I would still vote largely in favour of the other solution + faster projectile.
I have two main concerns:

  • First is : how clunky will this feel long-term?

As said by feldfeld:

well obviously it's a bit annoying to have your units waste time turning. I don't know to which extent, and the feeling of other players would help to know that

I fear that this might be the kind of things that players don't understand, since they aren't aware of dancing by default, and thus just seems like an un-necessary annoyance that cripples the game.

  • Second concern: it will lead to micro to circumvent it I think, such as clicking on a resources near where you want to go to avoid the turning penalty.

I fear that this might be the kind of things that players don't understand, since they aren't aware of dancing by default, and thus just seems like an un-necessary annoyance that cripples the game.

  • Second concern: it will lead to micro to circumvent it I think, such as clicking on a resources near where you want to go to avoid the turning penalty.

(Then just always let it take time to turn ^^ )

bb added a comment.Jul 23 2020, 3:58 PM

I would still vote largely in favour of the other solution + faster projectile.
I have two main concerns:

  • First is : how clunky will this feel long-term?

Not sure what you mean here.

As said by feldfeld:

well obviously it's a bit annoying to have your units waste time turning. I don't know to which extent, and the feeling of other players would help to know that

I fear that this might be the kind of things that players don't understand, since they aren't aware of dancing by default, and thus just seems like an un-necessary annoyance that cripples the game.

True, new players won't know about dancing and old players will forget. However is it that weird that a unit takes time turning? And since it happens on only a few commands, and just once per command, it becomes quite unnoticable, since there is command lag too.

  • Second concern: it will lead to micro to circumvent it I think, such as clicking on a resources near where you want to go to avoid the turning penalty.

This concern applies even harder to D2767, since there one doesn't even need to click a resource, but just walk commands will do. With this patch one 1) needs to have a resource near (or try messing with foundations or whatnot) 2) 1 wrong click and you are doomed 3) doesn't work with heroes and champs.

In D2837#122927, @bb wrote:

it became total hell.

Peformance-wise or behaviour-wise?

yes, behaviour-wise

In D2837#125598, @bb wrote:
  • First is : how clunky will this feel long-term?

Not sure what you mean here.

Basically, how "technical debt" is this issue? Is this something that we actually would want to implement? Or just a necessary annoyance?
I guess it's kind of the same point, but more on the product/dev side.

I fear that this might be the kind of things that players don't understand, since they aren't aware of dancing by default, and thus just seems like an un-necessary annoyance that cripples the game.

True, new players won't know about dancing and old players will forget. However is it that weird that a unit takes time turning? And since it happens on only a few commands, and just once per command, it becomes quite unnoticable, since there is command lag too.

The trick is that I don't think we can answer this without actually playing with it for a while. But yes, I can imagine that this would be weird and annoying.

  • Second concern: it will lead to micro to circumvent it I think, such as clicking on a resources near where you want to go to avoid the turning penalty.

This concern applies even harder to D2767, since there one doesn't even need to click a resource, but just walk commands will do. With this patch one 1) needs to have a resource near (or try messing with foundations or whatnot) 2) 1 wrong click and you are doomed 3) doesn't work with heroes and champs.

True, which is why I still much prefer to speed up projectiles.

bb updated this revision to Diff 12878.Jul 23 2020, 9:08 PM

Some cleanup

Owners added a subscriber: Restricted Owners Package.Jul 23 2020, 9:08 PM

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/2765/display/redirect

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/vs2015-differential/2232/display/redirect

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/macos-differential/1133/display/redirect

bb added a comment.Jul 23 2020, 9:21 PM
In D2837#125598, @bb wrote:
  • First is : how clunky will this feel long-term?

Not sure what you mean here.

Basically, how "technical debt" is this issue? Is this something that we actually would want to implement? Or just a necessary annoyance?
I guess it's kind of the same point, but more on the product/dev side.

TBH I find the diff rather simple: some toggle function to be added where required and 30 odd lines of handling code. And in case one ever wants to do proper ship turning one will need this kind of code too.

  • Second concern: it will lead to micro to circumvent it I think, such as clicking on a resources near where you want to go to avoid the turning penalty.

This concern applies even harder to D2767, since there one doesn't even need to click a resource, but just walk commands will do. With this patch one 1) needs to have a resource near (or try messing with foundations or whatnot) 2) 1 wrong click and you are doomed 3) doesn't work with heroes and champs.

True, which is why I still much prefer to speed up projectiles.

Speeding up projectiles will only hide the issue, not fix the root cause. Also I think players will earlier notice the fact arrows are unrealistically quick, than some extra command lag.

source/simulation2/components/CCmpUnitMotion.cpp
908–909

@Freagarach if one want turning on every move, one should remove this line and remove the m_RotateTime check

bb updated this revision to Diff 12879.Jul 23 2020, 9:25 PM
bb edited the summary of this revision. (Show Details)

semi

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/2766/display/redirect

Freagarach added inline comments.Jul 24 2020, 7:38 AM
source/simulation2/components/CCmpUnitMotion.cpp
908–909

Yeah, I had already tried it, and it was really not bad IMHO ^^
I can try again with a larger amount of entities.

wraitii added a comment.EditedJul 25 2020, 6:11 PM

Overall, I am opposed to the direction of this diff. I would much prefer a combination of D2767 and slightly faster arrows (1.5 to 2x faster). We could also slow formations down.
If the "jittering" of the rotation was fixed, I would be open to having it for cavalry, perhaps, and possibly units-in-formation.

I wish to suggest another alternative for the patrol case: make units stand at the end of their patrol for some seconds. This fixes the issue for patrolling completely.


In D2837#125640, @bb wrote:

Speeding up projectiles will only hide the issue, not fix the root cause.

"Wasting time turning" is hardly much better in that case. The issue is that our units aren't clever enough to get closer or fire somewhat randomly in the middle of the patrol, which would land occasional hits.

In D2837#125640, @bb wrote:

Also I think players will earlier notice the fact arrows are unrealistically quick, than some extra command lag.

I disagree:

  • I think it looks dumb, so that's at least one player that noticed this.
  • It's also unrealistic for humans to take time turning around. Cavalry - I'd be open to discussing it. Units-in-formation likewise.
  • Finally, I'm not sure our arrows aren't unrealistically slow right now, further I think gameplay trumps accuracy in that respects.

I also have units getting stuck in a replay:

  • It's also unrealistic for humans to take time turning around.

Uhm not really ^^ Try it I would say ;) It won't take as much time as with this diff in the game, but still, it takes two or three steps to turn around ;) Just the stopping to change direction is strange, but that is because our UnitMotion can't say "Oh, you want to go that way now, lets circle towards that." instead of stopping and choosing a new direction.

source/simulation2/components/CCmpUnitMotion.cpp
232

Notice CCmpPosition already has a turn rate.

but still, it takes two or three steps to turn around ;)

I mean yeah, but it doesn't really affect my movement speed, as I can turn while moving. Try it, as you say :)
Turning "in place" does take a little time but that's not really relevant here.

Just the stopping to change direction is strange, but that is because our UnitMotion can't say "Oh, you want to go that way now, lets circle towards that." instead of stopping and choosing a new direction.

Disagreed, our current system reflects what I do if I suddenly want to go in my back -> I just start moving towards that and rotate "on-the-fly".

We discussed a third way with @bb which was simply adding some acceleration to reach max speed, and that might be my preferred solution off-hand.

Angen added a subscriber: Angen.Aug 25 2020, 11:30 AM

We discussed a third way with @bb which was simply adding some acceleration to reach max speed, and that might be my preferred solution off-hand.

+1
Still there is the issue of calling our StopMoving, because units will have to accelerate again, what makes smaller issue with queued walking orders, but other than that this ways seems reasonable enough.
One issue I have noticed while trying accelerating by terrain slope, ranged attacks predictions will be off a bit for units in acc state, but might be ok-ish because spread, that ranged attacks have anyway.

bb updated this revision to Diff 13558.EditedSep 26 2020, 8:10 PM

Reuse the cmpPosition's turnRate, let formations really turn. Fixes jittering

bb updated this revision to Diff 13559.Sep 26 2020, 8:13 PM

Don't apply patches on patches bb, or at least work on 1 thing at the same time...

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/vs2015-differential/2696/display/redirect

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/vs2015-differential/2697/display/redirect

Build failure - The Moirai have given mortals hearts that can endure.

builderr-debug-macos.txt
../../../source/simulation2/scripting/JSInterface_Simulation.cpp:155:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        CFixedVector2D(-halfSize.X, -halfSize.Y),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
../../../source/third_party/fmt/format.cpp:145:7: warning: '_POSIX_C_SOURCE' is not defined, evaluates to 0 [-Wundef]
#if ((_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && !_GNU_SOURCE) || (defined(__ANDROID__) && __ANDROID__)
      ^
../../../source/third_party/fmt/format.cpp:145:37: warning: '_XOPEN_SOURCE' is not defined, evaluates to 0 [-Wundef]
#if ((_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && !_GNU_SOURCE) || (defined(__ANDROID__) && __ANDROID__)
                                    ^
2 warnings generated.
In file included from ../../../source/graphics/tests/test_Camera.cpp:17:
/Users/wfg/Jenkins/workspace/macos-differential/source/graphics/tests/test_Camera.h:168:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        CVector3D(-101.0f, -101.0f, 101.0f),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
In file included from ../../../source/simulation2/tests/test_SerializeTemplates.cpp:17:
/Users/wfg/Jenkins/workspace/macos-differential/source/simulation2/tests/test_SerializeTemplates.h:39:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        3, 0, 1, 4, 1, 5
                        ^~~~~~~~~~~~~~~~
                        {               }
1 warning generated.

Link to build: https://jenkins.wildfiregames.com/job/macos-differential/1597/display/redirect

Build failure - The Moirai have given mortals hearts that can endure.

builderr-debug-macos.txt
../../../source/simulation2/scripting/JSInterface_Simulation.cpp:155:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        CFixedVector2D(-halfSize.X, -halfSize.Y),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
../../../source/third_party/fmt/format.cpp:145:7: warning: '_POSIX_C_SOURCE' is not defined, evaluates to 0 [-Wundef]
#if ((_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && !_GNU_SOURCE) || (defined(__ANDROID__) && __ANDROID__)
      ^
../../../source/third_party/fmt/format.cpp:145:37: warning: '_XOPEN_SOURCE' is not defined, evaluates to 0 [-Wundef]
#if ((_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && !_GNU_SOURCE) || (defined(__ANDROID__) && __ANDROID__)
                                    ^
2 warnings generated.
In file included from ../../../source/graphics/tests/test_Camera.cpp:17:
/Users/wfg/Jenkins/workspace/macos-differential/source/graphics/tests/test_Camera.h:168:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        CVector3D(-101.0f, -101.0f, 101.0f),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
In file included from ../../../source/simulation2/tests/test_SerializeTemplates.cpp:17:
/Users/wfg/Jenkins/workspace/macos-differential/source/simulation2/tests/test_SerializeTemplates.h:39:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        3, 0, 1, 4, 1, 5
                        ^~~~~~~~~~~~~~~~
                        {               }
1 warning generated.

Link to build: https://jenkins.wildfiregames.com/job/macos-differential/1598/display/redirect

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/3249/display/redirect

Build failure - The Moirai have given mortals hearts that can endure.

builderr-debug-gcc6.txt
<command-line>:0:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [obj/simulation2_Debug/CCmpAIManager.o] Error 1
make: *** [simulation2] Error 2

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/3250/display/redirect

bb edited the test plan for this revision. (Show Details)Sep 27 2020, 12:44 AM
bb edited the test plan for this revision. (Show Details)
bb updated this revision to Diff 13563.Sep 27 2020, 3:25 PM

fix test

Successful build - Chance fights ever on the side of the prudent.

builderr-debug-macos.txt
../../../source/simulation2/scripting/JSInterface_Simulation.cpp:155:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        CFixedVector2D(-halfSize.X, -halfSize.Y),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
builderr-release-macos.txt
../../../source/simulation2/scripting/JSInterface_Simulation.cpp:155:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        CFixedVector2D(-halfSize.X, -halfSize.Y),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libsimulation2.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libgraphics.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libatlas.a(precompiled.o) has no symbols

Link to build: https://jenkins.wildfiregames.com/job/macos-differential/1600/display/redirect

bb added inline comments.Wed, Oct 28, 10:43 PM
source/simulation2/components/CCmpUnitMotion.cpp
1010

Alarm bells should go off when using floats to affect the simstate => the position turnrate needs to be fixed

I was wondering whether the turn rate needs to be in cmpPosition at all when we would do all rotation in cmpUnitMotion?

bb added a comment.Thu, Oct 29, 9:35 AM

Not all rotation is done in unitMotion, only on the first turn, when m_TurnTime is enabled