I am using the FollowerEntity script to create a game that has combat similar to Starcraft 2. Is it possible to create this behavior where the unit rotates to face the target without needing to move more? Right now I get functional rotation behavior with .SetDestination(), but not sure how to do it while the unit is already at it’s destination. Do I just move the object to it’s current position but with a new facingDirection? Or will I need to disable rotation on FollowerEntity and do this rotation myself in a custom script?
I am setting isStopped and locked to true whenever a unit stops to attack. I am doing this so that units can’t be pushed around by local avoidance logic (unlike when they are in an idle state). This makes it so the other units have to walk around them.
I was able to get a unit that’s attacking to continue rotating towards the target by calling .SetDestination(unit.position, directionToTarget) every frame. But to do this I had to set isStopped and locked to false. This unfortunately makes it possible for ally and enemy units to push the attacking unit out of the way.
I tried setting the priority of attacking units to 1.0 (moving units are 0.5, and idle are 0.0), and this prevented them from being pushed out of the way, but surprisingly the moving units (set to 0.5) are not going around them like they did when I have isStopped and locked to true. They just get caught behind the shooting units and can’t go around. I expected that having a priority higher would make other units go around them. Is that not the case?
Here’s a comparison video:
isStopped / locked = true (enemy unit doesn’t rotate, but units correctly go around each other when one is attacking
isStopped / locked = false + Rotation (shooting units rotate correctly, but moving units don’t correctly go around them)
Hmmm, so we’re trying to get the grey attackers to crowd properly around like the first video, but with the red unit rotating as it does in the second video. Let me know if that’s correct and that I’m looking at the right issue.
I spent a bit of time in Unity just now playing with the rotation property with isStopped and locked, but I’ll have to play with it more in the morning (it’s late haha). I’ll see what I can learn then
yes that is correct! They are sharing the same code logic, so fixing the rotation issue for the red unit introduced a bug in the grey unit. Thanks so much for the help!
So I did some testing using rotation and I was actually able to get it to manually set the rotation, which would probably work well in your case- lock and stop the unit and set it’s rotation manually when it’s stopped. However when I change the rotation, it seems to instantly snap back ignoring my changes. This seems related to another post on the forum so I’m wondering if it’s indeed a bug. If I set rotation in LateUpdate it actually works fine, but not in Update, or in any methods I make myself with just normal execution timing.
So for now it looks like setting the rotation property in LateUpdate is a good option if you like that, and I’ll tag @aron_granberg in this to see what he thinks.
