Feature request: Mod Manager auto update mods added via github that don't have tags

[SeventhM]

Before creating

• [X] This is NOT a gameplay feature from Civ VI, BNW, or outside - see Roadmap
• [X] This is NOT a gameplay feature from Vanilla Civ V or from G&K - If so, it should be a comment in https://github.com/yairm210/Unciv/issues/4697

Problem Description

Currently, for all mods with tags, it automatically checks for an update and sees if there's an update available. However, If you use a mod without a tag, e.g. my "secret" rebalanced deciv project (leaving undiscoverable partially because it's unfinished, partially because we already have 2-3 discoverable Decivs, partially because one of the Deciv maintainers claim they're working on a big update anyways, and partially because lazy), then it won't ever check for updates despite the mod manager still generating modOptions for it just fine

Related Issue Links

No response

Desired Solution

Update. Anyways, I believe this is how I broke the form last time. Maybe the form should avoid breaking like this

### Alternative Approaches

Maybe

### Additional Context

Speaking of autoupdating ModOptions, are we using the wrong line clears? Even Notepad++ shows all of the text in 1 long line. Same thing happens to save files

[SomeTroglodyte]

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.

[SeventhM]

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

[SomeTroglodyte]

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.

[SeventhM]

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)

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days.

[SeventhM]

Ngl, I would still would like to know the feasibility of this. Even just the concern about colliding mod names seems like enough to make this seem like it should be worthwhile to at least look into before dismissing

[SomeTroglodyte]

feasibility

Nothing is impossible, and this is far from it. Consolidate with Missing-Mod-Autodownload, and integrate Missing-Mod-Autodownload into both map load places... I had this µProject to get to having Mod versions to be able to point the user in some direction in issues or even in game loading, but that initial PR went down. Which could/would have eventually continued here depending on energy availability.

The other blocker, again, was that github classic API is such a kludge comparing with the paywalled OpenQuery abilities... One round-trip to fetch required metadata of all your mods, selectively, as opposed to 2*#ofmods. Major Joykiller. My idea to run all that under some dummy to auth as would probably get us shot down evilly by TinySquishy. Still got the account creds I created for POC's of that idea though..

Edit: "OpenQuery" is BS, I meant GraphQL. And of course it's not "pay"walled per se, but anti-anonymous-walled and as such open-unfriendly. The way to go may be to force our users to generate a GraphQL auth token from their github accounts and enter it in Unciv to enable autoupdates...