ID:1694472

Keywords: byond, client, crashing
 BYOND Version: 506 Operating System: Windows 7 Ultimate 64-bit Web Browser: Chrome 37.0.2062.124 Applies to: Dream Seeker
 Status: Open Issue hasn't been assigned a status value.
Descriptive Problem Summary:
The BYOND client will crash when attempting to load an icon for chat purposes.

Numbered Steps to Reproduce Problem:
After an icon has been uploaded to the game it will crash the server when outputting chat text to clients.

Code Snippet (if applicable) to Reproduce Problem:

Expected Results:
The client shouldn't crash.

Actual Results:
The client will crash (not responding)

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

When does the problem NOT occur?
This problem doesn't occur when preload_rsc is set to 2 so that it downloads all rsc files.

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.)
I have no idea if it occurs in earlier builds.

Workarounds:
Set the client.preload_rsc = 2 any other settings 0 1 or URL will cause the same issue.

 Oct 7 2014, 9:19 am I don't actually have any info I would need to reproduce the problem, like a code snippet or an example project. Can you elaborate on how to trigger this?
 Oct 7 2014, 11:29 am That'd be difficult to explain cause it's kinda hard to reproduce solidly. I've only begun to scratch the surface. Basically though when it comes to any preloaded/built in icons the game doesn't seem to initiate a crash. It only occurs when icons were uploaded to the game. The crash always seem to occur when the icons are displayed in chat. Example: src << "\icon[icon(custom_icon ? custom_icon : icon, icon_form ? "[icon_form]_normal" : "normal")] [src] says: [text]"  Icons are usually updated to the server periodically and the project i'm working on is fairly big already so i'm not sure if that could be contributing to the issue or not since it could be too big or something. I also am not able to reproduce this bug locally. Only when it's hosted. I was able to duplicate it however when I hosted it locally via daemon and connect to it that way.
 Oct 7 2014, 2:53 pm I wonder if icon() is related to the fact that it's crashing. Ideally what you'd actually want to do is just use the cache reference, not create an /icon datum like that proc does. This is the form that's more kosher: src << " [src] says: [text]"  I'm curious if using that format solves the issue; it would be a big clue.
 Oct 8 2014, 2:39 am (Edited on Oct 8 2014, 3:03 am) I'll give this a shot today and see what occurs. Edit: The example you showed me appears to return no icon to the chat screen. I think I remembered an issue like this before. I'm gonna play with it and see what happens though. Edit 2: Now I remember why this has such an odd issue. This string seems ok with using icon from a mob but not from a file. so custom_icon would return nothing whereas the default icon would return fine. Edit 3: Figured I'd show some examples of what I did and explain it more. mob var/icon/custom_icon = null proc upload_icon() custom_icon = icon(input(src,"Which icon are you uploading?")as null|icon) say(T as text) for(var/mob/M in view(src)) M << " [src] says: [T]"  In the above example this only returns an icon when icon "icon" is used and not "custom_icon" despite both being the same. Not sure why that is.
 Oct 8 2014, 9:17 am Try using fcopy_rsc() on the custom icon first, if it's a local file on the server. Although if it's an uploaded file, it should already be in the .rsc and wouldn't need that. It might help to see what kind of value the ref is, though, so if you could print out the value of \ref[custom_icon] it would be helpful.
 Oct 8 2014, 3:27 pm How would you print out the value?
 Oct 8 2014, 5:10 pm world << "\ref[custom_icon]"
 Oct 9 2014, 4:15 am Thanks Super Saiyan X. The print value returned as [0x21000501]
 Oct 9 2014, 6:33 am I would definitely do fcopy_rsc() first. In theory the datum should work for output, but you're always better off sending an actual cache file. Though again, with text output you can use the raw img tag and just include an iconstate attribute, so there really should never be a need to use icon() just to get a specific state--only a specific dir. Of course I still want to fix this if I can. A test case that reproduces it reliably would be good.
 Oct 10 2014, 5:15 pm Yeah it's kinda strange... i'm not familiar with fcopy_rsc() should this be done immediately when custom_icon() is uploaded? or should this be done during text output? I assume the first but I wanna make sure. I didn't know it was required heh. I can probably play with it more to figure out what the best way to handle it is. Sorry about the delayed response had some stuff to do today. Edit: It occurs to me that if I do fcopy_rsc() it would for the most part be okay but there's an issue in which updates to the rsc() can typically occur when I'm adding different music/sounds or tinkering with any icons really... I forget if the map is involved in the rsc but usually I wipe it anyway when the map has been altered. Wouldn't this cause an issue still?