Opacity ignored (For realsies this time)

ID:2066421
 
Apr 7 2016, 10:21 pm (Edited on Apr 7 2016, 10:31 pm)
Resolved
The client does extra view calculations on "extended" turfs, and was being told by the server to hold onto such turfs even when it no longer needed them.
BYOND Version:510.1337
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 49.0.2623.110
Applies to:Dream Daemon
Status: Resolved (510.1338)
This issue has been resolved.
Descriptive Problem Summary:
Opacity is ignored in certain circumstances when an object's bounding box is lower than a tile size. (I finally found the bug myself.)

Numbered Steps to Reproduce Problem:
Go to the right side of the wall. Go near (touch) the other mobs (in white). Go back to the left side. You can now see the mobs behind the wall.


Code Snippet (if applicable) to Reproduce Problem:
//See demo code.

Demo: http://files.byondhome.com/Kamuna/TestCases/ BoundsTestCase_src.zip

Expected Results:
Blackness, all blackness.

Actual Results:
http://puu.sh/oajQx/25c39b72d5.png
I see some whiteness!

Does the problem occur:
Every time? Or how often?
Every.
In other games?
Yes.
In other user accounts?
Yup.
On other computers?
Affirmative.

When does the problem NOT occur?
If you don't have a high view size and/or don't go near the mobs, or if you don't have a different bounding box size.

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.)
509, I believe?

Workarounds:
No high view size or use the default bounding box size.

EDIT: Actually, it seems to happen on a 32x32 AABB too.

Apr 8 2016, 12:54 pm
This isn't entirely a bug, but it's definitely behaving weird.

Part of the issue is that it's not bounds that determine visibility, but the extent of the icon. Because you're using pixel movement, the white mobs that are moving west stop at the wall with a step_x of -3. The icon, which is 32x32, therefore partially overlaps the visible tiles. So being able to see those icons would, in some cases, be considered correct.

Problem is, the behavior that triggers that change only comes up if you've got an "extended" turf to display the objects, and that shouldn't be the case here. Turfs are inappropriately being marked as extended, and the server is telling the client to hold onto them for way too long.
Apr 8 2016, 1:12 pm
Lummox JR resolved issue with message:
The client does extra view calculations on "extended" turfs, and was being told by the server to hold onto such turfs even when it no longer needed them.
Apr 8 2016, 1:12 pm
The "fix" for this basically makes the server tell the client to stop treating certain turfs as "extended" for opacity purposes, once they're no longer needed. (Before, it held onto them until a bigger map update, on the theory that they were harmless.) Please note however that in the future, it is very likely that the behavior used for extended turfs will end up applying to objects on "regular" turfs, such that when your icon extends into another tile, it will carry the same opacity as the tile.

The absolute cure for this issue is SEE_PIXELS, although that currently isn't supported in the webclient. (I plan for it to be handled eventually.) On the whole it doesn't make a lot of sense to use pixel movement and opacity together without that sight flag.
Apr 9 2016, 11:37 am
I believe I tried SEE_PIXELS, though, but that didn't work out in my game. I think it could have just been a silly variable assignment in loop mistake though. I'll try it again.

EDIT: Yeah, it was a silly variable assignment in loop thing. I forgot to change the check and assignment to SEE_PIXELS instead of 0.