Beacon Improvement Idea
hammy275 opened this issue ยท 2 comments
Instead of the system we have now, there would be every effect option that one could pick (at max-tier, there would be 10 options, 5 for each effect at level 2, and 5 for the effect + regen, with an II or the regen heart at the bottom right of the icon to show which is which).
A player would grab the option with one hand, have the payment material in the other, then put them both into the beacon at the same time, which would cause the effect to change.
I'd very likely have to keep the old system around for non-VR players, so adding an option to use that system for VR players wouldn't take much.
Since having both of these in the same ImmersiveBeacon
class would be an absolute nightmare, I need to devise a system for swapping immersives on the fly. I have a few ideas, listed in the order I like the most to least, though which one to go with is the question I'm still thinking on, especially given #273:
- Instead of holding a list of Immersives we iterate through, we instead hold a list of immersive
Supplier
s. This has the downside of being by far the most work to implement, but makes it extremely intuitive how to implement "switching" Immersives (simply return a different immersive instance from the supplier). - `Allow "un-registering"/"registering" immersives. This is less hack-y, but comes at the downside of mods needing to manage swapping immersives out more separately from ImmersiveMC, and means there isn't a single field to look at for getting a singleton reference to an Immersive.
- An
AbstractImmersive
implementation that does nothing but forward function calls given to it to an immersive stored in some field it has. This has the upside that the immersive only needs to be registered once, but is quite hack-y, and means if I make a new method for immersives, if I forget to forward it, issues can and will arise.
I think most of the above do genuinely complicate the API in a way that really isn't ideal. We should either:
- Make
ImmersiveBeacon
support both (or make the new one support non-VR) - Do the proxy system similar to the third bullet point above, but only for the beacon, and not part of the API.