Skip to content
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

Suggestion: custom RegistryEntryLists for modders and datapackers to use #3372

Open
TelepathicGrunt opened this issue Oct 7, 2023 · 6 comments
Assignees

Comments

@TelepathicGrunt
Copy link
Contributor

TelepathicGrunt commented Oct 7, 2023

Based on this discussion here:
#3310 (comment)

Some people may want Fabric API to modify RegistryEntryLists to allow for tag intersections and other behaviors. This would allow modders to make a worldgen structure json file be able to spawn in biomes that are tagged as cold AND overworld. Thus not needing the current combination tag in that Tag Unification PR as each person can just specify the intersection in the structure json file directly.

The RegistryEntryLists will still support the vanilla format. But if player or modder enters a specific format that Fabric API specifies, it'll use Fabric's custom RegistryEntryLists which then can support all kinds of operations between tags.

Neoforge/Forge already has an existing implementation of this so there is precedence for this in other loaders: MinecraftForge/MinecraftForge#8928

Up to Fabric if they want to pursue this idea or nah.

@apple502j
Copy link
Contributor

@TelepathicGrunt One question, are you requesting a direct port of Forge's spec to Fabric? Or, only intersections?

(Also, I recommend you join the Fabric Discord since that is where many discussions take place.)

@TelepathicGrunt
Copy link
Contributor Author

TelepathicGrunt commented Oct 9, 2023

@apple502j Mainly intersections but figured storage blocks is a large one that be best present on both. I think PR is in solid spot now for what tags are present for each PR.

Some tags will remain on one PR and not other if is it too niche or other reasons like the tool action tags just added to here that will never get accepted into Neo because Neo has a Tool Actions API instead.

If there’s any remaining tag on one PR you feel should be present as well on the other PR, lmk. Or if there is a frequent mod-defined tag that is missing from both that would be beneficial to have.

@apple502j
Copy link
Contributor

@TelepathicGrunt Ok, in case it wasn't clear, I was talking whether the entire custom RegistryEntryLists should be ported. Also, I suppose we should use the same serialization format?

@TelepathicGrunt
Copy link
Contributor Author

@apple502j oh shoot I thought I was on the tag Pr. Sorrry

@TelepathicGrunt
Copy link
Contributor Author

Anyway, on the RegistryEntryLists thing, it’s up to you all on what you all want to do with this. The end result that could be helpful for modders and players is the ability to do tag intersections in structure json and other places that takes in a RegistryEntryLists. This issue report is just describing one way that Forge did but if you all prefer another way to accomplish that goal, that’s fine. Doesn’t matter if same or different format. I’ll leave that up to whoever decides to implement it lol.

@apple502j
Copy link
Contributor

I think the design there is mostly alright, of course we probably don't want to deal with the mess associated with copypasting their code. I'll see how this goes. Will be added to the Registry Sync module.

@apple502j apple502j self-assigned this Oct 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants