When I create this object, I am trying to make it so it checks what is in its' location. If there are not one of two required turfs there, I want to null the objects' loc(thus deleting it).

Here is my attempt at a New() statement under the object, but it's just not working out how I thought it would.

for(var/turf/T in src.loc)
for(var/turf/tt in turflist)
src.loc = null
For both mobs and objects, the loc is the turf its on if its on a turf.
You check types with istype.
There is only one turf per coordinate.
As Nadrew pointed out, you have to put the ..() first.
src.loc = null
to get any atom in the same loc as another, use view(0).

In your case:

for(var/turf/t in view(src,0))

This will return the turf that you're currently standing on.

You can also just use src.loc, as it'll often return a turf. Be sure to check its type though, in case it doesn't return a turf (such as loc=null).
In response to Bravo1 (#2)
That's not working for me. Neither is the original poster's example.

for(var/turf/T in view(src,0))

The object still isn't deleting.
In response to OrangeWeapons (#3)
I believe, but I'm not 100% sure, its because you're still calling the parent after you run all that, so it object is still being created. If you don't want it to be created, then return 0 when the conditions for met. I could be wrong, but I'm pretty sure.
In response to Pyro_dragons (#4)
So basically, utilize a global variable to stop usage? urgh...not what I wanted to do, but I will do it.

Wait...what? Not sure if I even know how to do this...I'm confused. Lol.
In response to OrangeWeapons (#5)
Actually, ignoring what I said before, this method won't work. In this case, src is the turf you're working with. turf's don't have a view() proc if I recall correctly.
In response to Pyro_dragons (#6)
Not working.

for(var/turf/T in view(src,0))
return 0
In response to OrangeWeapons (#7)
I misread the first part. I thought you were working with a turf as the src. First of all, what you're trying to do won't work until the object is given a loc, which is done after New(), unless you give it a loc as one of the arguments. You'll need to call a separate function on the object after it's been created and set to check it's location, then delete it if you don't give it a loc when you call new on it.

If you do (such as var/obj/item/o = new(src.loc) and the like), then call the parent first, then check the loc and delete as needed.

for(var/turf/T in view(src,0))
del src

Side note: I don't think that nulling a loc is the same as deleting an object. Pretty sure, but I could be wrong.
In response to Pyro_dragons (#8)
Awesome, I made it into a proc. Thank-youuuz!
OrangeWeapons wrote:

>       New()
> for(var/turf/T in src.loc)
> turflist.Add(T)


This line is absolutely useless, there can't be more than one turf in src.loc -- there can only be one turf on any tile the map editor automatically creates a visual effect using the overlays/underlays list when you attempt to place a second turf on the same tile as an existing turf, and src.loc would be that turf. In the case of an object the loc variable will be what atom contains that object, if the object is on the map then the loc variable will be the turf its on. There's no need to loop over it, and looping over view(src,0) is also equally useless. There can only be one turf within view(src,0) if the obj is on the map.

..() // You forgot this, so the obj wasn't being placed properly.
world << "[]'s loc is [loc]"

If my_obj is on the map it will output "my_obj's loc is [turf]", if it's in an atom's contents its loc will be that atom -- this applies to all atoms, including turfs.
I'd just like to clarify a common misconception in this thread:

The default action for atom/New() does nothing. There is no point in calling it unless you've defined New() in a parent type. From the reference:

"By the time New() is called, the object has already been created at the specified location and all of its variables have been initialized."
In response to Pyro_dragons (#8)
You're right, a lot of people will tell you that you should always set loc to null to delete an atom, the problem they don't seem to comprehend is: If that atom is referenced by ANY variable whatsoever, it will not work to delete the object, it'll only move it, as a result it can cause lag due to a buildup of thousands of objects just because their references aren't being cleared properly.

setting loc to null is a great way to do it but you need to really double check everything that affects the atom in question in order to get it to work properly =P

Nice catch, I didn't even think that was the problem =3