Minecraft Version

1.18.x

Version

1.100.4

Details

https://github.com/cc-tweaked/CC-Tweaked/blob/mc-1.18.x/src/main/java/dan200/computercraft/shared/peripheral/generic/GenericPeripheralProvider.java#L48

getCapabilty is retrieved without provising a side, but a side is available, so that should be passed as well.

This is intentional, as computers are meant to have a view of the whole block entity rather than a specific face. For instance, you should be able to see all slots of a furnace, rather than only those accessible to the side the modem/computer is on.

Would a PR be ok that uses the sided capabiltiy if no cabality for null side is returned? it would only increase compatiblity.

Eeeeh, I guess?? Though probably also worth reporting an issue on whichever mod returns something for a side but not for the null/internal side - that's a bug on their end.

Its my own mod and a few machines cant realy do that since they are user configurable - its hard to explain. I would need some kidn fo merge for all sides but that would cause overlap of some methods.

I'm not super familiar with your APIs, but I don't think you'd need to merge in many cases. My understanding of HelperEnergyTransfer.getNeonCap/getSupportCap is that they're just restricting which sides energy is accepted from? It feels like it should be fine just to return the underlying power instance for the null side? Obviously not my code though, so may be entirely wrong.

I'm not super familiar with your APIs, but I don't think you'd need to merge in many cases. My understanding of HelperEnergyTransfer.getNeonCap/getSupportCap is that they're just restricting which sides energy is accepted from? It feels like it should be fine just to return the underlying power instance for the null side? Obviously not my code though, so may be entirely wrong.

for neon & support yeha. but the logisitc cap right now is the difficulty, as it is defined per side and has no real internal access. I will see what I can do with that. But huge thanks for mergign that so quickly.