andy5995

@LienRagyou got the segfault, but not the message about missing version information from curl? I built a new AppImage using Ubuntu Focal instead of Bionic. The filename is 0ad-0.0.27-rc1-27645-alpha-2306120428-x86_64.AppImage and it's available at https://github.com/0ad-matters/0ad-appimage/releases/tag/v0.0.27-rc1-27645-alpha (I have no idea if that will make a difference for you).

@LienRagI opened a ticket on the AppImage repo and replied at https://github.com/0ad-matters/0ad-appimage/issues/23 and wrote some troubleshooting steps that you could try. You can reply on that ticket if you're a registered GitHub user, or here on this forum thread.

@Stan`Probably would only required minor modifications. It just uses this existing docker image and a shell script. As long as GitLab supports things similar to GitHub actions, I don't think it would be very different (the script has variables that are GitHub specific). https://github.com/0ad-matters/gh-action-build-pyromod If anyone ever wants to set up a "GitLab action" and gets stuck, I'd probably be available to help.

@LienRagFrom what link did you get the appimage from? What is the exact filename of the appimage? Which LInux distro are you using?

Better link: https://github.com/0ad-matters/0ad-appimage/releases

@seehYou might find this to be a satisfying solution: HOME=$HOME/0adA27 ./0ad-0.0.27-rc1-27645-alpha-2305191528-x86_64.AppImage Then you'll probably want to copy your existing config into the ~/0adA27/.config folder

For 0ad, it would be a matter of the wiki being updated before the patch was merged. The patch submitter or zirs accomplice adds the new info to the wiki, leaving the prior version untouched, annotating when the changes were introduced. Anyone who plays a26 can clearly see what feature ze doesn't have yet.

@Stan`The doc changes are included with the patch... Here is a not-yet-merged patch where the doc changes are added to the "snippets" directory: https://github.com/mesonbuild/meson/pull/11445/files Then, iirc, when a release is made, the docs in the "snippets" directory get merged into the website documentation: https://github.com/mesonbuild/meson/tree/master/docs/markdown/snippets

@Stan`Agreed, but the question isn't a difficult one to answer. It's a common thing that projects face. You either have different docs for each version (e.g., after a release, you copy the existing docs and make changes to them as the code changes before the next release), or you do something like the meson project and just amend the documentation to note when the change was made.

Thanks for the FYI @real_tabasco_sauce @Stan`It's usually best when the docs get updated along with code changes (or in this case, major changes to a game unit). Otherwise there's little hope of the docs being updated at all, or keeping them up-to-date.

Looks like @maroderis now doing some related work for us in D4948

Anyone who wants to try 0ad at it's current development stage, if you're a Linux user, you can try the 0ad-0.0.27-svn-unstable AppImage There's no need to install any packages or do any building. After you download the image, just use `chmod +x <filename>.AppImage` Then you can run it like any other executable: ./<filename>.AppImage There's one more than one image on the download page; just grab the most recent. Before running the AppImage, you may want to back up your current 0ad config directory: cp -a ~/.config/0ad ~/.config/0ad.bak

Several random maps from the Community Maps 2 mod have more options for Player/Team placement.

There was D4303 but I abandoned my attempt to have that patch merged. Most of the random maps @Jammyjamjammanand I did that are included in the community maps 2 mod have extra placement positions available (stronghold, line, beside allies). The "Beside Aliies" option uses an algorithm Jammy made, the other two we pinched from Frontier and Ambush.

Only one reference to "elephants" in the Gameplay FAQ. Maybe someone will add some of the info from this thread...

I didn't see much there about Intel, what I have on my laptop. But as I mentioned, the drivers I have installed seem to be ok. The game runs with Vulkan enabled if I use a self-built binary instead of the Ubuntu 1804 AppImage. I'll post your suggestion on the ticket though. Thanks @hyperion

I chatted with @sternstaub in the matrix channel and ze didn't ask me to include it.

@hyperionThe problem has been consistent with all of them so far. So far the reports have been from people (including me) on Arch-based systems. If they are using an Intel or AMD GPU, the Vulkan backend is disabled. More details on the GitHub ticket I linked above. I'm glad to hear it's working for you though! Which distro are you using?

