Jump to content

Linux Steam Builds (Sort Of) Working!


Recommended Posts

I've updated my custom startup script. It will now keep save files inside the WINE directory instead of putting them into the home directory (which is bad behavior). Public domain for all I care:

#!/bin/sh# Directory this script is in, AKA Xenonauts install dircd "$( dirname "${BASH_SOURCE[0]}" )"# Use either xmessage or plain old echo for debug outputMESG=`which xmessage`if [ "$?" -ne "0" ]; then   MESG="echo"fi# Check if the Xenonauts executable existsif [ ! -f xenonauts/Xenonauts.exe ]; then   $MESG "Executable not found! Please re-install Xenonauts"   exit 991fi# Run the gameWINE=`which wine`if [ "$?" -eq "0" ]; then   # Initial setup, we don't want My Documents to link to ~   if [ ! -e wine ]; then       WINEPREFIX=`pwd`/wine $WINE exit       rm wine/drive_c/users/*/My\ Documents       mkdir -p wine/drive_c/users/`whoami`/My\ Documents   fi   WINEPREFIX=`pwd`/wine $WINE xenonauts/Xenonauts.exe $@   exit $?else   $MESG "WINE not found. Please install before running."   exit 992fi
Edited by kshade
Link to comment
Share on other sites

@kshade - please could you explain in detail why your startup script is an improvement over the default one? I'm not a programmer myself so I'm not entirely clear what it achieves and why?

It creates a Wine prefix to be used only by Xenonauts, which can help prevent harmful cross-interactions with other Wine applications.

A Wine prefix (also called "bottle") is a sort of virtual installation of Windows - it has Windows-style folder structure (e.g. "Windows", "Program Files", "Users", etc) and contains all the imitation .dlls that translate Windows-specific calls into Linux-specific ones, as well as various user settings. Problem is, some tweaks that may be necessary to make one program work under Wine may in turn cause a different program to break - say, one program doesn't launch unless you use an actual DirectX .dll from Windows, whereas another only runs when you use the version of that is provided by Wine. It is possible to set up individual configurations for each program, but creating a fresh prefix is a simple and foolproof way to avoid complications of that sort.

In effect, this increases the total install size of the game (by ~300MB), but prevents potential idiosyncratic issues from cropping up for users who have done something with their Wine configuration that Xenonauts doesn't like.

Link to comment
Share on other sites

Actually, if you could delete the /industrial/ tileset again and replace it with this one, that'd be great: https://dl.dropboxusercontent.com/u/26290309/industrial_updated.zip

Does that still work? If so, that should combine the best of the atlases with the fixing of the issues.

The new files work too, no slowdown and no crashes (GNU/Linux).

I've updated my custom startup script. It will now keep save files inside the WINE directory instead of putting them into the home directory (which is bad behavior). Public domain for all I care:

Why saving savefiles in home folder should be bad? Every application saves personal settings in user's home folder. It would be nice if xenonauts savegame folder would be hidden (just put a dot before, e.g. 'xenonauts' -> '.xenonauts'.

Link to comment
Share on other sites

xenonauts doesn't work for me. I'm on Ubuntu 12.04 with Wine 1.4.

I switched to experimental branch. The game downloads super-fast but I get the "missing executable" error in Steam.

Have you checked in the game directory that game files have actually been downloaded?

Link to comment
Share on other sites

@kshade - please could you explain in detail why your startup script is an improvement over the default one? I'm not a programmer myself so I'm not entirely clear what it achieves and why?
It creates a Wine prefix to be used only by Xenonauts, which can help prevent harmful cross-interactions with other Wine applications.

A Wine prefix (also called "bottle") is a sort of virtual installation of Windows - it has Windows-style folder structure (e.g. "Windows", "Program Files", "Users", etc) and contains all the imitation .dlls that translate Windows-specific calls into Linux-specific ones, as well as various user settings. Problem is, some tweaks that may be necessary to make one program work under Wine may in turn cause a different program to break - say, one program doesn't launch unless you use an actual DirectX .dll from Windows, whereas another only runs when you use the version of that is provided by Wine. It is possible to set up individual configurations for each program, but creating a fresh prefix is a simple and foolproof way to avoid complications of that sort.

In effect, this increases the total install size of the game (by ~300MB), but prevents potential idiosyncratic issues from cropping up for users who have done something with their Wine configuration that Xenonauts doesn't like.

That's pretty much it, yes. It also displays error messages as GUI windows instead of only on the command line (which might not be visible) and keeps the game from creating a visible folder in the user's home directory, which on Windows is fine but on Linux is a no-no. Saves live in Xenonaut's own WINE directory with this script, not quite where they might belong either but I don't really see you to implement proper UNIX-style settings folders while using WINE as a wrapper.

