AddNotifyLobbyUpdate, AddNotifyMemberUpdateReceived triggers callbacks only on the local player that modifies the attribute.

[Ermelious]

Describe the bug
The following 2 function's callbacks only runs on the Local Client that modifies an attribute:
AddNotifyLobbyUpdate
AddNotifyMemberUpdateReceived

They do not seem to execute on other connect clients. It seems to be necessary to modify attributes on their end before they trigger the callback with the changes on top of the changes that the other client had made.

I've compared and checked out the UILobbiesMenu.cs Samples script.

Have called the above 2 functions in the Start function and have checked in the EOS lobbies dashboard (dev portal) that indeed each of the lobby member's attributes have been modified which means that my functions in the buttons are working as intended (the callbacks returns success on the local client that modifies the attributes).

I can't seem to identify why the callbacks are simply not executing on other clients?

Am I suppose to poll a method in the update loop? I've checked and it seems like the EOS Tick is running each frame as intended as well.

This is may or may not be a bug as the samples script seems to run fine. Can someone please advice on this?

To Reproduce
This is what's in my Start Function:

private async void Start()
{
        NetworkManager.Singleton.OnClientDisconnectCallback += (ulong id) => LeaveLobby();

        assets.mainPanel.SetStatus(true, true);
        await UnityServices.InitializeAsync();

        eOSLobbyManager = EOSManager.Instance.GetOrCreateManager<EOSLobbyManager>();
        eOSTransportManager = EOSManager.Instance.GetOrCreateManager<EOSTransportManager>();
        eOSUserInfoManager = EOSManager.Instance.GetOrCreateManager<EOSUserInfoManager>();

        eOSLobbyManager.AddNotifyLobbyUpdate(ListPlayers);
        eOSLobbyManager.AddNotifyMemberUpdateReceived((string LobbyId, ProductUserId MemberId) => { Debug.Log("A member: " + MemberId.ToString() + " was updated."); ListPlayers(); });
}

And this is what's registered as the callback.

private void ListPlayers()
{
        foreach (PlayerSelectable playerSelectable in assets.currentLobbyPanel.playerSelectableParent.GetComponentsInChildren<PlayerSelectable>())
            assets.currentLobbyPanel.playerSelectablePool.Release(playerSelectable); //.gameObject.SetActive(false);

        Debug.Log("@@@@@@@@@@ current lobby: " + eOSLobbyManager.GetCurrentLobby() + " | " + eOSLobbyManager.GetCurrentLobby().Members.Count);

        bool isReadyToStartMatch = true;
        if (eOSLobbyManager.GetCurrentLobby() != null)
            foreach (LobbyMember lobbyMember in eOSLobbyManager.GetCurrentLobby().Members)
            {
                PlayerSelectable playerSelectable = assets.currentLobbyPanel.playerSelectablePool.Get().GetComponent<PlayerSelectable>();
                playerSelectable.transform.SetParent(assets.currentLobbyPanel.playerSelectableParent);
                playerSelectable.transform.localScale = Vector3.one;
                foreach (KeyValuePair<string, LobbyAttribute> attrib in lobbyMember.MemberAttributes)
                    Debug.Log("Attrib: " + attrib.Key + " | " + attrib.Value.ValueType + " | " + attrib.Value.AsString);
                Debug.Log("Member Attributes Count: " + lobbyMember.MemberAttributes.Count);
                bool isReady = (lobbyMember.MemberAttributes[GlobalLobbyConstants.KEY_USERSTATUS].AsString == PlayerStatus.Ready.ToString()) ? true : false;
                playerSelectable.UpdateSelectable(lobbyMember.MemberAttributes[GlobalLobbyConstants.PLAYER_NAME].AsString, isReady);
                if (!isReady)
                      isReadyToStartMatch = false;
            }
        if (eOSLobbyManager.GetCurrentLobby().Members.Count > 1)
            if (eOSLobbyManager.GetCurrentLobby().IsOwner(EOSManager.Instance.GetProductUserId()))
                assets.currentLobbyPanel.startMatchButton.gameObject.SetActive(isReadyToStartMatch);
    }

