Auto-update mods option

Caballero-Arepa commented 7 months ago

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

It's not a big deal, but most people usually take a long time updating their mods, or we just don't notice that there is a new update, and we play with the old version of the mod with our friends.

Desired Solution

It would be nice to have an option so when you open the game, it automatically starts updating the mods that have an update available.

If I want to join a game with a mod that is currently updating, then the game will stop me and make me wait for the mod that will be used to be updated.

Alternative Approaches

Or, a button inside the Mod Manager to "Update All".

Additional Context

No response

SomeTroglodyte commented 7 months ago

IMO querying the availability of an update is too costly at the moment.

Updating all "installed" mods at game start would be a background job that can run up to minutes - and then what if someone starts using a mod's data while the updater replaces the folder contents? Syncing nightmare. Unless it's a modal dialog "I'm updating" - but the decision whether to show it would already take a lot of bandwidth and time. Nah.

Could be easier using GraphQL as hinted in #10900, as you can fetch only the dates from a specific list of repositories in a single query with that API. Same caveat - it requires Authentication.

Doing such when loading a game would shorten the list, but the principle remains - one network round-trip per mod using the REST api, with 10900 possibly two for those using releases. One network round-trip total with GraphQL (plus actual update data).

Plus: Our RulesetCache is a preload-all type, so we would need to ditch and reload when we find an update... I'm pretty sure at the moment mod manager will ditch and reload all mods when a single one is updated - which is why it takes some time. That same delay on resuming a game would be unacceptable. Or do some more basic redesign to make that cache a load-on-demand type.

GraphQL that works fetching push/release dates for a specified list of repositories could look like this: ``` query { Repo001: repository(owner:"Caballero-Arepa", name:"Latin-American_Civs") {nameWithOwner, pushedAt, latestRelease {publishedAt}} Repo002: repository(owner:"Caballero-Arepa", name:"Inverted-World") {nameWithOwner, pushedAt, latestRelease {publishedAt}} } ```

github-actions[bot] commented 4 months ago

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.

Caballero-Arepa commented 4 months ago

Hmmm, what about a different aproach.

You can set to 'follow' certain mods, so:
An option to allow the game to load the mod list from github upon entering the main menu.
The game loads the mods and checks for updates
An indicator appears in the Mods button, advising that one of the mods you follow has been updated.

But perhaps this is not a big of a deal after all. Quite possibly an appendice feature, that could cause bugs for very little gain. So I know believe that the issue should be closed, to not waste anyone's time on this,

SomeTroglodyte commented 4 months ago

There's still the thing about the API efficiency. Such a 'follow' feature would be easy, single-roundtrip with the GraphQL api - for which these grinches made authentication mandatory. Which makes any coding frustrating by design. "Open Source" and mandatory trackability???

SomeTroglodyte commented 3 months ago

Just FYI - a certain nonpublic Unciv branch just ran its first autoupdate correctly.

Takes an eyeblink and is done when the first background map is faded in
Requires entering a github PAT in options
"set to 'follow' certain mods" - on the todo list, for now it just checks every installed mod
Missing - a confirm box to bypass and modmanage yourself

As teaser - the first few lines of the framework source:

```kotlin /** * Unciv's use of Github GraphQL API * * ## Concepts * - Switchable backends may be removed for production? The listing test takes averate 1.2s on Gdx, 2.1s on Ktor... * - Queries and Responses use class hierarchies: [GraphQLQuery], [GraphQLResult] * * ## References * - https://docs.github.com/en/graphql/overview/about-the-graphql-api * - https://graphql.org/learn/best-practices/ * - https://gist.github.com/magnetikonline/073afe7909ffdd6f10ef06a00bc3bc88 * * ## Ideas * - Streaming repo listing result as flow - does a gzipped-json parser exist that will emit before the network stream is fully arrived? * * ## Requirements * - (x) Query mods * - (x) Selectively query mods for auto-update * - ( ) Selectively query mods for auto-download missing mods * * ## TODO * - GZipped *query* * + Translate exception for malformed queries * + Auth token stored in settings * + Use for mod manager * - Use for missing mod autodownload * + Use for mod auto-update (from mod manager, from main menu?) * - Option to mark mods as autoupdate candidates * - RateLimit: Doc how to estimate cost * - RateLimit: UI */ @Suppress("unused", "MemberVisibilityCanBePrivate") // This is an API class GraphQL( val backend: Backend = Backend.Gdx, private val getAuthToken: (()->String)? = null ) { enum class Backend { Gdx, Ktor } // region Private data ... ... ... ``` ... ktor will likely be removed, it takes **twice** as long as the helpers in Gdx.Net - I'd have expected better. But if there is a chance to actually stream mod query results... Then ktor has best chances, So I began with that and plugged in Gdx as debugging tool at first.

github-actions[bot] commented 5 days ago

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.

yairm210 / Unciv