Descriptive Problem Summary:
/mutable_appearance doesn't keep its direction when used as an overlay/underlay and instead uses parent's (an atom or image to which we added /mutable_appearance as an overlay/underlay) direction.
Expected Results:
/mutable_appearance uses it's own dir just like /image
Actual Results:
/mutable_appearance uses parents dir
Does the problem occur:
Every time? Or how often? Every time
In other games? Any game that uses /mutable_appearance, I assume
On other computers? Yes
When does the problem NOT occur?
Occurs all the time
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.)
No idea, considering code comments on /tg/ codebase of SS13 I assume it's a problem since /mutable_appearance was added
Workarounds:
Use /image instead
ID:2805427
 Jul 19 2022, 12:32 pm
|
|||||||||||||
| |||||||||||||
To be clear we absolutely rely on this behavior.
If this is in fact a bug fixing it would lead to our human rendering system yorking blood and dying | |
I made a small demo to show you how it works:
https://drive.google.com/file/d/ 1blLTtN56ROyb9eNStg-XLafgWrn1qqQB/view?usp=sharing | |
overlays and underlays do not use mutable appearances, they can only use appearances. not even icons/atoms/etc can be used.
byond wise, the following two lines of code are the same thing. thing.overlays += mutable.appearance Whenever you add anything that is not an appearance to an overlay list, byond converts it to an appearance. visual_contents in the only way to use mutable_appearances like you want to use them. | |
There's actually an internal bit that says the dir needs to be kept, and it's applied in certain situations. Without knowing the details of how you're using this I can't look into it further.