Expected behavior
I expect the registered callback function ListPlayers to trigger whenever a Lobby Member updates his member attributes or when the host player updates the lobby attribute. Currently only the player modifying the attribute will trigger the callback, all other players will receive nothing on their side.

Screenshots
This is one of the issues happening because of this issue, whenever another player joins the lobby, my LobbyManager receives the new player but doesn't trigger the callback ListPlayers until the player modifies an attribute would the ListPlayers trigger. The same goes for the Ready Button. If Player A clicks on Ready button, a green tick shows up while on Player B's screen no green tick shows up on Player A's name until Player B clicks Ready, in which case there will be 2 green ticks, one on Player A and one on Player B in Player B's screen. Player A's screen will show only 1 tick on Player A's name while on Player B's name it will not display any Tick.

Desktop (please complete the following information):

• OS: Windows 11
• Editor, or standalone build: It's happening in both Editor and Standalone Build.
• Unity Version: 2022
• Plugin Version: 3.1.2

Smartphone (please complete the following information):

• Device: S23 Ultra
• OS: [e.g. iOS8.1] Android

Additional context
I've posted in the Discussions but have received no reply over weeks, hence posting it here as an issue to see if I can get any advice or if I'm suppose to post it here instead.

[skeyll]

@Ermelious

These notifies need options and specific args.

      void Start (){
           var options = new AddNotifyLobbyMemberUpdateReceivedOptions();
          //get interface from EOSManager 
          lobbyInterface.AddNotifyLobbyMemberUpdateReceived(ref options, null, OnLobbyMemberUpdate);
       }
       void OnLobbyMemberUpdate(ref LobbyMemberUpdateReceivedCallbackInfo info){
                //Update UI 
       } 

[Ermelious]

@skeyll thanks but did you mistake for another function because I'm using:
AddNotifyLobbyUpdate
AddNotifyMemberUpdateReceived

and not:
AddNotifyLobbyMemberUpdateReceived

The above 2 functions are in EOSLobbyManager.cs. Am I not recommended to use EOSLobbyManager.cs?, because the 2 functions seems to be used by Playeveryware's sample LobbyManager (UILobbiesMenu.cs) script as well.

[skeyll]

@Ermelious
Sorry! I thought you were calling the API directly. These notifications need to be registered with EOS by passing options, etc.

In EOSLobbyManager, this is done in SubscribeToLobbyUpdates at line 552, and this function is called in OnLoggedIn at line 902. Does your project call OnLoggedIn?

Maybe the current callbacks are being invoked from the Modify function's arguments, not from the notifications.

[paulhazen]

Additional context I've posted in the Discussions but have received no reply over weeks, hence posting it here as an issue to see if I can get any advice or if I'm suppose to post it here instead.

Apologies for this - it is something that the team and I have not been properly attentive to. We need to change the way we pay attention to the discussions section. Thank you for bringing it up and confirming for us that it's something we need to make an adjustment around, and I regret the oversight on our part.

@WispyMouse or another member of the team will follow up with you on the specific details of this issue early next week. Currently, we are focusing our efforts on the release coming out early next week. Regardless, I didn't want to wait to acknowledge our lack of responsiveness in the discussions section.

[Ermelious]

Additional context I've posted in the Discussions but have received no reply over weeks, hence posting it here as an issue to see if I can get any advice or if I'm suppose to post it here instead.

Apologies for this - it is something that the team and I have not been properly attentive to. We need to change the way we pay attention to the discussions section. Thank you for bringing it up and confirming for us that it's something we need to make an adjustment around, and I regret the oversight on our part.

@WispyMouse or another member of the team will follow up with you on the specific details of this issue early next week. Currently, we are focusing our efforts on the release coming out early next week. Regardless, I didn't want to wait to acknowledge our lack of responsiveness in the discussions section.

Thank you @paulhazen , appreciate the playeveryware team for this plugin.

@Ermelious Sorry! I thought you were calling the API directly. These notifications need to be registered with EOS by passing options, etc.

In EOSLobbyManager, this is done in SubscribeToLobbyUpdates at line 552, and this function is called in OnLoggedIn at line 902. Does your project call OnLoggedIn?

