andy5995

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, ) );

Death Canyon, a random map included in the community-maps-2 mod. It's generated from the heightmap of the skirmish map of the same name.