-
Notifications
You must be signed in to change notification settings - Fork 12
Move shard type loading to datapacks #22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Also fix some stuff we missed in porting to 1.20.4 |
| FabricLoader.getInstance().getModContainer(ID).ifPresent(mod -> { | ||
| ResourceManagerHelper.registerBuiltinResourcePack(ScatteredShards.id("test"), mod, ResourcePackActivationType.NORMAL); | ||
| ResourceManagerHelper.registerBuiltinResourcePack(ScatteredShards.id("bc23-assets"), mod, ResourcePackActivationType.NORMAL); | ||
| ResourceManagerHelper.registerBuiltinResourcePack(ScatteredShards.id("bc23-data"), mod, ResourcePackActivationType.NORMAL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Synthetic respacks should be registered on the client side
falkreon
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I definitely said in discord that there is an opportunity to load ShardTypes from data, but it needs to only happen for new worlds that have no ShardType data - otherwise data clobbers the (not-yet-extant) ingame editor, and that's no good. ShardTypeLoader should hold its own counsel about what the data-defined default types are, and only pour them into the server library if ShardLibraryPersistentState detects a fresh world / library and calls addDefaultShardTypes.
There are also quite a few extra diffs here that I don't understand the need for.
For supporting usage over multiple events (see discussion in Discord)