ID:1379797
 
Resolved
BYOND Version:500.1209
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Chrome 29.0.1547.66
Applies to:Dream Seeker
Status: Resolved (500.1210)

This issue has been resolved.
Descriptive Problem Summary:
When using pixel movement, normally there is a layering issue in Topdown format to where it looks as though you're standing over things that you shouldn't be. This is fixed by modifying your layers as atoms move around to be adjusted via their y coordinate (lower y coordinate results in a higher layer)

After updating to 500, this code has stopped working. The layers are getting set to decimals (something like 3.12) to make this all work. Not sure why this would happen but the only thing I can think of is that layers can only be integers now, or.. how things are drawn has changed. Who knows?

Numbered Steps to Reproduce Problem:
Use pixel movement, try to properly layer everything.

Code Snippet (if applicable) to Reproduce Problem:
atom
movable

var
Standing = 0

proc
update_layer()
layer = MOB_LAYER
if(isturf(loc))
var py = (y - 1) * 32 + bound_y + step_y
var max_y = world.maxy * 32
var scale = 0.01
layer -= py / max_y * scale

Move()
. = ..()
if(Standing) update_layer()


Expected Results:
Layers can be dynamic again

Actual Results:

Does the problem occur:
Every time? Or how often? Every time
In other games? Haven't tested
In other user accounts? Haven't tested
On other computers? Haven't tested

When does the problem NOT occur? So far, it always does (I'm pretty sure it's the BYOND version responsible)

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? In the most recent 499 version it worked just fine. It seems updating to 500 is responsible

Workarounds: I've not experimented with it really, since this seems to be a bug.
I'll investigate, but a test project will go a long way toward figuring this out.

I'm not sure why you're needing to do those adjustments in the first place. BYOND already does something like this internally (which may not be working for some reason, so I'll check) to make icons on the same layer sort consistently, and also to prioritize movement. Broadly speaking, the layering of atoms should be pretty consistent, especially in topdown mode. I wasn't aware of any layering problems that existed in that mode.
Well, it's less about that; The layering always worked fine in that regard (and still does)

Think of it like this, though. You have pixel movement which allows you to move in really close to things and intersect the icons. Say you want to appear behind a tree when to the north of it, but in front when to the south.. if the layer is absolute and doesn't change as you make that position change you can only be either in front or behind it. By determining if something stands and adjusting it's layer as it's positioned, you can get that effect.

I'll try to put something together here.
Here's a test project that should do what I'm talking about (it's compiled in 500.1209)

If the layering was the same, you'd be able to go behind the tree instead of standing on it.

http://www.2shared.com/file/gujpXKGl/LayerPrev.html
In response to Kitsueki
Kitsueki wrote:
Think of it like this, though. You have pixel movement which allows you to move in really close to things and intersect the icons. Say you want to appear behind a tree when to the north of it, but in front when to the south..

This is what SIDE_MAP format does. SIDE_Map acts as though it renders sprites back to front. Why are you reinventing this behavior in TOPDOWN_MAP?
There's no bug here.

You are never updating the mob's layer, and the trees are being updated every time they move... Which... They don't.
In response to Ter13
Because SIDE_MAP does it badly.

I like to think I was the first to do this because my bug report on the layering issues with SIDE_MAP was "resolved" and is still an issue, so I worked around it. It's a pretty simple snippet, and it works.

And it works for me just fine for me in 1209.

atom/movable
var standing = TRUE

proc/LayerUpdate()
if(standing && z)
layer = MOB_LAYER - Py() / map_height() * 1e-3

New()
..()
standing && z && LayerUpdate()

Move()
. = ..()
. && standing && z && LayerUpdate()

// edit
atom/movable
proc/Py() return (y - 1) * tile_height() + bound_y + step_y

var __tile_height
proc/tile_height()
if(!__tile_height)
__tile_height = isnum(world.icon_size) ? world.icon_size : text2num(copytext(world.icon_size, findtext(world.icon_size, "x") + 1))
return __tile_height

proc/map_height() return world.maxy * tile_height()
In response to Kaiochao
Taking a look at this demo:

mob
Standing = 1


fixes the problem. You forgot to set it so that the mob adheres to your layering rules.


This reminds me of a bug I reported a year ago. Time to give that some context... Hope you don't mind I'm borrowing parts of your bug report project, Kit.

http://www.byond.com/members/ Ter13?command=view_post&post=921216&first_unread=1
I'm confused: Is there a bug or isn't there? From the sound of it the demo in question is broken and so I can't really use that to verify the existence of a bug.

As far as the layering issues in SIDE_MAP (and also in isometric), I'm aware of those. For some time I've had some code on standby that I think will resolve their layering problems for good (transformations notwithstanding, as they'd be divorced from positional rules), but I haven't really had an opportunity to integrate that code.
In response to Lummox JR
Lummox JR wrote:
I'm confused: Is there a bug or isn't there? From the sound of it the demo in question is broken and so I can't really use that to verify the existence of a bug.

As far as the layering issues in SIDE_MAP (and also in isometric), I'm aware of those. For some time I've had some code on standby that I think will resolve their layering problems for good (transformations notwithstanding, as they'd be divorced from positional rules), but I haven't really had an opportunity to integrate that code.

This bug report was in error.

The one I linked is still withstanding, as you just acknowledged.
What's throwing me though is Kitsueki says there's a difference in layering behavior between 499 and 500, on TOPDOWN_MAP. That shouldn't be the case if everything is functioning correctly, as TOPDOWN_MAP's layering behavior should be unchanged. (Obviously there have been a few issues up to this point, like images, but those should be settled.) But I don't want to waste my time running tests on an example that's broken, as that will obscure any results.
Oh, yeah.. It seems mob wasn't set to be Standing in that demo. After switching it, it works fine... in the demo. In my actual project, mobs ARE set to be Standing (they always have been), but they still aren't layering properly. Somehow there's an issue in my project now, which.. well, I dunno. I guess I'll have to look into this a bit.

If you want to see what I was talking about, Lummox, set Standing = 1 for mobs in that demo
After checking previous versions of the game, it seems that this is a little bit deep. It doesn't work in any of the previous versions, so I suspect there's some -other- type of change from v500 affecting this. It wasn't in any of the layering code, so it has to be on another level.
Upon further investigation, making a new map seems to fix this.

Edit: Could this be linked to atoms having new variables from the update somehow? The trees and the like are placed in the map editor, so they should automatically inherit the new variables with no issues. None of the tiles or objects on my map are modified, they're all default (no custom instances)
I can't think of any particular reason an older map would have problems over a newer one. I suggest comparing the two in a text editor to see if they have any significant differences.

I'll try out your demo with the Standing var on for the mob and see what I can find.
I didn't see anything in the demo. However, there is a layering issue with mobs that was exposed in ID:1381145, which may be at the heart of this. I suspect they're the same issue. Please retest when 500.1210 is out.
Alright! I've been meaning to do as you suggested, but I've been busy with working and the like. I'll keep an eye out.
Confirmed that 1210 has fixed this issue.
Nadrew resolved issue with message:
Fixed as per ID:1381145
Just wanted to add a note that I removed the resolution message. Didn't want this appearing in the release notes since it's essentially a duplicate.