Hi,
We’re currently working on getting dedicated servers running for our game and are having troubles with party system/presence propagation to the overlay. We’re using Unreal Engine 5.5 with OnlineSubsystemEOS.
Our goal is to have party functionality work similarly to P2P lobbies, particularly for invites and joining, but we’ve run into a few issues. Since dedicated servers cannot create lobbies, we’ve tried to use the party feature with sessions. However, this approach doesn’t seem to work most likely because we cannot enable presence during session creation on dedicated server. Despite researching the topic, I didn’t found a clear solution.
One idea that came to my mind is to create a lobby when the first player joins the dedicated server session. However, I’m unsure if this is the best approach. Would this be the recommended solution, or is there some other (maybe more straightforward) way to achieve our goal that we’re missing?
If there are any relevant articles or documentation that might help, I’d appreciate any references.
Thanks, Pawel
I’ve got another question regarding sessions on dedicated servers. What is a reliable way of checking player’s platform in the session?
Hey [mention removed] Any chance you might be able to offer some insight on this topic?
Hey, sorry for the really long delay. When joining the session, you can set bPresenceEnabled to true. That should show the session information in the overlay. Be sure to call RegisterPlayer() on the server and on clients to keep the local session state updated. If you haven’t seen this talk on sessions/lobbies, I would recommend watching it. It’s long, but it contains A TON of valuable info.
You can use EOS_Connect_CopyIdToken on the client, pass the token to the server, the server can verify the token with EOS_Connect_VerifyIdToken, and retrieve the platform and account information from the token. Note that console platforms will be listed, but PC and mobile may not be.
Hey, I’ve actually tried enabling bPresenceEnabled while joining to a session and verified that EOS_Sessions_RegisterPlayers was called on client side, but it didn’t produce any visible results on the overlay.
It’s worth mentioning that we relay most of our logic on CommonUser plugins from Lyra and it does set bUsesPresence to true in UCommonSessionSubsystem::JoinSessionInternalOSSv1.
We’ve actually did implement the solution I mentioned originally in the post - creating lobby for players in session to bypass this issue. Right know it seems to fit our needs, do you see any downsides of that implementation?
No issues with creating a lobby and session. That is a typical use case to have a lobby for members of the same team to join while hosting a match on a dedicated server using a session. That said, I think this is a bug / feature gap in OnlineSubsystemEOS. At the SDK level, bPresenceEnabled needs to be set to true in EOS_Sessions_JoinSessionOptions. That isn’t happening in FOnlineSessionEOS::JoinEOSSession. As a test I hardcoded the value to true, and sure enough the session info shows up in the overlay.
... FJoinSessionOptions Options(TCHAR_TO_UTF8(*Session->SessionName.ToString())); Options.LocalUserId = ProductUserId; Options.SessionHandle = EOSSessionInfo->SessionHandle->SessionDetailsHandle; Options.bPresenceEnabled = true; //Added as a test EOS_Sessions_JoinSession(EOSSubsystem->SessionsHandle, &Options, CallbackObj, CallbackObj->GetCallbackPtr());First screenshot here is without the hardcoded true value. Second is with the hardcoded value. Notice the second screenshot includes the session presence info.
[Image Removed]We will work on getting a fix in for this.
Thanks, it works like a charm.
It turned out that we had some changes in our version of engine that caused modifying the value of bPresenceEnabled not to produce the expected results. Fortunately, we were able to identify them and successfully fix the issue and now party is displaying properly without the need of using the lobbies 
I’ve got one more question though, regarding the process of sending a client’s IdToken to the server, we want to do it before client connects to a server, to disable cross play in some cases. Is using http requests during AGameModeBase::PreLoginAsync good way of implementing it or would it be better to do it differently?
Passing the IdToken via HTTP request in PreLoginAsync works. However, to disable crossplay, a better approach would be to use the AllowedPlatformIds option available in the SDK. See EOS_Sessions_CreateSessionModificationOptions. On the client, you could filter out session search results not to join sessions that don’t have the players platform in AllowedPlatformIds.
I originally thought about using the AllowedPlatformIds, but we want to have division between PS5, XSX, and all PC platforms.
And using AllowedPlatformIds we can only set console platforms and steam, so from my understanding we can’t create a lobby/session, that won’t allow consoles players, but will let all PC platforms join, unless I’m missing something.
You can, assuming your game is NOT available on mobile. I created a KB this morning to help make this information more visible: [Content removed]
Let us know if you have any follow-up questions!
That’s great! I thought that Epic’s platform would need EOS_OPT_Epic set, which is not supported. If that’s not the case, AllowedPlatformIds would definitely makes things simpler
Thank you for your help!