Feature request: Mod Manager auto update mods added via github that don't have tags about unciv HOT 4 OPEN

mods with tags

Tags? As in, release tags? Or downloaded using a direct zip url? Any mod where the dash-converted folder name doesn't map verbtim to a repo returned from the query for topic unciv-mod can't be autoupdated, by design. We're not coding a bunch of alternative version/timestamp sources.

the form should avoid breaking like this

No idea what you mean with a 'form'. As in, in VB6, a Form is a Window?

wrong line clears

No, we're using json. Period. Prettyprinted json is an optional convenience. For save files, I'd advocate turning on the gzip option as default anyway.

from unciv.

No idea what you mean with a 'form'. As in, in VB6, a Form is a Window?

The GitHub issue form. As in, the rest of the template is broken if you end it with an open ```. Last time I managed to hide the entirety of that section in a spoiler

Tags? As in, release tags?

I meant to topics. I'm probably using the wrong word for everything. Notes for later I guess. I'm talking about mods downloaded from the in-game mod manager from GitHub. I can get not auto updating mods not downloaded from GitHub that don't have topics not updating, but mods downloaded from the mod manager should already have enough metadata to know exactly which repo/version to search. Even if we argue we shouldn't track this or that, I'm sure we run into expectation issues if someone wanted to download, say, a fork of Rekmod or branch of Deciv and still only got updates from commits on the master

from unciv.

Ah, the issue template. OK, was thinking that passage might have still be referring to mod handling.

wrong word

Nnnnn - github uses specific meanings for topics and tags, so in such a context "correct" use makes things easier, but outside github - not relevant. And I didn't think "missing" topics can be what blocks updates, after all you need at least "unciv-mod" to even appear in the query results. Or, you used the "enter url" button, which changes everything, to a degree. But I think I get where your issue might actually lie: Mod names are used as primary keys, there can be no two mods of the same name - to any Unciv "install". For github, the owner+name is the primary key. Therefore, we got a potential cardinality error. As in - results unpredictable when two mods of the same name occur. The info where a mod came from is there - in the modOptions file - but not used for matching on the mod management screen.

Any code change that doesn't overthrow what identifies a mod to Unciv would be fragile at best, so we could - identify and store each and every mod using the owner as part of the primary key (easiest done as another local folder level, but that's not the only solution), thereby invalidating all downloaded mods and all mod references in saved games.

That's a bit out of the question, right? Back to mods being essentially open and cooperative, so just don't publish colliding mod names? Or always query modOptions to get a selective key - which as I said could complicate a lot of code, potential for mistakes high, and so on. Wait - didn't the rejected mod releases/versions PR do some of that tracking already??? I already don't remember.

Hmmm... Another field in the primary key isn't even enough to really distinguish all github sources. Need branch and/or commit hash too.

from unciv.

Or, you used the "enter url" button, which changes everything, to a degree

What I'm referring to this entire issue

Wait - didn't the rejected mod releases/versions PR do some of that tracking already???

I don't think it did, nor was it a relevant factor in it being rejected I'm pretty sure

Or always query modOptions to get a selective key - which as I said could complicate a lot of code, potential for mistakes high, and so on.

I mean, maybe it complicates some of the code, but I doubt it creates that many issues (besides timeouts, maybe?) that it'll be problematic. The problem with the releases PR is assuming which release/branch a player might want for mod not yet downloaded, while this issue is more a request to make that assumption for mods downloaded intentionally of a specific branch to continue following that branch (unless the branch is deleted)

from unciv.