Problem: OC2 compat in IE and Forge registries

[malte0811]

I wanted to add OC2 compat to Immersive Engineering and ran into the following annoying problem:

• If I've understood the API correctly I need to register a BlockDeviceProvider (which then calls our shared code for CC and OC2 compat). Since this is a Forge registry I need to know if OC2 compat should be enabled before the RegistryEvent.Registers fire.
• IE has config options for all compat modules, both to be able to disable the module if it's broken on our end and to be able to disable compat if some mod breaks API. So we only know whether we want to enable OC2 compat once common configs are loaded.
• But Forge doesn't want conditional registrations to Forge registries, so configs aren't loaded until after the RegistryEvent.Registers have been fired and the registries are fully locked.

I don't think there's any good way to deal with this from IEs side: I could manually load the common config early, or make a new config file that doesn't go through Forge's system, but neither of those options is great. How much do you actually rely on BlockDeviceProviders being a Forge registry? If you don't really need it making them a non-ForgeRegistry would probably be the cleanest approach.

[fnuecke]

Thanks for the feedback! Hmm, couldn't the config be checked in the provider? I.e. always register the provider, but return Invalidatable.empty() if the config says the integration should be disabled?

Using registries just feels like the logical thing to use for... registering things, so unless that's a hard no-go I feel it'd be nice if they could be leveraged for this? I definitely am open to have my mind changed here though, I'm probably a little out of touch when it comes to current best practices in MC modding nowadays.

[malte0811]

Hmm, couldn't the config be checked in the provider? I.e. always register the provider, but return Invalidatable.empty() if the config says the integration should be disabled?

In principle yes, but:

1. (Not really serious) It doesn't match our existing system of compat modules which are only loaded if the module should be enabled.
2. If you break API at some point (it's still an early alpha after all), users would not be able to use the old IE with the new OC2 at all, since it unconditionally tries to access OC2 classes. Usually setting the config option to false would mean that the compat module class isn't loaded at all, so you could use new OC2 with old IE as long as you don't mind the IE machines not providing devices.

Using registries just feels like the logical thing to use for... registering things, so unless that's a hard no-go I feel it'd be nice if they could be leveraged for this?

Would it be possible to use the vanilla Registry/MappedRegistry classes for this registry? That seems like a reasonable compromise between "registering things should use registries" and "registries come with problematic restrictions" to me. They don't have all the features of ForgeRegistry, but also don't have the requirement of registering really early.

I definitely am open to have my mind changed here though, I'm probably a little out of touch when it comes to current best practices in MC modding nowadays

I don't think "universal" best practices really exist in modding. The Forge team has various things that they consider to be best practices, some of which aren't actually done by any large-ish mod and some of which are plain wrong IMO. No idea what they'd think about this particular problem.

[fnuecke]

If you break API at some point (it's still an early alpha after all), users would not be able to use the old IE with the new OC2 at all, since it unconditionally tries to access OC2 classes. Usually setting the config option to false would mean that the compat module class isn't loaded at all, so you could use new OC2 with old IE as long as you don't mind the IE machines not providing devices.

Would it maybe make sense to have a condition for registering integrations based on installed mod version, regardless? E.g. whenever any mod has a major version bump, assume API incompatibility, don't load integration? This way the registry registration is not config reliant, but mod version reliant, which should be technically the same as mod presence reliant, or am I missing something?

Would it be possible to use the vanilla Registry/MappedRegistry classes for this registry? That seems like a reasonable compromise between "registering things should use registries" and "registries come with problematic restrictions" to me. They don't have all the features of ForgeRegistry, but also don't have the requirement of registering really early.

I guess -- I just assumed allowing to use the DeferredRegister stuff would be the most convenient. I guess how OC1 did it, with static methods in the API, which get hooked up in the mod's early init, isn't really feasible anymore, due to the async mod loading? Are there better ways to work around this than IMCs?

[malte0811]

After looking around a bit it seems like IE is the only mod that (still?) has config options to stop all compat code from loading, so I just implemented your suggested approach of always registering the BlockDeviceProvider and returning empty when compat is disabled.

IE/OC2 compat is mostly working now, but I ran into a second problem: RPCDevice#suspend is not called on the devices I'm providing, apparently because RPCDeviceList doesn't pass the suspend call to its sub-devices.
I need suspend (or something similar) since IE machines provide a way for computers to override redstone control, i.e. to disable machines even when they should be running according to the RS signal. When the computer is detached (in some sense) I need to clear that state, since otherwise you'd end up with someone taking a computer to someone elses crusher, turning it off, and suddently you have a crusher that never runs for no apparent reason. Is suspend the right way to achieve this, or should I be using something else?

[fnuecke]

Cool, I'll keep the registration topic in the back of my head and maybe revisit in the future, but good to know it's ok for now!

Great to hear you're making progress there, and thanks for finding the missing forward in the RPCListDevice! That said, I think suspend doesn't perfectly fit your use-case. suspend also gets called on chunk unload, it's a pause not a stop. From how I understand it, you'd only want a callback when the computer is actually fully stopped (due to shutting down or being destroyed). I'll look into adding mount and unmount methods present in the VMDevice to the RPCDevice. Those are then "VM starting up, initializing devices/device connected to running machine" and "VM stopping, releasing devices/device removed from running machine".

If you have any general feedback on the API, things that are unclear or inconvenient, I'd be interested in that, too, btw :)

[fnuecke]

0.0.4 has the new methods, RPCDevice.mount() and RPCDevice.unmount(). unmount is the one you'll want, from what I understand.

[malte0811]

Thanks! Yes, suspend wasn't ideal, but it was the only vaguelly appropriate method that was available at the time. Now the only problem is keeping track of persistent computer control for the machines, but that's entirely on our end.

In general the API seems to work very well for our usecases, I was able to hook it up to the "generic" code I wrote with mostly the CC API in mind very easily.

[fnuecke]

Awesome, happy to hear that!

[Hawk777]

I need suspend (or something similar) since IE machines provide a way for computers to override redstone control, i.e. to disable machines even when they should be running according to the RS signal. When the computer is detached (in some sense) I need to clear that state, since otherwise you'd end up with someone taking a computer to someone elses crusher, turning it off, and suddently you have a crusher that never runs for no apparent reason.

I thought that was exactly how the OC integration in original IE worked. Anyway, isn’t there a possibility that people might not want their intentionally disabled machines to start running just because a cable got broken somewhere temporarily?

That aside, very glad to hear of IE hopefully gaining OC2 support sometime!