andy5995

I'll try to answer even though I'm a bit late... In you `$HOME/.local/share/0ad/mods/user/` folder (or corresponding Mac or Windows folder), create `maps/random/rmbiome` Copy randombiome.js into it, and edit this function (near the top of the file): function setSelectedBiome() { // TODO: Replace ugly default for atlas by a dropdown setBiome(g_MapSettings.Biome || "generic/alpine"); } You can change 'alpine' to any of the biomes listed in the generic folder. Now when you generate a map from a random map in Atlas, it should use that biome. Note that it only works if the random map includes the 'setSelectedBiome();' function (most random maps do).

@OutisSometimes it happens by design, and sometimes by accident. I've updated the wiki to explain more about that. See the player settings tab section and civilization subsection. By design, some map authors are trying to recreate historical battles and intentionally set the civs when they create a map. Sometimes certain structures or units are placed on the map during creation that can only belong to a specific civ, and therefore changing the civ during game set up would cause errors.

I'm experimenting with particle effects to generate waterfalls on random maps. I'm not super-great with particles or x-y-z things, or numbers, so if anyone wants to collaborate, ping me on PR 74 Video clip

At the top of that thread.

It's already been removed from Steam. I'm not surprised it was easy to have it removed. Though I don't know the steps taken to have it removed. I was just looking through the gpl-2 license file in the source root of the 0ad distribution. I didn't see anything that stated that derivative works must be of a different name than the original work. But perhaps "derived work" implies it's "separate" because it was "derived" from the original. My interpretation is that In this case, the person who put that on Steam did not have the rights because he or she wasn't distributing it as a derivative work, but branding it as the original work. Furthermore, section 2, subsection b of the GPL2 license states I read in a reddit post that the person who posted this on Steam was planning to charge 8 Euros for it. My interpretation of subsection b is that if someone tries to publish the original or derived work, they do not have any rights to charge money for it. Note that if the prepositional and a few other phrases are removed: You must cause any work that you distribute or publish, that...in whole ... contains...the Program...to be licensed as a whole at no charge to all third parties...

Enjoy your rest, @Stan`!

I've replaced the version in community maps with carpathian_2.zip.

I made a few changes to both Yekaterinaville and Mainland Rectangled Pic 1 shows an Arctic biome for Yekat... Pic 2 shows the Fall biome Pic 3 shows Mainland Rectanged with the Fall biome

Ticket 6640 created

@dandaman46I think I found the problem and fixed it in https://github.com/0ad-matters/0ad-appimage/pull/8 The updated appimage should be available in about an hour on the releases page.

@dandaman46Thanks for the report. And welcome to the forum. I'll look into it soon. In the meantime, you could try running it with the `--appimage-mount` option. You should get some output like `/tmp/.mount_0ad-0.XVxKe6` and no prompt. Then switch over to another terminal, cd to the directory shown in your output, then cd to usr/bin and run `./pyrogenesis`. After you exit 0ad, you can unmount the appimage by hitting ctrl-c in the terminal where you originally mounted it. Please let me know if that works for you.

I've updated the example. Using this, the mod will build when you push any new commits to your main (default) branch, or any time a pull request is opened or updated. The artifact will get uploaded to the workflow output page (where you can download it and inspect it if desired). You can see at this link near the top right: And at the bottom of the page is a zip file containing the mod (artifact). If the event that triggered the workflow is the creation of a tag starting with 'v', the pyromod gets built and uploaded to the release page (behavior that was in the original example). name: Build Pyromod on: push: branches: - main tags: - v** pull_request: branches: - main env: MOD_NAME: <your-mod> jobs: build-pyromod: if: ${{ github.ref_type != 'tag' }} runs-on: ubuntu-latest env: MOD_VERSION: ${{ github.sha }} steps: - uses: actions/checkout@v3 - uses: 0ad-matters/gh-action-build-pyromod@v1 with: name: ${{ env.MOD_NAME }} version: ${{ env.MOD_VERSION }} id: build-pyromod - name: Upload Artifacts # Uploads artifacts (combined into a zip file) to the workflow output page uses: actions/upload-artifact@v3 with: name: ${{ env.MOD_NAME }}-${{ env.MOD_VERSION }} path: "output/${{ env.MOD_NAME }}*.*" release-pyromod: if: ${{ github.ref_type == 'tag' }} runs-on: ubuntu-latest env: MOD_VERSION: ${{ github.ref_name }} steps: - uses: actions/checkout@v3 - name: Massage Variables run: | echo "MOD_VERSION=${MOD_VERSION:1}" >> $GITHUB_ENV - uses: 0ad-matters/gh-action-build-pyromod@v1 with: name: ${{ env.MOD_NAME }} version: ${{ env.MOD_VERSION }} id: build-pyromod - name: Create sha256sum run: | OUTPUT_FILE="$MOD_NAME-$MOD_VERSION.pyromod" cd output sha256sum $OUTPUT_FILE > $OUTPUT_FILE.sha256sum - name: Release PyroMod uses: ncipollo/release-action@v1 with: allowUpdates: True prerelease: False artifacts: "output/${{ env.MOD_NAME }}*.*" token: ${{ secrets.GITHUB_TOKEN }} omitNameDuringUpdate: True omitBodyDuringUpdate: True

1.x.x releases will point to v1 from now on. So your "uses" line should look like `- uses: 0ad-matters/gh-action-build-pyromod@v1` until v2 is released. https://michaelheap.com/semantic-versioning-for-github-actions/ https://github.com/actions/toolkit/blob/master/docs/action-versioning.md#versioning

Oh, yeah I get that when I just run ActorEditor normally. So I haven't tried to do anything about it with the appimage. Thanks for confirming the fix @hyperion. I'm merging the PR to trunk, which means a new release will show up soon. But you don't need it if you have the artifact. The only difference will be the filename.

@hyperionI've made a couple changes. Could you try the artifact at https://github.com/0ad-matters/0ad-appimage/actions/runs/3199921391 (The zip file at the bottom)

@hyperionI'm using Manjaro, and it appears that pango is packaged so that libthai is a dependency (explaining why I have it installed even though I don't speak Thai either). Can you temporarily install libthai, re-run ActorEditor to see if there are any other missing dependencies? I'm building the appimage with linuxdeploy, and it's got this option: `--library=[library...] Shared library to deploy` so I can try to specify libthai and any other commonly-missing deps.

Someone recently asked me in a chat about release-type stuff: Here's what I said: I generally have a different philosophy about release cycles. But it also depends on what's involved in doing a release. But what I usually do with rmw, if I make a bug fix that's a significant improvement (even if it's not a critical flaw or security risk) and would be helpful to users, I do a release. a bugfix or a nice new feature For minor changes that I think the majority of users won't care about or need, I wait. But the time it takes to do packaging and update docs for a release is also a consideration. I released my first software back around 2004, using SourceForge. I read there the suggestions they had about releases, and I guess I still kind of follow it: "Release early, release often" I say, if there are no known security flaws or new bugs, and there are some good improvements, release, so users can enjoy the changes, and the devs can get feedback. Another advantage is that any time a release happens, the project gets more active and more visible for a temporary time afterward.

@hyperionwhich distro do you use. I added some new info to the ticket Just curious, do you have 'libthai.so.0' on your system, but in a different location than where the appimage is looking for it?

@hyperionThanks for letting me know. Ticket created I'm glad the game part is working for you. Thanks for the feedback.

I pushed some changes so now `ActorEditor` will be accessible by using a symlink. As noted on README.md now: cd /path/to/<Appimage-File> ln -s <Appimage-File> ActorEditor The new images should be on the release page in about an hour. cc @hyperion@Stan`

Anyone who tried the a26 appimage and got **libc errors** should try the newer a26 appimage at https://github.com/0ad-matters/0ad-appimage/releases/tag/v0.0.26-alpha (Though no errors like that have been reported yet)

@KampotI'm glad you got it working! Since you're new to GitHub, I can understand how it could be confusing. It's the very first github action I made, and I've been using GitHub for several years. I know you've already looked at the files in the build-pyromod repo. If you look at some of the links in the README, it might help you understand better. They key element is the use of docker with the action. Note that Docker isn't required to make an action, but it can be very helpful. If at some point you have some specific questions about how it's done, feel free to post here. Good luck!

@KampotI made a couple mistakes in my docs. The release action should be 'ncipollo/release-action@v1` not `ncipollo/release-action@v1.1`

I've also updated the README with some extra info. Thanks for the suggestion @smiley

I can try to make things a bit more clear, but I'm not sure a tutorial is warranted at this point. There's already docs on building a pyromod, github actions, and docker. So... this thread is intended for anyone who hosts a mod on GitHub and want a bit of convenience when doing a release. Or this thread is intended for anyone thinking about hosing a mod on GitHub. People who don't use GitHub to mod will have no use for this action and can safely ignore this thread. The docs for using the Action on the repo README. It assumes the root directory of your mod is in the repo root (e.g., the repo root is where 'mod.json' is located) When the action runs, it will create the mod using the pyrogenesis archive builder as shown here, and output the resulting .pyromod file to $PWD/output. An example is shown on the README on how to access it so it can be used in a separate release action. The release action shown in the example is not required to use the gh-action-build-pyromod action (there are other release actions available on GitHub that can be used instead, if you prefer) No technical knowledge of Docker is needed to use the Action. I posted this for anyone who is curious about the docker image used "behind-the-scenes" for the action, or for anyone who wants to "audit" how the image is created, or make a PR to improve upon it. I'd be happy to answer any specific questions related to the Action. How's that @smiley?