ID:911629
 
BYOND Version:497
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Firefox 14.0.1
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
I've got two blocks, a red one and a blue one. When I go into the map to map these in, I get a glitch. Say I put a blue down at 3,3,1 then put a red down at 3,3,1 too. The red covers the blue. This is NOT the problem. The problem is when I change the pixel_z of the red block, the red block moves up but the blue block is not shown under it where it should be. It's still there for me to edit, but it seems that if I place a blue block again at 3,3,1 I can see it. (But the previous blue block is still there and still invisible). The funny thing is if I change the pixel_z of the blue block, when it moves up I can still see the red block.

Numbered Steps to Reproduce Problem:
1. Make 2 simple blocks.
2. Put on same x, y, z.
3. Change the top layered blocks pixel_z to 16.
4. Glitch!

Code Snippet (if applicable) to Reproduce Problem:
world
fps = 25
icon_size = 32
map_format = ISOMETRIC_MAP
view = 6 // show up to 6 tiles outward from center (13x13 view)

turf
Blocks
Red_Block
icon='Blocks.dmi'
Blue_Block
icon='Blocks.dmi'
icon_state="Blue"


Expected Results:
For it to look like one block is on top of the other. (AND YES I AM AWARE THAT I ALSO HAVE TO CHANGE THE LAYER TO GET THE IMAGE OF A BLOCK ON TOP OF ANOTHER)

Actual Results:
One block is floating and the other is invisible o.o

Does the problem occur:
Every time? Or how often?
Every time except if I change the pixel_z of the lower layered block.
In other games?
Don't know.
In other user accounts?
Yes.
On other computers?
Yes.

When does the problem NOT occur?
I have just begun isometric style mapping so I can't determine.

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.)
No.

Workarounds:
Workarounds stated above. But nothing certain to fix it.

You cannot stack turfs.
Ah alright. I've been stacking objs anyways cause you can't change a turfs location. Hiro if you know a bit about Isometric programming would you mind heading over to my other post in Developer Help and seeing what you can figure out the problems I'm having?
I think what you're seeing is actually a longstanding issue with stacked turfs (technically, one being an underlay) and pixel offsets, where the offsets just don't apply correctly. I'm not sure it's fixable without breaking legacy maps, though it could be fixed for newer compiles. IIRC there were some other problems getting those to load right as well.
Descriptive Problem Summary:
When I put a turf with different pixel x or pixel y, the other turfs stacked on the same tile mimic the pixel x and pixel y of the placed one.

Numbered Steps to Reproduce Problem:
1. Make a turf with a non zero pixel x and pixel y
2. Make a different turf without the changes
3. Also make sure that they are on different layers, so that you can stack them.
4. Go to the a map file and place the turf that has no changes
5. Stack on top the turf with altered pixel x and pixel y

Expected Results:
The turfs stack onto eachother no prob

Actual Results:
The non altered turf will mimic the pixel x and pixel y of the turf with the changed pixel x and pixel y. You can see right on the map file that the non altered turf will mimic the pixel x/y.

When does the problem NOT occur?
If they are both not turfs.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
I never had a situation where I had to stack turfs until this version. So I'm not sure.

Workarounds:
I could change the turf with the altered pixel x/y into a obj, but instead that messes with some of my other code that relies on it being a turf.

In response to PkMax
Turfs aren't stacked. They can't be since only one turf can occupy a single location at a time. What the map editor does is that it adds the turfs "under" the top most turf to its underlays. That also explains your problem.
In response to PkMax
The fact that the pixel_x/y of the underlays is not being respected is a known bug. Fixing it is slightly problematic because it could interfere with older games, but a simple .dmb version check may be sufficient to handle that. As I recall the problem with the offsets not loading from the underlays was itself a thorny problem, however.