Range and View

ID:2029828
 
Feb 4 2016, 5:11 am (Edited on Feb 4 2016, 5:17 am)
(See the best response by Ter13.)
So which is better to use I guess view must have a condition check wether its in src.view right?? so which is faster??

Also for world to return a list of mob/FormationManager type does byond loop through every obj in the world??

for(var/mob/FormationManager/fm in world)

I mean I have like 20 Formation Managers in world would it be best to use my own lists in such ocasions or find them through world????
Feb 4 2016, 5:17 am
Best response
range() is faster than view().

However, it's usually best to avoid calling either whenever possible.
Feb 4 2016, 6:24 am
To elaborate a little bit on "whenever possible", consider the following:

view() returns a list of literally everything the specified atom can actually see, it has to scan the entire screen, check if it's visible, and then add it to a list. You then usually filter through that list (for(var/mob/M in view()) for example, you're filtering the mobs).

range() does something similar, but slightly better.

Both end up returning lists which will be full of "fluff" information. Things which ARE in range() or view(), but aren't at all what you're looking for.

Depending on your number of players/mobs, it might be faster to keep a global list of mobs and loop through that instead (obviously this changes case from case, but most commonly these are used for mobs). If you're looking for other players in particular, and the number of players isn't too high, this will also usually be faster than range() or view(), though note it'll return clients not mobs.

    clients(var/atom/movable/ref,var/dist = 0)
        . = new/list()
        for(var/client/C)
            if(C.mob)
                if(dist)
                    if(get_dist(ref,C.mob) > dist)continue
                . |= C
Feb 4 2016, 9:14 am
One point of clarification on range() and view(): When you're looping through them looking only for mobs, the compiler actually includes a filter. These lists can be filtered for any base atom type (e.g., area, turf, obj, mob), and those items don't get added to the list. For instance, if you're just looping through turfs, range() will not traverse turf contents. So there are some built-in efficiencies, but it's still better to avoid calling them if there's a simpler call like get_dist().