Open rafadsm opened 1 year ago
This project doesn't seem to have the funds to have someone maintain and update it. I keep an eye on it every day, and the initiator has been running out of food for several days.
@316902108 The Godot 4 support was completed about 4 weeks ago but is on master branch rather than a release right now. If you encounter bugs you're welcome to submit a pull request which we'd be happy to review, merge, and provide attribution on. 👍
Hm. Unfortunately, I don't think NakamaMultiplayerBridge
will currently work with an authoritative match.
NakamaMultiplayerBridge.join_match()
is assuming that there is a host already connected to the match, which is responsible for allocating the peer ids. Normally, one player's client would call NakamaMultiplayerBridge.create_match()
which would make them the host, or if the match is created via NakamaMultiplayerBridge.start_matchmaking()
the host is selected automatically.
For authoritative matches to work, there would be a few pre-requistes:
NakamaMultiplayerBridge
depends on the messages being relayed, so your match handler code would need to be setup to relay those messagesNakamaMultiplayerBridge
, like, NakamaMultiplayerBridge.join_as_host()
for one player to join as the host, or maybe NakamaMultiplayerBridge.join_authoritative()
and have it automatically pick a host similar to how it works with the matchmaker? For the latter, there could maybe be code in the match handler that is responsible for selecting the host?In any case, I'm not sure what the advantage would be to using an authoritative match with NakamaMultiplayerBridge
anyway?
NakamaMultiplayerBridge
is simply using Nakama to relay the messages between the peers. These messages are binary data specific to how Godot sends RPCs - Nakama can't really process them in any way. If you really wanted Nakama to be truly authoritative over the match, you'd be better off not using NakamaMultiplayerBridge
at all, and instead send custom messages using the normal Nakama API.
In any case, I'm not sure what the advantage would be to using an authoritative match with
NakamaMultiplayerBridge
anyway?
I've been looking into doing this so that I can have an authoritative match so I can use labels make a lobby with functionality like private matches, region info, etc that could be filtered on the client following this guide https://heroiclabs.com/docs/nakama/guides/concepts/lobby/
My plan was to do the lobby and just relay everything else in MatchLoop which is pretty simple, just look for specific opCodes related to the lobby and relay everything else. This mostly works fine by just running the RPC, joining the lobby and calling nakama_bridge._setup_host() except there's a ton of spam errors despite the MultiplayerSyncronizer working fine.
Took me a while to realize what was going on but there's a pretty big issue that makes this really difficult to solve. The nakama bridge relies on being able to send to specific presences, but the MatchLoop isn't passed the target presences so there's no way to know where those messages where meant to go in an authoritative server without encoding the presences into your payload and parsing it on the server.
Im using
Godot 4.0.1 stable
with addon from branch 4.0 Im trying to useHigh-level Multiplayer API
with Nakama server match I did a .lua indata/modules
to create a match, some part of lua contents:in godot after login and socket is connected, i did like in README.md https://github.com/heroiclabs/nakama-godot/blob/master/README.md?plain=1#L172
but the events is never triggered and my
get_tree().get_multiplayer().get_unique_id()
always is0
In console (server side), im in the match and the match is running, when i connect second client, still not working or no feedback, rpc's not working too and console shows has 2 clients in the match When i usemultiplayer_bridge.create_match()
, works perfectly but the match is not Nakama Authoritative and my client is the hostIs there any way to make it work with Nakama Authoritative?