ID:2537237
 
Resolved
Objects with render targets starting with an asterisk sometimes still appeared in cases where multiple objects tried to use the same render target.
BYOND Version:513.1506
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 79.0.3945.88
Applies to:Dream Seeker
Status: Resolved (513.1507)

This issue has been resolved.
Descriptive Problem Summary:
If you have an overlay, and it has a render_target starting with * (meaning it shouldn't display), and that overlay is on an object, and that object is on a turf, and that turf is in the vis_contents of something that's visible, then the overlay will display even though the render_target of * means it shouldn't.

Numbered Steps to Reproduce Problem:
1. Have an overlay
2. Give it a render_target with *
3. Put it on an object
4. Put that object on a turf
5. Make that turf in a vis_contents list of something that's visible
6. Watch as the overlay displays even though it shouldn't

Code Snippet (if applicable) to Reproduce Problem:


Expected Results:
it doesnt display

Actual Results:
it displays

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

When does the problem NOT occur?
when the object is not on a turf that's in the vis_contents of something

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

Workarounds:
don't use an overlay I guess
Can you distill this into a test project? I want to check it out and see what's going on.
Do you have a test case for this? I've never seen this issue in normal tests so obviously there's something special about your test case that shows the issue.
Lummox JR resolved issue with message:
Objects with render targets starting with an asterisk sometimes still appeared in cases where multiple objects tried to use the same render target.
Just a quick tip on the multi Z if you're interested: to preserve proper perspective, you need to make sure each successive layer has the right scale relative to the main one. If the main floor is 1:1 and the one below it is scaled down to 15/16, then the one below that should actually be 15/17 assuming the floors are all the same distance apart.

Effectively distance from the camera is 1/d, and your current layer is where d=1. If the next floor down adds +1/15 to the distance, then the next floor before that is an additional +1/15 so that's why the math works out the way it does.
The reason I was subtracting 1/16 is so that the scaling is a multiple of 1/16 on all levels, that way the edges of the tiles would fall on pixel boundaries reducing the blurrines from scaling. I consider crisper scaling to be more important than depth accuracy.
In response to Monster860
A reasonable trade-off, then.