VV editor can now see /appearance types #10885
Conversation
|
Putting this on high priority - It's helpful to sort out wrong overlays from stuff, which means good for aiming better performance. |
|
Okay, I figured how to identify |
|
I'll fix more tomorrow. It only needs to do a few nitpick points |
|
Actually I did already. This is now ready for the full review again. |
|
|
||
| /// appearance type needs a manual var referencing because it doesn't have "vars" variable internally. | ||
| /// There's no way doing this in a fancier way. | ||
| /proc/debug_variable_appearance(var_name, image/appearance) |
There was a problem hiding this comment.
If the thing coming in isn't an image, then it shouldn't be typed as an image
There was a problem hiding this comment.
Welcome to Byond
There was a problem hiding this comment.
At least it's a single case. I converted it to movable.
There was a problem hiding this comment.
thats even worse, its definitely not an atom/movable. Its a variable type and should be untyped, with the type being resolved later on.
There was a problem hiding this comment.
Why even bother typing it with the wrong type, just use the unsafe access operator, :, and keep it untyped
|
Just going to wait and see what the TG folk have to say, since there are some things in here which seem really cursed but I can't think of many immediately better ways to do them due to the lack of a solid appearance type. |
This was resolved in the implementation we went with going with by |
Feels super cursed, but theres probably not a whole lot we can do since byond gives no access to the appearance type, the only alternate would be to entirely use unsafe accesses with the : operator instead of typing it to an incorrect type. I'm slightly more partial to that, since we are usign types wrong and expecting failures anyway, but since its just a VV extension, if it works, it works. |
yeah some maintainers who weren't up to date on reviewing their prs got slightly :( with me but i figure that people will iterate on this framework and make it better in the long run (if it sucks for the time being at least we made it in a way to catch any failure we could have). do flag us down if someone tries to enhance it here. thanks |
* appearance debug code * It's not actually working * clean up * Putting important comments * nitpicking * Improving QoL * fixing the spelling * isappearance actually does its thing * static to read only * real appearance type and image type * it actually fixes * nitpick * Try catch isn't necessary anymore * Clean up v2 * convert into movable * change them all to unsafe access * Follows TG review * Makes sprite file viewable * fixes correct var name * Final version * Final version_real * Fix comment
About The Pull Request
VV editor can now see /appearance types
These ones are kinda blackboxed, and we have no idea what these are in general.
I made it investigatable, but because of the nature of /appearance, the code is super janky, but it's inevitable curse.
I left an important comment inside:
Comment
Why It's Good For The Game
Debugging tool is good for us
Testing Photographs and Procedure
I can see things are duplicated inside.
some /appearance types are editable in specific situations (usually client only images like atom_hud)Actually it was /image and vv editor bug thought it's appearance. This pr fixed that too
Changelog
🆑
code: /appearance type references are now investigatable in vv editor.
fix: Fixed /image ref was identified as /appearance in vv editor
/:cl: