(mod tab) Section for Minecraft Versions in mods

[MinecraftMoments]

basically, you have the version number for the mod in a column, but sometimes it's hard to tell what mod version is for what minecraft version. it would be nice if there was a separate column for minecraft versions specifically, as sorting ur mods and checking they're updated would be easier knowing what minecraft version(s) they're listed as compatible with.

[Xetaxheb]

Sounds like kind of pointless clutter so long as you're not installing mods from different major versions that wouldn't have been compatible in the first place (i.e. 1.15 on 1.16)... which launching the game will tell you almost immediately the issue and which mod causes it so that's redundant

Ultimately for minor versions (1.16.4->1.16.5) almost always a mod is either compatible by nature or incompatible/buggy.... that is to say almost never are they marked as "only for 1.16.1 but NOT for 1.16.5" (although the system exists everyone just puts "1.16.x+")... so it doesn't actually help you to know what version they were "made for" as they're probably compatible with later (sometimes even prior) minor releases and you have no way of knowing that they're broken without testing them anyway.

And a bigger issue is almost all mods are marked as I said above: "1.16.x+" so this won't even tell you anything useful that launching the game wouldn't immediately.

[mk-pmb]

Sounds like kind of pointless clutter

I see a point in such a column: Better UX. It would give me easy reassurance that I picked the correct file, especially when the mod happens to be at a version slightly below my instance's Minecraft version. (#5176)

[Xetaxheb]

Sounds like kind of pointless clutter

I see a point in such a column: Better UX. It would give me easy reassurance that I picked the correct file, especially when the mod happens to be at a version slightly below my instance's Minecraft version. (#5176)

again, I disagree that it's better UX.. it doesn't tell you anything that you won't immediately find out on launching the game as far as compatibility goes (which if there's a problem version wise it will tell you before even loading), while adding a bunch of ultimately unnecessary extra text to read past. jar files are frequently inconsistently or improperly tagged as well, the information is not reliable. there are plenty of mods tagged, for example, "1.18+" that work on 1.18 but NOT 1.18.2 or similar situations. you already get the mods itself versioning which is substantially more relevant and important than what mc versions it targets. much more useful would be a dependencies check, highlighting mods missing dependencies, but that is another topic entirely; it could however be rolled into something like that, highlighting when there's version incompatibilities.

[mk-pmb]

it doesn't tell you anything that you won't immediately find out on launching the game as far as compatibility goes

On my potato machine, launching Minecraft takes several minutes. That's one reason why I'd like to have reassurance I added the correct files before I launch it.

while adding a bunch of ultimately unnecessary extra text to read past.

Let's make the column optional, hidden by default.

much more useful would be

I'm all for adding other useful features independently of this one. They don't conflict with each other.

[Xetaxheb]

On my potato machine, launching Minecraft takes several minutes. That's one reason why I'd like to have reassurance I added the correct files before I launch it.

This shouldn't be an accurate statement to what I'm talking about. If you have a version mismatch that is applicable to this, it should come up within a few seconds; either with the white pop up java-esque window on fabric or with pre-loading phase in forge, like this:

Let's make the column optional, hidden by default.

I mean that's definitely an option and you could maybe get a PR merged if you coded it

I'm all for adding other useful features independently of this one. They don't conflict with each other.

I'm just saying that if the other system were implemented I could see it being thrown in a (fleshed out) system like that.. but extra column with nearly useless text clutter is a terrible format

---

At any rate as it stands: the information isn't "accurate" or rather is unreliable when it comes to determining whether there's a problem. Mods can be tagged with various versionRange options including spanning multiple major minecraft versions and only certain subversions. The display could list something like "1.18.1-1.19.1" or even "1.19.3+" or even "" (https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html plus empty=no requirement) But the fact remains that in spite of whatever it's set to things can work anyway so you can easily get false negatives (from strict entries) or false positives (from lax entries) and it's unreliable in the context of setting up.

Ultimately: why add a bunch of text clutter to the list that's just going to be "1.19.4" repeated 200 times? Especially when if there's an issue you'll find out during the very initial loading phase that shouldn't take more than a few seconds?

[FeedTheChunk]

Beings that I have no idea how or if any of this could be implemented. Me, I think that if you had a button that you could click and it would run some sort of sanity check on the mods before loading. A sort of a quick run once to check versioning sort of thing. Although I rarely make my own packs and when I do they all have the same mods. Typically vanilla experience with a couple quality of life, QOL, mods. So getting the correct version(s) isn't really that big of deal IMHO.

[mk-pmb]

If you have a version mismatch that is applicable to this, it should come up within a few seconds

In my experience that screen was very rare. Usually when I picked the wrong file, it starts for several minutes and then a crash message is logged. Maybe this happens when old versions of a mod were too optimistic about their version range. IIRC the last time I had major problems with that was trying several 1.19.x versions of a mod, in hopes they would be upwards compatible with 1.19.4.

to determining whether there's a problem.

Yeah, which is indeed another use case. I'm here only for reassurance of my choice of file added. Seems like we have different use cases that just superficially seem to have the same solution. Maybe it shouldn't have been dupe-merged.

Ultimately: why add a bunch of text clutter to the list that's just going to be "1.19.4" repeated 200 times?

Because something in the ancient regions of my brain really likes quick validation. :D

[Xetaxheb]

Beings that I have no idea how or if any of this could be implemented.

This wouldn't be at all difficult to implement as a text column; it would take mere moments to expose the data.... the bigger question is whether it's worth cluttering the UI with it since it's low value or valueless information.

I think that if you had a button that you could click and it would run some sort of sanity check on the mods before loading.

This already exists in forge/fabric/quilt when you try to launch, it's called the pre-loading phase and catches everything that visually scanning the added info would do anyway.. version mismatches, missing dependencies, etc... except it's automated for you and generally more correct.

---

Maybe this happens when old versions of a mod were too optimistic about their version range.

This is exactly the problem and why the added ui info would be of little to no realistic use. It doesn't tell you anything the pre-loading phase wouldn't (and more succinctly instead of trying to eagle-eye or sort for out of place ones) and is more likely to just introduce user-confusion when a mod is actually compatible.

-- But my argument is not that it's difficult to do or says nothing, my argument is that the information provided is of so little value to be essentially worthless and not worth the UI mess. If you're installing improper versions that are hardcoded to not allow running, which are the only useful info this would show in basically any scenario, you will find that out in a few seconds of trying to launch. Adding it here isn't worth cluttering the UI with an always-on column (if you even noticed the discrepancy to fix) when this is really a one-and-done thing to resolve if you did mess up.