Issues outlined in #10

Issues + Explanation

Inside intersections, collisions are accidently detected with cars waiting to enter the intersection. This causes both cars to start moving at 0.1. This means a car which should be waiting actually ends up slowly entering the intersection. The car entering the intersection when it should be waiting can be fixed once the collision detection is fixed because once collisions are only detected at the correct times, then we can set speed to 0. Essentially once there is no situations which cause a deadlock we can set speed to 0.

Suggested Fix

If we disable collision detection through raycasting when inside intersections this will prevent the waiting car from detecting a collision, but that doesn't really matter once we eventually set the collision speed to 0. A different option is to disable collision detection by raycasting when inside intersections and to just trust the routing system. Another alternative would be to reduce the distance of the raycast when inside the intersection.

Issues outlined in #10

Issues/Explanation

When in the shorter lane, if a car is waiting at the intersection and another car goes around the last turn before the intersection it will not detect the waiting car. This results in the situation where the cars overlap and wait at the intersection. My best guess for why this happens is that the turn is instantaneous, so the raycast doesn't hit the other vehicle until right after the turn happens. This could be an issue because the right after the turn the second car is actually already inside the waiting car and I don't think raycast will detect collisions with any objects it starts inside.

Suggested fix

This might be fixed by adjusting the track (path) size. If there was more space between the intersection and the turn then a collision could be detected. However this is not an ideal fix because then if cars pile up waiting we could still have this bug wherever the turn is. The better solution might be to do a raycast in the direction of the planned turn beforehand.

Summary

The real world vehicles will be producing updates that can be used by the simulation to keep the two in sync. Need to finish and then test the code which uses these updates. The most important part of this is comparing the command queue between the update and the simulated vehicle.

Suggested Action

After accomplishing #13 it should be easy to convert the vehicles vector3 queue to strings which can then be compared to the update queue. An alternative method which might work is to simply compare the lengths of the queues, however this method is less robust and could result in errors I can't think of right now.

Summary

In the simulation the vehicle paths are a series of vector3 points they are traveling to. The real world cars use FORWARD, RIGHT, LEFT, etc. and travel until hitting a new node. To integrate the simulation we will need to create a function which converts vector3 paths into an array of strings with instructions for the real world cars.

Suggested Action

It might be necessary to store a vector3, normal to the front of the vehicle in the simulation, i.e. a vector3 always pointing in the direction the car is facing. Using this normal vector it should be relatively quick to iterate through the path and determine the necessary commands to reach each point.