ID:2370529
 
BYOND Version:512.1424
Operating System:Windows 10 Enterprise
Web Browser:Chrome 66.0.3359.181
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary: Incremeting pixel_z does not make turfs above appear.

Numbered Steps to Reproduce Problem: Increment pixel_z.

Code Snippet (if applicable) to Reproduce Problem:
https://cdn.discordapp.com/attachments/447586504332541953/ 448207044667899924/BUG.zip (File)
otherwise
client
New()
..()
spawn while(1)
pixel_z = pixel_z + 1
mob.pixel_z = mob.pixel_z + 1
sleep(world.tick_lag)


Expected Results: The turfs should appear.

Actual Results: They don't, unless I am using client.pixel_y instead.

When does the problem NOT occur? Not changing client.pixel_z

Workarounds: Using client.pixel_y instead.

Images :
https://cdn.discordapp.com/attachments/448207836149710850/ 448207858392236044/unknown.png - Using pixel_y.
https://cdn.discordapp.com/attachments/448207836149710850/ 448207940336353282/unknown.png - Using pixel_z, notice how the turfs are missing?
I see that only a few turfs appear and then scroll off the screen, but I'm confused as to what you're trying to do with this demo.

Increasing pixel offsets without bound is generally a very bad idea. Ideally it's better to reset those periodically. Or better yet, just alter mob.step_y which would do exactly what you need and would not increase without bound.
try moving around, you'll see that turfs dont render correctly
I don't know what you mean by "correctly". I can see the whole map doesn't stay visible as it does when altering pixel_y, and I agree that's likely buggy behavior. (I only say "likely" because there are some extreme situations the visual bounds code simply isn't designed to handle, but those situations should also never come up because any game that would see them could code around them.) But I'm not seeing anything beyond that.
If you shift pixel_y of client up, it moves the screen up, turfs appear on the up side of the screen, but if you shift pixel_z up instead, the turfs get cut off after a while.
Thing is, I'm not sure a pixel_z offset too extreme is necessarily a valid condition. I'll double-check how the visbounds code is handling all of this of course, but it seems like whatever effect you're going for would be better served with another method.

For instance, if you replace both increment lines with just ++mob.step_y, you get the same effect but the turfs don't disappear.