hyperion

Someone able to write automations should have no problem writing a patch to bypass such checks. So the highest difficulty for anyone to use such changes is either download and install a mod or a modified engine. Something everyone can do. Providing a mod or a modified engine is perfectly legal due the software license under which pyrogenesis and 0ad is published, arguing it's not moral isn't going to help. IMHO, the only thing worth looking into is what @ffm2 does with the script checking for abnormal patterns in the replay. Then if the heuristics in the script trigger for a ladder game you file a report and moderation can decide to take action based on written rules. If you host a non ladder game you are free to ban whoever for whatever reason you want. If you join a non ladder game you have no say in the rules nor should wfg.

I suggest to use a disk usage analyzer tool, a graphical one available on basically all distributions would be baobab, there are plenty others which you should be able to find with a web search or maybe your package manager. Also on a simple setup anything outside of /home is likely base system or installed via package manager.

Why? It's all about balancing the time spent until you place the CC and finding a good spot. So nothing changed. Again, this isn't bad just because, just different. At most this results in a slight shift in top picks, civ bonuses are meant to be balanced for regular starts, adjusting them on a case by case basis for nomad isn't out of question tho. Also the military value of starting cs isn't equal either. Right, are you going to work on it?

Is there a good reason not to start with 4 woman only on nomad? Feels to be more "nomad" and would make for and easy quick fix. Also, as you not loose resources for just placing a foundation moving it a few tiles away isn't a big deal me thinks. Non visible foundations which wouldn't block foundation placing of opponents either would be nice to have in any case. Edit: Check https://gitea.wildfiregames.com/0ad/0ad/pulls/7159 for the "quick fix".

Absolute path here; suggest instead make -C build/workspaces/gcc -j$(nproc)

That error comes from using python 3.12 which isn't supported yet, work is in progress to update spidermonky. Till then you'd have to use python 3.11 or earlier.

Curl version 8.10.0 had a regression that affected quite a few packages besides us, that one got fixed in 8.10.1. If you aren't using 8.10.0, then maybe there is another regression we aren't aware of yet.

Looking at libraries/clean-source-libs.sh I think I know what went wrong. From the base directory run git checkout libraries to restore the extra files deleted by ./libraries/clean-source-libs.sh, then try again. if you pass --with-system-cxxtest to ./libraries/build-source-libs.sh, then you have to do the same to build/workspaces/update-workspaces.sh and have the cxxtest package installed via package manager. Edit: https://gitea.wildfiregames.com/0ad/0ad/pulls/7130

Unlikely to be sdl related, for the sake of it I tested against 2.18 and there I can also reproduce the issue, resetting hotkeys doesn't work either. As for when more then 4 hotkeys get assigned I haven't figured out a minimal reproducer yet, it just sometimes happens.

On Debian you have to have the package python-is-python3 installed if you us the bundled copy. Or you can pass --with-system-cxxtest to update-workspace.sh if you have the cxxtest package installed.

What is the failure message you get? If you have system cxxtest you also might want to use that as this configuration is now supported.

Nice to see some toolkit love dropdowns are rendered behind other items horizontal scrolling is missing, and we can see that there should be a way to specify the size of the scrolled panel, so items resizing themself based on parent don't end up like the following. The only other thing I noticed is scrolling with mouse wheel when placing the courser anywhere in the scrollpanel isn't implemented yet.

The nightly-build repo is meant to provide Windows users a prebuilt binary. I doubt it was anticipated that someone would use it to build pyrogenesis. Some scripts expect to be living in a git repo. Check https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructionsGettingTheCode

1.21.1.4 looks to be older than the gpu, which might or might not be an issue.

"pull/216/head:pr216" is a called a refspec https://git-scm.com/book/en/v2/Git-Internals-The-Refspec while you don't have to checkout main first, a dirty branch won't work indeed, either commit or stash https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning or reset https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified first.

There are many ways to setup remotes. As for rebase-ing the active branch a simple: git fetch git rebase origin/main will do. Here I obviously assumed origin points to 0ad/0ad. Also demonstrates why you probably never will use pull. Actually you will even find plenty on "git pull evil" on the net. The term local fork can also be misleading/confusing. There are three repositories in the pr workflow: 0ad/0ad, <user>/0ad, and local. The term fork I'd only ever use for meaning <user>/0ad, just to avoid possible conceptual issues. A simple setup could be having only one remote configured in your local repo but setting url to 0ad/0ad and pushurl <user>/0ad. Let's assume the sole configured remote is origin. git remote set-url origin https://gitea.wildfiregames.com/0ad/0ad.git git remote set-url --push origin https://gitea.wildfiregames.com/<user>/0ad.git This makes commands simple stupid, but has it's own drawbacks. Recommended reading https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes

You could start with testing the build instruction https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructions Should have all info you need, but might need some refinement still.

Add 0ad/0ad repo as a (default) remote and you never have to update your fork

I don't know zulip but it seems to offer threadding over irc, but for that we have the forum and I think important topics can and should live here just as before. Also seems to need self-hosting. For casual development chat I don't think irc is lacking at all. Has the advantage to run even if our infra is down. And joining a network/channel is really simple for most everyone. Migrating to a different irc networks isn't that big of a deal either so freegamedev is fine by me if that feels like the natural choice, worst case we just migrate again.

There are also plenty of moldy dds textures where to source files are missing, if you are into restoration that might be something worth looking into as well

Well, semantics if you want, but in a dvcs unlike the cvcs there is no real "upstream"

Submodules are probably best described as pointers and are at least as hard to work with as pointers in C. The repository pointed at is a normal independent git repo.

That can be taken as an argument against an svn source-libs repo and using individual git repos if you want. There is no difference who hosts it, except that one hoster may be down while the other currently isn't. Basically, the use of submodules as described so far is just replacing a repo uri and a hash in "update-workspace.sh" with a submodule and that is definitely not worth the associated pain.

The point is not how to make submodules less cumbersome for some people but not others but if they offer anything at all in our case. We already have such a script, it's called update-workspace.sh for Linux, and any dep that can reasonably be un-vendored has a --with-system-* switch. Debian won't gain anything new at all by using submodules instead of plain old fetch everyone understands.

NIST banned the use of sha1 and I expect a strong push to migrate to sha256 object format the next couple years. The git object format is no longer labeled experimental and gitea supports it properly for all I know. Suggest to at least consider it.