DJWoodZ / Satisfactory-Discord-Bot

A Discord bot that posts Satisfactory Dedicated Server status information such as online players.
MIT License
21 stars 2 forks source link

Port Change with Satisfactory 1.0 #33

Closed spackletoe closed 2 months ago

spackletoe commented 2 months ago

It looks like Satisfactory no longer uses port 15777 -- it now only uses port 7777. What change should I make to ensure the bot still talks to my discord server? The log shows that the bot can't find the server, even though the server is running fine. Thanks!

Updating... Error: Connection timed out at Timeout.<anonymous> (/usr/src/app/node_modules/@djwoodz/satisfactory-dedicated-server-query-port-probe/index.js:20:12) at listOnTimeout (node:internal/timers:573:17) at process.processTimers (node:internal/timers:514:7)

generalrap commented 2 months ago

I tried changing SATISFACTORY_BOT_SERVER_QUERY_PORT to port 7777 in .env, but all that did was break the bot. I'm trying to find where else I could make that edit, but can't find anything else so far.

generalrap commented 2 months ago

Doing some digging, it appears that the Satisfactory logs are accessed via this probe: https://github.com/DJWoodZ/satisfactory-dedicated-server-query-port-probe

In that probe's index.js, it specifically connects via port 15777. I'm trying to see if there's a way to change that?

spackletoe commented 2 months ago

You just arrived where I was when I posted this. The file you speak of is in the error message above. It's a root owned file, so if you can be root where you can access it, you can make the necessary changes. My issue is that I'm running the Satisfactory Dedicated Server as a docker container (by ich777) through Unraid, which doesn't allow you to (or I haven't found a way to) access this file anywhere but the container's console, which doesn't let you be root. So until that index.js is updated, I'm out of luck.

I might be able to download the current release, edit index.js, then install it on my server?

I'll keep trying stuff.

DJWoodZ commented 2 months ago

Thank you for reporting this. I think changing SATISFACTORY_BOT_SERVER_QUERY_PORT to port 7777 doesn't work because the Satisfactory Dedicated Server works differently now.

It looks like the query port, which this bot relied on to obtain the server status, is no longer available. The format of the log file, which this bot uses to determine the player information, may also have changed. I will investigate further.

generalrap commented 2 months ago

I'll just reply here instead of also doing so at the other page so you don't have to jump back and forth. Looking forward to seeing what you think the solution might be! This bot has been a big part of the social life of our server, as being able to see who is on and when is fantastic for jumping on for some spontaneous co-op sessions. I'm more than willing to test things out if you need guinea pigs.

DJWoodZ commented 2 months ago

Thank you @generalrap. I have made some progress with this. It looks like the Satisfactory Dedicated Server's API has changed, but I think I've figured out the changes I need to make to DJWoodZ/satisfactory-dedicated-server-query-port-probe to get it working again. 🙂 The next thing for me to investigate is if the log file format has changed.

PBLCelt commented 2 months ago

I am glad this is being worked on. The Players on server seems to be working fine. The fact that it changed from UDP 15777 to TCP 7777 seems to be why its timing out.

DJWoodZ commented 2 months ago

I have just pushed a change to branch 33-port-change-with-satisfactory-10, which hopefully fixes this bot to work with Satisfactory 1.0.

Please note that SATISFACTORY_BOT_SERVER_QUERY_PORT has been renamed to SATISFACTORY_BOT_SERVER_PORT to reflect the fact that the dedicated server no longer has a separate query port. This will be 7777 by default. So you will need to update/recreate your .env.local file.

Also note that the majority of this fix was implemented in a new library (@djwoodz/satisfactory-dedicated-server-lightweight-query-probe) meaning the dependencies will need to be reinstalled. For example, with one of the following commands:

generalrap commented 2 months ago

Fantastic! Thank you so much, it's truly appreciated.

What's your recommended method of updating an existing docker container?

josephdicarlo1 commented 2 months ago

