Make javafml the default loader and default to version range *

[shartte]

Since making entrypoints in fmljava mods optional, it can be used to make resource-only mods without having to switch the loader to the lowcode loader.
To reduce modder confusion and ease of use, I propose that we:

1. make javafml the default for the loader property in neoforge.mods.toml and
2. default the loaderVersion to "*" since the FML version is already controlled through the dependency on neoforge

[Technici4n]

Good idea! I approve

[marchermans]

Allthough I kind of support the idea, having the different loaders actually indicate something different was IMHO the better solution.

I can understand the idea, but I would personally argue: Having a Java FML mod without a single entrypoint, is an invalid construct. Then again that would create a problem with Client only Mods, which IMHO should not have been handled in the @mod, but in the TOML in the first place like it is in FMJ.

Regardless if we continue going down this road: Delete the LowCode entirely, and indeed make the Java Loader the Default if not specified.

[Technici4n]

Having a Java FML mod without a single entrypoint, is an invalid construct.

An entrypoint can often be @EventBusSubscriber, @JeiPlugin, a service provider, mixins, ... This is why @Mod was made optional.

[shartte]

Allthough I kind of support the idea, having the different loaders actually indicate something different was IMHO the better solution.

I can understand the idea, but I would personally argue: Having a Java FML mod without a single entrypoint, is an invalid construct. Then again that would create a problem with Client only Mods, which IMHO should not have been handled in the @mod, but in the TOML in the first place like it is in FMJ.

Regardless if we continue going down this road: Delete the LowCode entirely, and indeed make the Java Loader the Default if not specified.

I've added a new RFC to deprecate lowcode for removal since you are correct. For people who want to make their datapack content a mod, it'd be easier to just drop the loader/loaderversion from their mod metadata going forward.

[marchermans]

Having a Java FML mod without a single entrypoint, is an invalid construct.

An entrypoint can often be @EventBusSubscriber, @JeiPlugin, a service provider, mixins, ... This is why @Mod was made optional.

That seems backwards in my opinion.

Those annotations should be either located via ASD, or via a custom ModLocator. Piggybacking on JavaFML seems at least not pass the sniff-test in my opinion. At least that is as long as there is a mod locator that loads libraries, because then the ASB tracking will work.

Besides that i have never seen any of those entry points without an actual @mod, so I am not sure what I should think of that argument.

[shartte]

Entrypoint is really the wrong name, I think.
You can have a mod with just mixins, that doesn't need a @Mod entrypoint.
Or a mod that just has @EventBusSubscriber and no direct mod entrypoint either.

IMHO all of those are valid, since we relaxed the requirement. For modders that seems really convenient!

[Matyrobbrt]

There is no need for a Mod entrypoint if all your mod needs to do is to kill every player that damages an entity, as that's just an event subscriber. Obviously this example is a bit far-fetched but the point still stands, a lot of mods compose their entrypoint of just adding event listeners, which they can replace with EBS. Additionally, as can be seen here at least 9 mods on 1.21.1 use EBS without a @Mod annotation and since this feature was only made available in 1.20.6+ I expected that over time the amount of mods that will use this pattern will only grow as more modders which only have event listeners in their entrypoint realise that they might not need the entrypoint at all.