Tricky Runtime

ID:1891888
 
Jul 8 2015, 8:21 pm
Code:
proc/get_link()
        sleep(10)
        world << loc
        var/list/other_doors = list()
        for(var/obj/game/item/door/other_door in loc:dir2exit(direction)) other_doors += other_door
        for(var/i in other_doors) world << i
        for(var/obj/game/item/door/D in other_doors)
            if(D.direction == OppositeDirection(direction)) linked = D


Problem description:
I'm having a weird runtime where I get the following error:

runtime error: Cannot execute null.dir2exit().
proc name: get link (/obj/game/item/door/proc/get_link)
source file: door.dm,36
usr: null
src: the door (/obj/game/item/door)
call stack:
the door (/obj/game/item/door): get link()
the door (/obj/game/item/door): New()

Apparently the location doesn't exist, yet world << loc outputs the location the door should be in.

Also
proc/get_link()
        sleep(10)
        world << loc
        var/room/room = loc
        var/list/other_doors = list()
        for(var/obj/game/item/door/other_door in room.dir2exit(direction)) other_doors += other_door
        for(var/i in other_doors) world << i
        for(var/obj/game/item/door/D in other_doors)
            if(D.direction == OppositeDirection(direction)) linked = Dlinked = D

This puts out the same error, I don't know what the issue is.
</<>
Jul 8 2015, 8:22 pm
Also the sleep(10) used to be a sleep(1) because I thought the world not initializing might be the problem, but 1 second is more than enough.
Jul 8 2015, 8:36 pm
Tried src.loc instead of just plain loc?
Jul 8 2015, 8:42 pm
Doesn't help.
Jul 8 2015, 8:58 pm
loc returns what turf your mob is on. However, if loc isn't identified, it returns null.

world << loc only outputs mobs. The doors are objs. So your loc returns null.

Correct me if I'm wrong.
Jul 8 2015, 8:59 pm
I'm pretty sure all atoms have a loc reference.
Jul 8 2015, 9:03 pm
Bah, I'm sorry. I meant world << outputs mobs
Jul 8 2015, 9:05 pm
Sorry, I'm not following you. My world << loc is returning the name of the location of the door.
Jul 8 2015, 9:36 pm
Your problem is with this: loc:dir2exit(direction)

"Apparently the location doesn't exist..."
The location won't exist.
Look up the reference on "loc" - "The container is always an atom (or null). For areas, this value is always null, since an area may not be contained by any other object."

What are you trying to accomplish? Is this a proc that will gather all the doors in a specific location?
Jul 8 2015, 9:43 pm
The proc is supposed to link the door at initialization to a door in the room that the door is leading into. The linked door has to be the opposite direction of the source door. (e.g. in room 1 a door faces north, in room 2, the room north of room 1, a door faces south, that's the door we want)

The idea is when you open/lock/smash the door, you do the same to the linked door, since in the game world, they're supposed to be the same door.

dir2exit simply takes a direction and returns the room that is in that direction from the src

e.g. in the previous example room1.dir2exit(NORTH) would return room2
Jul 8 2015, 9:48 pm
dir2exit returns a reference to the room that is in the specified direction. It is a proc that returns a list.

Also I'm still not sure what you mean by world << loc only working with mobs. I added that as a debug statement to ensure the door's loc was actually initialized. Why would it only work with mobs?

EDIT: Not a list but a reference to an object that loops through the contents of that object, which is a list
Jul 8 2015, 9:51 pm
So, there's two doors in one single spot, but the two doors belong to two different rooms. For example: South Room has Door 1 (which is facing North), North Room has Door 2, which is in the same exact spot as Door 1 but Door 2 faces South?

So, /room is a datum you've made, correct?
Have you changed the parent_type of /room at any way?
Jul 8 2015, 9:55 pm
I thought the issue was with loc, but that's not the problem. The issue is with dir2exit. Since it's a proc, you have to use the .operator. However, it only works with protoyped procedures.
Jul 8 2015, 10:04 pm
It's code for a MUD I'm making, the two door objects are in two seperate "room" objects. The "facing" of the door is actually a var in the door itself. The code is based off of how doors work in HellMOO.

As for the /room, I'm using a heavily modified version of Dan.mud

If I recall correctly, /room is a child of area. I've been using loc so far fine with /room and this is the only issue I've had.

And GoldenArk loc is a reference to an atom's container. It's not tied to mobs. My door is in an area, since that's what the library uses as /room.
Jul 8 2015, 10:12 pm
The way it looks like Dan's MUD demo is it already has a built-in feature you're looking for. north_exit, south_exit, east_exit, west_exit. You'll basically want a /door with the dir of NORTH to have a south_exit of the 2nd /door.
In Dan's MUD demo, the /room is not a child of /area at all. It's its own /datum type.
Jul 8 2015, 10:30 pm
In response to GoldenArk
GoldenArk wrote:
loc returns what turf your mob is on. However, if loc isn't identified, it returns null.

world << loc only outputs mobs. The doors are objs. So your loc returns null.

Correct me if I'm wrong.

The loc var is the atom that src is located inside. An obj or mob can be in another obj or mob, or a turf, or for turfless games (like MUDs) an area. A turf is always inside an area, and an area is always inside nothing.

world << loc will simply output whatever src.loc is; which is either an atom or null.
Jul 9 2015, 11:40 am
 
room
    parent_type = /area


/room is a child of area.

north_exit/south_exit/etc. are type paths of other rooms. My dir2exit proc takes the room (loc, in this case) and returns the appropriate _exit var.

I'm not sure really what' you're trying to say Maximus.

Sorry, I may be wrong, but looking at the runtime I don't think dir2exit is the problem. It returns a reference to another room, and I thought that by default if you specify 
in
and another object, it loops through the contents of that object.


This is my dir2exit proc.
room/proc/dir2exit(dir)
    switch(dir)
        if(NORTH) return locate(north_exit)
        if(SOUTH) return locate(south_exit)
        if(WEST) return locate(west_exit)
        if(EAST) return locate(east_exit)





room/proc/dir2exit(dir)
    var/room/room
    switch(dir)
        if(NORTH) room = locate(north_exit)
        if(SOUTH) room = locate(south_exit)
        if(WEST) room = locate(west_exit)
        if(EAST) room = locate(east_exit)
    . = room.contents


Changing it to this does not really help either.
Jul 9 2015, 11:46 am
And..... running manually using a verb without using New()
seems to make it work. Weird. I don't know why the game would return loc though if it hasn't been properly initialized yet.
Jul 9 2015, 9:11 pm
Okaaaay, since this and another of related bugs that seemingly come and go at random without any code changes are suddenly popping up that can be tied to the saving/loading feature of the library I'm using, after many hours of headbashing/frustration I have scrapped most of the save/load code in Dan.mud to keep just the object infrastructure and most of these problems have gone.