Timeline for Nested Coroutine Movement is slugish
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 17, 2016 at 9:59 | comment | added | ThePhantomz | I used the yield return StartCoroutine(Patrol()); call on the case statement and I implemented a Debug Log to see how many times the AI hits the method to detect how many times the method gets called using it like so : Debug.Log (character.name + " is at the waypoint for the " + countWaypoint + "th time"); I see the AI hits the method atleast 3/4 times once he reaches the waypoint, is there a way to only hit it once? | |
| Sep 15, 2016 at 23:54 | comment | added | DMGregory♦ |
If you want to pause the FSM coroutine while running Patrol, you can do this without an extra boolean. Replace the line starting the Patrol with: yield return StartCoroutine(Patrol()); - this chains execution from FSM to Patrol, lets Patrol yield as it needs to, and resumes FSM where we left it once Patrol exits (ie. reaches the end or a yield break;)
|
|
| Sep 15, 2016 at 21:13 | comment | added | ThePhantomz | The Character Component is my ThirdPersonCharacter object (AI) which is included in the Unity Starter Package (The Ethan Character you get by default). The NavMeshAgent is also an Ethan Character - If you look at the code i use its NavMeshAgent to move the AI this way. IE i am moving around using Ethan, but my AI Character is also a clone of Ethan. The AI's agent and character use the ThirdPersonController Objects. | |
| Sep 15, 2016 at 21:05 | comment | added | Leo |
What kind of components are the agent and character? Try to add debug.Log() messages to figure out what is exactly executing during the sluggish movement. Maybe there is something external to this code affecting the gameObject movement.
|
|
| Sep 15, 2016 at 20:57 | comment | added | ThePhantomz | Yes, i am assuming this value to be the cause of the issue. He "reaches" / intersects the waypoint and then this twitching behaviour starts to happen until the AI leaves this 2 value radius / distance | |
| Sep 15, 2016 at 20:54 | comment | added | Leo | When it starts to be slugish, how close it is to the waypoint? Close enough to consider the agent reached it? (2 units from what I see in the code) | |
| Sep 15, 2016 at 20:49 | comment | added | ThePhantomz | Hi Leo. Tried your solution. It has the same effect as my previous comment. The AI moves to the waypoint normally as he should, once in a close vicinity of the waypoint the movement becomes twitchy again (The AI moves to the waypoint - Doenst walk, just gets slided onto the waypoint position), then the movement is twitchy again till he gets further away from the waypoint, then moves perfectly again. It seems the waypoint radius is an issue of some sort. | |
| Sep 15, 2016 at 20:40 | comment | added | ThePhantomz | Only saw your update now, let me try this 1st | |
| Sep 15, 2016 at 20:40 | comment | added | ThePhantomz | An update : I implemented the Bool for an IsMoving flag. This works to some extent. When the AI reaches the Waypoint, the movement is still stop, go, stop go behaviour. Once the AI moves a certain range away from the Waypoint, the AI moves as he should. Therefore we have contained the slugish behaviour to the waypoint, almost like we want it but not there yet. | |
| Sep 15, 2016 at 20:39 | history | edited | Leo | CC BY-SA 3.0 |
added 2224 characters in body
|
| Sep 15, 2016 at 20:29 | comment | added | Leo | You could add a bool to your class, that indicates if the FSM should be executed in the next cycle. Set it to false when calling the patrol coroutine, and set it to true when the patrol coroutine is over. I'll update the answer. | |
| Sep 15, 2016 at 20:20 | comment | added | ThePhantomz | Hi. Thanks, i noticed Gregory answered the same. Might you have a solution as to "Finishing the current patrol state by walking to the waypoint 1st" before firing off the FSM coroutine to move again. | |
| Sep 15, 2016 at 20:17 | history | answered | Leo | CC BY-SA 3.0 |