@vladislavbelov@Stan` @hyperionRegarding the appimage problem with the Vulkan backend disabled, I got this reply from one of the AppImage maintainers So... no surprise there. I was able to bundle libvulkan.so into the appimage, and had the same problem. I then ran `ldd pyrogenesis | grep vulkan` and found no reference to libvulkan. How is libvulkan being referenced normally when pyrogenesis is run?

If Vulkan is enabled in the config, but the 0ad-spirv mod is not enabled, the game crashes. I've noticed since I first started testing with the Vulkan backend, and last checked at r27513. I have to edit user.cfg to change the backend to opengl, then enable the mod, then set the backend to Vulkan again. Sound: AlcInit success, using OpenAL Soft FILES| UserReport written to '/home/andy/.config/0ad/logs/userreport_hwdetect.txt' TIMER| RunHardwareDetection: 4.66227 ms FILES| Hardware details written to '/home/andy/.config/0ad/logs/system_info.txt' TIMER| write_sys_info: 16.2635 ms Assertion failed: "0 && (L"Can't find a usable technique")" Location: ShaderManager.cpp:269 (LoadTechnique) Call stack: (0x56156f637a5e) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x637a5e) [0x56156f637a5e] (0x56156f5ec261) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x5ec261) [0x56156f5ec261] (0x56156f5ed7eb) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x5ed7eb) [0x56156f5ed7eb] (0x56156f5ee064) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x5ee064) [0x56156f5ee064] (0x56156f3b8641) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x3b8641) [0x56156f3b8641] (0x56156f3ba5a8) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x3ba5a8) [0x56156f3ba5a8] (0x56156f3ba81c) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x3ba81c) [0x56156f3ba81c] (0x56156f3e7659) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x3e7659) [0x56156f3e7659] (0x56156f3e7914) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x3e7914) [0x56156f3e7914] (0x56156f3ed68c) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x3ed68c) [0x56156f3ed68c] (0x56156f2af1cd) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x2af1cd) [0x56156f2af1cd] (0x56156f0ad5f8) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0xad5f8) [0x56156f0ad5f8] (0x56156f099478) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0x99478) [0x56156f099478] (0x7f3ccf43c290) /usr/lib/libc.so.6(+0x23290) [0x7f3ccf43c290] (0x7f3ccf43c34a) /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7f3ccf43c34a] (0x56156f0aae4a) /tmp/.mount_0ad-0.GI6udT/usr/bin/pyrogenesis(+0xaae4a) [0x56156f0aae4a] errno = 0 (No error reported here) OS error = ? (C)ontinue, (S)uppress, (B)reak, Launch (D)ebugger, or (E)xit? e Redirecting call to abort() to mozalloc_abort Segmentation fault (core dumped)

I installed Ubuntu Focal on my Laptop (with the Intel GPU). I built 0ad from svn and Vulkan was detected. The AppImage I built with Focal didn't detect Vulkan on that laptop. So that tells me this issue is an AppImage problem, not a 0ad problem. It's a safe bet that the same would hold true for builds on Bionic.

An AppImage I made in an Ubuntu Jammy container worked on my Laptop with the Intel video. An AppImage I made in a Focal container did not. I opened a ticket on the AppImage repo and posted a summary. @Stan`@vladislavbelov@Jammyjamjamman

Oh, I was talking about using a build environment in a docker container to create the AppImage. I don't know anything about running graphical apps from a docker container. I think the image would be pretty huge. It would contain a base OS, plus the deps, plus the game. Also, escalated privileges are needed to run docker (which may not be a problem because escalated privileges are need to install the game). Although... might be worth someone's time to try it sometime and see the results. That would be another forum thread though. Maybe split this into a separate topic@Stan`?

Without. I just now applied the patch and it worked on Manjaro. I left a comment on D3127. Thanks.

@vladislavbelov I made an AppImage in a Manjaro build environment and that ran (on my laptop with the Intel) with Vulkan enabled (Yay!). Maybe the vulkan libraries from Ubuntu bionic aren't playing correctly with the drivers on newer distros? Or the vulkan drivers on Manjaro can't play well with a program (inside the AppImage) linking to different versions of vulkan? I think the next logical step would be for me to build an AppImage in an Ubuntu Focal, or Jammy (or Debian Bullseye) environment, and see how that runs on my Manjaro laptop. That would definitively answer the question of whether the vulkan drivers on one system can interact with a binary built with other libs (which in this case are included inside the AppImage). What do you think? cc @Jammyjamjamman@Stan` I haven't tried the test yet. Do you still need me to?