hyperion

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.

Same, can build pyrogenesis just fine using a Debian installed using the iso here https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/ *suspects some migration wrt python in the past left some breakage behind ...

I'll setup a vm with the installer you linked to and try to reproduce the issue later.

@zyli thanks for continuing to try. For all we know now the issue is due to install scheme and once fixed it should work for you and other Debian users. First try the patch from @s0600204 , it's inlined in the text and so you might have missed it. His patch looks like a clean approach to fix the issue. Apply it on a clean checkout and try to build 0ad. On the off chance it's not a complete fix you could try to do the symlink trick, if that works we are sure what the issue is and only need to find all places to change. For the symlink trick approch: export DEB_PYTHON_INSTALL_LAYOUT='deb' (needs to be done every time you open a new terminal) run "./update-wokspace.sh" the build fails then create the symlinks as suggested, don't clean the build or anything the like. run "REBUILD=false ./update-workspace.sh" If this succeeds we are sure to have found the cause and that there is nothing more to it. @Freagarach you might want to try as well.

Only distutils was either there or got pulled in by "apt-get build-dep 0ad"

There is an add action dropdown, select raise concern under audit action so the commit is marked as needs work. A comment might get forgotten.