space-wizards
Replace sprite layer keys with a LayerKey struct
This adds a new LayerKey struct that is meant to be used when working with sprite layer keys instead of working with string, enum, or object keys. This should generally make it easier to work with layer key data fields. Previously that always involved a decent bit of boilerplate where you would have to manually use IReflectionManager to try parse a string key as a possible enum key. Now you should be able to just have a [DataField] LayerKey Key and use that directly.
The new struct supports implicit casts from strings & enums. So while this is a breaking change, it doesn't seem like it actually needs a content PR.
Other changes:
- Separated various "TryGet" sprite system methods into a non-logging "TryGet" and an error logging "Resolve" method
- This also removes support for object keys, which were already disincentivized in #5602 by just not having overloads for methods that take arbitrary object keys. Now they will start throwing exceptions.
Supersedes #6025
These keys are not exclusively used by SpriteComponent. It seems like we should have a solution that covers other solutions too?
Hence why I originally used Objects to cover this. So long as PrototypeCopyToShaderParameters.LayerKey can HumanoidVisualLayer data, I am happy :woman_shrugging: Any way I can help with this? It's been sitting for quite a while now.
Any way I can help with this? It's been sitting for quite a while now.
You can make a new PR that supersedes this one.
Honestly, after looking at my changes in the superceded PR over the last few hours... I'm not actually sure I could do this any better than it is done here. The use cases for layer keys, as far as I can tell, are exactly two: Strings and Enums. Besides doing exactly this, with a proper struct to handle that data in expected ways..? The only other option is object, which can handle arbitrary data - but seems to not be desired here. Mind you, while I am not new to this, I am also not the most experienced programmer, and it's very possible I am missing something - so I could very well be wrong. :woman_shrugging: Will give it another look, but... I don't see much room for other approaches '^_^