@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

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

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

@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!

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