Unexpected behavior

Hello! I recently finished the Realm Rush section of the course but I realized I had missed the line “pathfinder.NotifyReceivers()” in the Tile Class.

After adding this line I am getting some unexpected behavior. In some instances the enabled enemy will still follow the path but without smoothly lerping from point to point. In others, I have enemies “Ping-Ponging” between the start point and the next element in their path. Here are some videos showing these behaviors.

here is the project on github in case anyone would like to take a look at my code.
https://github.com/NMcKinnis/Project-Realm-Rush.

1 Like

Hi,

Have you already compared your code to the Lecture Project Changes which can be found in the Resources of this lecture?

Actually, the enemies are not supposed to move back to the starting point. Their individual starting point for their new path is supposed to be their current waypoint. There might be a problem in your code.

Have you already tried to add Debug.Logs to your code to see what is going on during runtime?

1 Like

I have compared it but I didn’t see the problem. Do you have suggestions on where/what to log to help find the issue?

From what I understood after watching the first video, the problem starts when you place something on the enemies’ path. Given your code calculates a new path, the new path might be wrong. Since the scene is fairly complex (= many waypoints), debugging the path might be a bit exhausting. For now, figure out how many elements the path list contains before and after the recalculation.

If the path suddenly contains a very high number of elements, it might be that it has not been cleared. In that case, check your code again to figure out if the code does what you expect it to do. The behaviour of the enemies looks as if their path got recreated over and over again, maybe even based on the wrong coordinates. Debug.Logs can help you understand which and how often code-blocks get executed during runtime.

If the issue still remains, create a new scene with a much smaller grid and try to recreate the problem. If you were able to recreate it, you could log the coordinates of the single path elements into your console and manually check if they form the expected path or if there is chaos. You don’t want to check hundreds of coordinates manually. That’s why I suggested the “much smaller grid”.

Debugging can be a bit repetitive and boring but if you check your code and data systematically, you’ll eventually find the problem. :slight_smile:

I did not understand bug 2. What is the problem in the second video?

Since both videos seem to refer to the path and enemy movement, I assume that the problems might be related. Try to fix the obvious problem from the first video first.

1 Like

Hi Nina,

Thanks so much for your feedback. I really want to get this solved. I will report back my findings.

As for bug 2, I apologize that name was confusing. It’s just one bug, but a second video of it showing what happens if I block the front of the path vs the middle. Not sure why it creates such different behavior though.

I went through the final version of the course on gitlab and compared them to my scripts and can’t find any differences.

Clearly I have added things of my own but none of the stuff I have added even touches the pathfinding stuff from the course.

I will try your steps and report back ASAP

@Nina I put a Debug.Log(path.Count) in Update and found that it was clearing the list properly. I wasn’t able to figure out how to log each element of the path however I did make a scene with a smaller grid and the problem continues.

Do you have a suggestion on the syntax and proper place to log each element of the path?

To explain a bit further about the second video is that the enemy is pathfinding properly but isn’t smoothly moving from point to point as it should.

Thanks again for your help!

That’s great because it means that you could test the problem with less data. :slight_smile:

With a for- or foreach-loop, you could log the positions of the path elements into your console. As long as you do not know the order and the positions of the waypoints, there is no way to tell that the “enemy is pathfinding properly” because it might be that the waypoints are in the wrong order.

Try to work with one enemy only in your scene. Make the enemy move from the starting point to target waypoint to ensure that the pathfinding works correctly if you do not interact with the grid. Given it works correctly, try to figure out how often a new path gets calculated after you placed one tower on the enemy’s path. Given the problem occurs, restart the game and place a tower that does not block the enemy to figure out if the problem is caused by the towers in general or just when you place a tower on the path.

The next step could be to log the enemy’s current position and the current target position into your console whenever the nextWaypointIndex increases. This way, you could figure out if the next target position used by your code makes sense.

The goal is not necessarily to find the bug but to narrow it down, so don’t skip any steps unless you found the problem.


If you use Visual Studio, you could check the value of variables directly and do not need a loop. That’s fairly easy.

This is also possible in VS Code but since I do not use VS Code to write C# code, I do not know how to use the debugger.

1 Like

@Nina

I followed your instructions and found that the problem occurred even when I commented out the line that blocks the node. The bug occurs anytime Notify Receivers is called. At that point the path seems to have some issues

Found it!

Originally when writing the RecalculatePath method Gary has us write the line StopAllCoroutines();

I had "StopCoroutine(“FollowPath”)) I had thought at the time that I was being cleaner for being more specific as I had not seen any other coroutines being used by the Enemy Mover script. When I tried switching that line, presto it was fixed so… what gives? Is the Vector3.Lerp a coroutine?

Thanks again for all your help!

Good job on analysing and finding the problem! :slight_smile:

Regarding the Vector3.Lerp method, no, that’s not a coroutine but a normal method returning a value based on a parameter: value = v0 + t * (v1 - v0);

t would be the parameter whose value ranges from 0 to 1 (0 % to 100 %). v0 and v1 would be your two constants. With t = 0f, the returned value would be v0. With t = 1f, the returned value would be v1.

If there is a problem with v0, v1 or t, you might get a “funny” result.


See also:

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms