Arch Linux User Repository

Please note that you can flag the package out-of-date and I'll get a notification just the same as when you comment here. I'll always be sure to check for the latest version and update things accordingly. Use the comments to report issues or fixes regarding the package.

Typically I update the package within a day or so of being notified. If you don't want to wait, you can easily update the PKGBUILD yourself: In the case of a regular release, just update the _pkgver field and replace the first md5sums value with SKIP, before running makepkg -Csi or when your AUR helper asks you if you want to make changes before proceeding with the build / install.

@copygirl Easiest way to navigate that problem would probably be to ship two .desktop files. One just called vintagestory.desktop with glthread enabled as default, and vintagestory-compat.desktop or vintagestory-fallback.desktop with a different Name or Comment field and glthread explicitly disabled.

The developers reverted the change to their launch script again in version 1.18.4, and instead ask the user if they want to enable mesa_glthread in their own install script – which this package doesn't use.

I don't want to push a change that could potentially cause users issues depending on their specific setup. I'm not sure if the check works for everyone, or causes freezes as some have reported on the forums. So for now I'll leave things as they were before.

@Athemis Thank you. I would not have noticed this without your input. I ended up changing the included launch script to just cd and call the run.sh provided by the developers. I'm thinking of waiting for the next release to include this change.

Vintagestory since 1.18.2 will set "mesa_glthread=true" for improved performance when launched using the provided run.sh and detecting both a X11 session and Intel/AMD drivers. See below snippet from run.sh for further details:

# if the user has a Intel or AMD Graphics we enable mesa_glthread which should give a performance boost
# we assume when having AMD that they are using the newer mesa driver (not AMD Catalyst driver) since that should be the default and recommended by AMD anyways
# intel has always been mesa
# note: we advise against using the Nouveau on NVIDIA (mesa) since it is no where near the proprietary drivers performance
# further we ran into issues when setting mesa_glthread on wayland (game freezing) so we are only setting it for x11 display server

if [ "$XDG_SESSION_TYPE" = "x11" ] && lspci -vnn | grep VGA | grep -q "AMD\|Intel"; then
  export mesa_glthread=true
fi

I can confirm occasional freezes when loading or within the main menu when setting mesa_glthread=true using a wayland session. However, including the above code into vintagestory.sh provided by this packages seems to be safe.

A little bit of "help" with starting to install server.sh to bin (posting this here because it could be useful, but I gave up partway through figuring things out): Adding install -Dm755 "$pkgname"/server.sh "$pkgdir"/usr/bin/"$pkgname"-server to the PKGBUILD installs the server shell file to vintagestory-server.

@JavelinD The game doesn't support Wine, only Mono. Both multiplayer and mods should work fine - unless perhaps a mod does something incorrectly. You can ask on the forums or Discord for help, and please provide a modlist and the appropriate log files (client-main.txt in this case, I believe).

Can't get the game to connect to a server with mods using just mono. Running through wine gets me in however mouse look isn't working? No idea why. I'm not experienced enough to figure it out. I can still open any menu and interact with it. Scroll wheel and clicking work just fine. Posting here in hopes that somebody has some kind of idea.

I wasn't even aware that there was a server tarball on there, that isn't made clear on the VS site.

I'm currently maintaining a Docker image for VS that runs on Alpine and includes the bare minimum needed to run, with a mounted filesystem.

Having a service available in a server package would be great, maybe take a look at https://github.com/archlinux/svntogit-community/blob/packages/redis/trunk/redis.service?

The way redis does it is just fine in my opinion, the entire PKGBUILD is in that dir as well.

This package already includes the server binary in the install directory, just like you noticed with the Windows installer. Obviously this one is not intended to be used as a server-only install as it includes graphics, models, sounds and music which is a huge chunk of the download. To avoid that you'd download vs_server_<version>.tar.gz instead.

Creating a separate server package would be a good idea. I'm personally not knowledgeable enough to set up a service with working start and stop commands - assuming that would even be the preferable setup for a server package.

Would it be very different to create a second package that included the server binary?

It seems like the Windows version of the game includes the dedicated server executable combined in the client directory. That's another option, although it might not be in the spirit of how Arch Linux packages things. It would make me happy though. :) Reason? Easier server upgrade process.