MCMP3 API Specification Discussion

[amadornes]

Comments and discussion on the working draft of the MCMP3 API spec are welcome, both here and on Discord.

You can find the code here, and some basic examples here.

---

FAQ:

But won't this API require a hard dependency on MCMP?

Yes.
The way this API is designed forces you to have a hard dependency on MCMultiPart.
This is intentional to make development of MCMP-compatible mods easier.

Is there a way to have a soft dependency?

Yes, SoftMultipart:
A library you can ship with your mod that will proxy calls to MCMP if it's installed, and fall back to either vanilla or custom behavior if it's not.
Its API will be almost the same as MCMP's, so that's the one that needs to be written first.

When will MCMP3 come out?

I have no clue! Hopefully soon, but it all depends on the kinds of feedback I get and how quickly I can get the actual implementation working.

[nikita488]

I think BlockSlot can use ForgeRegistry instead of cache?

[amadornes]

I think BlockSlot can use ForgeRegistry instead of cache?

There's no point in using a Forge registry if I'm not going to allow custom types to be added (and there's no need for them), and there's no need for IDs because they're never stored to NBT or sent over the network.

Slots are purely used as an "alias" that you can use at runtime to reference several kinds of parts in a unified way, so I don't think adding a Forge registry for them is really needed.

[sirati]

I would prefer if cosmetic multi block parts, like faces, would be treated separately. That means pipes would define the whole subspace they occupy, but faces would indicate that they are 'cosmetic'/'puncturable', so the collision checker ignores their collision.

Alternatively, or at the same time, it would be good to have an IMultiPart method that is called after the collision check failed, to give the multipart a chance to overrule it.

Lastly, what is the current implementation state of this and i seem to not be able to find the Discord link on this repository.