It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Any info why "Shadow Tactics: Blades of the Shogun" has version 2.2.2.f only for win and mac?

Did the linux binary choke on QA - if yes, is the dev trying to fix or it's over? Or was it not even submitted? If I understand the release notes on steam correctly, the 2.2.2 does exist for linux, so it's probably the QA thing, or not delivered. Some transparency in the process would help, I don't mind if we are not told particular buglist or contract detail, but at least some "undecided, other, secret || not delivered by dev || rejected by GOG || on the way" would be nice - and not just with this game.
avatar
ped7g: Any info why "Shadow Tactics: Blades of the Shogun" has version 2.2.2.f only for win and mac?

Did the linux binary choke on QA - if yes, is the dev trying to fix or it's over? Or was it not even submitted? If I understand the release notes on steam correctly, the 2.2.2 does exist for linux, so it's probably the QA thing, or not delivered. Some transparency in the process would help, I don't mind if we are not told particular buglist or contract detail, but at least some "undecided, other, secret || not delivered by dev || rejected by GOG || on the way" would be nice - and not just with this game.
Hi, I replied to this question here: https://www.gog.com/forum/general/general_linux_faq_and_troubleshooting/post1186
avatar
immi101: "original" = keep the timestamps the same as they are when the developer transfers the files to you. normally you expect that copying/transferring a file should not modify file attributes.
when I have a tool/mod that works on the old disc version but not with the GOG version then looking at the modification dates of the files is a quick way to get an overview if and where GOG modified things.
same when a game gets an update and I want a quick look which files got changes. Stripping the file modification dates is simply a loss of information for no apparent reason. There is a reason why that information is retained when copying data on an usb stick and giving it to somebody, when putting it into a innosetup installer and distribute it to people or when putting a file in a zip archive and extract it later.
Going against established common behaviour is bound to cause confusion and irritation. (and bugs: see that link for Oblivion)
I did some research and I've learned that in case of Oblivion vanilla is not affected and that the modding issues are caused by usage of legacy modding tools that can be replaced with better modding tools.

We will keep an eye on this. By all means please report all such problems to us! Since the timestamps thing affects games downloaded from Galaxy client in the first place, I would be grateful if you could report them using our Galaxy Issue Tracker: http://mantis.gog.com

avatar
immi101: I did some testing yesterday and some games indeed take notably longer, see Kingpin for the worst offender.
but note that all this was tested under linux+wine. some windows people probably should try to verify that.

(the good news: innoextract is way faster with the new installers ^^)

<data>
That's some good data that we can work with. We will investigate cases such as Kingpin and see what can be done to improve install speeds. Thank you!
avatar
immi101: <snip>
I've found that some of the new installers are faster, and some are slower. I think it's partly due to Wine and partly due to system setup; Wine seems to have some fairly substantial overhead with file access, as I've noticed for quite some time that games with lots of smaller files take considerably longer to install in Wine than they do on Windows, or similarly sized games with fewer but larger files (and for games that have large files the new installers will need to create/access a *lot* more files). Also I have two HDDs in my system and install from one to the other to speed things up, but the new installers won't benefit as much from this.

It's always been much faster to unpack the installers with innoextract though. Civilization IV is a particularly notable example:

Installing Civ4 via Wine: 28:31
Unpacking the Civ4 installer using innoextract: 0:37
avatar
immi101: <snip>
avatar
adamhm: I've found that some of the new installers are faster, and some are slower. I think it's partly due to Wine and partly due to system setup; Wine seems to have some fairly substantial overhead with file access, as I've noticed for quite some time that games with lots of smaller files take considerably longer to install in Wine than they do on Windows, or similarly sized games with fewer but larger files (and for games that have large files the new installers will need to create/access a *lot* more files).
that would fit to the test results. Arcanum has 70 files while Kingpin has 5444.
so the slowdown is probably increased a lot under wine. I wonder how much of it can be seen under windows.

avatar
adamhm: It's always been much faster to unpack the installers with innoextract though.
right, of course.
but I was more pointing to the fact that it got even faster with the new installer. I hadn't quite expected that difference in speed between zlib <=> lzma decompression.
Post edited April 20, 2018 by immi101
avatar
linuxvangog: I am currently working with the team responsible for Windows installer to publish fragment of code that the community can use to unpack new installers. Eventually it won't be much different from what community came up with already.
I totally missed this whole development. Thanks for trying to help and thanks to @immi101 for the implementation! Hopefully innoextract can accept the working solution upstream.
Post edited April 20, 2018 by shmerl
avatar
linuxvangog: I did some research and I've learned that in case of Oblivion vanilla is not affected and that the modding issues are caused by usage of legacy modding tools that can be replaced with better modding tools.
If I remember this particular issue correctly, the problem was that the file modification dates on those .esm and .esp files were somehow removed all of a sudden during an installer/Galaxy file update.

So yes, Wrye Bash could have handled such files more graciously, but to be honest have you ever run across any windows file with a blanked out modification/creation timestamp outside of this context? I'm sure I haven't.
Post edited April 27, 2018 by WinterSnowfall
What I don't get is that GOG staff knew this messing around with file timestamps was a problem as they had already rolled it back once:

https://www.gog.com/forum/general/wrye_bash_no_longer_works_after_recent_oblivion_galaxy_update/post12

So why have they changed them again?
avatar
Korell: What I don't get is that GOG staff knew this messing around with file timestamps was a problem as they had already rolled it back once
The content system does not store file timestamps. They didn't remove or add timestamps, just switched back to the older build method.
avatar
Yepoleb: The content system does not store file timestamps.
Then I see this as a big flaw in the content system as it shows that it does not store all of the data for the files. And yes, the timestamp is part of the file data.
I also think that original timestamps need to be preserved. First, with older games it helps in identifying which particular version of the game GOG sells by looking at file creation dates. Second, it is useful to be able to see which files were added by GOG's team in the game folder as opposed to original game data. Here again I refer to original file creation dates.
avatar
Korell: Then I see this as a big flaw in the content system as it shows that it does not store all of the data for the files. And yes, the timestamp is part of the file data.
I agree, this was a stupid oversight when the system was designed. It is not easy to fix now though, as this requires changes at every stage of the process, so I think we should give them at least a few weeks of time before complaining again. It's probably better to look into finding a community solution than to wait for this feature to get implemented.
avatar
Yepoleb: It's probably better to look into finding a community solution than to wait for this feature to get implemented.
I’m not sure we can do anything if timestamps are lost at packaging time.
Post edited April 30, 2018 by vv221
avatar
vv221: I’m not sure we can do anything if timestamps are lost at packaging time.
You could get them from an old installer and write a patcher.
avatar
Yepoleb: I agree, this was a stupid oversight when the system was designed. It is not easy to fix now though, as this requires changes at every stage of the process, so I think we should give them at least a few weeks of time before complaining again.
What a mess..

The problem is that Gog's devs are already changing many installers.
The later they'll acknowledge the issue, the less it will be possible for them to fix it.

Could you guys suggest them any good solution that wouldn't require chunks and timestamp loss? :'(
Post edited May 12, 2018 by phaolo