Modiomod for A27?

[Grautvornix]

In A26 there was a quite handy mod named "modio.mod" that marked mods on mod.io that were available in a newer version than installed on the user computer.

Any chance this could be updated to A27+ ?

(unfortunately I am not able to do that myself)

[Grautvornix]

Could that funciton possibly be integrated into the new vanilla version? It was quite handy...

 

here is the link: https://mod.io/g/0ad/m/modiomod#description made by @Silier for Alpha 0.26 - and i am most grateful for it!

Edited Thursday at 20:01 by Grautvornix
added version

[Grautvornix]

Again thanks to @Silier for this great little mod and the idea behind!

Not being a SW developer, I asked Claude to help and adapt it to 0.28. Here it is. I also have the version that is said to be working with SVN (currently 0.29) but still have to test it. If it works I will provide it as well.

 

Again - this is not a professional solution and I apologize for using AI help. What I do appreciate is that the change doc created includes the what and why it was changed. I would suggest to include this little feature into the game itself.

Here's the exact logic for colour code per line  in the mod.io list (from getModIOColor() in the file):

• Gray — the mod.io listing itself is invalid (the engine rejects the mod entry, e.g. broken mod.json on mod.io's side). You won't normally see these unless you uncheck "Filter valid mods," since that filter hides invalid entries by default.
• Red — dependencies not met: this mod requires another mod (or a specific version of one) that you don't have installed. This applies whether or not the mod itself is installed.
• Yellow — installed, and a newer version is available on mod.io than the one you have. (This can only apply to something you already own — the check for "update available" only fires if it finds a matching installed mod.)
• Green — installed, dependencies met, and your installed version is current (no update pending).
• White (no color) — not installed, but otherwise valid with dependencies met.

The order matters — it's a priority chain, not independent flags: gray beats red beats yellow beats green beats white. So a mod with an unmet dependency shows red even if you already own it and it's up to date; only once dependencies are fine does it fall through to yellow/green/white.

One more detail: selecting a mod also shows text warnings in the description panel independent of the row color — "(Warning: Dependencies might not be met.)" and "(Info: Update is available)" — driven by the same areDependenciesMet/isUpdateAvailable checks.

 

 

 

modiomod-r28.zip modiomod-changes.md

Edited Thursday at 22:03 by Grautvornix
Updated R28 version with colour code legend and check for updates button

[Thalatta]

I agree that this would be a nice addition to vanilla.

[wowgetoffyourcellphone]

A small ledger telling what the colors are would be nice. 

[Asher]

Would this just be in the download mods page? I think it would be nice to have the update checker in the main mod page

[Grautvornix]

@wowgetoffyourcellphone absolutely - currently the script only provides a warning in the map description the user is highlighting if the colour is grey, yellow or red. Difficult to find the space in this densely populated window.

May be we should shorten the list output to fewer lines and provide a one-line legend?

At the same time there could be more space underneath to show the mod description in full (gets sometimes truncated).

My concern is only that the modio.mod is a small convenience helper function only, and integrating it into the game should not trigger a major redesign of the mod.io interface code.

@Asher I do agree - but I am afraid this would mean preloading mod.io data whereas currently, the user has to agree to the conditions and the connection first and then intentionally start looking at what is available.

 

 

[Asher]

1 minute ago, Grautvornix said:

@Asher I do agree - but I am afraid this would mean preloading mod.io data whereas currently, the user has to agree to the conditions and the connection first and then intentionally start looking at what is available.

But, it could just check what mods you currently have, and see if there is a newer version on modio. You could still have to agree to update

[Grautvornix]

OK, and now including a simple colour legend on top. Thanks @wowgetoffyourcellphone !

R28 is for Version 0.28 and R29 for the new SVN version 0.29 (nightly build). Looks like the internal mechanisms changed. 

There is also a little user and maintainer documentation.

modiomod-documentation.md modiomod-r29.zip modiomod-r28.zip

[Grautvornix]

New Version, now with a button "Check for Updates" on the mod selection screen prior to downloading anything ewlse (thanks to @Asher) .

Unfortunately, for me everything is green as my mods are all updated already... Could somebode please do some testing?

Again R28 is for Version 0.28 and R29 for the new SVN version 0.29 (nightly build). There is also a little user and maintainer documentation.

modiomod-changes.md modiomod-r28.zip modiomod-r29.zip

[Asher]

1 hour ago, Grautvornix said:

Could somebode please do some testing?

Just downloaded it and tested it. I saw a mod that was yellow, some green, and some white. Also, the check for updates button worked. It seems to be working for me. Maybe being able to update mods from the main mod menu would be nice (though, it takes 5-7.324 seconds to get to the download page that it probably doesn't matter, and if you need to agree to the terms and conditions)

Can that be a Pull Request?

[Grautvornix]

This is indeed just a conceptual study (hence the documentation so devs can understand quickly what was done and why) and it appears to work. I'd be delighted if we could integrate it into the main game at some stage. So far it works ok as a mod, I just don't know how I could push that into the game myself (I do remember  the controibutor must be registered and most of all, he needs to understand and be able to explain his code, which I cannot).

And frankly, this is such a tiny function that we should not devote too much energy into and instead focus precious development time on more important things. Bottom line: if it s is simple to iuntegrate, go for it, if not, leave it a mod.

 

[wowgetoffyourcellphone]

I actually wish this page would show the mod's thumbnail.

[Grautvornix]

@wowgetoffyourcellphone wasn't aware that mods have thumbnails, except delenda est which is far more than just a mod

Here are screenshots of the download screens as a referncee and to orient where an how we could place the thumbnails:

This is the mod.io download screen (on R28) indicating which mods are already installed (green), and which of the installed mods could be updated with a newer version (yellow)

 

And this is when the button "Filter  valid mods" is disabled. All mods are shown and thos not compatible and not installed are shown in grey.

Edited 3 hours ago by Grautvornix
reconsidered what Wow actually meant (stupid me)

[Asher]

@Grautvornix, I could try implementing it, if you want. I don't think it would be that hard

[Grautvornix]

@Asher Thanks! That would be awesome! (plus you would have a look at the code of course as well I hope )

[wowgetoffyourcellphone]

1 hour ago, Grautvornix said:

@wowgetoffyourcellphone wasn't aware that mods have thumbnails, except delenda est which is far more than just a mod

Mod.io asks the modern to include a thumbnail image for their site. Perhaps the download page could pull those images.

[Asher]

1 problem, the r29 version is checking depedncys for r28, so most are red in the download mods page

Edited 1 hour ago by Asher

[Grautvornix]

@wowgetoffyourcellphone  Here is the response by Claude: 

"This one I can answer with confidence, and it's a no — not a matter of GUI/JS effort, but an engine-level wall. I read ModIo::ParseModsResponse() in source/ps/ModIo.cpp, which is the only place mod.io's API response ever enters the game. It explicitly whitelists which fields get copied out of the JSON into what JS can see: name, name_id, summary, version, filesize, the file hash, the download URL, and the dependency metadata blob. There is no logo/thumbnail/icon field parsed anywhere — I grepped the whole file for "logo", "thumbnail", "image", "icon", "texture", "sprite" and got zero hits.

It's not just an oversight, either. The class's own header comment spells out a deliberate security boundary: "we only allow mods to download one of the mods returned by this class (using indices)... [so] a malicious mod [can't] use this to download arbitrary files." StartDownloadMod() only ever downloads the one signed mod zip a user explicitly picked — there's no general-purpose "fetch this URL" capability exposed to mods at all, which a thumbnail fetch would need.

So this would require: parsing the logo URL in the engine's C++ (currently absent), a new download path distinct from the one deliberately locked to signed mod packages, and a way to load an arbitrarily-downloaded image as a displayable GUI texture at runtime — none of which a data/GUI-overlay mod can add. modiomod only overrides .xml/.js files inside the existing VFS; it can't ship or patch engine C++."

I cannot assert correctness or not but it sounds plausible, unfortunately.

@Stan` Could you please have a look at, or comment this? (not downloading from mod.io more than exactly the mod itself is intended as a security feature) Thanks!

[Grautvornix]

16 minutes ago, Asher said:

1 problem, the r29 version is checking depedncys for r28, so most are red in the download mods page

This appears to be not on error on the modiomod but the database itself prevents compatibility as it seems. These mods claim compatibility for 0ad=0.28 hence indicating that they are not compatible to 0.29. You can even download them but it is not possible to activate them. 

The change must occur in the mods themselfves, e.g.  by their author. I am not sure if changing their mod.json would make them compatible...this might not be a task for the modiomod.

Amended the documentation accordingly (cf. section A.4.

modiomod-changes.md

[Asher]

Just now, Grautvornix said:

This appears to be not on error on the modiomod but the database itself prevents compatibility as it seems. These mods claim compatibility for 0ad=0.28 hence indicating that they are not compatible to 0.29. You can even download them but it is not possible to activate them. 

The change must occur in the mods themselfves, e.g.  by their author. I am not sure if changing their mod.json would make them compatible...this might not be a task for the modiomod.

Amended the documentation accordingly (cf. section A.4.

Maybe I should have said it differently. The filter compatible mods was on, but it was showing r28 mods in red on the list

[Grautvornix]

@AsherOh! Indeed, you are right!

Here is an update correcting this behaviour as well.

If you could test it, please? (on my R28 and R29 installations it seems to work)

modiomod-r28.zip modiomod-r29.zip modiomod-changes.md