koobas.hobune.stream
How does Time.timeScale impact Unity's NavMeshAgent?
Hey folks...I have a game in build right now wherein I'm using Unity Pro's navigation system. It's an asynchronous turn-based game, so when you play your turn, part of that process is viewing your opponent's previous turn.
Since most folks are an impatient lot, I wanted to give them the ability to "fast forward" the replay of their opponent's turn. The replay is not in the form of a "video" per se. In order to make effective use of storage and bandwidth limitations, I'm mainly just capturing key events during the opponent's turn and replaying those events on the current player's system. But what I'm finding is that if I increase Time.timeScale to make the game go faster, my navigation mesh agents get all tangled up. The get stuck rounding corners, they lose track of their destination and just end up staying still, and sometimes they choose a different navigation path than they would have chosen when Time.timeScale was set to 1.0.
I don't think there's anything that I can do to regulate this or "fix it." The higher I set the time scale, the worse it gets. I can somewhat comfortably fast forward to 1.25 times the original speed...but anything higher than that and the navigation becomes so far removed from the original data that it can't be considered a replay at all.
Is there anything I should tweak in the navigation system when modifying the time scale?
today's sophisticated question !
I do not know the answer to the specific question on the Nav $$anonymous$$esh system.
ONE THOUGHT: when you do replays like that. For example "ghost replays" in a race game. I would very strongly urge you to NOT alter the physics time. It's just not the way to go. Simply, alter your program$$anonymous$$g - it will be a matter of changing just the one variable so the playback is faster.
That is definitely a sound idea.
ANOTHER THOUGHT: you know how you say you only grab some key info, not too much, and interpolate. Consider, you should just grab more. It costs nothing to send that little data. It's always better to get more.
@Fattie...thanks for the response. I'd considered modifying my own code to artificially scale the time...but this also comes with the added requirement to scale the movement speed of the Nav$$anonymous$$eshAgent. So if I double the time scale in my code...then I must also double the movement speed in the agent...unfortunately...this results in even worse behavior than indicated in my original post.
When I edit the speed of the Nav$$anonymous$$eshAgent...the character moves in bursts...speeding to the next intersection or toward the next curve...then slam$$anonymous$$g into the wall and recalculating his path. I've tried modifying the acceleration value of the agent...which helps...but I can't find a "sweet spot" that works well.
I didn't think the time scale would impact the nav agent at all, to be honest. By all accounts that I've read...it seems to be Unity's recommended method of "manipulating game time." But clearly, it has an impact even on the path decisions that the AI makes.
I suspect that maybe there's some tweak of some value that I can adjust to take this into account.
Any more brainstorms of ideas would be greatly appreciated. Thanks again!
Had the same Problem. Fixed it with workaround.
void Update()
{
if (Time.timeScale > 1.0f)
{
CheckSteeringTargetPosition();
}
}
protected float _distanceStearingTarget;
protected void CheckSteeringTargetPosition()
{
float distanceST = Vector3.Distance(navMeshAgent.transform.position, navMeshAgent.steeringTarget);
if (distanceST <= 15) //distance to next edge on nav mesh
{
if (_distanceStearingTarget < distanceST)
{
navMeshAgent.transform.position = navMeshAgent.steeringTarget;
}
else
{
_distanceStearingTarget = distanceST;
}
}
}
Wow, I thought this thread was dead. :)
Thanks for the workaround advice. I will try this in my build and see if it yields the results I'm looking for.
Out of curiosity, you have the literal "15" in your code sample on line 14. Is this a value that might need to be tweaked, or is 15 somehow a special value with respect to perfor$$anonymous$$g this adjustment?
Thanks again!
You can change this value if you want. Had the same problem and searched for it. Found no answer. So i tried to find it out.
The distance value is a check for the navmesh agent how far it is away from next steering target. Every update the nav mesh agent gets a Time.deltaTime "push" to the next steering target position. It depends on your time scale factor. In my project i have streets with 10 - 15 width.
if the nav mesh agent is in range of 15 it saves the value in _distanceS$$anonymous$$ringTarget. Next update it checks if the _distanceS$$anonymous$$ringTarget value is smaler than current distanceST. So my workaround sets the position of the agent to the nav$$anonymous$$eshAgent.steeringTarget position when it looses his right way and jumps over next target.
If you don´t have some obstacles or agents in navmesh agents way you can also RE$$anonymous$$OVE the distance <= 15 check ?!
In this code snippet you need to get the Nav$$anonymous$$eshAgent component at start before it updates.
e.g.:
Nav$$anonymous$$eshAgent nav$$anonymous$$eshAgent;
void Start() { nav$$anonymous$$eshAgent = GetComponent(); }
This is awesome...thanks for your help. I am working on other areas of my project right now, so I put this problem on the shelf to be resolved later.
When I get back to it...I will post the results here, but so far, this is the first real workaround that anyone has been able to suggest.
Thanks! --RB
I'm having the same problem and I can't find a value that fixes it. In my case actors are always slower than when the timescale is set to 1.
