Open Technici4n opened 2 years ago
This API proposition is very hardcode-heavy.
Making Resource Reloaders able to be ordered directly would be both simpler to use, more extensible, and will result in a more stable API. It would also result in something much more consistent to register resource reloaders.
Not to mention how AFTER_TAGS could be confusing to users thinking that having a reloader after that moment gives you free access to tags (it doesn't since they only get applied AFTER resource reloading is done).
The Phase Ordering stuff is great, I'd rather see it being made more abstract to be able to be extracted out of events. To keep a "before/after Vanilla" a "proxy" identifier could be created in such system.
My concern with a before/after approach is that it's easy to introduce accidental reorderings of vanilla's resource reloaders.
Maybe something like this would work better? (I really don't like the identifiers)
public enum VanillaReloader {
TAGS, LOOT_CONDITIONS, RECIPES, LOOT, LOOT_FUNCTIONS, FUNCTIONS, ADVANCEMENTS
}
Event<AddServerResourceReloaderCallback> BEFORE_VANILLA = create();
public Event<AddServerResourceReloaderCallback> afterVanilla(VanillaReloader... vanillaReloaders) {
// Compute earliest event that satisfies the constraints
}
Event<AddServerResourceReloaderCallback> AFTER_ALL_VANILLA = create();
Not to mention how AFTER_TAGS could be confusing to users thinking that having a reloader after that moment gives you free access to tags (it doesn't since they only get applied AFTER resource reloading is done).
You have access to tags in the apply phase if you query them through the TagManager
in the DataPackContents
- this is actually one of my motivations, as it would make the "tags populated" resource condition a lot cleaner to implement. But I agree that it would require proper documentation.
A problem with the current identifier system is that you can't easily request to run a reloader after "all"/most existing reloaders. With event phases, it would be possible to run a reloader after all reloaders in the default phase, which is already better for something like resource conditions that tries to also work for modded simple JSON reloaders.
You have access to tags in the apply phase if you query them through the
TagManager
in theDataPackContents
- this is actually one of my motivations, as it would make the "tags populated" resource condition a lot cleaner to implement. But I agree that it would require proper documentation.
The issue here is methods like isIn from BlockState won't work properly. That's how it can be confusing.
A problem with the current identifier system is that you can't easily request to run a reloader after "all"/most existing reloaders. With event phases, it would be possible to run a reloader after all reloaders in the default phase, which is already better for something like resource conditions that tries to also work for modded simple JSON reloaders.
What?... I'm still not sure I understand the motivation here.
The issue here is methods like isIn from BlockState won't work properly. That's how it can be confusing.
Yeah obviously. But IMO resource reloaders are somewhat tricky and should be careful with what they're doing. :smile:
What?... I'm still not sure I understand the motivation here.
The idea was to be able to clear a thread local cache that runs after all SimpleJsonResourceReloader instances. Maybe there are other ways to do it.
But in any case all of this stuff is still somewhat low priority, and mostly posted here to start a discussion. I have other things to take care of first.
The idea was to be able to clear a thread local cache that runs after all SimpleJsonResourceReloader instances. Maybe there are other ways to do it.
I'd rather look into the existing events that are triggered after a complete reload and make them more consistent to make them usable for that kind of use case.
Goals:
Here is my proposed solution, for server resources. I think we can do something similar for client resources. I am not sure that we need all the
AFTER_XXX
events.