[0.18.9] No longer playable on NixOS

[Baughn]

I use the 'steam-run' package to run Factorio on NixOS, which provides a FHS environment by remapping the filesystem, pointing /usr at a package in /nix/store. /usr is normally nonexistent, making this a necessary prelude to running Factorio without patching the binary.

However, somewhere in the 0.18 series the data location sniffing in Util.cpp appears to have gone wrong, making it believe the data files are supposed to be in /usr/share/factorio. As I'm running it from ~/Downloads, this is of course not the case -- see errors below.

If I could see precisely how you're sniffing this, I could probably amend steam-run to provide a more accurate simulation of Ubuntu.

Code: Select all

~/Downloads/factorio » nix-shell -p steam-run --run "steam-run ./bin/x64/factorio"                                                 svein@saya
   0.000 Error Util.cpp:83: Error configuring paths: There is no package core in /nix/store/l3fg9r2gnz41vwd7krhmljjl3cfpgw0m-steam-run-fhs/usr/share/factorio. Deduced executable directory: /home/svein/Downloads/factorio/bin/x64, read data: __PATH__system-read-data__, write data: __PATH__system-write-data__
   0.000 Goodbye

[ptx0]

this also occurs on Gentoo Linux, which we've worked around by symlinking dirtily.

[justarandomgeek]

You can probably work around this at least by editing the generic placeholders in the path fields of config.ini to have correct paths in them for your system.

EDIT:
The default __PATH__system-read-data__ placeholder expands to __PATH__executable__/../../data (except on macs, afaik) and __PATH__system-write-data__ to __PATH__executable__/../.. or to a platform specific user-tree path.

It's not entirely clear from your log line if the __PATH__executable__ var will work for you, you can definitely put a literal path in to point it to the right place.

[Baughn]

It doesn't get far enough to create config.ini, so I don't think that's an option.

[Baughn]

Version 0.18.8 works fine, by the way.

[Baughn]

This appears to be fixed in 0.18.10, but there's no corresponding changelog entry. I'm worried it might be by accident.

[posila]

Thanks for letting us know. There was no change anywhere near the area that would break it in 0.18.9, and no change in 0.18.10 to attemp to fix it.

[Baughn]

So when I confirmed that 0.18.8 worked fine, I didn't actually check 0.18.9. Turns out it also works fine, which means whatever was changed is in my OS. Fortunately I can git-bisect it...

Unfortunately this didn't let me replicate the bug. This should mean it's environmental, and I've changed too many things to be sure of what made the difference. Considering it works right now, I'm going to call this closed until it happens again. At which point I suppose I'll dig out IDA.

[Rseding91]

So when I confirmed that 0.18.8 worked fine, I didn't actually check 0.18.9. Turns out it also works fine, which means whatever was changed is in my OS. Fortunately I can git-bisect it...

Unfortunately this didn't let me replicate the bug. This should mean it's environmental, and I've changed too many things to be sure of what made the difference. Considering it works right now, I'm going to call this closed until it happens again. At which point I suppose I'll dig out IDA.

I just want to say, this has got to be the most linux-user-like-statement I've ever read

You change random stuff and things break. You have no idea why something is broken but unrelated you keep changing random stuff and it starts working again without even meaning to do it. Meanwhile we've changed nothing but get blamed for the random tinkering you've doing.

It's why anytime any linux user makes a bug report I just let it sit for 2 -3 days and a *huge* percent of the time they just self-reply with "nevermind it's working now" or "I fixed it/I broke it earlier with some change I did that I never needed to do but i'm a linux user so I did it anyway just to see what would happen."

97.63159%~ of the time it works every time to just ignore bug reports from linux players

[dee-]

Kudos for using NixOS, having tested with different versions (game AND OS!), volunteering to git-bisect it (which OS can?), pulling the report back and describing what has ben done

[ptx0]

yes, but it's still broken on Gentoo, where no tinkering or other things have ever occurred.

it's always been broken here.

Code: Select all

% ls -al /usr/share/factorio 
lrwxrwxrwx 1 root root 24 Jan 14 12:09 /usr/share/factorio -> /home/kash/factorio/data

is needed to make it work.

[Bilka]

yes, but it's still broken on Gentoo, where no tinkering or other things have ever occurred.

it's always been broken here.

Code: Select all

% ls -al /usr/share/factorio 
lrwxrwxrwx 1 root root 24 Jan 14 12:09 /usr/share/factorio -> /home/kash/factorio/data

is needed to make it work.

Does using the --executable-path PATH commandline parameter help you in any way? It's description of "Override autodetected __PATH__executable. Usually not needed except on very weird systems." sounds like it would solve the problems given in this thread.

[ptx0]

yes, but it's still broken on Gentoo, where no tinkering or other things have ever occurred.

it's always been broken here.

Code: Select all

% ls -al /usr/share/factorio 
lrwxrwxrwx 1 root root 24 Jan 14 12:09 /usr/share/factorio -> /home/kash/factorio/data

is needed to make it work.

Does using the --executable-path PATH commandline parameter help you in any way? It's description of "Override autodetected __PATH__executable. Usually not needed except on very weird systems." sounds like it would solve the problems given in this thread.

it finds the x64 binary just fine but the data path detection is where it goes wrong. it says cannot find package.core. but I will have to give this a try later.

[blahfasel2000]

In case you are still trying to debug this, the following command usually helps with finding out which file locations a program tries to access:

Code: Select all

strace -e open,openat,fstat -o /tmp/strace-open-log /path/to/bin/x64/factorio