Maybe the current callbacks are being invoked from the Modify function's arguments, not from the notifications.

@skeyll thanks for the assistance I've looked into it and indeed I've not handled the similar functions in the OnLoggedIn function in my own LobbyManager.cs script. But now I'm getting another error, some issues with lobby member attribute.

Getting the following error now after including the functions in OnLoggedIn:
eOSLobbyManager.SubscribeToLobbyInvites();
eOSLobbyManager.SubscribeToLobbyUpdates();

KeyNotFoundException: The given key 'USERSTATUS' was not present in the dictionary.
System.Collections.Generic.Dictionary`2[TKey,TValue].get_Item (TKey key) (at <b11ba2a8fbf24f219f7cc98532a11304>:0)
LobbyManager.ListPlayers () (at Assets/Scripts/UI/LobbyManager.cs:645)
PlayEveryWare.EpicOnlineServices.Samples.EOSLobbyManager.OnLobbyUpdated (System.String lobbyId, PlayEveryWare.EpicOnlineServices.Samples.EOSLobbyManager+OnLobbyCallback LobbyUpdateCompleted) (at Assets/Samples/Epic Online Services Plugin for Unity/3.0.3/Standard Pack _ EOS Plugin for Unity Samples/Scripts/EOSLobbyManager.cs:1355)

This happens only for the host, when another player attempts to connect to the host. The connecting player's screen displays his username just fine but on the host, both "DISPLAYNAME" and "USERSTATUS" lobby member attributes of the connecting player is not found. It seems as though the AddNotifyLobbyUpdate and AddNotifyMemberUpdateReceived caallbacks are being execute too early, before the attribute is updated sucessfully. I'm wondering what is the proper way of doing this instead of using a coroutine to wait till the attribute has been added/updated on the host side.

Is this the reason why on the Samples UILobbiesMenu.cs script this similar handling of members in the lobby UI was implemented in the Update loop instead of by the callbacks? (Because of this delay that causes member attributes to be not found on the host as the attribute hasn't reach the host yet?) Is there no way to handle it by the callbacks?

[Ermelious]

Just to update on this, I've managed to resolve the issue after realizing that since AddNotifyMemberUpdateReceived callback calls everytime it receives an update, it was triggered twice when a client connects, the first was when it received my "USERSTATUS" member attribute and the second was when it received "DISPLAYNAME". Can confirm that both the host player and client are triggering the MemberAttribute update callbacks now.

I'm beginning to understand how the AddNotifyMemberUpdateReceived assigned callback is executed.

Thanks again to @skeyll for the assistance in my initial issue, I've basically added the following 2 functions from the OnLoggedIn function into my own LobbyManager script (right before the lobby is created):

        eOSLobbyManager.SubscribeToLobbyInvites();
        eOSLobbyManager.SubscribeToLobbyUpdates();

I will see if I should use OnLoggedIn instead of using the above 2 functions directly since I'm using EOSLobbyManager as well.

To conclude, there seems to be a possibility to depend solely on callbacks from AddNotifyMemberUpdateReceived and AddNotifyLobbyUpdate to handle the update of UI in an active Lobby (instead of counting whether the lobby member count has changed in the update loop though that is another option as seen in the sample UILobbiesMenu.cs script screenshot circled in red in my previous post above).

I'm not sure if the playeveryware team recommends using the samples in projects or to only use them as a reference and to create all components (including the managers) from scratch instead. But initial impressions are that I should create my own LobbyManager script to handle the User Interface while depending on the various "Managers" to handle communication with EOS. (Correct me if I'm wrong)

[WispyMouse]

Ahoy @Ermelious!

I'm glad you were able to resolve this Issue. For now, this GitHub Issue is being moved over to a Discussion, to consider the feedback you've given.

The samples code, especially the Managers, are intended to be directly used in your projects. These are supposed to be easily either used as-is or copy and pasted from in to your own Manager code, or however else you want to handle plugin actions.

Our team is considering ways to improve the clarity of how to use the samples code. Your feedback is helpful for identifying points of confusion, and we'll think on how to improve the documentation in this space.