Closed momintlh closed 4 months ago
The issue where callback was getting overridden is fixed, so now each RPC event can call its own callback, but when the same event has different callbacks, only the latest one gets invoked. Current solution I have is to change the Dictionary<string, Action>
to Dictionary<string, List<Action>>
, so each event can hold multiple callbacks, But I might be Overengineering this part, so any suggestions would be helpful. @SaadBazaz @asadm.
Changes are in this commit: c60dc8d
The issue where callback was getting overridden is fixed, so now each RPC event can call its own callback, but when the same event has different callbacks, only the latest one gets invoked. Current solution I have is to change the
Dictionary<string, Action>
toDictionary<string, List<Action>>
, so each event can hold multiple callbacks, But I might be Overengineering this part, so any suggestions would be helpful. @SaadBazaz @asadm.Changes are in this commit: c60dc8d
I think your approach is fine. Do you have any other solutions in mind?
RpcRegister: function (name) {
if (!window.Playroom) {
console.error("Playroom library is not loaded. Please make sure to call InsertCoin first.");
return;
}
function registerCallback(data, sender) {
//TODO: callback from unity here? dynCall('vi', callback, [data, sender])
console.log(`${sender.id} played their turn!`);
console.log(`recieving: ${data}`);
return 'okay!';
}
// Register the callback for the RPC
Playroom.RPC.register(UTF8ToString(name), registerCallback);
},
I believe the (data, sender) should be accessible from with unity, right? for that I can have a dynCall() within registerCallback and pass the data, sender as arguments, to do something after the rpcCall has invoked its callback. (will need to serialize both data and sender before passing as well.)
^ is this the correct architecture here? @SaadBazaz
RpcRegister: function (name) { if (!window.Playroom) { console.error("Playroom library is not loaded. Please make sure to call InsertCoin first."); return; } function registerCallback(data, sender) { //TODO: callback from unity here? dynCall('vi', callback, [data, sender]) console.log(`${sender.id} played their turn!`); console.log(`recieving: ${data}`); return 'okay!'; } // Register the callback for the RPC Playroom.RPC.register(UTF8ToString(name), registerCallback); },
I believe the (data, sender) should be accessible from with unity, right? for that I can have a dynCall() within registerCallback and pass the data, sender as arguments, to do something after the rpcCall has invoked its callback. (will need to serialize both data and sender before passing as well.)
^ is this the correct architecture here? @SaadBazaz
Looks about right, what if we need multiple? 😬 Does the PlayroomKit JS support multiple callbacks?
multiple callbacks for one rpc? yes.
DEMO game: https://mmntlh.itch.io/playroom-demo
Score (UI) is updated using RPC now. I tried using rpc for syncing movement (instead of using get/set state) but it was super laggy.
Changes:
Next Tasks:
Testing:
Verified the changes by testing RPC registrations and calls with different modes from both C# and JavaScript. Checked the sequence of ENUM values and ensured correct callback invocations.
Test Results:
Host registers and gets the following response:
Nonhost player calls:
based on #37
Final demo output: https://mmntlh.itch.io/playroom-demo