hyperion

@Lion.Kanzen did some related work. I don't know the state but maybe he can use help.

@andy5995, just a random thought, might be a case of snap curl vs apt curl.

For me the lowest is turtle at 0.1 speed? But that might be more comfy anyway because commands are for the next turn (in mp some more), so with 0 speed you won't see the results of your action until you speed up again.

This active pause sounds a lot like simulation speed 0, which you can set via console or add an option for via mod.

Yes, and in this context it's an Americanism among maybe some others, translating acknowledging a command for my native language / military would be something like "understood" or "copy" which is also gender neutral.

user.cfg has higher precedence than local.cfg which has higher precedence than default.cfg. So default.cfg are sort of system defaults and local.cfg are user defaults, so if a property is set in user.cfg 0ad won't check there. If it's not in user.cfg it will first look in local.cfg and if that doesn't yield a result check in default.cfg.

0ad-git? Your package script might need to build the spir-v shaders or use the 0ad-spirv mod.

In theory yes, but with line of sight in RTS this is probably not that meaningful.

The main game has airplanes! There is also a dragon.

That's the UnitAI, not the AI player, still unquestionably worth fixing, maybe file a bug if there isn't one already.

System print screen is all about your system, if it's broken fix your system (compositor). About screen shooting error messages, you can do that but never show them to others, they much prefer them as plain text. Any error message you see in game is also logged to stdout and the logfiles and allows for easy copy paste.

Dynamic input delay probably feels much worse than static somewhat lengthy one. At least for competitive play this seems a no go. That's a good idea anyway, nothing to do with turn lengths.

100ms isn't humanly noticeable anymore I'd wager, so is there a need for 50ms? As for networked games, where the issue is most prominent wrt input lag, we aren't bound by turn length but RTT. Looking at your graphs, given your fast machine sim update is always well within turn length, so no issue. But the gain isn't proportional to the reduction in turn length, so on slow machines sim update might no longer fit into shorter turns lengths when it did before which would lead to variable turn lengths much easier I'd guess which probably isn't that nice. Maybe your proposed tweaks can make up for it.

10. Gathering resources under enemy tower.

Only those give the engine a chance to verify the mod beside being user friendly on top. This are hacks which shouldn't be advertised at all. Sure once upon a time this was the only way and people will figure them out if required for very specific use cases.

No need to apologize. Maybe one needs to first run into an issue to appreciate another solution. I just suggest to try early to create a mod and patch against vanilla 0ad to see what it entails before spending lots of time on other details. Good luck.

There is an android port, just that it is likely outdated / in disrepair. If you are up to it get the sources and see what needs to be done to get it working again.

you can replace a file with an empty file and adding .DELETED at the end, this way if you load your mod you can "delete" files in the base mod. This is how you can remove a civ from the game for example via mod. The script just does this for files you deleted in your git branch, so you don't have to care about anything, just working on the git branch as if you want to submit your changes to vanilla is all you'd have to care about. Generating a mod from it comes then for free.

That one or the one on gitlab. If you work on a branch you can just git diff -U5000 A26 > my.patch and upload it to https://code.wildfiregames.com for review. This approach also allows you to delete files via mod easily and the mod is much smaller. Feel free to adopt it or not

Can't say anything about the content but suggest rethinking the setup. My suggestion is fork the 0ad/0ad repo, create a branch maybe based on the tag A26. Then edit binaries/data/mods/public directly. This makes it much simpler to port the changes to 0ad vanilla. Also you can rebase your changes to a different version easily like when A27 gets released. Generating a mod can be done using a script, just did a minimal port of my shell script to python so it would possibly run on Windows too. If your branch is based on A26 run the script from the git base directory as python3 <path to script> A26 pyrogenesis-mod-generator.py

No, developers should see what users will see.

I always find it funny to have an rc for an alpha, that's not how versioning is supposed to work ... The we don't have a stable api or are feature complete is sufficiently communicated with a version lower than 1.0.0, having a warning in the modder guide to emphasize this once more while being sensible with actual changes and I call it fair game. About unhappy users, true there will be more but that should be proportional to happy users. Even a decade ago the game was sufficient to entertain for many hours. ... or features catch up with computers

This is much better than the past no doubt, still you can't expect users to be able to fix their maps created in atlas this way. I'm not advocating to not make changes for functional reasons but cosmetic changes are hard to defend.

Not pyrogenesis but 0ad. Not that either officially claims something like an API That change was done manually and after tripping enough people someone wrote a script, it would have helped it it had been the other way around. Write a script, if the output is what is desired commit the result of the script.

Worst are the ones like stone -> rock, don't think @Freagarach is guilty of similar ones.