fabric
fabric copied to clipboard
FabricMC
Add warning when trying to run Fabric API as an executable
This PR shows this when the jar is run as an executable. This would fix a lot of the confusion around the API, and the current code does not seem to have problems with anything else in the API.
I don’t believe we are allowed to release this onto curseforge. I’m 99% sure that executable jars are against the TOS. Please correct me if I’m wrong.
I have asked around, and it seems it is in the clear. BetterFPS does this as well and is allowed on curseforge.
It's been updated with both ResourceBundles and headless support, you mind re-reviewing?
I would also add something to link to the fabric installer, so that people can install the loader if they don't have it yet
Buddy, this made me laugh :laughing:
Is this really necessary? I believe 95%+ of players know this should be dragged into mods directory. Other mod APIs, including Forge, Quilt & LiteLoader haven't shown up a warning like this.
If players don't know Fabric API is a mod instead of an executable library, you can add a tip in the installer, noticing them download Fabric API in CurseForge/Modrinth and put it into mods directory. Besides, can't those players who download Fabric API in CurseForge/Modrinth realize such a thing from such a website should be treated as a mod? I think it's not our duty to add a dumb Swing app & make Fabric API fatter and fatter.
@teddyxlandlee
Accessibility features make you laugh? sad
While, yes, a large user base should know this should be put into the mods directory, there's also the question of new users.
In one of my most recent user support I've encountered an user who seemed to be a computer novice, which made the user support quite more intense. I don't think being hostile to new users and features facilitating support is a good approach.
This comment honestly comes off as a rather elitist take and hostile towards new users. I would rather not have the same issue as Linux here in Fabric or its alternatives.
This feature looks good, but I believe it should belong in Loom so that everyone can use it (with optout ofc). Also the branch is 1.16, which is way outdated.
This feature looks good, but I believe it should belong in Loom so that everyone can use it (with optout ofc). Also the branch is 1.16, which is way outdated.
Great idea!
However, I think the class should be shrunk as small as possible. Using proguard and package-less class name can shrink it in a specific way.
Also, add a boolean toggle in remapJar. If it is set to true, the already-shrunk class binary will be dumped into the jar along with Main-Class manifest (if not set).
To make it short:
- The class may be mod-insensitive, which means Fabric API uses the same class & the same warning text as other mods.
- No resource bundles, if possible. Texts are stored inside the class directly. Also, it's a bad idea to let the class trying to understand
fabric.mod.json. - Loom copies the already-configured class binary into your remapped jar. This means you don't need to compile it again, because the binary has been stored in Loom.
This was made as my first PR ever. I am now a developer for many mods, and can likely recreate this much better, so as such, I'll close this.
This feature looks good, but I believe it should belong in Loom so that everyone can use it (with optout ofc). Also the branch is 1.16, which is way outdated.
How would it be included in Loom? Would it just embed itself into the jar?
How would it be included in Loom? Would it just embed itself into the jar?
To store the class file in Loom, and dumps it into remapJar along with Main-Class manifest attribute.