GET_EXTERNAL_KVP* natives for server API

hi
i’ve been using KVP natives quite a lot recently, especially for server-side scripts, and i’ve noticed that natives such as GET_EXTERNAL_KVP_STRING have only been implemented by this PR for the client API.
in my test server, i have a “core” resource that acts as a small database which uses the KVP natives set to save different kind of information tied to a R* license identifier, and i’d like to access this information from other resources (e.g. maybe a PvP-focused resource that wants to read a player’s kill/death ratio info saved by the “database” resource?) but that is currently not possible since GET_EXTERNAL_KVP* natives are not implemented for the server API.
i suppose i could also store information about a player using their statebag, but since it might be “sensible” data i’d rather not let the client(s) be aware of it (unless there’s a way to set player state from the server without it replicating to client(s) that i do not know of :stuck_out_tongue: .)
registering exports in the “core” resource that fetch said data and using them in another resource is also not possible, since (i suppose) the latter would not have access to the KVP data belonging to the resource that registered the export methods (i’ve tried this, by registering an export method in the “core” resource, written in C#, that fetches a KVP string and returns it; but the return value would always be null when calling this export from another resource, in this case, written in Lua.)
i could request and transfer said data from resource to resource using server->server events, but implementing GET_EXTERNAL_KVP* and by extension SET_EXTERNAL_KVP* natives for the server API would be much better, in my opinion.
would this request ever be considered or should i find another way to structure my resources?
thanks :slightly_smiling_face:

That seems like user error or a bug.

… there’s a ‘replicated’ flag, too.

Anyway, request makes sense, this is a lot of code duplication and it should perhaps be unified indeed.

alright, i will test this behaviour some more and submit a bug report if it does actually seem like a bug rather than user error :+1:

also, thanks… guess i should’ve read the statebag docs more carefully.

thanks for your quick response to this request, too :slightly_smiling_face: