ID:1142862
 
(See the best response by Jemai1.)
Why don't functions like view(), oview(), range() return true type paths?

environment/cave
parent_type = /turf

mob/verb/test()
for(var/environment/e in view())
world << "[e.type]"


This does nothing, why?

Yet, when I do this:

mob/verb/test()
for(var/turf/e in view())
world << e.type


I get output:

/environment/cave


The point is, shouldn't I be able to filter by my own defined path types?
it works when I do this

    for(var/atom/e in view())
world << "[e.type]"


maybe it needs to be var/turf/environment/e ?
In response to Magicsofa
Magicsofa wrote:
it works when I do this

>   for(var/atom/e in view())
> world << "[e.type]"

maybe it needs to be var/turf/environment/e ?

Well first of all, I don't even use /turf anywhere in my code... I don't think /turf/environment would be a valid path type even if environment's parent is /turf because technically its path is not derived from /turf

Secondly, it IS /environment, and DM knows it, view() and range() just fail to respect it.
Well I guess the compiler is able to "ignore" the parent type when you specify it that way, and only cares about what is explicitly typed in the code. On the other hand, the object being created gets the full path of /turf/environment. This seems to make sense to me...If the created object's type path was /environment, then setting the parent type would only have a partial effect of letting that type inherit from another.
In response to Magicsofa
Magicsofa wrote:
Well I guess the compiler is able to "ignore" the parent type when you specify it that way, and only cares about what is explicitly typed in the code. On the other hand, the object being created gets the full path of /turf/environment. This seems to make sense to me...If the created object's type path was /environment, then setting the parent type would only have a partial effect of letting that type inherit from another.

How do you know the created object's type path is /turf/environment

Nothing I can do with code will show me that, everything tells me its /environment.

The compiler doesn't let me do var/turf/environment/e
huh...well that is strange. I just realized your edit, which says that for(var/turf/e) outputs /environment. I think you should post this in bug reports!

If you don't mind me asking, why are you avoiding using the /turf path directly?
In response to Magicsofa
Magicsofa wrote:
huh...well that is strange. I just realized your edit, which says that for(var/turf/e) outputs /environment. I think you should post this in bug reports!

If you don't mind me asking, why are you avoiding using the /turf path directly?

I have an extremely fast and extremely robust tile system which pretty much replaces default BYOND implementation with my own, specific to my game. I avoid a lot of headaches by deriving from my own path which lets me generalize a lot of the code into deep base types (I write a /wall behavior, all walls follow it), as well as create large code templates that are created with my own code output utility(I don't have to type out long code files of icon state definitions when i define a new area in game code). It also presents its self properly in the object tree for map editors. I can also pass this on to people without exposing code.
Well those are all good reasons...I can see that changing everything to use /turf would be a ridiculous endeavor
Best response
That is because /environment/cave is not a type of /environment.

Your inheritance tree as actually as follows:
environment
parent_type = /datum

environment/cave
parent_type = /turf


That means
ispath(/environment/cave,/environment)!=TRUE

That is why you are not getting outputs from for(var/environment/e in view())

Instead, you should be looping through /environment/cave or make the following inheritance tree
environment
parent_type = /turf

environment/cave

//or
path_here/does_not_matter/cave
parent_type = /environment
In response to Jemai1
Ah I see, so the parent_type is the actual type and the /path is just how it's organized?
Yes. If you don't specify a parent_type, /type1/type2 will have /type1 as parent_type by default.
This is where I realize I was trying to do multiple inheritance without realizing its not possible in DM. FML
Yeah, this problem I had was actually more complex than what I posted here, but I have figured it out.

Thanks for all the insight guys.