ID:2127717
 
BYOND Version:510
Operating System:Windows 10 Pro 64-bit
Web Browser:Firefox 47.0
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
We recently made a switch to 64x64 on our SS13 branch. This was done by upscaling all the icons with a script.

Other than some issues with Dream Maker (id:2127204, id:2127016) there has been one more significant BYOND issue we've ran into: Dynamic RSC Corruption.

With Dynamic RSC Corruption, I mean that clients suddenly begin having certain frames in the icons be removed or replaced with others during the game.

This can happen on both icons in the RSC at compile time (regularly included) or generated with icon operations by the server at runtime.

If you're failing to see what it can look like: imagine that if you use the same floor sprite everywhere, every floor suddenly turning into a door for a specific client.

This issue has happened in the past at 32x32 sprites for us. (I personally have experienced it). And when it happens it appears to happen for multiple clients at once (the one time it happened for me other people were reporting it too and an issue on our GitHub was even made but I'm failing to dig it up)

Numbered Steps to Reproduce Problem:
I have no idea. Idle as observer in a long round of SS13 on our server where we moved to 64x64 is the only thing I can suggest to reproduce it.

Does the problem occur:
Every time? Or how often? Appears to happen after playing for a long time.
In other games? No
In other user accounts? Yes
On other computers? Yes

Workarounds:
Restarting Dream Seeker fixes it.
If I had to guess is it mismatching appearance information with the proper sprite to render it?

It seems to always function by icon state, everything of a specific icon state is replaced by another random icon state.
It's worth noting that while it happens for multiple clients at once, it isn't the same between clients. The icons that get switched around are different for everyone, if I'm not mistaken.

I haven't played since the 64x64 update. I'm guessing it's just been much more common since then?
Oh, I found the report
https://github.com/d3athrow/vgstation13/issues/7055

Of note is the image in it in which a certain space tile was replaced with the image of a clothed plasmaman, which suggests that it is not just an icon_state thing because clothes are overlays. Similarly, the images in the original post and second comment show a player whose south-facing icon is broken, including clothes and everything.
In that case its just mixing up appearances entirely.
I have been told that dir and appearances are independent, so it's not even an appearance thing. As you can see in the linked issue report, it has previously affected only a certain direction of an appearance, albeit only very rarely.

My theory has been for a long time that it is some memory value overflowing, due to the fact that before the switch to 64x64, it only happened in extremely long rounds (3+ hours). The fact that increasing the sprite size worsened the problem seems to strengthen that theory.
In response to Exxion
Exxion wrote:
I have been told that dir and appearances are independent, so it's not even an appearance thing.

This isn't entirely true. There's some code that handles dirs separately for other reasons, like making sure a 4-dir icon faces the right way when you move diagonally. But appearances do take dir into account.

As you can see in the linked issue report, it has previously affected only a certain direction of an appearance, albeit only very rarely.

My theory has been for a long time that it is some memory value overflowing, due to the fact that before the switch to 64x64, it only happened in extremely long rounds (3+ hours). The fact that increasing the sprite size worsened the problem seems to strengthen that theory.

I suspect memory is involved here as well.
Is there any method we could use to get you the diagnostic information necessary to uncover the source of the issue?
Off the top of my head, no. I can't think of anything. The key to uncovering something like this is usually to be able to reproduce it in the debugger, although if memory exhaustion is a critical component then that's gonna be impossible.
I quizzed a few people in game about their experiences since they have a lot of opportunities over the past few days of our playtest to experience this issue.

1. It seems no one has ever seen a shift occur on an object that is currently in view, only upon something that is coming into view.

2. It also seems that once an appearance has been 'corrupted', it will have a tendency to shift between multiple other appearances when coming in and out of view. I did not realize this was the case earlier.

I think these may be important details, and that it points the issue towards some particulars of client code that track when something is in view or not and pulls out the appearance. I can only speculate as I only know some basics of that code from its peculiarities (such as when an animated icon state plays again upon coming into view after being out of it).
I've experience this exact problem, its seems to happen randomly usually effects individuals but sometimes it can effect multiple people at a time with different images. The main code that produce this glitch for my game was a code that added indents or markings to terrain using icon blending effects.
                if(!ricon) ricon=src.icon
var/icon/i=new(src.ricon,src.icon_state)
src.ShiftBack(600)
clickeffect=icon('DamageEffects.dmi',"6")
clickeffect.Shift(pick(NORTH,SOUTH,EAST,WEST,NORTHWEST,NORTHEAST,SOUTHEAST,SOUTHWEST),rand(-6,6))
i.Blend(clickeffect,ICON_SUBTRACT)
var/icon/i2=icon(src.ricon,src.icon_state)
i2.Blend(i,ICON_OVERLAY)
src.ricon=i2
src.OverPut(i2,600)

You know, this happens to space turfs all the time, but I've never seen it happen to any other kind of turf. That was the case even before parallax. What was different about space turfs back then?
It might just be that there are so many different appearances for it and they're placed randomly, so they enter and exit view quickly, but maybe it's something else
Actually I just remembered I DID have it happen to the basic default floor sprite once, first it disappeared, then it changed into a completely different icon altogether.

This was much later and after parallax got in so it did result in most of the station having a space background which was kind of neat.
I have something to add:

I was attempting to transition a 32x32 top-down ss13 codebase to 64x64 isometric, and I found that the south-facing sprite of a human captain has the actual human replaced with something random consistently.
generally a different bug it seems, since the above glitches affected multiple objects(turfs) and they can't directly be reproduce, If your problem can be easily reproduce, it may be fairly easy to spot the problem. The random icon appearance changes may be related to the initial problem which would be nice since the initial problem has no direct triggers for smooth debugging.
When you're seeing the wrong icon, does switching to or from software rendering mode fix the problem (even if it's just in the other mode)?
The problem occurs both in hardware and software mode
In response to Monster860
And switching between doesn't show any difference? That is, the same wrong icons are still wrong after you switch?
Yes
Okay, so that's interesting. The most likely explanation for this is that somehow, DS is overwriting frames of the icon with another icon after loading both. That is, I don't believe at all that this is .rsc corruption; I think it's strictly a client issue. I haven't seen any info yet that would explain why this is happening, but I'll keep looking.
Page: 1 2