hyperion

For option 1 and 2 the button placing is a bit unfavorable. Option 2 is still in the realm of ok-ish. Maybe placing the main buttons vertically would make it much easier on art. The stargate (option 3) works tho.

If it's on a filesystem which supports hardlinks this shouldn't be to costly, not sure about giteas support, but worth testing for sure.

Visible garrison is quite the joke without scaling, battlements on walls look like shin guards. Now I imagine an archer roughly the height of ship body in a crow's nest. I doubt making ships anything else than simple units which work mostly like land units will ever lead to something playable.

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