Mentula

Since mods are maintained by "private" users, who are not necessarily into the details of 0 A.D. development, any missing update to mods (or faulty code, or unclear installation instructions, or whatever can be related to mods) is solely a modder's responsibility. In this sense, I don't think this is something 0 A.D. (as a project) is lacking. I know it can be frustrating not to have our favourite mod promptly installed the same day a new 0 A.D. version is released, but as a user... just be patient, updates will come. I find that 0 A.D. devs are doing a good job to signal the changes that may impact mods from one version to another. Maybe modders (I totally include myself here) should be more alert to release dates. And of course, be clear on installation instructions, care about cross-compatibility with other mods, and other stuff that sometimes is done without precise or established guidelines.

Hi folks! LocalRatings was updated to version 0.28.1, compatible with 0 A.D. 28. Before making the mod available via the official downloader (Settings > Mod Selection > Download Mods) I would wait a few more days to have it tested, as some code re-work was needed to port the mod. Since I am not active in the lobby (sigh!) some of you may want to help testing it on R28; I appreciate any bug report. To test the mod, you can download the zip file and extract it into the mod folder (see here to locate the mod folder on your system); then activate the mod via Settings > Mod Selection.

Thank you for the clarification @phosit I think the info you just provided should be added to this guide: https://gitea.wildfiregames.com/0ad/0ad/wiki/PortA27ToR28 And possibly to this guide too: https://gitea.wildfiregames.com/0ad/0ad/wiki/Modding_Guide Porting mods to R28 is not straightforward without this piece of information.

@phosit right, I was too quick. So, what works and what does not: ✔ gui/pregame/mainmenu~MyMod.append.js ✖ gui/pregame/mainmenu~MyMod.js The second approach has worked in all versions prior 28 - and this was "the" established practice, as far as I could see. It looks like the "append" keyword has a special meaning for evaluation of files (I tried with other keywords). Then I have two questions: Should modders be advised to rename all files of the form "module~MyMod.js" with "module~MyMod.append.js"? If so, could this be explicited somewhere? Probably not so relevant here https://gitea.wildfiregames.com/0ad/0ad/wiki/PortA27ToR28, but it would have helped.

@phosit try creating a file gui/pregame/mainmenu~MyMod.append.js with any content; this file is not loaded. Or do you get a different outcome?

That's the point. If the directory gui/pregame was loaded by the xml - like it was before: <script directory="gui/pregame/"/> then one could create a file named mainmenu~MyMod.js and do all sort of scripting therein (for example making proxies of existing functions). But this is not the case anymore for the pregame page. At first glance, this is the only page which changed behaviour. To make a comparison, session.xml is still loading the entire directory gui/session: <script directory="gui/session/"/> I wish I was! New release, new work for porting mods. I played my last game in 2023, but 0 A.D. is always in my heart.

Hi devs and modders, In 0 A.D. 27 and before it was possible to mod the pregame page by adding scripts to the gui/pregame folder. Example of applications are: adding items to the main menu; running startup scripts. Since commit 0fcc4f5fc5 the gui/pregame directory is not loaded anymore, in favour of loading the mainmenu.js file only. It is not clear how mod scripts can run in this page after this change. ✖ It is not an option to override mainmenu.js, mainmenu.xml, page_pregame.xml or other files. This will of course break the compatibility with other mods, as only the last loaded mod will execute the code. Maybe @phosit, do you have an idea? I am pinging you as the author of the change. Thanks.

Free Software can legally be sold (although I am not stating this is specifically the case of 0 A.D.) See this: https://www.gnu.org/philosophy/selling.en.html The word "Free" in "Free Software" can be misleading due to its ambiguous meaning. GNU and FSF clarify which interpretation should be given to the word "Free". Quoting from https://www.gnu.org/philosophy/free-sw.html.en: [...] think of “free” as in “free speech,” not as in “free beer.”

Here: https://gitea.wildfiregames.com/0ad/0ad/src/branch/release-0.28.0/ You probably looked at the main branch of the repo.

