andy5995

It seems like there's not enough ice textures for terrain. I found this public domain ice texture and like it, but it seems to have some jagged outcroppings. I like that it's not completely smooth, but I think it needs *some* smoothing otherwise it looks funny when units walk across it. Can anyone touch this up or make a texture based on it? The shiny, smooth but somewhat ripply ice texture is what I like, and the color. The third pic is where I tried to modify the first one, and made it 2048x2048 but probably lost some resolution... It looks nice in-game but I think it could be improved.

Congratulations

Doesn't sound too complicated. There's already a few functions that determine the height at a specific point, or to set constraints (such as height). It would add little more code, but I don't see it as being complicated. @maroderdoes that sound about right to you?

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...

I think one common reason that error can happen: https://trac.wildfiregames.com/ticket/6586

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)