There's a small caveat though: Existing save files will not be found and have to be moved manually.

Link to comment
Share on other sites

In effect, this increases the total install size of the game (by ~300MB), but prevents potential idiosyncratic issues from cropping up for users who have done something with their Wine configuration that Xenonauts doesn't like.

And why should the game waste 300MiB for a rather unlikely what-if? If a user has done something to their Wine configuration, maybe they should know what they are doing.

Also, on a purely technical note, if I'm reading the script correctly, it's rather broken (e.g. it will try to use /usr as WINEPREFIX for anybody who installs the game as a package rathen than using Steam).

IMO the current script is fine as it is for the general user. Those who want to play with it can play with it.

Link to comment
Share on other sites

Also, on a purely technical note, if I'm reading the script correctly, it's rather broken (e.g. it will try to use /usr as WINEPREFIX for anybody who installs the game as a package rathen than using Steam).

True, this is for Steam only.

Link to comment
Share on other sites

Well, I'm not sure how everyone elses experiences have been going (I only skimmed the first pages).. but on Arch Linux running wine 1.7.21 it seems to work flawlessly. I had to install wine before running the game (the script only works with apt based and yum based by the looks of things.. but thats not a big deal). I've been playing all day without anything unusual at all.

Link to comment
Share on other sites

Actually, if you could delete the /industrial/ tileset again and replace it with this one, that'd be great: https://dl.dropboxusercontent.com/u/26290309/industrial_updated.zip

Does that still work? If so, that should combine the best of the atlases with the fixing of the issues.

I found another map where that terrible slowdown is happening (terror mission).

I am attaching a screenshot of one of the worst (i.e. slowest) areas of that map.

Would it be possible to give it the same cure offered for the industrial map? Regards

snapshot2.jpg

snapshot2.jpg

snapshot2.thumb.jpg.c3b823028d70a834c695

Link to comment
Share on other sites

Try it and see (try both).

It works like a charm, thank you so much!

I found another map where that terrible slowdown is happening (terror mission).

Would it be possible to give it the same cure offered for the industrial map? Regards

I haven't had a terror site yet although I see no reason for it to work normally after I'm having the same issues on Industrial, so I'm joining the plea! I think desert military base missions also have a similar issue, albeit to a lesser extent.

Edited by KevinHann
Link to comment
Share on other sites

Steam, latest experimental build.

I'm not seeing any great slowdowns during gameplay. I do see a long (25sec) delay at the start of every ground op. The progress bar disappears before completion and I see my squad sitting in the chopper for a while before they wake up. I think it's just a scene-swapping issue. It's probably switching to the GC view before everything has loaded, hence the lack of progress bar completion.

I am also seeing an occasional CTD with autoresolve. It's rare. I think it only happens when I click autoresolve very quickly after the popup. 95% of the time autoresolve works properly.

Link to comment
Share on other sites

I am using Fedora 20 (64 bit), Gnome 3.10.2, and Wine 1.7.20 on a laptop using the integrated Intel GPU. I have tried both 1.0.7, and the latest community edition. I've tried both launching directly and via steam.

Having a problem where xenonauts seems to refuse to be in the foreground. If I move Xenonauts to it's own virtual desktop with no other windows present... I can then select the window and have it stay in the foreground allowing me to play the game.

Once I get the window to finally come up, things work pretty well with a few exceptions. Some times the Steam overlay does not accept mouse clicks. Occasionally the increment/decrement buttons increase by full stacks rather than individually (Can get around this with some fiddling and then it works as it should...). I've also had the game outright no longer respond to keyboard at one point after switching between applications.

Also, the windowed mode checkbox doesn't seem to do anything.

Thanks for the great game :D I've put quite a few hours into it on both Linux and Windows now.

Link to comment
Share on other sites

Having a problem where xenonauts seems to refuse to be in the foreground. If I move Xenonauts to it's own virtual desktop with no other windows present... I can then select the window and have it stay in the foreground allowing me to play the game.

Using the registry key mentioned in the following bug post solves the foreground issue with Gnome 3.10.x. (Apparently this bug is fixed in 3.12.x)

https://bugzilla.gnome.org/show_bug.cgi?id=722743

This also makes a good case for the xenonauts startup script using it's own wine prefix that also happens to have the key imported by default.

Link to comment
Share on other sites

  • 2 weeks later...

So far, so good. My stationary computer with no decent GPU and big screen (even 2 of them), went pretty smooth on Ubuntu 14.04.

Of course, there is little stuttering, and fast-forward makes little sideshow (which is totally bearable with me. As mentioned - no nice gpu on it). Game runs on own window, and doesn't conflict anyhow with multi-monitoring.

Played approximately 6 hours at weekend, with no crashes so far. Guess, it's ok. )

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...