OpenMods / OpenPeripheral

https://openmods.info
MIT License
67 stars 25 forks source link

Reject OpenPeripheral #138

Closed EngineerCoding closed 10 years ago

EngineerCoding commented 10 years ago

Is there any way how I can reject OpenPeripheral from mounting my blocks? Since there is no real API documentation (seriously, work on that) I cant really figure it out :/

If it is not possible, make an interface IReject or along the lines of that, because I dont want to let my block to be mounted by OpenP..

Thanks

mikeemoo commented 10 years ago

"seriously, work on that", this mod is open source. Please refrain from telling us what to do. You're far less likely to receive help.

boq commented 10 years ago

Just implement IPeripheral in your TEs. We won't touch it. If you don't define your own peripheral functionality, there is no need to disable autogenerated ones.

EngineerCoding commented 10 years ago

Mikeemoo: Okay, I know it sounds rough, but you as maintainers know better what those API interfaces do than me. I have to go through all code for a precious amount of time, since I have to go very deep to document it properly. Im sorry for my rough speaking here, but in my opinion thats kinda the job of you maintainers (who develop it more than me). Though I do want to give my apologies.

boq: That is just problem, Im using a wrapper to make it easier to make peripherals. Because of that Im using the dan200.api.IPeripheralProvider to actually make it look like a peripheral. That way, you guys cant see its a peripheral but it actually is. Thus I need something reject OpenP from my peripheral, otherwise only OpenP's adapter is the peripheral. And that is what I really dont want :p

I could override the original variable from CC via reflection which holds all the providers and make sure my peripheral is first to be mounted, but thats an ugly coding style in my opinion. Thats why I wondered

boq commented 10 years ago

dan200.api.IPeripheralProvider is CC1.6. We don't support that version yet.

EngineerCoding commented 10 years ago

Doesnt matter, because I could have written this before CC 1.6. Then I would mount my own TE, but cant because you guys are probably already loaded and take over all TE's. Because you directly register on TileEntity.class and CC treats it like: 'when x comes first Ill just use that.' Makes sense on CC's side, not on any other mod which uses IPeripheralHandler and when OpenP is loaded.

Im probably not the only one who thinks its really usefull to have this.

After thinking about this, Im not a smart man. We have dependencies, so I can load before OpenP and dont worry about this. That way OpenP can also easily be broken, because it doesnt get called because someone is first. But thats a problem outside OpenP.

boq commented 10 years ago

In versions before CC1.6 there are two alternatives to implement peripherals:

Also, we are registering handlers in postInit, i.e. as late as possible. But due to CC inner workings (hash map), we can't predict which provider gets called. Also, this is why we can't implement that right now.

We had similar situation with Thaumic Tinkerer, which ended with author adding adapters to OpenPeripheral.