Descriptive Problem Summary:
When attempting to copy/duplicate an icon (in my particular case, code functioning as a polaroid camera), if an atom has a dir other than SOUTH, and it's icon_state does not have a sprite for that dir, the atom comes back as being invisible (or black, in the case of turfs).
Expected Results:
I would expect the return to be the icon_state for SOUTH if no other sprite exists within an icon_state for the dir being evaluated for.
Actual Results:
It returns what I would assume to be the graphical form of null.
Does the problem occur:
Every time? Or how often? Every time dir is not SOUTH and the icon_state does not support that dir
In other games? I would assume so
In other user accounts? Yes
On other computers? Yes
When does the problem NOT occur?
When dir can be reliably accounted for beforehand in the code running the icon duplication.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Not to my knowledge.
Workarounds:
Writing code to attempt to evaluate the dir of the atom as SOUTH when you know the icon_state won't support other dirs.
| |||||||||||||
I guess there are two schools of thought on this: One is that if you did do a dir-based "cut" of an icon, you wouldn't necessarily want states included that didn't include the dir. The other is that a fallback to a default dir might be preferable.
I'm not sure how this should be handled when the dir in question is diagonal and the icon state has four dirs. | |
My thinking is that byond should have a built in fallback to the default icon_state if a sprite for the dir being requested does not exist, and put the onus on the projects to account for necessary sprites (I'm not sure if you would want to have it create a log as well). At least in TG's SS13, I cannot think of any instance where something has icon states for only the four dirs and could then get a diagonal dir through any means, aside from variable editing.
| |
I suppose falling back on a blank icon for each such state probably does make the most sense, and is unlikely (though not necessarily guaranteed) to mess up any existing projects.
| |
I edited my previous post, I meant default icon_state and dir for a sprite** if the requested dir's icon_state doenst exist.
E: Basically, I don't think byond should be returning a blank as it currently does doing what we are doing. It should return the icon's south default if it cannot return anything else, and if a project needs it to return that something else, it's on them to create the sprite for it. | |
I know this is bumping an old post but I've been trying to work around this issue.
It's frustrating that it works that way because it doesn't correspond with how DS interprets this same thing. If I have an object on a map that has a singular icon_state and I set it to have any direction, it will still show up on the map with the same icon_state. But now if I use darkcampaigner's very useful getflaticon() on that object, as in my specific use case, which takes the object's dir as the icon's dir: it will give an invisible icon unless that dir is SOUTH. And all that forces us to manually manage which icons have directional icon states and which don't. Or to use getpixel() extensively and rather hackishly to determine if we've been given an invisible icon. | |
http://s24.photobucket.com/user/AndroidSFV/media/ 41d6690f-fa9a-4063-bd3d-430bb89cf250.jpg.html?state=copy&sp= false
http://s24.photobucket.com/user/AndroidSFV/media/ Bug2_1.jpg.html?state=copy&sp=false
The above screens show two objects (only one of which has dir of south, the object only has an icon for south) and three mobs (only one of which has icons for the 4 primary directions, the crabs only have an icon for south). The camera object takes a photo but only the object with the south dir and the mob with icons for multiple dirs is shown, in addition to background stuff which can be considered merely control, if at all.
As far as I can tell, the code is good. It seems it is just returning a null value for the image when there is no icon for the dir the object has. If more info is needed, please say so.