andy5995

@MirceaKitsune You will need it for the 0ad repo on gitea. https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructionsGettingTheCode#linux

And this is done automatically as part of the build process, if I understand you correctly. I'm on Manjaro as well, with Python >3.10 and don't need to do anything special.

@MirceaKitsuneYou may also have to install the Manjaro package 'python-six'.

I'm able to build on Manjaro Linux. You may have missed the extra build step './build-source-libs.sh' in the libraries directory before you run the update-workspaces script. Note https://gitlab.archlinux.org/archlinux/packaging/packages/0ad/-/blob/main/PKGBUILD?ref_type=heads

@Stan`I get these errors when I run 'python3 /home/andy/src/my-0ad/0ad-appimage/0ad-0.27.0/source/tools/entity/checkrefs.py -m $PWD/community-maps-2 -tax' and I have no idea what's causing them. WARNING - Could not find art/terrains/terrain.rng WARNING - Could not find art/terrains/terrain_texture.rng INFO - Validating textures... WARNING - Could not find art/textures/texture.rng INFO - Collecting materials... Traceback (most recent call last): File "/home/andy/src/my-0ad/0ad-appimage/0ad-0.27.0/source/tools/xmlvalidator/validator.py", line 77, in read root = ET.parse(physical_path).getroot() ~~~~~~~~^^^^^^^^^^^^^^^ File "/usr/lib/python3.13/xml/etree/ElementTree.py", line 1204, in parse tree.parse(source, parser) ~~~~~~~~~~^^^^^^^^^^^^^^^^ File "/usr/lib/python3.13/xml/etree/ElementTree.py", line 569, in parse self._root = parser._parse_whole(source) ~~~~~~~~~~~~~~~~~~~^^^^^^^^ xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 1, column 4 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/andy/src/my-0ad/0ad-appimage/0ad-0.27.0/source/tools/entity/checkrefs.py", line 863, in <module> if not check_ref.main(): ~~~~~~~~~~~~~~^^ File "/home/andy/src/my-0ad/0ad-appimage/0ad-0.27.0/source/tools/entity/checkrefs.py", line 141, in main if not validator.run(): ~~~~~~~~~~~~~^^ File "/home/andy/src/my-0ad/0ad-appimage/0ad-0.27.0/source/tools/xmlvalidator/validator.py", line 169, in run self.find_materials(os.path.join("art", "materials")) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/andy/src/my-0ad/0ad-appimage/0ad-0.27.0/source/tools/xmlvalidator/validator.py", line 152, in find_materials if material.read( ~~~~~~~~~~~~~^ self.get_physical_path(material_file["mod_name"], material_file["vfs_path"]) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ): ^ File "/home/andy/src/my-0ad/0ad-appimage/0ad-0.27.0/source/tools/xmlvalidator/validator.py", line 79, in read self.logger.exception(physical_path) ^^^^^^^^^^^ AttributeError: 'Material' object has no attribute 'logger'

I started on it https://github.com/0ad-matters/community-maps-2/pull/137 cc @Stan` @temacnI got Gaia working already, with no errors or warnings. @MirceaKitsune

@temacnThanks for the feedback. What maps do you like? The incompatibility is more likely due to differences in the data between a26 and a27. Many mods refer to functions that are defined in the javascript library under the mods/public folder. I'm not sure when I'll get to updating it. @Stan`@real_tabasco_sauce@wowgetoffyourcellphoneare there some scripts available that can do some migration? I remember some were provided after the a24 or a25 release...

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.

But the map generates very slow so I'm abandoning this method.

So this works, got some help from @Jammyjamjamman and @trompetin17 g_Map.log("Freezing water"); const IceArea = new createArea( new MapBoundsPlacer(), [ new TerrainPainter("alpine_ice_01"), new TileClassPainter(clIce), new SmoothElevationPainter(ELEVATION_SET, heightSeaGround - 0.1, 0), ], stayClasses(clWater, 0)); for (const position of IceArea.getPoints()) g_Map.placeEntityPassable("obstructors/placement", 0, position);

This is for https://github.com/0ad-matters/community-maps-2/issues/134 This works but I think there must be a better way. It seems crude, and the object (a placement obstruction) covers most, but not all, the tiles. Any suggestions? The usage of createArea() was already in the map script. The new code is the call to createDecoration() g_Map.log("Freezing water"); createArea( new MapBoundsPlacer(), [ new TerrainPainter("alpine_ice_01"), new TileClassPainter(clIce), new SmoothElevationPainter(ELEVATION_SET, heightSeaGround - 0.1, 0), ], stayClasses(clWater, 0)); createDecoration( [ [new SimpleObject("obstructors/placement", 1, 1, 0, 0)], ], [ scaleByMapSize(600, 1800), ], stayClasses( clIce, 0, ) );