ID:113716
 
Resolved
Use of new/icon() without a source icon caused client-side icon operations to fail. In addition, ftp() did not deliver client-side icons in the proper .dmi format.
BYOND Version:483.1092
Operating System:Windows 7 Ultimate
Web Browser:
Applies to:Dream Seeker
Status: Resolved (484)

This issue has been resolved.
Demo: http://files.byondhome.com/tenkuu/icon%20bug_src.zip

There seems to be an issue with the new client icon processing and icon.Insert(). Run this demo using version 483.1092 and it will generate a bad icon. Trying to open it using Dream Maker gives the error 'Unable to read test.dmi'. Trying to open it via Paint gives the error 'Paint cannot read this file. This is not a valid bitmap file, or its format is not currently supported.'

Downgrading to version 492.1091 and running the demo produces an icon that be read by both Dream Maker and Paint.

It doesn't seem to be related to named arguments. I removed the use of those and it's still not creating a proper icon.

Basically the snippet in the demo is used to create mirrored icons in NEStalgia, and this is a screenshot showing how it's rendered in game using version 483.1092: http://files.byondhome.com/tenkuu/screenshots/ mirrorglitch.png
Just for reference on that bugged screenshot, here is how the mirrors are supposed to look: http://files.byondhome.com/SilkGames/nes/v120/mirror.png
This actually seems to be ftp(), not Insert(), that's having the problem.
tenkuu will have a better answer, but that may be a separate issue. We don't use ftp() anywhere in the NEStalgia code, and that mirror glitch is happening in worlds running 483 but not in 482.
We do assign this created icon to an atom's icon variable, which calls fcopy_rsc? It probably has to do with that and all related procs such as ftp() and fcopy(), which both save bad icons.
I found the issue, which turned out not to be a problem with Insert() at all but with null icons. As a workaround, I recommend replacing all calls to new/icon() that don't use a source icon with ones that use a blank source that has no states at all. Functionally it should operate the same way it did in 482 but it'll work correctly with the DDMI format.

As for ftp() that's a separate issue but I've just lumped both fixes together under this report.