Suggestions and Issues about the mod browser

[ajustsomebody]

1: a suggestion about optimising mod update times: make the updates only download the commits that you havent got yet for not updating the mod in a while instead of downloading the whole mod. if you downloaded the mod at commit 1 then it got 2 more commits it should first get commit 2 then commit 3, if this commit way of updating performs worse as in megabytes downloaded then it should revert back to normal way of downloading in this case

2: the mod browser is very problematic when you press install or update on another mod if you havent finished the first download/update yet, there should be a logical queque in order to fix it

3: also when will we get mod pictures?

4: mod sizes are displayed inaccordingly as ravignir says

[ravignir]

Just one thing (if possible): Mod sizes are displayed wrongly, it is displaying the total size of the repository (including deleted files, changes etc). It should display only the current size of a repository - if possible.

[ajustsomebody]

Just one thing (if possible): Mod sizes are displayed wrongly, it is displaying the total size of the repository (including deleted files, changes etc). It should display only the current size of a repository - if possible.

didn't know this was the case, adding that as well

[SomeTroglodyte]

Go ahead and do the research for 1 (where I don't understand you at all) and 4: https://docs.github.com/en/rest/reference/search#search-repositories 3 was in the queue but is stalled as Yair didn't have time to evaluate the predecessor #4033, and I haven't yet freshened it up and merged forward 2 well be more patient then - or very quick, dl'ing two mods in parallel can work. Honestly, I'd rather block the UI while a dl runs to prevent such nitpicking, but then I'd have to enforce a timeout which would need new code, too.

5: Mod mgr on a phone in portrait

[ajustsomebody]

Go ahead and do the research for 1 (where I don't understand you at all) and 4:

ok I'll try to explain it better: say you have abc mod with version 1.1 and the newest version is 1.4, say there are

version #'of commits 1.2 3 1.3 3 1.4 2

you are 3 updates away from the version you want to download (latest version) you first download the commits of 1.2, by date order, download commit 1, put it inside mod files and repeat and you are at 1.3, do the same for commits and do the same for 1.4. if this way of update has been calculated to be less megabyte efficient than directly downloading the entire 1.4 repository and installing it then the classical way of downloading will be used

https://docs.github.com/en/rest/reference/search#search-repositories

are we sure that the mod manager doesn't download the whole repository + it's commit history as well?

3 was in the queue but is stalled as Yair didn't have time to evaluate the predecessor #4033, and I haven't yet freshened it up and merged forward

ok

2 well be more patient then - or very quick, dl'ing two mods in parallel can work. Honestly, I'd rather block the UI while a dl runs to prevent such nitpicking, but then I'd have to enforce a timeout which would need new code, too.

well, i think an ui block would be better than 3 bugged mod installs so

5: Mod mgr on a phone in portrait

:+1:

[SomeTroglodyte]

mmgr only downloads repo zips for the default branch exactly as offered like this:

That is, no history, internal details, whatever, just the final collection of files. The bloody entrails are responsibility of the mod author.

But <facepalm/> about that concurrent download - you're right, one or two temporary names are static and therefore that will collide. Had completely forgotten about that.

[ajustsomebody]

mmgr only downloads repo zips for the default branch exactly as offered like this:

That is, no history, internal details, whatever, just the final collection of files. The bloody entrails are responsibility of the mod author.

But <facepalm/> about that concurrent download - you're right, one or two temporary names are static and therefore that will collide. Had completely forgotten about that.

so why do mods show up like they are bigger in storage space than what they are?

[SomeTroglodyte]

"Go ahead and do the research for ... 4: https://docs.github.com/en/rest/reference/search#search-repositories"

The size comes from the github API response from the search query... Just look at: https://api.github.com/search/repositories?q=topic:unciv-mod&sort:stars&per_page=1&page=1 ... that size. If that's different from the unzipped zip's size (it is) then please find out why.

[ajustsomebody]

"Go ahead and do the research for ... 4: https://docs.github.com/en/rest/reference/search#search-repositories"

The size comes from the github API response from the search query... Just look at: https://api.github.com/search/repositories?q=topic:unciv-mod&sort:stars&per_page=1&page=1 ... that size. If that's different from the unzipped zip's size (it is) then please find out why.

didnt know they arrive as zips thx, so should i cross that out?

[ajustsomebody]

Also another problem: mods show up as if they were updated while they arent. for instance the civ 6 mod shows that it has been updated on 30/7/2021 but in reality it got it's last update 6 months ago, how could this be fixed?

[SomeTroglodyte]

Same answer - if you can find out how to get at the information I could consider patching. Actually, in this case I actually know some detail...

But first, what Unciv works with for that mod is: https://api.github.com/search/repositories?q=topic:unciv-mod%20Civilization-6-Mod&sort:stars&per_page=1&page=1

Take a look and compare. I'd say explanation is that the updated_at from the API reacts to all changes, even in metadata outside of commits. Maybe. Look up the documentation if you want to know exactly. We could show "pushed_at" instead, but as you can see, that's still not necessarily the time the actual master branch changed content.

Now releases have their own API - so one could get at that '2021-01-22' stamp of the latest 'release' and one could also make sure to download releases instead of the default branch, if they exist, but:

• That would be at least one extra round trip per mod, while currently we have one round trip for 30 mods
• Therefore we would be guaranteed to hit the rate limit. You'd get 5 mods, then after a minute waiting you'd get another 5, and so on.

I'd welcome you to try to take this up with the github API maintainers - both for size and timestamp.

However, I am not worried about people redownloading my mod when I change just its description without having new content. No damage but bandwidth waste.

Lastly, consider this: I change a unit icon or several in my mod. These graphics are vastly bigger than before, but I forget to update the atlas, You'll get an update notification in our mod manager and it'll display the increased size, but functionally, nothing has changed. .... And this would behave the same even if the search API had the fields exactly as we wish for.

[ajustsomebody]

Same answer - if you can find out how to get at the information I could consider patching. Actually, in this case I actually know some detail...

But first, what Unciv works with for that mod is: https://api.github.com/search/repositories?q=topic:unciv-mod%20Civilization-6-Mod&sort:stars&per_page=1&page=1

Take a look and compare. I'd say explanation is that the updated_at from the API reacts to all changes, even in metadata outside of commits. Maybe. Look up the documentation if you want to know exactly. We could show "pushed_at" instead, but as you can see, that's still not necessarily the time the actual master branch changed content.

Now releases have their own API - so one could get at that '2021-01-22' stamp of the latest 'release' and one could also make sure to download releases instead of the default branch, if they exist, but:

• That would be at least one extra round trip per mod, while currently we have one round trip for 30 mods
• Therefore we would be guaranteed to hit the rate limit. You'd get 5 mods, then after a minute waiting you'd get another 5, and so on.

I'd welcome you to try to take this up with the github API maintainers - both for size and timestamp.

However, I am not worried about people redownloading my mod when I change just its description without having new content. No damage but bandwidth waste.

Lastly, consider this: I change a unit icon or several in my mod. These graphics are vastly bigger than before, but I forget to update the atlas, You'll get an update notification in our mod manager and it'll display the increased size, but functionally, nothing has changed. .... And this would behave the same even if the search API had the fields exactly as we wish for.

cant we just check for the commits that have affected jsons that have got into master? it shouldnt change anything in game KBs or anything just that it has been updated.

[SomeTroglodyte]

check commits

1..N round-trips per repo, see above

[yairm210]

1. Impossibru
2. Fixed
3. Nope
4. Factually incorrect