andy5995

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.

@SciGuy42Pretty complex! Sweet! When I tried the first two, I got an error "JavaScript error: maps/scenarios/Carthage_2.js line 1248 cmpPlayer.GetCiv is not a function" You wanna do a PR to add these to https://github.com/0ad-matters/community-maps-2 ?

Cool. The bots seem to handle this one ok

Thanks. I opened an issue. @Jammyjamjamman noticed recently that fields can't be constructed on ice. I wonder what the difference is between fields and other objects that get constructed.

Arctic biome on a small map

There is a mod that adds water as a resource but it hasn't been updated since a22 https://github.com/0ad-matters/resource_water which I forked from https://github.com/0ADMods/resource__water

@ItmsChatGPT. That's why I had to ask if it was possible. I'll be sure to mention the "author" next time I post information like that to make it more clear. Let me know if you'd like me to set up a repo that publishes the docs like I mentioned in my original post.

@Stan`@ItmsCan this be enabled so that pull requests from the wiki can be reviewed? And do you agree that it would be a good idea? https://gist.githubusercontent.com/andy5995/2091495227261dc76d0f8657df78f362/raw/508ad5ee4268d51d5db26be48ec4cdd0a6312a3e/gistfile1.txt

I documented the fix https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructionsGettingTheCode The current heading is "Recovering from errors while syncing your fork". I won't link to it directly because the section hasn't been reviewed yet and the heading might change. @Stan`@trompetin17

@trompetin17 gave me the solution on IRC and I'll update the docs within the next day or two.

That does nothing. I get my prompt back with no messages, warnings or errors.

My config: $ cat .git/config I first used 'git fetch upstream' and then 'git rebase upstream/main' I get this error:

I got it building again, I went back to trying on Ubuntu Bionic with gcc-8 (the build fails on gcc-7 on bionic error: 'byte' in namespace 'std' does not name a type). Completed successfully on amd64. I'm building an arm64 AppImage on am amd64 system now. It might take a few weeks because emulation tends to slow things down a bit.... And it already failed:

Maybe one reasonable alternative would be for 0ad to host the flatpack manifest file in a gitea repo. So it would be hopefully easier for someone who volunteers to be the primary maintainer to maintain and anyone could help with it. Sounds like @ShadowOfHassenalready volunteered to do the initial setup?

@OtelloHello! I'm not famililar with Flatpak maintenance, but you may have to report that to https://github.com/flatpak/flatpak/issues If they tell you to report it here, then please provide a link to the ticket you open. You may want to wait for more replies here, someone may have different information. I'm really not sure.

I'm trying to build a 0ad a26 appimage for arm64, but can't get it to build on amd64 yet. Details on my PR: https://github.com/0ad-matters/0ad-appimage/pull/26#issuecomment-2381130695 But I'll leave a few details here as well. As far as I can tell, the error causing the fail is `invalid literal for int() with base 16: 'file'` during the SpiderMonkey build. There's already an a26 appimage, that I built on either focal or bionic. My present script for building is at https://github.com/0ad-matters/0ad-appimage/blob/303c4fdcc79bad3e5564492d38f2e49eaceabcd3/make-appimage.sh I've tried with and without the Debian patches. This is part of the log from the last attempt to build at https://github.com/0ad-matters/0ad-appimage/actions Is there already a patch for this, or does anyone know of a fix? I know supporting a26 is not really the highest priority right now, but I thought it would be nice to have an arm AppImage available for a26 if possible. logs_28977915588.zip

@BaelishIf you're on an amd64 system and don't mind using an AppImage, you can download the 0ad AppImage and just run that.

Thanks, it's working now.

No, I hadn't done that. Ok, I've generated a new key (the public key I usually use got rejected due to its length) with: ssh-keygen -t ed25519 -f ~/.ssh/wfg I added the pub key to my settings and verified it (created and added the signature) but I still have the same problem.

On GitHub, I save my work (if I'm on a different branch) and checkout main, then git fetch origin pull/216/head:pr216 which creates branch 'pr216' (based on changes from pr 216), then I check that out.

I created a fork on the WFG gitea instance. I get an error when I try to clone:

@real_tabasco_sauceI think I can offer some useful tips about this. I haven't used git much the last few months so I'll do my best. I hope someone will correct me if I'm mistaken about anything or omit anything. I don't think you'll have to fetch and rebase each time you want a make a change. While working on a separate branch: 1. If no new commits have been made to the main branch, you'll be able to just continue working on your branch 2. If you know that any new commits to main do not include any files you are working on. If a file has been edited that you're working on, rebasing will help prevent merge conflicts later. You may find it's not always strictly necessary though. 3. If you know your code changes won't affect or break any new code changes that have been committed (or vice versa), then your branch doesn't need to be up to date with what's in the main branch. Sometimes you won't know for certain or it may take time to check, and you'll just want to rebase, or someone may suggest that you to "rebase your branch" if they're aware of a branch you're working on (for example, if you have an open PR that you're still pushing to and isn't ready for merging yet). In this case, you'll be able to skip the "fetching and merging into your local fork", but you'll need to switch to the main branch, pull, checkout your branch, then rebase (unless you run into the conditions or similar ones like I mentioned above.