Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

Civilization VI [Steam] had the massive Fall 2017 patch released for Windows on October 19th, but sadly the patch is taking a while for Linux (and Mac).

For those hoping to dive back into Civilization VI with the refreshed game over the holiday, this is sure to be rather dissapointing news. Especially since it's quite a big patch and it means Linux gamers are currently missing out on the Khmer & Indonesia DLC pack. Here's what Aspyr Media said in their update:

UPDATE 12/20/2017
 
Due to extensive development and necessary code fixes, this patch has taken significantly longer than previous updates.  We will not be able to release the Mac and Linux Khmer and Indonesia update until sometime after the holiday break. We apologize for any inconvenience. 

I'm sure they have perfectly valid reasons, I just hope they haven't encountered a really nasty bug that takes a while to work around. Even so, it's hard not to be dissapointed since this patch is now over two months late. You can keep an eye on this page for updates. 

Full details on what the patch does is available here.

Article taken from GamingOnLinux.com.
0 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
27 comments
Page: «3/3
  Go to:

Colombo Dec 29, 2017
If you write comments, then they are part of code.

Its the same as leaving variable name after everything else was changed and thus the variable name no longer correspond with its function.
jens Dec 29, 2017
  • Supporter
Quoting: tuubiIgnoring the condescending tone of your reply
I guess both our comments have that condescending tone. I apologize if that triggered something inside you, that was not my intention.

Quoting: tuubiis that supposed to be an argument against code comments?
No, as I stated, there are lots of valid comments. Mostly about WHY a certain piece of code has to be there, assumptions, preconditions, external references etc.

I discourage comments about WHAT a certain code is doing, these kind of (simple or ugly) comments should be part of the code itself.

// This is needed due to this and that

var i = 0; // iterates over list Y

// Does something
[a few lines of code]

// Does something else
[a few lines of code]

// Does something different if this is given
if (this == that && that == something)
{
  [a few lines of code]
}

should imho be written as
// This is needed due to this and that
var yIterator = 0;
DoSomething();
DoSomethingElse();

if (ThisIsGiven())
  DoSomethingDifferent();

...


The second version is much more robust against rework and refactoring, don't you think? Note that I was taking about several years, i.e. ten, between Developer/Team A and B, where A and B have never spoken to each other. Development methods (coding styles, review procedures, team organization) were quite different ten years ago and will be again quite different ten years in the future. Code that has to to survive this time span will get messy over time due to different approaches how to solve things, especially because teams doing maintenance later are usually not the strongest ones. Having code as robust as possible, that includes removing ugly comments and replace them with method extraction and better naming, helps to stand the test of time a little bit better.

Edit: Extend sample.


Last edited by jens on 29 December 2017 at 2:26 pm UTC
jens Dec 29, 2017
  • Supporter
Quoting: GuestThat book has the word "agile" in the full title. No way I'm going to read it. I despise that term.
Yeah, shame that this term has been so heavily abused, especially by so-called scrum masters that never really understood what this is about. The original meaning/the statements from their manifesto are still very valid if one reads with care.
jens Dec 29, 2017
  • Supporter
Quoting: GuestOh, and medical device development isn't suited to "proper" agile. It needs documentation for every minor detail and change (with good reason really).
Yes, sure, should have added that there are branches that needs a different or adapted treatment. There is no "one size fits all". If someone claims so for whatever, it ain't true.


Last edited by jens on 29 December 2017 at 10:56 am UTC
slaapliedje Dec 30, 2017
My 'favorite' thing to see now is a mish mash of languages inserted into scripts. I am in the middle of trying to teach myself python while rewriting this python script that currently uses a perl script/library, and several bash scripts that then run fabric commands....

Where I currently work, I even say a Nagios check that is written in perl, that then calls a bash script to set up the environment, which also calls another perl script, which then runs a bash script...

I am pretty shit at coding, but even I know that is just a jungle of wtf?
tuubi Dec 30, 2017
View PC info
  • Supporter Plus
Quoting: slaapliedjeMy 'favorite' thing to see now is a mish mash of languages inserted into scripts. I am in the middle of trying to teach myself python while rewriting this python script that currently uses a perl script/library, and several bash scripts that then run fabric commands....

Where I currently work, I even say a Nagios check that is written in perl, that then calls a bash script to set up the environment, which also calls another perl script, which then runs a bash script...

I am pretty shit at coding, but even I know that is just a jungle of wtf?
I guess that's how the Unix-like ecosystem of "small tools that do one job well" is built. As long as the scripts are well separated and have clean interfaces, it doesn't really matter how they're scripted. But yeah, that could also be a jungle of wtf.
slaapliedje Dec 31, 2017
Quoting: tuubi
Quoting: slaapliedjeMy 'favorite' thing to see now is a mish mash of languages inserted into scripts. I am in the middle of trying to teach myself python while rewriting this python script that currently uses a perl script/library, and several bash scripts that then run fabric commands....

Where I currently work, I even say a Nagios check that is written in perl, that then calls a bash script to set up the environment, which also calls another perl script, which then runs a bash script...

I am pretty shit at coding, but even I know that is just a jungle of wtf?
I guess that's how the Unix-like ecosystem of "small tools that do one job well" is built. As long as the scripts are well separated and have clean interfaces, it doesn't really matter how they're scripted. But yeah, that could also be a jungle of wtf.

Makes it really hard to troubleshoot, that is for sure.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.