ImmersiveMC

ImmersiveMC

683k Downloads

Beacon Improvement Idea

hammy275 opened this issue ยท 2 comments

commented

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.

commented

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 Suppliers. 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.
commented

I think most of the above do genuinely complicate the API in a way that really isn't ideal. We should either:

  1. Make ImmersiveBeacon support both (or make the new one support non-VR)
  2. Do the proxy system similar to the third bullet point above, but only for the beacon, and not part of the API.