hyperion

Thanks, https://gitea.wildfiregames.com/0ad/0ad/pulls/7300

There is no release version of a27, I suppose you mean main branch. If an identical error is printed you either didn't build what you thought you did or didn't run what you built. This exact error message does no longer exist in main. Building a26 at this point from a checkout is non trivial, I suggest to inform the maintainer for the package for your distribution (usually bug report) and if you want to have a go at it yourself use the package build scripts, which have all prior fixes, and the package build tools of your distribution to create an installable package instead. You can't catch a segfault.

@tuk0z, yes the bug was fixed with https://gitea.wildfiregames.com/0ad/0ad/commit/bb1910ff4c696502d3d518a0cd36c7bd2795554f, distribution maintainers or anyone building a26 from source can cherry-pick that commit to support >=openal-1.24.0. The next release will include the fix. Bug report for Debian sid https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087990

https://gitea.wildfiregames.com/0ad/0ad/pulls/7234

Quick check: alcGetString(nullptr, ALC_DEVICE_SPECIFIER) returns nullptr or at least a char* starting with "\0" in 1.24.0 It's only used for printing the device name into a logfile. Making the follow up code expecting non NULL segfault. Skipping that part the sound works just fine, as it's only used for printing the device name into a logfile.

You assume 1 target only, but usually there are bunch clumped together. So spread may even make projectiles more effective. Imagine 20 of your units shooting the same unit when 5 are already enough to drain all health of said unit. In that case you might get even 2 or 3 units instead of just one with the volley.

if the idea behind is to enable "never heard of that mod, let me check it might be something good" then yes, there is merit. But if @Atrik shows up and that trainer assist thingy isn't listed will you trust it? You won't, right? As such making it worthless for such purpose.

I consider it perfectly fine you banning this user when you host, no reason required, being insulted for it, I consider bad behavior that should be sanctioned where reasonably possible. But going on a witch hunt or donning the justice knight kit to harass progui users isn't any better in this regard and I have seen statements of this happening too. I have no recipe handy for making the lobby a less toxic place. Nothing will change with suggested anti cheat measures like only signed mods or make all mods visible. Still only a download and install is required to get around it. You can't ever make it any harder than that for those willing to cheat. Commercial game studios started to install malware (hooking into kernel and taking ownership of your pc) to try to fight this problem, don't think this is a route to pursue for 0ad. What has potential is analysis of replay data and screen recordings, as that is much much harder to get around. The usage of progui, should it be written down, should be a bannable offense in ladder games, not using it in SP for instance or in games that a user hosts. I'm not concerned it might happen, it will happen. If just saying this is bad, don't do it would work, there wouldn't be a need for prisons, there wouldn't be drug addicts and MP lobby would be a nice place where everyone gets along with each other. It's not the late 1960 where everyone believes in fluffiness. PS: Just to be clear, some suggestions have merit on their own and would make for nice additions, just not as anti cheat measures. And making the game much less attractive for those that do not cheat, just in vein hope to fix cheating that way should be avoided.

I think I saw this in the forum before. Something with Windows and enabled scaling IIRC. Maybe https://www.thewindowsclub.com/how-to-change-scaling-for-specific-apps-in-windows-11 helps.

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