Phantom Objects (Buildings)

ID:1527211
 
Mar 23 2014, 11:04 am
(See the best response by Kaiochao.)
Code:
obj/map/assorted

    name = "Building"

    main

        layer = TURF_LAYER +1

        WIDE_RED
            icon        = 'wide_building_01.dmi'
            icon_state  = "02"

    roof

        layer = M_LAYER +10

        WIDE_RED
            icon        = 'wide_building_02.dmi'
            icon_state  = "02"


Problem description:

The building vanishes. Not all of them, and not all the time. But as you can see below, I walk 1 tile away and BOOM. Demolition. Walk back a space, and a wild building appears.

It's doing my head in. Anyone have any clues how to make it stop it? ._.

Mar 23 2014, 11:06 am
If I recall correctly, BYOND will stop rendering something if you've moved a certain distance from the source tile (which is going to the bottom left corner of your building).
Mar 23 2014, 11:28 am
Best response
Try setting the bound_width/height to the tile-size of the building (pixels rounded to the nearest icon_size, so some multiple of 32). That would make it occupy all the turfs that it appears to cover.
Mar 23 2014, 11:58 am
In response to Kaiochao
Kaiochao wrote:
Try setting the bound_width/height to the tile-size of the building (pixels rounded to the nearest icon_size, so some multiple of 32). That would make it occupy all the turfs that it appears to cover.

If this doesn't work you can also change the pixel_x so it's centered,then it would be visible even when you move.
Mar 26 2014, 10:41 am
Thanks. Good idea on the pixel offset, should have thought of that. Unfortunately bound_height and width did not seem to do anything.
Mar 26 2014, 11:01 am
You might want to consider this:

By default, BYOND only sends information about what's located in the tiles within the viewport of the player. If your viewport size is 10x10, BYOND sends an 18x18 chunk of the map by default. This is because it sends an extra 4 tiles in either direction by default.

Way back in the day, there used to be a limit on pixel_x and pixel_y. They couldn't go above 128 without getting all messed up. You'll notice that 128 is 32*4... Interesting.

At this time as well, we were limited to 32x32 icons for every BYOND world. Isn't that also quite interesting?

Well, these aren't coincidences. It's because at the time, the 4-tile buffer was constant. It ensured that objects would never "pop" out of existence when you walked away from them, like you are experiencing now.

When Lummox came aboard, he fixed some of this behavior, by creating a variable screen-buffer based on pixel offsets. If the largest pixel offset to exist in the world increases beyond 4 tiles in distance, that view buffer too increases.

Now, if I set pixel_x or pixel_y to 256 in a 32x32 world, the view buffer increases to 8 tiles in size. We don't know if this is a permanent change, or is capped to the highest current pixel_x/pixel_y value. We also don't currently know what the limits of this buffer are, but I'm assuming it can't push the view limit beyond the built-in 5K tile area limitation.

Now, here's where things get interesting. atom.transform doesn't obey any of these rules. It's totally separate. This can be used to manipulate this feature further to your needs.

However, your best bet is to center the building, and use a negative pixel_x and pixel_y offset. Obviously, the smaller the offset, the better. If you have a stationary image that's really, really big, though, I strongly recommend breaking it up into no larger than 4x4 chunks, in order to keep this. If it's a movable object, I don't recommend breaking it up at all, because it's far better to have your movables be one consistent object, than it is to avoid increasing the view buffer.