@DJWoodZ just wanted to chime in and say thanks for this awesome project and getting it fixed up so fast, the factory must grow 🛠️

DJWoodZ commented 2 months ago

I recommend:

1) stopping your existing discord bot container, if it is running (e.g. docker compose down) 2) checking out the branch (e.g. with git pull and git checkout 33-port-change-with-satisfactory-10) 3) checking/editing your .env.local (i.e. if it contains SATISFACTORY_BOT_SERVER_QUERY_PORT, rename it to SATISFACTORY_BOT_SERVER_PORT and set the correct port, e.g. 7777) 4) (optionally) bring it back up in foreground mode so that you can easily see the logs (e.g. docker compose up --build --force-recreate) 5) bringing it back up in detached mode (e.g. docker compose up -d --build --force-recreate)

generalrap commented 2 months ago

I'm getting an EISDIR error that's gumming things up when I try to start up the container; seems like something is trying to read a directory instead of a file. Any suggestions?

Attaching to server-1
server-1  | Poll interval: 60000 milliseconds
server-1  | Found: /usr/src/app/db/db.json
server-1  | Updating...
server-1  | Logging out
server-1  | node:events:497
server-1  |       throw er; // Unhandled 'error' event
server-1  |       ^
server-1  |
server-1  | Error: EISDIR: illegal operation on a directory, read
server-1  | Emitted 'error' event on Tail instance at:
server-1  |     at ReadStream.<anonymous> (/usr/src/app/node_modules/tail/lib/tail.js:215:26)
server-1  |     at ReadStream.emit (node:events:519:28)
server-1  |     at emitErrorNT (node:internal/streams/destroy:169:8)
server-1  |     at emitErrorCloseNT (node:internal/streams/destroy:128:3)
server-1  |     at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
server-1  |   errno: -21,
server-1  |   code: 'EISDIR',
server-1  |   syscall: 'read'
server-1  | }
server-1  |
server-1  | Node.js v20.17.0
server-1 exited with code 0
DJWoodZ commented 2 months ago

That error suggests there is an issue with the log file path. However, when you use docker compose, the SATISFACTORY_BOT_LOG_LOCATION value in the .env/.env.local file is ignored. There is some information about how this works in the readme.

If you have changed the path in the compose.yaml, or if you need to change it, it might be worth refamiliarising yourself with this.

generalrap commented 2 months ago

Yes, good catch; I completely forgot I had changed that directory when I originally stood this up, and needed to update the compose.yaml file.

The bot is now connecting halfway. It comes online in Discord and gives a 0/4 player count, but otherwise does not send any messages about server status or player joins/disconnects. This is what the container is currently outputting:

Attaching to server-1
server-1  | Poll interval: 60000 milliseconds
server-1  | Found: /usr/src/app/db/db.json
server-1  | Updating...
server-1  | Log file open 09/17/24 10:05:04
server-1  | Updating...
server-1  | Updating...

I'm sure there's just a small thing I'm missing?

EDIT: It just keeps saying "Updating..." indefinitely.

DJWoodZ commented 2 months ago

The Updating... message refers to the network polling, but the player counts, joins, etc. are derived from the log, which is tailed in real time.

The log file format does not appear to have changed in v1.0, so I think your issue will be related to the log path or something causing updates to the log to not be detected (e.g. permissions).

You can try enabling SATISFACTORY_BOT_LOG_USE_WATCH_FILE in your .env.local, and it'll use an alternative method to detect changes, however, that shouldn't be necessary if you didn't need it before, as nothing related to reading the log file should have changed. I.e. your previous compose.yaml should continue to work, providing your environment hasn't changed.

I recommend double checking the compose.yaml is correct (specifically the volumes section, and remembering that SATISFACTORY_BOT_LOG_LOCATION refers to the path inside the container), then you should perhaps connect to the container in interactive mode to debug it, i.e. to ensure the log is correctly located and updated when you join/leave the server.