Hi @Adriano0ad, Here is a solution if you want to control the margin between buttons dynamically. No file replacement needed. If you want to change the margin for all panels: setPanelObjectPosition = new Proxy(setPanelObjectPosition, {apply: function(target, thisArg, args) { const vMargin = 3; // Vertical margin between buttons const hMargin = 3; // Horizontal margin between buttons target(args[0], args[1], args[2], vMargin, hMargin); }}); and place this code in a new file gui/session/unit_commands~MyMod.js. If instead, you want to change the margin for one/some panel(s) only (f.e. "Construction" panel): g_SelectionPanels.Construction.setupButton = new Proxy(g_SelectionPanels.Construction.setupButton, {apply: function(target, thisArg, args) { const ret = target(...args); // Run original function const vMargin = 3; // Vertical margin between buttons const hMargin = 3; // Horizontal margin between buttons const data = args[0]; setPanelObjectPosition(data.button, data.i + getNumberOfRightPanelButtons(), data.rowLength, vMargin, hMargin); return ret; }}); and place this code in a new file gui/session/selection_panels~MyMod.js.

The topic here is not quality of code or variable names, but code obfuscation. The point in the license is Section 1 "source code". GPL authors clarify that "[...] Obfuscated “source code” is not real source code and does not count as source code. [...]". This is not sufficient to be compliant with GPL3, and not sufficient to qualify as FOSS. Obfuscated code violates Freedom #2 of Free Software as clearly explained here. But besides the "legal" part... if you are a developer who cares about free software (as autociv does), then you will also understand that distributing source code made intentionally hard to be understood is contrary to the purpose and principles of Free Software itself.

This would be a violation of autociv's license. And for good reasons, as explained here: https://www.gnu.org/philosophy/free-sw.html

I can answer, even if I'm not nani. Very important questions - which eventually can be rephrased as "why use proxies?". I hope the rest of this post will clarify. There are various reasons, I'll just state the two I find most important. One reason is compatibility with other mods. Imagine two mods overwriting the same init function: then, only the last loaded mod will work, whereas the first loaded mod will not work - not nice for users. Additionally: if you develop a mod, you expect to develop your code based on options.js from the public mod, right? But if this file is replaced by some arbitrary custom file, you can never know if your code will work properly. In other words, if you want your mod to be compatible with other mods, then you should let the other files exist, and not overwrite them. Another reason is compatibility with 0 A.D. itself. When a new patch or version of the public mod is released, it may happen that options.js gets changed too, as part of the update. If so, you (the mod developer) must take care of replacing that file too, and release a new version of your mod with the new file. And you have to do the same will all other files that have changed... dirty job indeed! Instead, if you build your mod around existing files, your code will (most likely) work straightforward - without having to check for all files that have changed and replace them one by one. So, what does it mean to build around existing files? And what should modders do? Answer is: use PROXIES! Javascript Proxies (similar to Python decorators - I seem to remember you like Python) ensure that modded objects wrap existing objects without overwriting them. An example: by using a proxy, you can run your custom init function after, before or around the original init function. And this is exactly what happens inside options~autociv.js! patchApplyN is a brilliant example of a proxy: it executes custom code around the original init function in options.js. You can find another concrete example of a proxy for the init function in options.js here. Most likely, it is caused by another mod which replaces existing objects/functions/variables/etc. - and if this is the case, you can gently ask the author to get acquainted with proxies.

It is not the case for A27, but in the future it may happen that a new 0 A.D. version will change the metadata.json replay file structure, f.e. adding, removing or replacing data. Then, LocalRatings will need to update its logic too, to reflect the new metadata structure. In other words, future replays may not be compatible with today's replays - at least from data extraction perspective. There is also one more consideration: the "interpretation" of ratings may be different from version to version, due to balance adjustments and gameplay changes. For example, a parameter that was relevant in A26 may not be relevant in A27 anymore and viceversa. So the interpretation of ratings would change too. For these two reasons, I am in favour of distinguishing the two versions.

You can export/import your color scheme from/to local.cfg: [customcolors] 1 = "21 55 149" 2 = "150 20 20" 3 = "86 180 31" ... 16 = "80 80 80" or alternatively, from/to user.cfg: customcolors.1 = "21 55 149" customcolors.2 = "150 20 20" customcolors.3 = "86 180 31" ... customcolors.16 = "80 80 80"