I'm wondering if the way ive got this worked out could be improved upon, since id ideally want as little overhead as possible.

I have a 'track' which is basically a turf with an Entered(). When a mob walks into it with certain veriables set, it auto walks them around it.

icon = 'dlane.dmi'

icon_state_a = "on"

I have have added to the turfs Entered() the following;

for(var/obj/lane/duel/D in oview(10)) if(!D.activate) D.icon_state = D.icon_state_a

So while im walking around this track, and Entered() is being set off, all obj/lane/duel within a 10x10 view of the turf will switch their blank icon_state's to the objs set "icon_state_a" variable (but only if they dont have a mob linked to them).

Having the mob/activate is a good way since then when a mob leaves the server or whatever, i can search the world for obj's they affected and reset them. Ready for another player to affect.

Would this be a laggy way to deal with this? Is there a better way?

The whole point of this is to have an object 'do something' when a mob walks within a certain range of it with certain variables to give an effect a bit like below...

The object would be the "DUEL" and it would be invisible until a mob walks within range of it with a certain variables set.

So is this the best way i can hope for, or is there a more efficient way?
So, ..this is the best way then? I tweaked it a little to remove the mob/activate and simply copied their key there instead.

I was thinking of adding a var to my turf, and making a subtype so that i can place every 5 squares of the track. Those would be the only ones that would have the variable that would trigger this for(). That way it wont be doing it on EVERY turf the mob enters.

I just wanted to see if there was some better way id not considered (quite possible).
Another way to go is to modify Entered() for all turfs, but only do this particular check when the vars of the entering atom are right. Depending on your setup that may or may not be better than having a special track of dedicated turfs set up.

I prefer to generalize because it tends to make better design, so for instance a turf might call Trigger() for all objects on it when a mob steps on. But in your case you're checking a fairly wide view and it wouldn't make sense to do that all the time. And in practice I don't always generalize either; SotS II's code is full of specific cases because Entered() is pretty much only going to trigger a trap or a teleporter, or pick up an item, so the set of possible actions is pretty limited.

Lummox JR