-
-
Notifications
You must be signed in to change notification settings - Fork 194
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
[1.21.x] Topologically sort reload listeners based on dependency ordering #1915
base: 1.21.x
Are you sure you want to change the base?
Conversation
This class injects a ModLoader.hasErrors() check into code that would not be reached if the mod loader errors.
Also adds static keys for the neo-added listeners.
Last commit published: 2601dc47a353d69a67627b17b8cba5638f481e6d. PR PublishingThe artifacts published by this PR:
Repository DeclarationIn order to use the artifacts published by the PR, add the following repository to your buildscript: repositories {
maven {
name 'Maven for PR #1915' // https://github.com/neoforged/NeoForge/pull/1915
url 'https://prmaven.neoforged.net/NeoForge/pr1915'
content {
includeModule('net.neoforged', 'neoforge')
includeModule('net.neoforged', 'testframework')
}
}
} MDK installationIn order to setup a MDK using the latest PR version, run the following commands in a terminal. mkdir NeoForge-pr1915
cd NeoForge-pr1915
curl -L https://prmaven.neoforged.net/NeoForge/pr1915/net/neoforged/neoforge/21.4.89-beta-pr-1915-listener-sort/mdk-pr1915.zip -o mdk.zip
jar xf mdk.zip
rm mdk.zip || del mdk.zip To test a production environment, you can download the installer from here. |
@Shadows-of-Fire, this PR introduces breaking changes.
|
src/main/java/net/neoforged/neoforge/client/event/AddClientReloadListenerEvent.java
Show resolved
Hide resolved
src/main/java/net/neoforged/neoforge/resource/NeoListenerNames.java
Outdated
Show resolved
Hide resolved
src/main/java/net/neoforged/neoforge/resource/VanillaClientListeners.java
Outdated
Show resolved
Hide resolved
src/main/java/net/neoforged/neoforge/resource/VanillaServerListeners.java
Outdated
Show resolved
Hide resolved
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.
Looks fine to me, but someone else should review it before merging. When it is merged, do remember to make an announcement as this is a breaking change.
event.addListener(NeoForgeReloadListeners.CLIENT_MOD_LOADING, ClientModLoader::onResourceReload); | ||
event.addListener(NeoForgeReloadListeners.BRANDING, BrandingControl.resourceManagerReloadListener()); | ||
|
||
// These run before vanilla reload listeners, so we add them before LANGUAGE, the first vanilla one. |
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.
Is it worth having a special FIRST
field in VanillaClientListeners
? And maybe LAST
?
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.
Maybe? The field indices are already ordered by their vanilla order, but sentinel fields that always point to the current first/last values might be useful (or a liability, if we forget to update them...)
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.
They're even more of a liability for modders I think.
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.
In that we should prefer to not add them? Or in that relying on non-sentinel fields would be dangerous for modders?
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.
Yeah I mean that it's a liability for every modder if we don't provide these fields.
* | ||
* @see {@link AddReloadListenerEvent} for registering server-side reload listeners. | ||
*/ | ||
public class AddClientReloadListenerEvent extends SortedReloadListenerEvent implements IModBusEvent { |
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.
Add is weird naming compared to Register, as it implies that things can be added multiple times somehow. Also, anyone searching for the event will probably look for "RegisterReloadListener" or similar.
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.
We had this discussion a bit earlier:
As for the names, I used Add because we aren't registering anything. There is no registry for these objects, they're being added to a List.
As for user discoverability, I've found that people are usually aware of the AddReloadListenerEvent
but are not aware of the RegisterClientReloadListenersEvent
.
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.
The list counts as the "registry" in this case. See also the registration of color providers which is just adding stuff to a map.
|
||
/** | ||
* The main ResourceManager is recreated on each reload, just after {@link ReloadableServerResources}'s creation. | ||
* | ||
* The event is fired on each reload and lets modders add their own ReloadListeners, for server-side resources. | ||
* The event is fired on the {@link NeoForge#EVENT_BUS} | ||
*/ | ||
public class AddReloadListenerEvent extends Event { | ||
private final List<PreparableReloadListener> listeners = new ArrayList<>(); | ||
public class AddReloadListenerEvent extends SortedReloadListenerEvent { |
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.
Should the name not contain Server
somehow?
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.
It could, but I'm okay with the current name. I prefer to imply Server
as a default state that doesn't need to be present in the class name, while client-only is non-default and must be reflected (hence AddClientReloadListenerEvent
).
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.
A silly example: we have ServerStartedEvent not StartedEvent. The event is limited to server reload listeners and the naming should make it clear. Even the documentation mentions server-side resources
.
* @see {@link VanillaClientListeners} for vanilla client listener names. | ||
* @see {@link VanillaServerListeners} for vanilla server listener names. | ||
*/ | ||
public class NeoForgeReloadListeners { |
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.
Make class final
and add a private noarg constructor.
* @see {@link VanillaServerListeners} for vanilla server listener names. | ||
* @see {@link NeoForgeReloadListeners} for Neo-added listener names. | ||
*/ | ||
public class VanillaClientListeners { |
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.
final
and private constructor.
* @see {@link VanillaServerListeners} for vanilla server listener names. | ||
* @see {@link NeoForgeReloadListeners} for Neo-added listener names. | ||
*/ | ||
public class VanillaClientListeners { |
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.
Should be moved to a package under net.neoforged.neoforge.client
.
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.
Guessing that needs to be moved for #1920
Sucks for discoverability, but not much else to do about it. Links from the other classes will suffice.
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.
Indeed. And the links in the other classes will break with split sources but that's no big deal.
* @see {@link VanillaClientListeners} for vanilla client listener names. | ||
* @see {@link NeoForgeReloadListeners} for Neo-added listener names. | ||
*/ | ||
public class VanillaServerListeners { |
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.
final
+ private ctor
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.
Honestly both of those things are pointless. Extensions of this class are meaningless, and so would be instantiations.
I'll stand by not bothering with either unless there is a necessity for them.
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.
It's just good practice, and if we ever get around to generating javadoc it will at least stop generating the constructor.
Overview
This PR introduces dependency sorting for both client and server reload listeners. The sort is topological, using FML's
TopologicalSort
class as the backbone. Reload listeners are added to a DAG where an edge froma->b
means thata
must run beforeb
.The sorting logic, and the modder-facing API, is in
SortedReloadListenerEvent
, the parent class of bothAddReloadListenerEvent
andAddClientReloadListenerEvent
(formerlyRegisterClientReloadListenersEvent
).Requirements
As a prerequisite, this change enforces that all reload listeners are named. The name must be provided via
SortedReloadListenerEvent#addListener
at the time of registration. Vanilla listeners are preemptively named, viaVanillaClientListeners
andVanillaServerListeners
, which hold the class->RL maps for all known vanilla listener types.Note: Mods that are currently using mixins or other non-event means to inject reload listeners will crash after this change.
Sorting
Each
SortedReloadListenerEvent
maintains aGraph<PreparableReloadListener>
which holds the directed edges that dictate the dependency information. An edge froma->b
means thata
must run beforeb
. New edges are added to the graph via#addDependency(first, second)
, which creates a new edge fromfirst->second
.When the vanilla listeners are added in the event's constructor, edges are added such that each vanilla listener depends on the previous one in-order. This guarantees that the vanilla order is maintained without relying on implicit behavior from the toposort.
Finally, after the event has concluded, but before the sort, a search is performed to find dangling nodes and attach them to the last vanilla node, such that all mod-added listeners run after vanilla if they do not otherwise specify dependency ordering.
Error Handling
A dependency cycle in the toposort is an unrecoverable error and will cause the game to crash. If any cycles are detected, an
IllegalArgumentException
will be thrown containing a string representation of the cycle(s).For example:
Notes
This PR supersedes #1289.