Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
This can really be ignored, that's a typical error reported for dedicated servers based on Steam running on Linux. This library is not needed to run the server.
I encounter this error in a private UE5 project running a dedicated server through Steam, but the server works just fine.
It is a Linux container running Proton to execute the Windows binary files of ASA. It works and it is also stable. Running my server since 2 days without any crash (so since I launched it).
I appreciate it! Okay using the -d on the compose now I can see netstat showing its listening on the desired ports so that's great, and I know my router is forwarding those two ports to the server's IP but I can't see my server in the client's server for unofficial dedicated servers /w password but that's something I guess I gotta figure out.
Do you know of any way to poke the server's own logs so I could maybe see what it actually launched with arguments wise? I'm wondering if it picked up the start-parameters file content correctly so I can be sure the server's name is what I think it is.
I found the server logs and can see its launching as "Server: "ARK (6 digit number)" and I can search and find it with my client but when I attempt to join and provide a password (the one I want or some random garbage) it gives me a pretty long reply of along the lines of Join Failed with a bunch of Net driver type info that includes my proper WAN IP and such.
Not sure how to proceed here, but I think the important part is probably figuring out why it won't take the start-parameters file info like the SessionName="MyWantedServerName" and that I can't search for that and find it
I think this .so is required for the Steam client. I have read something about it in Valve's docs, might be run on that though.
What's your setup? You're hosting the server in your local network on a Linux machine and attempt to connect to it through your Windows client? Machines in the same subnet?
Also try to connect directly by open the console and enter the IP address of your Linux server by typing "open x.x.x.x" in the console. Console can be opened by pressing ` (backticks) if you're on an American layout. Friends of mine using a German layout were experiencing issues when they attempted to open the console. Might be a layout thing.
Regarding the session name: Could you paste how it looks like? Also try as an alternative to put the session name in the GameUserSettings.ini by adding a section called "[SessionSettings]" and adding a key called "SessionName".
Could look like this:
[SessionSettings]
SessionName=My cool server
Try "Feynt\'s Island" and see if that helps. Some chars are interpreted by the shell whether you like it or not and you have to 'escape' them by putting a \ in front, so the shell interprets it as plain text. Normally a ' would explicitly tell the shell 'what comes next is a string, don't assess it for commands'.
Oh well, thanks for trying and letting me know.
Yep a Ubuntu linux VM with this container running within, I deduced its networking related I get the error that people are talking about in this thread when I connect to the server through the server search function:
https://steamcommunity.com/app/2399830/discussions/0/3881599433106449323/?ctp=4
One thing I thought of is I was using non-typical ports (7778 and 27015) so I opened up the typical 7777 & 27020 on the router to forward and changed the server's values and the docker compose, now it doesn't give me that odd looking timeout but it just times out after 30 seconds after waiting to join the server after putting in the password.
I ran a tcpdump on the host and I saw no comms at all coming to the ark server.
So I tried the console 'open:myserverInternalIP:7777' and I can connect (...without a password prompt?!) and I saw the network traffic between the server and my desktop in tcpdump along with the server's log to confirm that I was connecting to it.
So now I'm at a loss, but for different reasons.
Does the server have multiple network interfaces? e.g. multiple IPv4 addresses?
Just the one virtual one (its a VM) and then the internal virtual ones that docker makes itself. I figure if the router port forwarding wasn't working right the server wouldn't even show up in the list in the client and its the same settings I'd used to host many ark:SE servers over the years on linux VMs, adding docker to the mix is new to me this round, as is the ASA of course.
I was also thinking and tried using the console open command to try to reach the server through my router using its LAN address of 192.168.1.1 (no go just timed out cool I doubt the forwarding is listening on that interface any ways), but when I tried using my WAN IP I got that other timeout error with all the extra right away.
I'm wondering if the ASA method is trying to direct my desktop to come at the server from the external IP and my router is slapping down that silly traffic. You'd figure more people would be posting about stuff like that if it was the case.
Let me also just vent for a sec on how stupid it was for Wildcard to name the two games so similarly because its really hard to weed out server trouble shooting for ASE vs ASA, aaargh.
I'll keep trouble shooting but I think I might abandon the container based method just to see if I touch earth with a *yuck* windows based host.
Edit: Another test I opened port forwarding on the router to the server's SSH port and could connect to it no problem via my WAN IP, so hair-pinning through the router works fine.