vis_contents not an /atom var

ID:2309870
 
Oct 28 2017, 7:46 pm
Not a bug
BYOND Version:512.1393
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 61.0.3163.100
Applies to:Dream Maker
Status: Not a bug
This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
Attempting to add something to vis_contents for an /atom results in and 'undefined var' error. The var claims to belong to /atom.
Numbered Steps to Reproduce Problem:

Code Snippet (if applicable) to Reproduce Problem:
atom
  New()
    .=..()
    var/obj/O = new
    vis_contents += O


Expected Results:
vis_contents to be valid for /atom
Actual Results:
invalid var error
Does the problem occur:
Every time? Or how often?
In other games?
In other user accounts?
On other computers?

When does the problem NOT occur?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds:

Oct 29 2017, 12:11 am
This is actually correct. Although the reference lists it under atom/var for simplicity, it also states that the var only applies to turfs and movables. Areas don't have this var, thus it isn't available to all atoms.
Oct 29 2017, 12:11 am
Lummox JR resolved issue (Not a bug)
Oct 29 2017, 2:36 am
Ah, my mistake. I found a workaround anyway. Thanks.
Oct 29 2017, 4:04 pm
Aaand this is the point where you realize the BYOND Atom model makes no damn sense.
Oct 29 2017, 4:20 pm
In response to PJB3005
PJB3005 wrote:
Aaand this is the point where you realize the BYOND Atom model makes no damn sense.

Agreed, though I'm not sure I have a problem with vis_contents not working on /area.
Oct 29 2017, 4:57 pm
I don't really either. I just have some stuff that I use on both turfs and movables, and atom is the easiest place to put it. I can either just typecast it to what I want, or use src:vis_contents if I'm sure it won't be an area.
Oct 29 2017, 5:12 pm
Flick:

This is an interesting hack I use for pixel movement foo.

#define DEFAULT_BOUNDS "1,1 to 16,16"
atom
    var
        step_x = 0
        step_y = 0
        bounds = DEFAULT_BOUNDS
        bound_x = 0
        bound_y = 0
        bound_width = TILE_WIDTH
        bound_height = TILE_HEIGHT
    proc
        Cross(atom/movable/o)
            return Enter(o)
        Uncross(atom/movable/o)
            return Exit(o)
        Crossed(atom/movable/o)
            Entered(o)
        Uncrossed(atom/movable/o)
            Exited(o)


Maybe you can do something similar by defining vis_contents on atom anyway. I've shown no major issues with overriding /atom behavior at this level to allow me to simplify a lot of pixel movement code.
Oct 30 2017, 6:08 pm
Defining vis_contents on atom is likely the best way to handle this.

But the fact areas are atoms is news to me, I don't mess with areas enough for that connection to be made.
Oct 30 2017, 7:49 pm
Area
Turf
Obj
Mob

Dan was clever
Oct 31 2017, 3:14 am
I always did like the acronym nature of it, it's fun, it kind of implies they're all on the same level of the hierarchy though, which isn't true:
datum
    atom
        area
        turf
        movable
            obj
            mob

user types can go anywhere in this tree, but basing things on atom and movable directly get a bit ~weird~.

user defined movables have the internal structure of an obj, but don't have the path /obj (The internal structure is what isobj() looks for, not the path, so isobj() on a user defined movable is actually true!)

I think user created atoms act like turfs? though lummox has said before that isn't true so I'm unsure what they are in truth, I'm not able to check right now.
Oct 31 2017, 6:14 am
In response to CrimsonVision
CrimsonVision wrote:
though lummox has said before that isn't true so I'm unsure what they are in truth, I'm not able to check right now.

That's the opposite of what's been said. Internally any /atom/movable attempted to be initialized will create an /obj, while any /atom attempted to be initialized will create a /turf. This isn't an issue for overrides and changes to structure.
Oct 31 2017, 12:31 pm
It's not the opposite, he has shot it down before.
Though I likely won't be able to find it because lol forum search.

EDIT:


Aha! I found it, I took a hunch on what the thread was called.
Oct 31 2017, 2:21 pm
In response to CrimsonVision
CrimsonVision wrote:
Though I likely won't be able to find it because lol forum search.

http://supersportsbattle.com/searchbyond
Oct 31 2017, 2:58 pm
atom for me meant anything with a physical presence in the world.

areas don't fit that narrative. areas are metadata about turfs.

but turf's loc is an area, so it makes sense i guess
Oct 31 2017, 4:46 pm
In response to CrimsonVision
CrimsonVision wrote:
It's not the opposite, he has shot it down before.
Though I likely won't be able to find it because lol forum search.

EDIT:


Aha! I found it, I took a hunch on what the thread was called.

var/atom/a = new/atom(locate(1,1,1))
if(istype(a,/turf))
    world.log << "istype"
if(isturf(a))
    world.log << "isturf"
if(locate(1,1,1)==a)
    world.log << "isloc"


Unfortunately, the reality is a bit different and more complex.

The above code will result in "isturf" and "isloc", but not "istype".

You yourself confirmed this later on in the same thread you linked: http://www.byond.com/forum/?post=2256093
Oct 31 2017, 8:08 pm
You're confusing type with typeid.

she was talking typeid, you're talking type.
Oct 31 2017, 8:10 pm
atoms have a typeid of a turf, but would fail a isturf type test, this is actually intended behavior, the same applies to movables and objs, movables have a typeid of obj, pass isobj, but fail istype(/obj). its why /tg/ uses movables, creates children of movables, and even mapped isobj to istype(/obj) using a macro