Cannot locate() \ref IDs of types derived from /image.

Page: 1 2
Aug 31 2016, 5:00 pm
However, /image isn't derived from /datum

Image's parent type variable is set to /datum

Those two statements can't co-exist, one of them is a bug.
Aug 31 2016, 5:02 pm
Unless you see it in stddef, it's just a faux-type, like /list, it has special handling all around. I agree, one of them is a bug, and I'd imagine the one where it's improperly inheriting procs is the one.
Aug 31 2016, 5:05 pm
However.

datum
    proc
        SomeProc()
            world << "Proc"
image
    SomeProc()
        world << "Some image proc."
        ..()
            
mob
    verb/Test()
        var/image/I = new()
        I.SomeProc()


Works fine for me, displays "Some image proc." then "Proc" as expected.
Aug 31 2016, 5:05 pm
Are you sure you have world.log set to something? If not you're gonna spit the output into the options and messages window.
Aug 31 2016, 5:20 pm
In response to MrStonedOne
MrStonedOne wrote:
However, /image isn't derived from /datum

Image's parent type variable is set to /datum

Those two statements can't co-exist, one of them is a bug.

The last time I checked, /image is some sort of half-brother or bastard child of /atom (and I forget what exactly, but had some properties of /atom/movable)
Aug 31 2016, 5:23 pm
It's a mutant like /list is, really. I think the stuff they did to make user-defined procs work on them gave them some kind of datum-derivation but it doesn't seem to be a perfect child of anything.
Aug 31 2016, 5:47 pm
I've heard of stddef, but no idea where to find it inside byond.
Aug 31 2016, 6:04 pm
Create a new code file and name it 'stddef.dm'
Aug 31 2016, 7:01 pm
Are you sure you have world.log set to something? If not you're gonna spit the output into the options and messages window.

Definitely, which makes this all the more confusing.

Like my example, I have dispose() defined at the datum level. I was setting up a simple image tracker to make sure images that are not being viewed do not slip through the cracks.

    proc/unregister_watcher(image/img, watcher)
        if(!watchers[img])
            return
        var/client/c
        if(islist(watcher))
            for(c in watcher)
                c.images -= img
                watchers[img] -= c
        else
            c = watcher
            c.images -= img
            watchers[img] -= c
        if(!length(watchers[img]))
            world.log << "image should be dispose()"
            img.dispose()
            watchers -= img

image
    dispose()
        world.log << "image dispose()"
        loc = null
        world.log << "image [tag] deleted"
        tag = null


I know the code reaches img.dispose() because I see the message "image should be dispose()". However, I never see the debug messages inside of image.dispose(), despite the code clearly reaching that point. If I change image/dispose() to an image-level proc, such as image/proc/cleanup(), it works fine.

Also, these errors appear when trying to define a proc for a list:
code\image_manager.dm:43:error: proc: list-derived types are not supported
code\image_manager.dm:43:error: new_list_proc: invalid proc definition


So yeah, there may be a bug involved where images are concerned.
Aug 31 2016, 7:31 pm
Have you tried moving the messages outside of log and just spit them out to world? I'm definitely having no troubles with datum procs working on images.
Aug 31 2016, 7:37 pm
In response to Nadrew
Nadrew wrote:
Have you tried moving the messages outside of log and just spit them out to world? I'm definitely having no troubles with datum procs working on images.

Just tried that; same result.
Aug 31 2016, 8:14 pm
Gotta be something somewhere else in the code at fault then, as noted in my example above, it works fine standardly.
Aug 31 2016, 9:07 pm
I would expect a proc defined for images would work fine. While internally it has a special type, it should act basically the same as an atom for var and proc purposes.

Lists are indeed a different animal, though.
Page: 1 2