andy5995

AppImages are available from https://github.com/0ad-matters/0ad-appimage/releases

@technocratOne alternative is to use the AppImage instead: https://github.com/0ad-matters/0ad-appimage/releases/tag/v0.27.0

I added a little more description to the README To use this mod, just select Kushites as the civ, there is no need to change the bot settings. Most of the Kush units will have a higher HP. This mod is primarily when you want to fight a more difficult AI than the default "Very Hard" AI. Another benefit is that you can play a game with fewer units on the map because you can replace two or three AI opponents with one Kushite opponent.

What's the best way to verify that vulkan is being used as the backend? I have the option set in my config and there are no errors or warnings in the console. Is that mostly a guarantee vulkan is being used properly, or is there something in the log I could look at to verify with certainty that vulkan is being used? I did see this in mainlog:

As far as maintaining, it's not really time-consuming provided they can be migrated easily each time there's a new version of 0ad released. I don't know how often that's a problem yet.

@wowgetoffyourcellphone@Stan`I'm still thinking about this. My thoughts right now are... I don't know if there's a point to me maintaining maps that no one plays. But at anytime, if there is a map that someone likes that has been proposed for removal (or has been removed and still works) from 0ad, they can submit it for inclusion in the community-maps-2 mod.

Which maps? I don't remember saying this but I might have changed my mind since then. If they are unfinished maps, then you are correct, I don't want to include them.

@Stan`Yes, that's right.

@Stan`thank you for the suggestion, but I've never had to set those to build on any other architectures. I've helped with the MegaGlest appimage build which uses qemu in a GitHub runner to create arm64 packages. No problems. I build several different things in this Dockerfile, also with qemu, building on Focal and Jammy for amd64, arm64, and arm/v7. Does 0ad do any testing on different architectures in its CI? Ironically, I was inspired into building on arm64 after you suggested it in a pull request comment on the 0ad-appimage repo. it's made more work for me, but it's been an interesting learning experience.

@BaelishSadly, the development build has been broken for a long-time on many distros. https://gitea.wildfiregames.com/0ad/0ad/issues/6895 @Itmshas a pull request open to fix the SM problem: https://gitea.wildfiregames.com/0ad/0ad/pulls/7222 One easy work-around is to install a different version of Python (although I see you got the build working above, I'll reference it anyway): https://gitea.wildfiregames.com/0ad/0ad/issues/7080#issuecomment-102788 A fix should have been prioritized, or the document for the build instructions should have been updated accordingly. There's already enough documentation that appeals to developers to contribute. All that happens when a project has a broken build for so long is that potential developers get confused, waste their time, and become turned off. And project maintainers become discouraged that more people are complaining than contributing.

Ticket opened: https://gitea.wildfiregames.com/0ad/0ad/issues/7213

@RangerKOn Linux, it's '~/.local/share/0ad/mods/user/maps/random' or '~/.local/share/0ad/mods/user/maps/skirmishes' for skirmish maps. I just opened a ticket that suggests adding a section to the wiki that clearly explains how to try/test maps. Also, some maps are put into the community maps 2 mod. That mod you can install from the 0ad mod downloader.

I think people new to the game don't understand but will figure it out quickly enough. I like "Dyanamic" the best, but why not a tooltip that offers a minimal explanation? Dynamic or Random doesn't really say anything to a new player. Neither does "Skirmish". Having "Skirmish" as a map type is really pointless, imo. A tooltip that offers a minimal explanation would be good, or just having the explanation appended in the right pane where "Map Type: Random/Skirmish" is displayed.

@Stan` @ItmsI suggest allowing pull requests on any fork. For example, I was going to help with https://gitea.wildfiregames.com/0ad/0ad/pulls/7075 So I pulled the branch and was going to open a pull request on abian's fork:with-lto branch. On GitHub, when this happens, the user can merge the pull request on his fork. If he does so, the already-open PR (link above) on the main upstream repo gets updated. You can see here i don't have the option to open a PR on his fork. It only allows me to open a pull request on my fork or the 0ad repo:

Longer than a minute on a large map.