Waypoints and GC not working on WebGL build for tower defense

Unity Engine
1

Hey all,
So I’m adapting the Ray Wenderlich tower defense engine for my own purposes and starting to shape it with my own programmer art placeholders as the beginning of a prototype. The pinkish part of the screen are where the enemies (squares right now) come and travel. The green area with the gate is the “base” they try to smash. So far, it looks fine in the Unity editor. This screen shot is from there after a number of shots from my towers (circles) to the enemies:

3771682--315073--upload_2018-10-10_15-10-48.png
3771682--315073--upload_2018-10-10_15-10-48.png936×523 91.4 KB

However, this is what it looks like in the WebGL Player – notice the un-collected bullet projectiles building up.

3771682--315070--upload_2018-10-10_15-7-35.png
3771682--315070--upload_2018-10-10_15-7-35.png1920×1080 300 KB

Can any of you Unity guys explain this? Is WebGL just that nascent and underdeveloped as a platform in Unity 2018 to have bugs of this caliber?

Even worse: The waypoints behave differently. I have invisible start, middle, and end spots assigned to each enemy square. They work fine in the editor, but in the WebGL Player, the middle waypoints are sometimes out of bounds and cause some of the squares to indefinitely bang against the tops and bottoms.

2

PC Build does not have these errors either – it works fine there. Only WebGL leaves a trail of un-garbage-collected projectiles and wrongly placed waypoints.

3

I think I found the culprit for all of this. As this is a rapid prototype, I still have some code in Update(), and it depends on this in both those instances:

if (gameObject.transform.position.Equals(endPosition))
        {
            Debug.Log("reached end");
            if (currentWaypoint < waypoints.Length - 2)
            {
                // 3.a
                currentWaypoint++;
.....

My debugger has shown me that position.Equals never succeeds in WebGL. It does succeed in PC, and in the Unity editor.

UPDATE: Using Vector3.distance and a threshold of 0.05 totally fixes this. I’m not suggesting position.Equals never works, but when I used Time.deltaTime as my counter instead of Time.time (long story about my revision of the original mechanic), that may have affected things? Just a guess to help with debugging.