You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mojang's datapack stuff has a tradition of throwing whenever it finds registry entries not actually present.
This makes sense for things like recipes/advancements which are useless if the named entries aren't actually there.
However, for tags, it's useful for integration purposes for a mod to predefined a bunch of foreign mods' blocks/items in their own tag json. This means if that tag is loaded where one of the foreign mods isn't present, it throws and none of the entries in the file load at all.
How do we feel about patching the loader to just continue on missing entry instead of throwing?
The text was updated successfully, but these errors were encountered:
No conditions will not be added. That ads way to much complication to the system.
The only thing that is needed is a 'optional' identifier.
Similar to vanilla's '#' identifier for nesting tags.
They use ResourceLocations, which means [a-z0-9_.-] is the possible values for the namespace/beginning of the values.
Perhaps adding a ^ prefix for 'optional' entries.
Also it's been debated to expand the tag system to have a "remove":[] entry. Instead of the overwrite boolean.
Mojang's datapack stuff has a tradition of throwing whenever it finds registry entries not actually present.
This makes sense for things like recipes/advancements which are useless if the named entries aren't actually there.
However, for tags, it's useful for integration purposes for a mod to predefined a bunch of foreign mods' blocks/items in their own tag json. This means if that tag is loaded where one of the foreign mods isn't present, it throws and none of the entries in the file load at all.
How do we feel about patching the loader to just continue on missing entry instead of throwing?
The text was updated successfully, but these errors were encountered: