to summarize, I would say I’m making a coop game, where players can join friends on their saves.
the way I’m handling accounts atm is merely cosmetic, since I want to develop it as agnostic to EOS or SteamOS as possible; When the game starts for the fist time it makes a SG_SavedConfigs.sav (now it handles the “accounts”, but later will be only be used to store options related data).
Players make the accounts and when they are logged in, they can create a new game, load a previous one or join sessions with another players through specific menus…
When a new game is created a new session is created along with it’s own SG_ServerData.sav, when loaded, it takes the data from the server’s specific SG_ServerData.sav (the file name is managed through an array inside SG_SavedConfigs.sav).
When players select which session to join, they are placed in these sessions as clients. Since I only have my pc to work on it, I’m only testing in PIE as standalone and there is where the problem begins, whenever the PIE who JOINS the session tries to send a Run on Server request, to get their “characters data”, they end up seeing themselves as the host (Local controlled, With authority), not the client, the Run on Server is then checking the client’s game info about the SG_ServerData.sav which is loaded on host’s PIE and returns nothing as a result, even both “accounts” having characters created in the same .sav.
if I change to listen server, only PIE1 can host, but both can see their characters on character selection screen.
Seeing yourself as “Local controlled, Has Authority” on the joining instance means that instance never actually connected, it is just another standalone game running its own world. Opening a “join” menu doesn’t change that by itself, so the Run on Server event executes locally and reads the local .sav.
Things to check:
Print the Net Mode (or call Get Net Mode) on BeginPlay in the joining instance. If it says Standalone, the join failed. With the Null subsystem, Find Sessions only works with Use LAN enabled on both Create Session and Find Sessions, and the host must have opened the map with the listen option (Open Level with Options = “listen”).
For quick testing, skip the menus: Editor Preferences > Play, Net Mode = Play As Listen Server, Number of Players = 2 (or Play As Client). That gives you real server/client roles in one click. Standalone PIE is only good for testing the full session flow.
Design-wise, keep save data server-side. The client should call a Run on Server RPC from an owned actor (its PlayerController or PlayerState) with only the account ID, and the server (GameMode) loads SG_ServerData and sends the result back via a Client RPC or a replicated variable. A client should never read the host’s .sav itself, because it won’t have that file on a real remote machine.
Both instances on one PC share the same Saved/SaveGames folder, so name the files per instance while testing.
There was something I was overlooking and thanks to your comment I noticed it, after creating a session, my “Server” PIE wasn’t reloading the map, so even if it was set as a server, objectively it wasn’t one.
my solution was to validate with game instance if there was an active session (self made bool) and if so, to reload all the ServerData to the GameMode prior to giving access to the character selection screen. Thank you very much.