Registry sync v2 - API #167
Conversation
thecatcore
added
enhancement
- differentiate "synced" Index-Key-Value registries from simple Key-Value registries - start preparing registry remapping
… missing when it should.
… missing when it should. (again)
…ween their numerical ids.
thecatcore
force-pushed
the
feature/registry-sync-v2/api
branch
from
d9996b3
to
3a74c69
Compare
|
|
||
| @Override | ||
| public PacketByteBuf writeCompound(NbtCompound compound) { | ||
| return this.writeNbtCompound(compound); | ||
| public PacketByteBuf writeCompound(NbtCompound tag) { |
There was a problem hiding this comment.
tag -> nbt / compound
| @@ -71,6 +71,10 @@ public String toString() { | |||
| return this.namespace + ':' + this.path; | |||
| } | |||
|
|
|||
| public String toTranslationKey() { | |||
| return this.namespace + "." + this.path; | |||
There was a problem hiding this comment.
unused - any reason why we need this? items, blocks and such have their own format for translation keys
There was a problem hiding this comment.
It's used later in the registry implementation to set the translation key automatically, which was something already done in registry sync v1 previously.
| public PacketByteBuf writeCompound(NbtCompound compound) { | ||
| this.writeNbtCompound(compound); | ||
| public PacketByteBuf writeCompound(NbtCompound tag) { | ||
| this.writeNbtCompound(tag); |
There was a problem hiding this comment.
tag -> nbt / compound
| public PacketByteBuf writeCompound(NbtCompound compound) { | ||
| this.writeNbtCompound(compound); | ||
| public PacketByteBuf writeCompound(NbtCompound tag) { | ||
| this.writeNbtCompound(tag); |
| @@ -20,6 +20,7 @@ | |||
| import net.legacyfabric.fabric.api.util.Identifier; | |||
| import net.legacyfabric.fabric.api.util.SinceMC; | |||
|
|
|||
| @Deprecated | |||
There was a problem hiding this comment.
could add a javadoc comment here, stating what should be used instead
| @@ -20,6 +20,7 @@ | |||
| import net.legacyfabric.fabric.api.util.Identifier; | |||
| import net.legacyfabric.fabric.api.util.SinceMC; | |||
|
|
|||
| @Deprecated | |||
There was a problem hiding this comment.
ditto, same for the rest of the v1 api
| import net.legacyfabric.fabric.api.registry.v2.event.RegistryEntryAddedCallback; | ||
| import net.legacyfabric.fabric.api.util.Identifier; | ||
|
|
||
| public interface Registry<T> extends Iterable<T> { |
There was a problem hiding this comment.
Registry -> RegistryExtensions? I don't think its a good idea to keep it as the same name as an existing minecraft class
There was a problem hiding this comment.
RegistryExtensions doesn't fit in this case as this interface can be used to implement a custom registry implementation.
However maybe we should prefix those classes with either Fabric, LF or LegacyFabric to differentiate them from vanilla classes as you've said.
New registry api, more extensible, only handles registry infrastructure (remapping included).
Individual registries for content are moved to their own module in other pr depending on this one.