YetAnotherConfigLib

YetAnotherConfigLib

13M Downloads

Mod metadata not appearing in PrismLauncher

OpenBagTwo opened this issue · 11 comments

commented

Mod version: YetAnotherConfigLib-3.4.2+1.20.4-fabric.jar
Minecraft version: 1.20.4
Loader: Fabric 0.15.3
Launcher: PrismLauncher 8.3 Flatpak (Linux), PrismLauncher 7.2 macOS

Describe the problem

PrismLauncher shows the mod's name as ${name} and the version as ${version}. This has happened for none of my other mods, nor prior versions of YACL.

This appears to be strictly cosmetic—I've had no issues with running instances with the mod, nor does this incorrect name / version appear in the game logs.

Screenshot from 2024-05-05 11 00 50

Screenshot from 2024-05-05 11 00 41

Steps to reproduce

  1. Create a PrismLauncher instance (Minecraft 1.20.4, Fabric)
  2. Add YACL as a mod, either through the built-in downloader (I sourced from Modrinth) or by downloading the JAR straight from the release page

Affected Systems

I've reproduced this both on macOS and Linux versions of PrismLauncher and also an old ManyMC instance. I have no idea if this issue affects other, non-MMC-style launchers.

Severity

Again, this is strictly cosmetic

commented

Experiencing the same thing.

commented

its just the PrismLauncher/PrismLauncher/issues/2364 just mixing up the forge and fabric i think it was

sorry i don't use github much

also EXPECT GETTING A RESPONSE WILL HAPPEN

commented

I can confirm this too. mods.toml and neoforge.mods.toml aren't processed, but are still included during the build.

modLoader = "javafml"
loaderVersion = "${loaderVersion}"
#issueTrackerURL = ""
license = "LGPL-3.0-or-later"

[[mods]]
modId = "${id}"
version = "${version}"
displayName = "${name}"
authors = "isXander"
description = '''
${description}
'''
logoFile = "yacl-128x.png"

[[mixins]]
config = "yacl.mixins.json"

[["dependencies.${id}"]]
modId = "${forgeId}"
mandatory = true
versionRange = "${forgeConstraint}"
ordering = "NONE"
side = "BOTH"

[["dependencies.${id}"]]
modId = "minecraft"
mandatory = true
versionRange = "${mc}"
ordering = "NONE"
side = "BOTH"

For some reason, launcher reads metadata from META-INF/mods.toml, even if instance is using Fabric Loader

commented

I was just commenting, wasn't really expecting anyone to respond!

commented

i had this same problem it's more of an issue with mainly the mods end
this mod shouldn't have data for forge but there's data for it tho when using fabric
for more info look here PrismLauncher/PrismLauncher/issues/2364

commented

pls note im just a random bozo i don't know anything about how this mod or prism works

its checking for one data before another probably
soo its IG checking for forge then fabric but it finds useless data (for fabric ver) and reads it like fabric data then moves on to the next mod showing up as ${name} with its version being ${version}

commented

Related: with neoforge it displays an error saying mod is invalid and causes a crash instead of just warning that it it a Fabric mod.

Error when installing Fabric version of YACL:
image
In the logs this can be found: net.neoforged.neoforgespi.locating.InvalidModFileException: Invalid modId found : ${id}

Warning when using Fabric version of Sodium:
image
As you can see, there is an option to proceed to the main menu and ignore it.

I think with the latter the problem is much more obvious for a typical user - although it could be worse as the file does have fabric in the name and if you are aware of Fabric Mod Loader you could probably work it out pretty quickly. Although 'is not a valid mod file' could also make you think that something went wrong with the download...

commented

the only thing about the name not saying its for fabric could just be that the mod was first made for fabric
or more likely there may or may not have been a version for that modloader plus with the fact most mods use github if the mod is managed by a ton of people there's bound to be a change like that so it's easier to tell if there's many loaders the mod works with

also that menu would and should always be there as a backup for idiots mixing loaders with incompatible versions

also sorry about slow responding i don't look at github much + im new

commented

Seems to be fixed in 3.4.3

commented

It should be okay to close it then.

commented

nice