hyperion

locale.cfg should be local.cfg to have any effect, also not sure it will be picked up in that location, move it to ~/.config/0ad/config/local.cfg

Looking at the arch wiki it says there are three drivers, me is using radv on Gentoo. See https://wiki.archlinux.org/title/Vulkan#Switching_between_AMD_drivers if you use the closed source driver (arch default) and if switching makes a difference.

That doesn't sound like a good idea. Downloaded the latest appimage and it ran with vulkan just fine on an amd gpu (vega 8), so which image is apparently broken?

If even you mess up then I take it as solid proof that a release is far to expensive Sad to hear and wish you all the best and a speedy recovery.

@Stan` A good code name is one that people know how to pronounce and is available from the day the development cycle starts. That way the vulkan announcement could have mentioned it for example. Cynically speaking, currently the code name is simply another RB (even a month after FF), sort of a tradition already. I don't expect everyone to agree but unless the two points I mentioned are fulfilled we are better off without a code name in the first place. Axx naming convention is how everyone refers to releases anyway.

Anything that hasn't any silly requirements like letters or relation to a feature so that we can have the name for A28 committed with the first commit in the development cycle.

It's the "ignoreInCompatibilityChecks" one which is responsible for making the mod "invisible". If it doesn't work it's a bug. How did you test it's not working?

There is a property that a mod can set in mod.json to take it out of validation, shiny most likely does this. mods/user is a ugly hack that was invented for use with atlas and never fixed properly. Avoid it whenever you can, it can break your installation in wondrous ways.

I downloaded the boonGUI.zip and discovered it's a zip containing the boonGUI.zip which is the actual mod So either unzip what you downloaded once or repeat the steps using the *.pyromod download.

Ah, I thought it was obvious to replace 'path/to/someMod.zip' to with the actual path. My bad for assuming something to be obvious that is not. Let's say its in Downloads and is called boonGUI.zip then it be 0ad ~/Downloads/boonGUI.zip Hint: use tab completion whenever possible As said before, right click and "open with 0ad" in file manger will work in all likelihood too if a terminal is to foreign, but you won't see any errors then and it will be a lot harder to figure out what goes wrong if it goes wrong.

It should open the mod menu with the mod already installed and selected, click save and restart and you are good to go Edit: @Chesnutter, yes, nautilus is one of many file-managers, and likely the one you use.

@Chesnutter To install a mod hassle free run 0ad path/to/someMod.zip A simple "open with 0ad" in your gui based file-manger should work as well.

Are you sure those flags survive any and all of those creative hacks cross platform software developers came up with to work around quirkiness in windows headers. Even if building with an w10 sdk would under circumstances produce binaries that work I see no reason to not use an w7 or older sdk for CI.

Sure for release and CI builds anything newer then windows 7 sdk isn't an option, just meant to say if you build for yourself choose what you like.

It's unlikely that a newer toolset causes issues. C linkage is rather stable. Just take it as a well tested setup. If a newer toolset or Visual Studio causes problems reports are certainly welcome.

There is also a patch by @wraitii making attackers temporary visible so this would make a reasonable combo, probably attacked units should become visible as well. Compared to attack_range + ~70m vision_range which would only reasonably solve the issue this would be full solution.

Sure, just mentioned it to show it's not _that_ obvious. So minimum vision range is "horizontal shooting range" + "largest building size" / 2 + "some 30 meters for elevation to make it unlikely" for all units?

Imagine a map with height set to minimum everywhere except a column in the center with height set to max, now every ranged unit if placed on top the column can reach any point on map. So how much to increase the vision range to call it good enough?

Then what is your solution? Make SoD leaky (which IMHO is against it's purpose) or increase vision range of catapult to make it less obvious?

But if you don't have vision you don't know that it's already destroyed. You can just guess it but maybe your opponent snuck a few dozen repairers there in the meantime so you really can't be sure unless you check in which case the cata will stop firing. If it does stop firing without vision then it's a case of leaking info that the shroud of darkness is supposed to hide. Btw, this is not limited to catas but applies to all ranged units, it's just not as obvious for others due to relatively large vision range compared to shooting range.

Expected behavior. Why do you think it's a problem?

SM stand for spidermonkey, some distros call it mozjs and it looks your distro calls it simply js. https://software.manjaro.org/package/js91

Indeed, now I can reproduce. With python3-setuptools installed the following allows me to build 0ad in Debian SETUPTOOLS_USE_DISTUTILS=stdlib ./update-workspaces.sh @zyli phew, no reinstall needed --- Tried Fedora 37 and can build just fine. Wonder what I need to break that one (no, not setuptools)!

Thanks. Went through all skirmish maps and can't find any missing shaders anymore with 0ad-spirv-0.27.11. Also disabled validation to get an estimate an vulkan vs gl performance, it's mostly a tie. Some times one is slightly faster than the other and sometimes the other way around. Tho it feels like not comparing the exact same. For instance shore waves are rendered in gl without fancy while it requires fancy with vulkan, also using vulkan models throw shadows onto themself while in gl only onto other objects. To sum up overall they feel roughly the same performance wise. I also didn't come across other issues on the level as those 3 textures mentioned earlier in this thread. Those are the only issue I consider on the level of RB. Do you have an inkling of what is going on there? I just blindly adjusted props size to 64 from 60 as it's 2^6 and it happens to work for me.

Maybe ask on the Debain forums if my guess is reasonable and if you can fix it manually. Looking at the standalone build of mozjs91 at https://salsa.debian.org/gnome-team/mozjs/-/tree/debian/91/master I can't see an indication of your bug either. Sadly, I can't really help much with debugging if I can't reproduce the issue, just grasping at straws.