First, I want to thanks for some new API methods, especially for Details API, which is nice addition to have.

Returning #1424 I want to suggest some new API methods, that can be implemented inside CC:T to make writing addons for this mod easier and can be useful additions.

Extract ITurtleAccess from common code

This is not big requests, but absence of such API forces one to create abstract method in multi-loader code and than just implement same method in loader-specific code with nearly same code. Probably exposing ITurtleBlockEntity or just a subset of this should be sufficient enough.

Useful use-cases for this will be transfering different information between turtles, for example, transfer collected experience or fuel.

Extracting Peripheral from blockPos

So, this one probably is little harder to implement, but in general it would be nice to have ability to get peripheral from world block. This can simplify different peripheral_hub implementations for different mods.

Extract ITurtleAccess from common code

So my inclination here is to expose this as a capability/block lookup rather than as an interface. That is the more Modded^TM way to do things, though I realise doesn't actually reduce the amount of multi-platform code you have (though does mean you no longer have to rely on internals).

Thoughts?

Extracting Peripheral from blockPos

To handle this in a cross-platform way in CC:T, we have a ComponentAccess interface (see also createPeripheralAccess). This provides a way to get peripherals (or any other 'component') from the adjacent blocks.

I quite like this design, as it also handles things like caching and invalidation under the hood (which is especially important on the Forge side with cap invalidation), but I don't know if it's too high level for what you need?

So my inclination here is to expose this as a capability/block lookup rather than as an interface. That is the more ModdedTM way to do things, though I realise doesn't actually reduce the amount of multi-platform code you have (though does mean you no longer have to rely on internals).

My proposal to expose this API was mostly about removing rely on internals parts, so I am pretty fine with this solution.

I quite like this design, as it also handles things like caching and invalidation under the hood (which is especially important on the Forge side with cap invalidation), but I don't know if it's too high level for what you need?

So, this request is mostly related to "I want to make another wireless-like wired peripheral_hub" (which I actually did).

But the way it works is pretty ugly, it just ignores capability invalidation for forge and for fabric it uses API that clearly states it shouldn't be used for this and ignores generic peripherals (which is fine for me, because I overwrite this system in UPW anyway).

So, I would like to have a some better way to be able to handle this correctly. It seems that having ComponentAccess exposed as part of API can help me to archive this goal, so if this is possible to do, it will be a nice addition to CC:T API on my opinion.