Hello!
I am trying to initialise the services to connect to our internal server, and I was creating them in the nk.run_once() method, so it’s only created once. Now I wanted to store this object somewhere I could see from inside the match handlers for when I have a new match I can ask configurations to the internal server. Where can I do this? I tried putting into the context, but it’s not there when I’m inside the handlers.
nk.run_once(function(context)
nk.logger_info("Initializing services")
context.server_client = ServerClient:create()
end)
function M.match_init(context, setupstate)
local gamestate = game.create()
local tickrate = 1
local label = "TexasHoldem"
local response = context.server_client:config_retrieve()
-- DO SOMETHING HERE
return gamestate, tickrate, label
end
Hi @faustofonseca. Unfortunately you won’t be able to store custom objects/properties into the context object in the run_once right now. The Lua runtime is sandboxed and runs in a similar way to a Function as a Service executor within the game server. The state for the VM is lost at the end of the RPC function call.
Fortunately in your example code you use the match handlers which do allow you to maintain state which will be threaded through the match lifecycle on each function invocation. I’d recommend you just cache the ServerClient:create() inside the state table object which you return when the match handler is created. i.e.
function M.match_init(context, setupstate)
local gamestate = game.create()
local tickrate = 1
local label = "TexasHoldem"
gamestate.server_client = ServerClient:create()
local response = gamestate.server_client:config_retrieve()
-- DO SOMETHING HERE
return gamestate, tickrate, label
end
The code above does mean that each match handler will cache it’s own ServerClient instance but the overhead is very small unless the logic inside that :create() call is very computationally expensive?
Hello @novabyte,
I actually had to review my own code. My fear was that I was creating a new session on each match and thus having a new call to the server without need. One solution I was thinking was actually storing the session token in a collection with a expiry date and then re-use it on every match. But I actually remembered that, since I’m doing server-to-server, I’m going to use a master key, so It’s fine to just create a new ServerClient instance per match.
I must confess I, sometimes, need to wrap my head around the fact that I’m using a stateless server 
Thank you so much for your help!
No worries. I’m glad you’ve found a good strategy for it.
sometimes, need to wrap my head around the fact that I’m using a stateless server 
That’s a good point although the server isn’t quite stateless because it does maintain a lot of information and pass them through (like presences, chat channels, streams, etc, etc) in various first-class APIs. You can think of the Lua server runtime as stateless though because each lightweight VM from the pool is reset after the custom logic is executed.