-
Notifications
You must be signed in to change notification settings - Fork 30
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
Rewrite language loaders and allow for multiple entrypoints per mod #126
Conversation
Last commit published: 567632e2ab2c7dd4be91462df1d7b1f11dfc622d. 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 #126' // https://github.com/neoforged/FancyModLoader/pull/126
url 'https://prmaven.neoforged.net/FancyModLoader/pr126'
content {
includeModule('net.neoforged.fancymodloader', 'earlydisplay')
includeModule('net.neoforged.fancymodloader', 'loader')
}
}
} |
@Matyrobbrt, this PR introduces breaking changes. Compatibility checks
|
private static final Supplier<Map<String, String>> globals = Suppliers.memoize(() -> { | ||
final var globals = new HashMap<String, String>(); | ||
globals.put("mcVersion", FMLLoader.versionInfo() == null ? null : FMLLoader.versionInfo().mcVersion()); | ||
globals.put("neoForgeVersion", FMLLoader.versionInfo() == null ? null : FMLLoader.versionInfo().neoForgeVersion()); | ||
return globals; | ||
}); |
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.
yeh this sucks
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.
refactor for later: not make this static
@@ -55,7 +54,8 @@ public MethodVisitor visitMethod(int access, String name, String desc, String si | |||
|
|||
public void buildData(final Set<ModFileScanData.ClassData> classes, final Set<ModFileScanData.AnnotationData> annotations) { | |||
classes.add(new ModFileScanData.ClassData(this.asmType, this.asmSuperType, this.interfaces)); | |||
final List<ModFileScanData.AnnotationData> collect = this.annotations.stream().filter(ma -> ModFileScanData.interestingAnnotations().test(ma.getASMType())).map(a -> ModAnnotation.fromModAnnotation(this.asmType, a)).collect(Collectors.toList()); |
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.
kek
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.
so one way (later) to speed up annotation scanning is to reintroduce the "annotation interest" but it's complex, so forget about it for now.
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.
This implementation has no speed impact regardless, at best a memory impact, as ann data has already been collected by then.
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 just meant that in general, to make any sense at all it'd need to use constant-pool scanning based on the interest to avoid having to parse the class-file in the first place.
But assuming we can just cache the entire annotation index per-jar based on a file-checksum, the speed advantage probably diminishes.
This PR changes language loaders to directly load mods instead of relying on a scan data consumer, and allows a mod file to have different mods loaded with different locators. Right now there's no way to express it in the default toml format, but that can be changed.
It also allows a javafml mod to have multiple
@Mod
annotations, with an optional dist parameter.