How to access custom variables and methods of authoritative match handler in other modules?


I’m making a match handler on Lua runtime. The match handler itself has some variables and methods besides the needed functions for a match handler such as the match_loop or match_join. I have defined my own variables and methods that should exist for each match (so, not global) like this:

local M = { a_variable = -1 }

function M.a_method()

function M.match_leave(...)
    -- ...

I want to make an RPC so that the client can access the a_variable of their own match. I saw the source code and found that there is a function nk.match_get(match_id). But it doesn’t seem to give me access to the a_variable or the a_method that I created for my runtime match handler.

Can you help me with this?

Nakama 3.11.0; Docker; CockroachDB;

You should store these variables in storage i think - Nakama: Lua | Heroic Labs Documentation


Thank you!
Yes that will work for sure. I was just wondering if there’s a way to access the match handler variables directly.

The function header for the MatchGet is MatchGet(ctx context.Context, id string) (*api.Match, error)

Hey @amuuu, get_match() won’t return you variables or methods you declared in code. It does return the match handler name, so you could store it as a key using the storage engine together with your relevant variables/data.

Thank you I have to use the storage engine then.

@amuuu Also worth noting there may be other ways to achieve what you need. What exactly will these variables/functions be doing, and how will they be accessed?

If it’s clients that need to call them then you should do this via match data sends with specific opcodes you designate - when the match loop receives those opcodes it would trigger the correct function on behalf of the user, and return the results via a broadcast if needed.

@zyro thanks for the response!
The main thing that I do with those variables is managing some gameplay roles and ID assignments.
I wanted the clients to use the RPC to get the latest version of that data structure every few seconds.

If the server broadcasts its updated data structure whenever someone leaves or joins, I think the opcodes that you mentioned is quite useful. The only thing that I don’t know, is whether it’s possible to broadcast match state messages to presences from inside of match_leave or match_join methods directly, like using some nakama runtime method.