andy5995
-
Posts
505 -
Joined
-
Days Won
9
Posts posted by andy5995
-
-
5 hours ago, LienRag said:
I got it here : https://github.com/0ad-matters/0ad-appimage/releases/tag/v0.0.27-rc1-27645-alpha which means that it's the 0ad-0.0.27-rc1-27645-alpha-2305191528-x86_64_65744d18aeb7b41697563d9ec7040137.AppImage file.
I tried it on OpenSuse Leap 15.4
@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.
-
1
-
1
-
-
On 29/05/2023 at 3:41 AM, Stan` said:
I really should make a video on how to install mods, pyromod, drag and drop, command line, put the zip in a mod folder with the same name, the options are endless
I wonder if @andy5995's pipeline to package mods would also work on gitlab.
@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.
-
19 hours ago, LienRag said:
I get
/usr/bin/AppImageLauncher: /usr/lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so) Erreur de segmentation (core dumped)
@LienRagFrom what link did you get the appimage from? What is the exact filename of the appimage? Which LInux distro are you using?
-
On 22/05/2023 at 3:59 PM, Stan` said:
Flatpaks are not made by us, and they don't want experimental versions. So likely never.
There is an appimage there https://github.com/0ad-matters/0ad-appimage/actions
@andy5995 seems to be working on it (thanks again)
Better link: https://github.com/0ad-matters/0ad-appimage/releases
-
2
-
1
-
-
@seehYou might find this to be a satisfying solution:
HOME=$HOME/0adA27 ./0ad-0.0.27-rc1-27645-alpha-2305191528-x86_64.AppImageThen you'll probably want to copy your existing config into the ~/0adA27/.config folder
-
1
-
1
-
-
2 minutes ago, Stan` said:
Right so that would require trac pages to be versioned somewhere (in svn it would seem) and then somehow generate the docs from that... That sounds hella tedious. Also I assume more people read the Meson docs than people read the trac wiki.
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.
Quote(Added in A26)
Elephants can kill female citizens
(Changed in A27)
Women can kill elephants easily, but elephants can fly.
Anyone who plays a26 can clearly see what feature ze doesn't have yet.
-
31 minutes ago, Stan` said:
Feels like something they do after a release?
@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
-
On 28/02/2023 at 3:54 AM, Stan` said:
@andy5995 Obviously it is best, yes. I suppose the committer did not know elephants were referenced at all in the FAQ. At least I did not. Also it raises the question of whether we should update the FAQ before the updated has been released, to avoid confusing players.
The change is mentioned here wiki:Alpha27:Gameplay
@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.
-
On 17/02/2023 at 2:40 PM, real_tabasco_sauce said:
Probably wise to hold off on that, however, because there are some huge changes to eles:
https://trac.wildfiregames.com/changeset/27391
This will make them less effective against buildings and much more effective against units.
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.
-
-
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-
1
-
-
53 minutes ago, Helicity said:
What is the name of this map / mod?
Several random maps from the Community Maps 2 mod have more options for Player/Team placement.
-
3
-
-
5 hours ago, Lion.Kanzen said:
@andy5995 Wasn't he working on something like that? Related to starting positions.
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.
-
1
-
-
Only one reference to "elephants" in the Gameplay FAQ. Maybe someone will add some of the info from this thread...
-
2
-
-
On 06/02/2023 at 12:17 PM, hyperion said:
Looking at the arch wiki it says there are three drivers, me is using radv on Gentoo.
See https://wiki.archlinux.org/title/Vulkan#Switching_between_AMD_drivers if you use the closed source driver (arch default) and if switching makes a difference.
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
-
On 03/02/2023 at 2:56 PM, asterix said:
@andy5995here is good candidate for your community maps mod
I chatted with @sternstaub in the matrix channel and ze didn't ask me to include it.
-
20 hours ago, hyperion said:
That doesn't sound like a good idea.
Downloaded the latest appimage and it ran with vulkan just fine on an amd gpu (vega 8), so which image is apparently broken?
@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
QuoteAll I can say is that AppImage does not use any form of sandboxing or virtualization by default; so it is likely a driver/library compatibility issue? Try experimenting with bundling more/less components.
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) -
On 20/01/2023 at 12:50 PM, andy5995 said:
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 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.
-
On 17/01/2023 at 10:39 PM, andy5995 said:
@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?
I haven't tried the test yet. Do you still need me to?
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
-
On 18/01/2023 at 1:34 AM, Stan` said:
If you run into cases where vulkan doesn't work with the game yeah running it into the docker could be nice
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`?
-
33 minutes ago, s0600204 said:
Was that with or without the differential Stan` mentioned above (D3127) applied? (Because that should now work...)
Without. I just now applied the patch and it worked on Manjaro. I left a comment on D3127. Thanks.
-
1
-
-
@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?
I haven't tried the test yet. Do you still need me to?
Alpha 27 Pre-release/Release Candidate Build Testing
in Game Development & Technical Discussion
Posted
@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).