ID:2403508
 
Code:
var/turf/t = src.loc
var/area/a = t.loc
a = new /area/safe(t)


Problem description:I've been doing this for a while by just using the code above to create temporary safe areas. When their timer is up, they are set back to their old area the same way. I just want to know if it is safe, it seems like it is, but I just want to be sure.

The reason I do this is because checking if a pc, or npc is in a safe zone is easy to do this way. It also doesn't use view(), so it seems to be a faster way to check if a target is safe or not. The only other way to know if the potential target is safe is to use view() to check for police, which seems like it might cause lag when 50 npcs are doing it 10 times a second. I hope my way of handling it is not causing some invisible problem. DD has crashed several times this week, I'm a bit worried this might have somehow caused it. My friend thinks it did, but I really hope not.

This is absolutely not good, while creating areas on the fly may work it's probably not going to be very friendly to the memory footprint of the game. The way turfs and areas don't eat a massive amount of memory is by sharing where possible, and you're essentially killing its ability to do that by generating a ton of unique areas over and over. That may be what your crash is coming from.

You should just give the area a variable that you can set for safety.

area
var/is_safe = 0


Then just set is_safe where needed instead of creating and destroying an area and "moving" a turf (which you're not, you're actually creating a brand new turf with the same properties as the old one)
By using a = new /area/safe(t) with the turf in the parenthesies, it assigns it to the existing safe area, and only one is ever found. I tested this by making a verb to see how many areas exist in the world.

The funny thing is if I just create a new area without the turf in the parenthesies, it will add an extra area of that type and then there would be 2 area/safes in the world. The way I do it it still leaves only one.

Is it actually creating another that does not show up in the for(area/a in world) or is it safe the way that I did it?
The issues start to arise when you start coming up with slightly unique combinations of area/turf because of the reassignment, after a while it COULD lead to some internal build up and wackiness.

It's definitely not the ideal method to do what you're trying to do and is always going to be a lot more overhead than it's worth (since if it's gracefully handling it as you say, that means there's a lot of internal reshuffling happening to compensate). Simply altering a variable on an existing area is going to be a lot less work on the system and results in far more readable code.
I have another idea. When a npc is searching for a target, is it better to do a for(var/mob/v in player_list) and then use get_dist to find out which one is closest if they are within a distance of 7, attack them, or better to do a for(var/mob/m in view(7, src))?

It might work out if I create a police_list, and do the same thing, and just flag players as being safe if they are near police. There would never be, unless I get very lucky, more than 10 or 15 players, and including npc police, only about 50 of them, but each view(7) searches through that many tiles every time its used. I'm not sure if get_dist is a better option than for(var/mob/m in view(7, src)). Which would you do?
If you don't need to worry about opacity, using range() is better than view. In my tests on the game I work on the get_dist() method was only slightly faster, but both were faster than view().
If you want to change a turf's area at runtime, add the turf to the area's contents.
The mistake you are making is that you are thinking about areas like they are movable objs, in that they live on top of a turf.

In reality, turfs and areas do not touch. Turfs link to an area, and areas store a list of turfs that link to them.

Think of areas as objects that can be multiple places at one time. Creating a new area is largely unnecessary unless you want that area to be distinct.

I have another idea. When a npc is searching for a target, is it better to do a for(var/mob/v in player_list) and then use get_dist to find out which one is closest if they are within a distance of 7, attack them, or better to do a for(var/mob/m in view(7, src))?

As a general rule, don't have NPCs search for targets. Instead, have players notify NPCs of their location whenever they move. The only time an NPC should search its surroundings for a target is when it loses its current target and needs to potentially find another.

The reasoning for this is that the only logical way to have an NPC be instantly aware of a target it needs to attack is to have them search every frame for a player. This means you are searching for targets every single frame for every single NPC in the game. Your game's performance degrades according to the number of enemies in the world at one time.

If you do this the other way, and notify NPCs from the player, you can actually tie performance to the number and activity level of players.

As a general rule, you are going to have more enemies than players in your typical game, and it's going to be far easier to control the number of players in a game than it will be for you to control the number of active NPCs without having players notice something isn't right.