Add OpenComputers API
egorchik007 opened this issue ยท 15 comments
Please add OpenComputers API.
It's another mod which adds computers to minecraft.
It's much better at perfomance (native runtime for Lua) and at some other features.
https://github.com/MightyPirates/OpenComputers
Translation: Please add support for the OpenComputers API and add all the functions that you made available for ComputerCraft.
I recommend using the prefabricated DriverTileEntity and ManagedEnvironment for easy implementation, and if you prefer the ComputerCraft way of registering methods, implement ManagedPeripheral on the ManagedEnvironment. Think of Driver as the CC IPeripheralProvider (except it's for one specific TileEntity class/superclass, it also works on interfaces implemented by TileEntities, see here) and ManagedEnvironment as the IPeripheral (especially when used in combination with ManagedPeripheral). To register a driver, just call li.cil.oc.api.Driver.add(thedriver).
Furthermore, it is recommended to implement NamedBlock on the ManagedEnvironment and to set the priority so that the name of the environment with the highest priority gets chosen for display (higher number means higher priority, so for your superclasses, set it to 1 and for subclasses to 2, 3 etc., for instance).
Hey @Vexatos, thanks for the more in-depth explanation.
After doing a bit of research, would it be alright if I just implemented SimpleComponent and ManagedPeripheral in classes I also implement IPeripheral in, and just have the OC methods call the CC ones? I want to try and do this with as efficiently as I can.
@aidancbrady That would work as well and would not require registering any driver. But there is a drawback: OC will propagate its network across all connected Environments (SimpleComponent being one). Depending of the CPU tier in your Computer, there is a certain maximum amount of components that may be connected at once. Meaning if you, for instance, implement SimpleComponent on your cables and machines, every single Cable and all machines connected to those cables and all cables connected to them etc. would become part of the network and ultimately crash the computer due to the exceeded component limit. By registering a driver, You force the player to place an Adapter block from OC adjacent to the block they want to interface with. This means that only the one block the player wants to interface with gets added to the network and thus the component count. This issue occured with PneumaticCraft until it got changed to the Driver-based system.
Note that you could still easily implement your methods in your TileEntity just like you want to and then just call tile.whateverthemethodiscalled() from the ManagedEnvironment. This would probably be the best way as all methods would be in one place (the TileEntity) but the component issue wouldn't occur.
In that case, what's the easiest way I can build on my already-existent CC integration by means of drivers? For my machines, right now I implement IPeripheral in the base machine class and take care of several common methods there, and then take care of the more specific methods (getMethodNames()/callMethod()) in functionality base classes (TileEntityElectricMachine for Enrichment Chambers/etc, TileEntityAdvancedElectricMachine for Osmium Compressors/etc). I currently just pass getInventoryName() as the peripheral name and everything works alright. Is something like this possible with the driver system?
@aidancbrady it is. When implementing NamedBlock on the ManagedEnvironment, you need to implement preferredName which you can just call tile.getInventoryName() in. For the methods in ManagedPeripheral, you could also just, as I said, directly relay them to their according methods in the TileEntity. See here for how to implement the Driver and here for how a basic ManagedEnvironment looks like. Just mind that you won't need to use @Callback methods when you instead implement ManagedPeripheral.
So it doesn't matter if I don't return the highest-level class in getTileEntityClass(), then?
Exactly. You can just return a superclass there and it will call createEnvironment everytime it finds a TileEntity with that superclass.
Then you cast the TE to that superclass and give it to the environment, and your Environment now has the tile it can relay all the methods to.
By the way, OC does have a maven repo.
Oh, another note: Convention for OpenComputers has component names lowercase and separated by underscores, so for instance geolyzer or tape_drive. It would be nice if your blocks adopted this convention. It's mainly there because then it is easier to call the component functions.
