hyperion

https://docs.mod.io

A generic "check for updates" mechanism would make a lot more sense. Then it works for single player as well as any other mod on mod.io. Mod.io offers the API required, so the only thing really preventing it is finding someone sitting down and implementing it.

For me 3.2 works well unlike 3.0 so I'd always recommend the former. From your synaptic screenshot it looks like you also installed 3.2 in parallel, so reinstall/update of some might have fixed the "alternatives" setup.

https://github.com/JustusAvramenko/delenda_est/blob/master/Contributors and License.txt

On Linux the game respects environment variables like HOME and XDG_* Going by the terms used in your question I suspect you are using Windows and so you're limited to use the option -writableRoot which writes everything to directories below where the exe itself resides. Could also be useful for when installing 0ad to an usb stick for example.

A tts model is typically less than 100MB but likely is limited to a single language, so one might not be enough. The output could be generated and bundled while creating the mod if performance requires it. Size generated content depends on total text spoken obviously and the quality/bitrate of the encoding, might come at another 100Mb per hour. Splitting into addon-mods is possible. However, this would be a larger project (not just tts but the whole integration of speech) and I don't think it would be coming anytime soon, tho for immersion this would be a nice to have. Waiting for video support

Maybe the OP should clarify if they can run 0ad at all without trying to install a mod but as I read between the lines they can. If this shall be considered fatal then and error should be thrown for arb and a message stating "no graphics backend could be initialized, shutting down ..." should be printed.

This error should have nothing to do with the mod or installing it, isn't fatal but would be nice to sort out as it prevents you from using a decent graphics backend but let's focus on the main issue going by topic. Can you install other mods this way? Are you able to download and install the mod via mod.io and just not via terminal install? What happens if you rename the zh-lang-0.0.26.pyromod to zh-lang.zip and place it in your mods folder and restart the game? https://trac.wildfiregames.com/wiki/GameDataPaths lists the various default paths. Also the game logs to stdout, if an error message can't be seen there you won't find it in log files either.

Fantastic video! Well, still I can't find the relevant portion in the code by skimming, all I found was the use of normal maps in the fragment shader (sure might have missed it tho). This would also give some level of perceived smoothness but is not what I have in mind for smooth shading, still the term flat shading isn't entirely appropriate either. Maybe normal map shading?

Hard to tell even with a crafted example but noticeably different than in blender. Much weaker effect which might come down to a much cheaper algorithm. Could some tweaking get us closer to blender without ramping up computation time?

What would I have to change to make it work as this doesn't look like smooth shading at all.

If you use vulkan you have to enable the 0ad-spirv mod available on mod.io to get the required shaders

1.) Smooth shading interpolates geometry during render, which isn't free and so the game engine doesn't do it as far as I'm aware, at least I never stumbled over code that would indicate otherwise. What you get is basically the same as flat shading in blender. 2.) While baking you have to set metallic to 0 from what I remember when experimenting a year or two ago, don't know why tho. Could well have been a bug in blender.

I suppose tts would have to be done similar to how png to dds with nvtt is done currently and not by using some web service. And I strongly agree with @Stan` to be careful with models as pirated data for training is pretty much standard.

The argument is it can't reasonably be discovered and to a lesser extent the means to distributing units across fields are lacking. If those issues can be fixed diminishing returns doesn't sound bad but coming up with a decent proposal seems non trivial.

Wild west is also fair but I don't mind either way. I see why people would want such a CoC and think it won't hurt at all. I'm fine with rules as long as they are written rules well thought out. It's exposed in the config file which I consider perfectly legitimate to edit. Beside a possible advantage it might also help with performance. There are quite a few config options that people tweak that are not exposed in the UI. "gui.scale" for example only got exposed in the UI in svn but anyone with a 4k monitor probably wants to tweak it already.

And I suggest to go trough with the polishing if you are serious about creating a CoC for ladder games. Get others interested in such involved where possible. I see. Well, I'd say this isn't that straight forward. First of all there is an option in the base game to not render decorative actors but isn't exposed in the UI (set renderactors=false if memory serves me right). Small trees mod is standard in the AoE competitive scene. Lastly there might be made an argument that color blind people need texture tweaking.

Globbing is used for almost all of 0ad, so rerunning premake or update-workspace.sh should be all you need to do.

Overall reasonable but would need quite some polishing. What I don't get are units visible behind trees, the base game has unit silhouettes except maybe for the ARB shaders. Also number garrisoned can usually be inferred from arrow count. To what end? Legitimization only comes from writing the supposed rules down black on white, publishing a CoC for ladder games on the wiki or even better in-game. Some users making up rules on the go definitely lack legitimization. Well, you can't detect it ever, technically outright impossible. It's entirely voluntary to share what mods you use. Atrik earlier in this tread also stated it would be nice to see others mods in the UI and as we are all curious creature I see why people would want it, but bare in mind this can be faked at will with no means of enforcing. In AoE it mostly works because there is a healthy e-sport scene and no one will want to train with mods that can't be used in tournaments, 0ad is far from there. The barrier isn't that high but I concur it exists. But a tutorial is written fast and we have seen quite a few proof of concept mods for such. I think I remember a mod that allows you to read enemy chat was posted not long ago Maybe ChatGPT can also tell you how to

I somewhat doubt it as the python 3.12 porting only really started with SM120, if you want me to try on a different distro feel free to share your patch. I also realized we could just pre apply the binary patches as we repackage the tarball anyway, so blatantly updating bundled virtualenv to a recent version via binary patch (18M) could be avoided. @Stan` I played a match with SM91 vs SM102 and no OOS occurred, my guess the same would be the case for some more esr branches in both directions as we are no longer in the age of netscape where javascript was more like a toy. About we heavily patching SM, compared to distros we are close to vanilla . The reason for giving up is more likely that requiring a different SM minor than the one provided by the distro leads to "slot conflicts", ie a user needs two versions of SM with the same major which can't be installed at the same time. For a packager it's hard to tell if the header check for minor is meaningful, so if in doubt do as upstream insists.

The major we ensure with pkgconfig already. So the the check in the header is redundant. I tried fixing sm91 for python 3.12, that one looks really tricky, needs more than linked patch in the bug and I ended up with binary patches for virtualenv before stopping for now. If we can't add git to the build deps I fear we won't add support for python 3.12 either.

That incident with 78 affected at least a few distributions, so they must have used system spidermonkey at that time. Also that we are aware that some distros package sm wrt ICU in a way that causes issues is due to them using (or trying to use) system sm. Looking at the spec file linked by Norse we also see support for system sm. So if they can they really would prefer that option any day, but the rigid check makes this somewhat tricky for packagers.

Happy new year!

It's a python-3.12 issue, I created a trac ticket with a link to the upstream patch, no need for more info or experiments, it's easy enough to reproduce. Gentoo did for the longest time, then stopped because the restrictive header check became annoying for packaging, not because it could lead to OOS. Pretty sure once upon a time Ubuntu did the system mozjs thingy as well. The header test I consider a remnant of the sm-1.8 days. The pc file already ensures same major version.

Apparently Fedora also uses devel packages so you'd need https://packages.fedoraproject.org/pkgs/mozjs91/mozjs91-devel/fedora-39.html, not mozjs91.