Realtime Gamelift Script Server Questions

0

For a gamelift realtime script, how do I set remote breakpoints for debugging the script?

How do I develop on a local instance for a gamelift realtime script? (Not a custom gameserver build, a realtime script)

I need to find a better workflow for debugging. Currently I have to upload a script to debug but I run into limitations with that.

posta 3 anni fa229 visualizzazioni
7 Risposte
0
Risposta accettata

A bit late, but the attached may help. monitor.txt|attachment (2.8 KB)

Basically it "tails" all the logs (there are lots, especially if your app keeps crashing) so you get the log output in real time.

Instructions (setup):

  1. Rename file as ".js" (I had to put as .txt to upload here)
  2. Put into the server app path so it gets uploaded to the "etag" directory one each deploy.
  3. Add https://www.npmjs.com/package/tail into package.json

Instructions (to run):

  1. SSH in to the instance to monitor.
  2. You need to run as root (sudo).
  3. cd to any "etag" (in /local/game - can be any of the etags, does not need to be the "latest" if you are doing multiple deploys)
  4. Run: /local/NodeJS/bin/node ./monitor.js

Notes:

  • Currently monitors last 10 files; each "server" (i.e. how many times your run your .js as set in console/CFN) creates a log file, so if you have more than 5 servers (on the single instance) then you might want to increase this. Of course there is performance hit, but for debugging you should be fine. [Monitor twice the files so you get the crash logs of the old ones)
  • Keep your etags clean with ls -td /local/game/etag-* | tail -n +3 | head -n -1 | sudo xargs rm -rf --
  • Keep your logs clean with cd /local/game/logs/ ls -t | tail -n +20 | sudo xargs rm -rf --
con risposta 3 anni fa
0

Right now I believe there is no method to locally run the script. Having written a few realtime scripts I share your pain on this.

I'll reach out to the GameLift service team as things may have changed since I worked with Realtime scripts.

For remote debugging, you can open any port on the fleet but that may not be enough for what is required as you can't launch the script with -inspect AFAIK.

con risposta 3 anni fa
0

Thanks for letting me know your thoughts. This is definitely a major pain point of mine right now. The problems I keep running into with realtime script debugging: -Not verbose enough logs and no control over that (i.e. -inspect, etc.)

-I have to spend time finding the correct log by ssh if downloading it directly is not possible for some reason through the AWS console

-I have to spend time uploading, which I've made a script to help automate but still takes time to run

So basically the feedback loop is very long if I want to test and verify simple things. I end up debugging blind in some situations and it becomes a huge time sink.

You have any ideas/thoughts on how to locate the right log faster for situations where downloading the log via AWS console is not possible @REDACTEDUSER

con risposta 3 anni fa
0

You can remote into the instance and tail the logs live on the box. Thats the faster path to debugging that I know of.

For a windows fleet theres good information here: https://forums.awsgametech.com/t/windows-remote-access-wont-connect-to-gamelift-fleet-******

If you need help for Linux fleets, let me know.

con risposta 3 anni fa
0

[quote="Robbie, post:5, topic:9955"] y monitors last 10 files; each “server” (i.e. how many times your run your .js as set in console/CFN) creates a log file, so if you have more than 5 servers (on the single instance) then you might want to increase this. Of course there is performance hit, but for debugging you should be fine. [Monitor twice the files so y [/quote]

@REDACTEDUSER

con risposta 3 anni fa
0

I was on vacation last week, and restrained myself from trying your script. So I finally tried it today, and wow. This is exactly what I needed. Thank you. This will help me out so much. Can't thank you enough @REDACTEDUSER

con risposta 3 anni fa
0

Thanks for the feedback.

con risposta 3 anni fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande