I've heard reports far and wide that the Linux to Linux multiplayer in Dying Light is broken. Myself and Samsai tried to connect to each other many times and it failed every time, lets get it fixed.
It's important due to it being a big game to have on Linux (and it makes Linux look better if games actually work properly), and there's a big update and expansion due out tomorrow.
I've asked them about it a number of times to no reply, until now. They just today replied to my latest support ticket about it, and they said they know nothing about this website or the bug (big sigh).
To quote my support ticket:
QuoteCould you explain your issue in more detail, please? Also, we do not know anything about the website you have mentioned.
Lastly, to help us diagnose your Linux issue, we would like you to send us the following files:
1) a list of all your environment variables (you can generate it by using the printenv command),
2) Dying Light's so-called crash.log files, which are created when launching the game. To find your Log files, go to your game's directory and then to .../DW/out/logs/ crash_??????_?????????.log
3) a report from a program called HardInfo.
You can download HardInfo by using the following line from the console: sudo apt-get install hardinfo
If you could all attach all the info into the comments (use dropbox or something for the crash logs), that would be fantastic. Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
It could have not been broken at all in the first place. For instance, I only tried to connect to strangers and who knows what NAT type they've been behind. The game doesn't seem to support revconnect so even if I wasn't behind ISP NAT they were and we couldn't connect.
Then, my ISP almost always provides an internal NATted IP but sometimes if I reconnect long enough (I wrote a script to automate that) I can get a WAN IP that's routable in the internet. Another point is that the port the game uses isn't clearly stated anywhere unlike most of the other games. All these factors may add up to what we had, the game wasn't playable in co-op.
Then, my ISP almost always provides an internal NATted IP but sometimes if I reconnect long enough (I wrote a script to automate that) I can get a WAN IP that's routable in the internet. Another point is that the port the game uses isn't clearly stated anywhere unlike most of the other games. All these factors may add up to what we had, the game wasn't playable in co-op.
0 Likes
Some more info. Yesterday we tried that setup, two on Linux, one on Windows and it seemed a bit weird. When the Windows guy connected, the other Linux one couldn't connect (dropped right after entering the session). So the connect order matters for us, at least when I host on Linux. First the Linux connects, Windows goes second. We played a couple of missions without any issues then. Going to try with one more Linux player so it would be 3 Linuxes and 1 Windows.
0 Likes
I tried to connect to another Linux player (and the other way around) and no luck this time. So the right answer to the question asked is: it depends on your luck. Wireshark shows several STUN requests so I think the game doesn't listen to any UDP port but instead binds a random one and sends to the other side. Most of the packets Wireshark marks as "GVSP" protocol, that's probably an error in detection. Other than that, the log is flooded with this (coming from me to the other player):
In the end, this should depend on the type of NAT both of you use. And it's not a simple topic.
Simple Traversal of UDP Through NAT
Message Type: Binding Request (0x0001)
Message Length: 0x0024
Message Transaction ID: 684e6b382b68454f6a4938394e2b5547In the end, this should depend on the type of NAT both of you use. And it's not a simple topic.
0 Likes
Well, if it makes you feel better, it's not platform-specific. It's easy to find such threads about XBox One and people never solved this. At least I managed to find how the game initiates the session. From the look of it, the game detects IP/port just fine but for some reason doesn't start the actual game session. It sends a single UDP packet that's not STUN-related and that's all. With another player it works as intended so it's probably a bad implementation of a really nice idea. It should have allowed to play even when both (or more) players are behind ISP NATs as long as port numbers are not altered by the ISP. Unfortunately, there's no debug info about these connection attempts so it's impossible to say why it fails.
0 Likes
Patreon
PayPal
See more from me