Support us on Patreon
PayPal
Here's your utterly weird news of the day. Some time ago Xenonauts was ported to Linux by Knockout Games. The official website now claims it's not actually supported and is only meant for whatever the heck they mean by 'legacy customers'. Thanks to reddit for originally pointing it out.
Despite the Linux version being sold on GOG, Steam & Humble, I find it rather anti-consumer to claim on the official site that the Linux & Mac versions aren't actually supported. With regards to 'legacy customers', essentially, it's only meant for people who purchased it originally. If that's truly the case, having it advertised for sale across those stores is pretty bad practice.
This is taken right from the official site purchase page:
On Steam, they still say this:
That's obviously outdated information then.
The GOG & Humble store copies don't mention anything in relation to this at all.
It's actually another game that was ported natively to Linux to be included in a Humble Bundle (HIB 15 specifically). Games ported to be included in those bundles don't always get the best support.
Notice I said "natively" above, well, it was actually a goal on the original Kickstarter to do a Linux version. They eventually did a Wine-port and then the native port for the Humble Indie Bundle 15.
So, taking all that into account, why is it suddenly being claimed it's only for legacy customers? It just doesn't add up and I don't like it.
Considering the developer has moved on to making the sequel, which might support Linux, this will seriously impact my decision to support them.
I've sent an email to the developer to see if we can get this cleared up, as I never like to outright not support a small developer, but nothing sounds good here right now. Article taken from GamingOnLinux.com.
Despite the Linux version being sold on GOG, Steam & Humble, I find it rather anti-consumer to claim on the official site that the Linux & Mac versions aren't actually supported. With regards to 'legacy customers', essentially, it's only meant for people who purchased it originally. If that's truly the case, having it advertised for sale across those stores is pretty bad practice.
This is taken right from the official site purchase page:
QuoteLinux and Mac versions of the game are available on both platforms but are not officially supported; they were created for legacy customers and no technical support will be provided for those platforms!
On Steam, they still say this:
QuotePlease note that the native Mac / Linux versions of the game are still in beta, however older WINE-wrapped "ports" are available and known to be stable whilst development of the native ports is still ongoing.
That's obviously outdated information then.
The GOG & Humble store copies don't mention anything in relation to this at all.
It's actually another game that was ported natively to Linux to be included in a Humble Bundle (HIB 15 specifically). Games ported to be included in those bundles don't always get the best support.
Notice I said "natively" above, well, it was actually a goal on the original Kickstarter to do a Linux version. They eventually did a Wine-port and then the native port for the Humble Indie Bundle 15.
So, taking all that into account, why is it suddenly being claimed it's only for legacy customers? It just doesn't add up and I don't like it.
Considering the developer has moved on to making the sequel, which might support Linux, this will seriously impact my decision to support them.
I've sent an email to the developer to see if we can get this cleared up, as I never like to outright not support a small developer, but nothing sounds good here right now. Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
Considering the developer has moved on to making the sequel, which might support Linux, this will seriously impact my decision to support them.
Yeah, and they have a kind of tech demo for Xeno2 only via Galaxy GoG, one more reason to be prudent.
1 Likes, Who?
Wow... I own the game and follow the development of X2, but I didn't know this
and it comes as a shock for me. To see this kind of bad practise from Goldhawk
is horrible and makes me quite sad.
@liam: Have you actually been in contact with the developers?
How do they justify this behaviour?
Best regards,
lagh
and it comes as a shock for me. To see this kind of bad practise from Goldhawk
is horrible and makes me quite sad.
@liam: Have you actually been in contact with the developers?
How do they justify this behaviour?
Best regards,
lagh
0 Likes
@liam: Have you actually been in contact with the developers?As noted:
How do they justify this behaviour?
I've sent an email to the developer to see if we can get this cleared up, as I never like to outright not support a small developer, but nothing sounds good here right now.
1 Likes, Who?
BabaoWhisky 12 May 2017
Hopefully, there will be Phoenix Point for us !!!
1 Likes, Who?
@liam: Have you actually been in contact with the developers?As noted:
How do they justify this behaviour?
I've sent an email to the developer to see if we can get this cleared up, as I never like to outright not support a small developer, but nothing sounds good here right now.
Sorry liam.
I missed the last sentence. Please let us know what they answer.
0 Likes
No matter what the case ends up being right now, this is not the way to handle it. What should have been done was to make an announcement explaining any cuts in support, what is and isn't considered supported anymore and why. Cutting down on support for one's last game to focus on a new one makes sense, but selling a game and then stating it's not supported (in a different place than the store no less), is absolutely not okay.
If they really want to go down this route, they should at least put a sticker on the Steam / GOG page explaining that they don't have the manpower (or whatever) to support the Linux version at this time and offer it at half price in exchange - for existing Linux users, maybe offer Xenonauts 2 for free or at half price as an apology.
For what it's worth, I backed their original Kickstarter precisely because they promised a Linux version (right after they posted "We’ll also be putting female soldiers into the game, and providing a Mac and Linux version of the game too." )
Last edited by Cybolic on 12 May 2017 at 9:16 pm UTC
If they really want to go down this route, they should at least put a sticker on the Steam / GOG page explaining that they don't have the manpower (or whatever) to support the Linux version at this time and offer it at half price in exchange - for existing Linux users, maybe offer Xenonauts 2 for free or at half price as an apology.
For what it's worth, I backed their original Kickstarter precisely because they promised a Linux version (right after they posted "We’ll also be putting female soldiers into the game, and providing a Mac and Linux version of the game too." )
Last edited by Cybolic on 12 May 2017 at 9:16 pm UTC
2 Likes, Who?
As it is a single player game, my expectation and explanation as follows:
Thanks to stubborn and weird release cycle of the most popular GNU/Linux distro, Ubuntu, developers need to update and adapt their titles for every LTS release. When SteamOS and Steam client updates are added to this equation, some developers simply stop sopporting the games after certain LTS release. Most of the games should still work fine anyway, but in time, outdated dependencies might prevent those games to function properly or even launch. This won't be an issue for now but after half decade, you will wonder for what reason certain games do not work any longer... Does any one remember icculus' Medal of Honor Allied Assault beta port which is literally impossible to natively run on modern distros currently? That is why having "source code" matters...
Last edited by rea987 on 13 May 2017 at 12:03 am UTC
Thanks to stubborn and weird release cycle of the most popular GNU/Linux distro, Ubuntu, developers need to update and adapt their titles for every LTS release. When SteamOS and Steam client updates are added to this equation, some developers simply stop sopporting the games after certain LTS release. Most of the games should still work fine anyway, but in time, outdated dependencies might prevent those games to function properly or even launch. This won't be an issue for now but after half decade, you will wonder for what reason certain games do not work any longer... Does any one remember icculus' Medal of Honor Allied Assault beta port which is literally impossible to natively run on modern distros currently? That is why having "source code" matters...
Last edited by rea987 on 13 May 2017 at 12:03 am UTC
2 Likes, Who?
GustyGhost 13 May 2017
Spoiler, click me
You are right in that the ABI unstable nature of Linux makes it difficult to support well. However, it is not impossible, but it does require knowledge and skills that your average developer will not have unless they are already very familiar with the platform.
Steam's runtime was a good attempt to alleviate this, however it creates problems of its own. We used the steam-runtime SDK at VP simply because it gave a nice consistent set of libraries to build against. However, it quickly became a problem that they were too old, and the toolchain used to build against them (gcc 4.5) was also getting too old.
Valve did work on a newer steam-runtime, but it was only usable from inside a chroot. This is no good when you are using an IDE or some other application which wants to call those tools - you either have to run said IDE/app inside the chroot (which can be a dependancy nightmare) or live with a relatively slow invocation of the chroot enviroment for every file compiled.
Yes I know this is where the fanboys start screaming "use makefiles!" but this not what game devs are used to on other platforms, and quite frankly, they are cumbersome.
I did actually start to assemble a custom "SDK" for VP's Linux stuff, based around GCC 4.8 (which was still fairly current at the time).. but other things stopped me getting it finished off. Building your own toolchain with crosstool-ng or the likes is certainly not what your average dev will be used to dealing with!
edit: I should also say that expecting a developer to recompile the game when there's ABI breakage is not an acceptable solution. You really cannot expect a a developer to support something forever, and "just release the source code" is not a viable solution. More work needs to be put into ABI stability on Linux, for it's own good.
Am I reading this right? VP as in Virtual Programming?
0 Likes
You are right in that the ABI unstable nature of Linux makes it difficult to support well.
The Linux as a kernel has never break ABI. The problem is always other dependencies. It is not Linux fault. So the solution is not to "fix" Linux but to "fix" development for Linux as a platform so the developers would do the right thing by default without even thinking about it.
0 Likes
Alright. No money from me anymore to them. And we still have unbeaten openxcom! :-)
0 Likes
Don't use IDEs to compile releases, use a compile server that lets you recompile all games for a new platform each time you update the platform for a new game. Use automated tests to see if there are any regressions, and if there are none, then offering an updated version shouldn't be too hard.
Last edited by Ketil on 13 May 2017 at 12:27 pm UTC
Last edited by Ketil on 13 May 2017 at 12:27 pm UTC
2 Likes, Who?
Sorry, I meant, don't use IDEs on desktop computers to compile releases.Don't use SDKs to compile releasesHuh ? That doesnt make any sense... in this case an "SDK" is simply a known set of libraries. This is what every other platform does.
Simply building with "Latest compiler" against "Latest glibc/libstdc+++/whatever" is simply not a good idea.
Having a compile server with support for multiple platforms, and automated testing reduces the burden of anything breaking with a recompile. Usually the ABI changes are worse than the API changes. At some point even offering new binary automatically tested, but announcing it unsupported could still be better than not updating it at all.use a compile server that lets you recompile all games for a new platform each time you update the platform for a new game. Use automated tests to see if there are any regressions, and if there are none, then offering an updated version shouldn't be too hard.That still means pushing new releases.. which with publishers often means they want to do a round of QA before they approve release. Not feasible. Plus there is only so long you can viably do this for. You simply cant expect infinite maintenance on every released game.
1 Likes, Who?
I strongly prefer this over the status quo, which is "we don't want the overhead of supporting Linux, so we just won't port at all". I hate that attitude so, so much, but the vast majority of developers not already porting are taking EXACTLY that stance. There is a significant minority that are stuck with only D3D-based renderer options or a custom engine making the port far from trivial, but in the modern day that's usually not the case; making a functional binary on some common version of some common distribution really is as simple as hitting "build".
We can take care of ourselves, come on, throw us a bone! We'll figure out ourselves how to make that one very distro-specific binary run elsewhere, we've gotten pretty good at that. If we run into an issue we can't work around, we'll document it a lot better than virtually any Windows user and make it a lot easier to fix, and that's all we want -- feature parity and the occasional bugfix.
I feel that taking offense to this approach will push them towards the above attitude and drastically reduce the odds of the sequel being ported.
Last edited by roothorick on 13 May 2017 at 5:05 pm UTC
We can take care of ourselves, come on, throw us a bone! We'll figure out ourselves how to make that one very distro-specific binary run elsewhere, we've gotten pretty good at that. If we run into an issue we can't work around, we'll document it a lot better than virtually any Windows user and make it a lot easier to fix, and that's all we want -- feature parity and the occasional bugfix.
I feel that taking offense to this approach will push them towards the above attitude and drastically reduce the odds of the sequel being ported.
Last edited by roothorick on 13 May 2017 at 5:05 pm UTC
2 Likes, Who?
As it is a single player game, my expectation and explanation as follows:
Thanks to stubborn and weird release cycle of the most popular GNU/Linux distro, Ubuntu, developers need to update and adapt their titles for every LTS release. When SteamOS and Steam client updates are added to this equation, some developers simply stop sopporting the games after certain LTS release. Most of the games should still work fine anyway, but in time, outdated dependencies might prevent those games to function properly or even launch. This won't be an issue for now but after half decade, you will wonder for what reason certain games do not work any longer... Does any one remember icculus' Medal of Honor Allied Assault beta port which is literally impossible to natively run on modern distros currently? That is why having "source code" matters...
I have native Metal of Honor Allied Assault running on Fedora 25 just fine right now. That said, it wasn't install and done. I used a walk through for most of it and had to manually figure out audio to get it working. If they have one good Linux person to keep the dependencies/library versions in order (packaging old versions and fixing startup scripts) it shouldn't really be an issue. Contracting that from time to time shouldn't be a problem either, as long as your contractor is good. This is to much for a lot of dev/publishers though, even on Windows after a decade many games don't work without user fixes. I remember editing the binary for Red Faction 2 with a hex editor so it would work with DirectX 9 (this game is still sold on Steam even though it won't run out of the box on anything newer than Win XP).
Last edited by m2mg2 on 13 May 2017 at 8:37 pm UTC
1 Likes, Who?
@jaycee has the right implementation, the ability to be able to have and use multiple .so files (a smarter shared object linking mechanism)- there could be an even simpler solution where the game ships with its required .so files bundled with the game as part of the installation - completely removing dependency issues. Its kind of a no-brainer really
1 Likes, Who?
No support (for Linux, while Windows version is supported) = unprofessional developers.
Last edited by Shmerl on 14 May 2017 at 3:13 am UTC
Last edited by Shmerl on 14 May 2017 at 3:13 am UTC
0 Likes
How to set, change and reset your SteamOS / Steam Deck desktop sudo password
How to set up Decky Loader on Steam Deck / SteamOS for easy plugins
See more from me