Cardinal Components API V6

[Pyrofab]

Cardinal Components API V3 came out almost two and a half years ago, with very few breaking changes ever since. However, as time went on, some opportunities for improvements appeared - some of which may constitute rather large paradigm shifts.

This discussion is here to discuss the various possibilities, opportunities and pitfalls for such an update.

Here are some ideas :

• supporting codec serialization for components
• supporting off-thread component sync (read and write)
• simplifying partial component sync

Also some things I would like to shove in there :

• package rename (dev.onyxstudios -> org.ladysnake)
• maven group rename (maybe changing the maven structure for each module ?)

Paging @UpcraftLP, @forgetmenot13579

[forgetmenot13579]

To suggest another change, renaming ComponentKey to ComponentType to reflect (and allow) our adding functionality to that class other than simply acting as a key, such as storing Codec instances and potentially some networking information.

[EvieTheOwl]

Codec Serialisation Support Suggestions by @forgetmenot13579 #164

[forgetmenot13579]

We're already using ASM, so why not get funky with it for the partial syncing API?

void syncXXXX(MyAwesomeData dataOne, SomeDataClass dataTwo) {
  // Update the state of this component based on the contents of `dataOne` and `dataTwo`
}

Classes implementing AutoSyncedComponent can further implement methods similar to that shown above with some requirements:

• Each argument must be something we know how to read/write to a PacketByteBuf. This might be a primitive, NbtSerializable, or some new Syncable interface
• When multiple sync methods exist with the same argument types, both methods must have discriminants (the XXXX above)
• Methods must be void

I'd note that yes, these sync methods can have multiple arguments. This is especially useful for updating single entries in a larger map via a method like void updateEntry(String id, SomeValue value) { ... }.

We would then use ASM to create classes derived from these component classes with two changes:

• Create a new method syncXXXX$receiver with signature and method body matching that of the original sync function
• Override the original syncXXXX method to send a custom sync packet to the client

From there, we'll create an instance of this new class and discard the original. We would need to either enforce implementation of CopyableComponent on AutoSyncedComponent or accept using reflection to copy field values from the original component to our generated class.

This implementation will allow users of CCA to simply call their component.sync(myData) method and we will transparently intercept that call and effectively run the code they would expect to run on the client instead of the server. It also has the potential to be made context-aware, such that it behaves intuitively with #161.

[Pyrofab]

With 1.20.5 coming this week, I think the content of the V6 is more or less settled. I am still open to minor (possibly breaking) changes while we are in beta phase so I will keep this thread open for a little bit, but codecified components and partial syncs will have to be postponed.