Changing Logger output and adding Stacktrace

Local Setup
1

Hi there, I have 2 questions regarding the Logger.
For the game I’m currently developing I have a Nakama server setup with typescript to create authoritative matches. I also wrote a library for handling specific game logic on the client and to handle action validation on the server, wich I import through rollup.

During development I noticed I found it hard to debug for 2 reasons.
The first reason is because a log message is long and bloated in my case a log would look like this

{“level”:“warn”,“ts”:“2022-03-30T12:37:11.552Z”,“caller”:“server/runtime_javascript_logger.go:84”,“msg”:“Explosion id 5 is not recognized”,“mid”:“aabcef5c-ff20-4135-bafc-40ee63395dba”}

this exceeds my window width making the logs less readable. In my case I only test 1 match a time. so I wouldn’t need the timestamp or the match ID values in my log.

The second reason is because the caller always points to a go file which I can’t access so I don’t know where in my code the error originiates from. It could be in my match handler, it could be in a module imported and it takes time to find these things while I’m used to have a stack trace that shows me at what point the error failed such as :

ReferenceError: FAIL is not defined
   at Constraint.execute (deltablue.js:525:2)
   at Constraint.recalculate (deltablue.js:424:21)
   at Planner.addPropagate (deltablue.js:701:6)
   at Constraint.satisfy (deltablue.js:184:15)

So my question is, is it possible to change what the logger outputs per default?
and is it possible to get a more proper stack-trace to work inside the Logger?

2

Hi @Aaron, welcome to the forums.

So my question is, is it possible to change what the logger outputs per default?
What we usually recommend is to pipe the output to jq to format it however you like, as we currently don’t support logger changes.

and is it possible to get a more proper stack-trace to work inside the Logger?
This is currently unsupported due to a limitation of the JS engine Nakama uses.