math isn’t very expensive and doesn’t require tick events to apply.
But, here are a few things going on to think about when dealing with anything that’s on a minimap and real time.
If you change each model to have a corresponding mesh of some kind and set this mesh to be at a Z distance of 80,000 if I recall correctly. Anyway up in the sky enough to be outside of the skysphere.
If you set up a copy of the spline (1:1) up there in the sky as well, just below your cars…
And if you then create a little screen capture 2d component and render the meshes (selective, ignore everything but the players and the spline) that creates a nice little render texture for you…
You can then place that render texture anywhere at all, and it will always show the current progress of the race with a somewhat low cost and a 100% accuracy.
For the actual position (1st, 2nd, etc) and re-ordering the names in a list.
That’s a bit more complex.
To begin with, the system to check if a passing car earns a spot or not has to be done by each car when actually passing another car.
In this instance (via an event call, not tick btw), you would normally update an array (or in the case of Unreal probably use a map). To reflect the position change (or not, if the logic says otherwise).
Generally speaking, with any kind of such interaction, you have a large enough collision mesh that triggers on overlap events to make any number of determinations (also for ai logic).
In an extremely lazy setup, you could add 2 of such meshes, one in front and one on the back, and detect who is where comparetevely to each other.
Such as that if car a reports the posterior being triggered and car B reports the anterior being triggered, you know that car B is either catching up or being passed by car A.
To determine that you can just compare the 2 speeds. A Lowe speed is getting passed.