hyperion

One is a resource the other not, there is no inconsistency here. This is the same as AoE2 AFAIR.

If it's really old hardware as stated Vulkan won't be available, and the userreport_hwdetect indeed suggests this to be the case.

Needs fuse-2.x, fuse-3.x being the latest. The package might be called fuse:2, libfuse2 or similar depending on distro.

Not just us but other to have trouble making a decent mod interface as well Anyway, I had in mind things like loading the correct mods on joining a game / starting a replay, fetching mods or fetching content from host on demand etc. All those perks I see as a requirement for splitting mods as one pleases. That isn't trivial and also touches on the topic of security. Having the editor mod only depend on mod mod is probably the right choice.

The game logic isn't meant to be part of the engine, sure the engine sets some limits as to what a game can do and the engine can offer some routines for some performance critical aspect to be handed off as well. As for 0ad aka public, sure splitting off or splitting the mod itself (a la 2-4) might make sense if there where a better dependency/mod loader, see the mess the community mod created. The all as a block situation isn't ideal for people to get started.

Well, unless overwritten in user.cfg it should pick up changes to default.cfg. Best to keep those changes in user.cfg you really like deliberately in local.cfg and delete user.cfg once in a while or at latest when 0ad is acting up. For completeness https://code.wildfiregames.com/rP15671

It is bound by default $ grep attackmoveUnit binaries/data/config/default.cfg attackmoveUnit = "Ctrl+Q" ; Modifier to attackmove targeting only units when clicking on a point

That might be related to the custom assets handling, if it just requires exporting from blender as a gltf for instance and the rest is fully handled by the engine I could imagine this to change.

@Ceres You can lock teams in match setup, I'd argue this covers your use-case.

Maybe leaving trac for bugtracking and wiki independent makes more sense, aka having a global bugs.wfg.com and wiki.wfg.com shared for all projects on git.wfg.com? In case of splitting pyrogenesis and 0ad in future this would be a headache otherwise.

Appears to run "git clone --bare", which when testing locally on a btrfs file systems uses reflinks, ie. the clone shares physical extents.

Then a COW filesystem like Btrfs might be best bet as it supports "offline" de-duplication so even if gitea doesn't cp --reflink you'd be fine. https://www.man7.org/linux/man-pages/man2/ioctl_fideduperange.2.html Added bonus of using Btrfs, backups are easier. Don't know Go but I'll grab the gitea sources, maybe I can figure out what it does. They don't share subdomain so splitting sounds like a good idea regardless?

Because they went extinct around ice age and were only reintroduced by the Spanish? Not sure what the current science stand is on the topic. I just remember that this one is/was hotly debated due to the book of Mormon.

Being connected or easily balanced or similar I don't consider valid reasons. The more different or spread around the globe the better I'd say. As long as the AI can reasonably play them. On the other hand I fully agree that we need enough historical material to not make it a fantasy game. Inventing structures and units for the sake of game play isn't a good thing at all. We probably do this to often already.

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.