Descriptive Problem Summary:
In certain circumstances, BYOND fails to update an image properly when using browse_rsc().
Numbered Steps to Reproduce Problem:
Using code linked below:
Instructions: (with cache cleared of previous runs of this code)
1. Start with the 'A' object. Send it to the browser: it's red. Try all the different colours and all works well. Change it back to red and send it to the browser.
2. Now try the 'B' object. Send it to the browser: it's green. Now make it red, and send it to the browser. It stays green! Blue, yellow, and back to green still work.
3. Now try the 'C' object. Before sending it to the browser, make it red. Now send it. It's red. Change it to blue, send it, make it red, and send it again. It stays blue.
4. Make the 'A' object yellow and send it. Now make 'C' red and send it. C is now successfully red.
If "filename.png" does not exist in the cache, then browse_rsc() works properly.
If "filename.png" *does* exist(even from a previous session), then what happens depends on what icon data has been browse_rsc()ed in the current session.
Assuming, say, "D.png" does exist in the client's cache folder:
There seems to be something cache-like going on. If 'A' has been sent with the red icon, then attempts to set "D.png" to also be the red icon fail. Other un-used icons work fine. If 'A' then has its icon successfully changed to another colour and browsed, then it's now possible for 'D' and "D.png" to be assigned the red icon.
It's as though a cache has determined that red was no longer in use and so everything worked. Maybe if an icon is cached, it tries to get it from the cache rather than sending it again, but it's failing silently. Or maybe it's determining wrongly that "D.png" is already the same as the red icon, if, say, "A.png" has been browsed as the red icon.
Code Snippet (if applicable) to Reproduce Problem:
When browse_rsc() sends an image, that the image always gets sent.
If a particular icon has already been sent, and "filename.png" already exists, sending that icon as "filename.png" fails, with "filename.png" retaining its previous icon.
Does the problem occur:
Every time? Or how often?Every time
In other games?N/A
In other user accounts?Untested
On other computers?Untested
When does the problem NOT occur?
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
Problem still occurred in 400.952. Not tested with pre-alpha-channel .dmi files.
Have browse_rsc send files named on a per-unique-icon basis. One possibility involves naming the file based on "\ref[src.icon]". However, this would require investigation into things like icon_states and icon variables like var/icon/browsericon. If icon_states don't change that reference, they will run into similar problems as above. A custom browsericon variable for (maybe) each object in the game seems very inefficient, and a quick test shows that references to icon variables within procs are quickly re-used.
Another possibility is to create a kind of browseRscCache datum, which would handle mapping unique icon&state resource objects to filenames.