What is the parent of obj, turf, and mob

ID:1872209
 
Jun 12 2015, 2:11 pm
Code:


Problem description: What is a tree that is the parent of all three if you go back far enough. I thought it was atom but my code seems to not work for turfs. So rather im doing something wrong or atom is just the parent of mob and objects

Jun 12 2015, 2:18 pm
/atom is the parent of /turf, /area, and /movable (in which movable is the parent of /mob and /obj).
Jun 12 2015, 2:18 pm
 
atom
    area
    turf
    movable
        obj
        mob
Jun 12 2015, 2:24 pm
Then datum is the parent of atom. Woo.

If you're not calling ..() in an override to a child proc, then the parent action won't run. For example, if you override atom/Click() but don't call ..() in obj/Click(), then atom/Click() won't be called.
Jun 12 2015, 2:27 pm (Edited on Jun 12 2015, 3:05 pm)
 
datum
    atom
        area
        turf
        movable
            obj
            mob
            image?
    sound
    database
    matrix
    icon
appearance?
client
list
savefile
Jun 12 2015, 2:28 pm
/sound, /database, and /matrix are all proper datums. They're defined in stddef.dm, which you can peek at in any project by creating a new file with that name.
Jun 12 2015, 2:36 pm
but when i do this
//above her is a for loops to go through x and y coordinates
for(var/atom/a in locate(x,y,src.zoneNumber))

world<<a
<br/> a only prints out objects

as long as its not trying to do both i can just do turfs seperatley. My print statment suggests that for whatever reason it isnt doing turfs
Jun 12 2015, 2:39 pm
The problem is that locate() in that context is going to return a turf, so you're actually checking for atoms within a turf, which will only be objects and mobs. If you want to access the area that contains the turf, you can use turf.loc

var/turf/my_turf = locate(x,y,z)
if(my_turf)
    src << "[my_turf] exists within [my_turf.loc] and contains:"
    for(var/atom/movable/A in my_turf)
        src << A


A tile can only ever contain a single turf, so there's really no need to loop over them on a single tile.
Jun 12 2015, 2:41 pm
EDIT: Yeah, that ^^^^

locate(x,y,z) returns a turf, so you are looping through the items in that turf, (its contents), which will just be objs and mobs.
Jun 12 2015, 2:41 pm
locate(x,y,z) returns a turf, so checking "in" locate(x,y,z) would be checking in turf.contents.
var/turf/t = locate(1,1,1) // grab the turf at (1,1,1)
Jun 12 2015, 2:47 pm
Oh thank you, I get it

Now if anyone else wants to answer this question or I'll put it in another one of no one does.

What's more efficient in respawnimg a dungeon.

Option A. When player leaves dungeon entire dungeon deletes objects/mobs and respawn them to (is there better ways than deleting them?)

Option B. After leaving a room or upon entering one you reset that rooms enemies and objects. So deleting them and than respawnimg them off of the copyable dungeon

Or can byond do this fast enough that it won't matter too much?
Jun 12 2015, 3:05 pm
It's probably actually best to leave the objects there and just hide/show them as needed. Creation and deletion of objects, especially on a larger scale is actually more costly on resources than just leaving the stuff in memory and reusing it over and over without ever deleting it.

So you end up with one mass creation event, and no mass deletion events instead of many of both over and over.

Of course if you're dealing in very large scale you do need to manage the amount of things you have existing at some point, but even then the best route is to manually get rid of any references to that object (including its location), and letting the garbage collector handle removing it from memory.
Jun 12 2015, 3:06 pm
In response to DanteVFenris
A lot depends on the sizes of the rooms/dungeons. Darke Dungeon takes the approach of saving the whole dungeon and then deleting everything when it's unloaded.
Jun 12 2015, 3:21 pm
In response to Nadrew
But some objects are moved to solve puzzles is the problem. Or variable are changed so the same puzzle can't drop a key repeatable.

Some of them easy to switch back some not.

So would it be more efficient to just save their original location and send them their rather than deleting? Well it probably would I guess. But there's a bunch of variables too I might need to revert. But it sounds like deletion is tough on byond so maybe the hastle to code that will be worth it

My rooms are screen size.

My first dungeon is 9 rooms however it will be the smallest