CC: Tweaked

CC: Tweaked

57M Downloads

Being able to use generic peripherals alongside non-generic peripherals

Quezler opened this issue ยท 7 comments

commented

Basically just a way to bring some attention to TeamPneumatic/pnc-repressurized#1034

That mod adds peripheral methods to some of its blocks, but the inventory/fluid methods don't get bound because of it.
Creating this here in the hope that people have tried to figure this out before, and have knowledge of clean ways to do it.

More context can be found in the linked issue, this description is just the bare minimum summary of what the issue entails.

commented

There's a fair bit of historical baggage in PNC which is in big need of ... modernising.

Got some pointers to using the generic peripheral system?

commented

There's a fair bit of historical baggage in PNC which is in big need of ... modernising.

Yeah, I very much sympathise! I think a lot of computer mod integration is also originally written to support OC and CC, which definitely makes things easier from the implementers side but more awkward from the consumer's side. Which is fair - computer mods is (rightfully!) not the most important thing.

Probably should talk with fnuecke about some common API, so we can avoid this when OC2 is stable!

Got some pointers to using the generic peripheral system?

Basically you implement GenericPeripheral and add static classes to that method which target a specific type. So for instance, AbstractAirHandlingBlockEntity would look something like:

public class AbstractAirHandlingBlockEntityMethods implements GenericPeripheral {
    @Override
    public ResourceLocation id() {
        return new ResourceLocation( MOD_ID, "air_handling" );
    }

    @LuaFunction(mainThread = true)
    public static float getPressure(AbstractAirHandlingBlockEntity self, Optional<Direction> direction) {
        if (!direction.isPresent()) {
            return airHandler.getPressure();
        } else {
            LazyOptional<IAirHandlerMachine> cap = getCapability(PNCCapabilities.AIR_HANDLER_MACHINE_CAPABILITY, direction.get());
            return cap.map(IAirHandler::getPressure).orElse(0f);
        }
    }

    @LuaFunction
    public static float getMinWorkingPressure(AbstractAirHandlingBlockEntity self) { return self.getMinWorkingPressure(); }

    // Etc...
}

Then register that class with ComputerCraftAPI.registerGenericSource. I'm happy to have a go at a PR if that'd be helpful, though obviously no obligation to merge it if you think it's worse!

commented

Thanks! Actually looks pretty straightforward; I'll have a play and see how easy it is to adapt to it...

commented

Great. Feel free to ask if you've got any questions or complaints, happy to make some changes to the API if there's any awkward areas with it.

Closing this, as for now I want to keep explicitly provided peripherals and generic peripherals separate.

commented

The recommended way to do this is just to use the generic peripheral system to implement one's peripheral too.

However, it looks like PneumaticCraft have reimplemented their own Lua-method system on top of CC's ๐Ÿ™„, so that's probably not an option.

commented

#1093 as an some idea?

But in general, ye, this is pain sometimes. I just copy-pasting peripherals

commented

Sounds about right, i've read some fragments about it currently being a pain and that a rework was desired in the future ๐Ÿค”