Grautvornix

Looks like the latest SVn update solved this issue. Thank you very much!

Phantastic - it seems the latest SVN update solved this issue!

Just some very basic consideration (non historical of course): My first reaction was "Anorganic entities like ships or siege engines actually cannot learn, which is the basic conditions to move upwards on the elite training ladder", but the crews operating them can and these are in our case part of the virtual anorganic unit. Like, a good artillery or sailing/rowing crew can move quicker and aim and hit targets much better than newbies. Therefore it does make sense. I believe, auto repair (self-healing) is something that would realistically be feasible only ashore for ships, e.g. at a shipyard at best - and it does cost resources (wood and metal). For siege engines there were no depots, instead I guess they were built near the battlefield. So repair is done by other units.

@Asher darn! You are right! Walls can have gates, so why not have a gate under water for a ship to undercross the bridge? The animation could be challenging though...

I know this is a potential touchy subject most software developers don't like to see - but there are non-developers (like myself) who are not good enough in coding / SW developing to get a more complicated mod done: Now, If I specify and design and test a mod and ask an AI to code it - what does that mean? I'd like to discuss a few questions. Finally, it might be usefull to provide guidance to others what vibe coding implies in this specific case: The mod might be using some code of 0AD thus automatically inheriting the GPL v2 license. Do I need to tell which parts this refers to? The mod created by the AI should be checked by a tool like scancode (https://scancode-toolkit.readthedocs.io/en/stable/index.html) to avoid using accidentally, and not knowingly, other IPR. (AIs are typically trained with anything they can get including all kind of code repositories on the internet with various license models.) @Asher kindly provided a useful link for consideration (https://seisan.com/ai-generated-code-intellectual-property-ownership/) but frankly, this leaves quite a few questions open. If a tool like scancode finds some infringement, what can I do? rewrite the code manually? Only use the "generated" code it for myself but not publish it? If I contributed to writing the mod by creating the ideas, design, specs and test scenarios and finally testing it - just not writing the code - does that justify a partial authorship? What does that do with the "right to use"/"right to publish"? Questions I'd also like to have your opinion on are these: Would such vibe code be acceptable at all as game mod? Under which conditions? (e.g. state how the mod was implemented, state any known dependencies etc.) Would it help offering instead of the actual code only its design documentation and a few screenshots as an inspiration to actual developers should they want to implement such a function? Would it make sense to provide issue reports of game code identified by the AI when implementing the mod ? Sorry for the long text, but I'd really appreciate your input and opinion on these subjects!

Oh no! Here I am again with another crazy concept how we could implement bridges (sorry I don't give up ) Bridges could actually be walls with the turrets being the bridges pillars (appropriate art still to be designed. Like building that surface during the build process, the bridge could survface from the water until it reaches a certain height above seal level. They can onyl be built in shallow and possibly medium shallow water. Building is done using fisherboats (animation needs to be invented). Bridges cannot be undercrossed by ships. Briges can be destroyed by siege engines and by war ships Now the most difficult and special thing: Bridges can be crossed by individual units one at a time if we garrison them onto the bridgehead, then they would automatically move "sideways" along the wall from position to postion (if I remember correctly, walls have garrison positions), from segment to segment, until they reach the other side where they are automatically ungarissoned. there could be simple wooden bridges (cheap) only for infantry and civilians, and more expensive/wider wooden bridges also for cavalry, and heavy expensive stone bridges (you would afford only in special conditions) able to transport also siege engines and elephants. I would like to do some testing using standard walls and sideways "movement". It will look clumsy initially but we might eventually find a way to generate the right animations. Gameplay-wise, bridges can serve as bridges, but also as barriers to protect a river mound or the space between islands. Their high cost may prevent unconditional use though. Again, I'd be curious to know your thoughts on this!

That would be awesome! My core interest in this it to get a tool running for myself, and if it works, I am happy to share it. I do hope this issue can be solved. I have more tools in the pipe (a simple keyboard visualisation mod, finished, showing to dudes like myself where the game hotkeys are on my particular keyboard also as a reference in-game), and I also have created a python-based map validator/converter (based on Stan's scripts and other infos I was able to gather) that takes a newly created Atlas map, or an old map, highlights issues and allows fixing them, and finally converts it into R28 or R29 (under test). I would also like to look into trying to introduce a mod testing sideways movement of garrisoned troops along wall segments to the point of attack, as well as a selling-back mod for ships/buildings and siege engines once you destroy them yourself. While I do acknowledge that real software development is a serious task and requires a lot of knowledge (I don't have) and certainly a lot of effort, vibe coding is fun as well (and it still needs a bit af creativity and energy in definition and testing). Hence I would really like to know if and how I can share such results safely (even without a license if needs be). The least we could probably use this for is to test mechanisms and concepts - so that we can obtain a spec and an "inspirational" design for real devs if they wanted to implement it in reality.

Thanks, will have a look! As the mod is re-using/modifying some of OAD's own scripts, shouldn't it inherit OAD's license GPL v2 anyway?

Well, I did the specification, guidance and the verification / validation testing, but as I am not a software developer, I asked Anthropic Claude to do the coding. How can I release that content to the public without using the word license? (I am new to this so please excuse my ignorance)

Fixed a few minor issues and updated the docs, and uploaded both modiomod versions to mod.io. they will be available once they are signed. modiomod-tools-1.4.7.zip modiomod-r28.zip modiomod-r29.zip

Well, from my perspective (single player only) I would answer "yes and no": - Yes: it would have quite some historical references. The resources would go back to gaia. - No: - This would leave no choice to the besieged player wiht a single CC to recover eventually and counter attack. Also, resources are with the player and not with the building. So, if the besieged player has multiple CC and only one is under siege should he also loose resources? I believe no. We do have a gradual change of ownership of any building that is under siege (surrounded by troops if you tell them to capture instead of destroying it). I believe this models more or less what you had in mind, but nothing happens to the besieged player's resources though. So - again - from my personal perspective, I regret, but would not be in favour of that proposal.

Frankly, I don't think that we should do that. Not argueing from history but from the gameplay perspective: For a game that offers different civs, these need to be balanced so they all remain a valid option to be chosen by the player. Any "less capable/less valueable" civ would simply never be chosen and we can remove it from the game. But all this while having different characteristics so that specific strategy might be beeded to win a game, e.g. Kush against Rome.

Here is another update to version 1.4.5 for both mods (modiomod-r28 and modiomod-r29). Had Claude check the code and it found a few little glitches and I also improved the info text display for each selected mod below the list so that it is actually readable. Attached is also the documentation (a readme is also avaialbale within each zip). Also tried to find a way to display all the mod icons that are available on mod.io, but they cannot be downloaded automatically from within the game. Therefore there is a little add-on python tool that does that outside the game and stores the icons within the modiomod structure. Not noice but possibly an inspiration for future in game implementation. modiomod-tools-1.4.5.zip modiomod-r28.zip modiomod-changes.md modiomod-r29.zip TOOLS.txt

@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

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!

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

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

Well, using something like Claude code you can provide a local folder with local git and you don't need to upload anything. Claude would work on your folder directly (it is said to save tokens as well ).

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.

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

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

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

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

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!