Hosting the Server on LAN

[brokeNdb]

Firstly, thank you for this.

My question would be if it's possible to host it on a server PC with open ports and possibly connect using that IP?

It's absolutely amazing and so far I haven't found anything to fault apart from wishing I could somehow help contribute to this project!

[p1xeless]

It would be great if we could set up a server so that friends can join us with the ports! Right now, my efforts to do this have been unsuccessful :(

[Evansch0]

It would be great if we could set up a server so that friends can join us with the ports! Right now, my efforts to do this have been unsuccessful :(

what did u do to test this

[Sol-Low]

The best we can do without making changes to the code is getting the server database to have multiple player's data on one instance. Sadly it does not exactly allow multiplayer since the code as written makes a new map instance for each player upon launching to/from any given map (station or Fortuna III)

To do this start by:

1.Run the MongoDB and ProspectServerAPI on your desired "Server"

2. On each player's local game client, add a file named "backend.txt" to the Win64 directory that contains just "https://:8443"

3. Create a certificate using the included generator with the "--common-name <Server's ipv4 address here>" option to create one for that server and provide that to your friends.

4. Allow access to that server on port 8443 by whatever means you need (port forwarding, VPN to a common LAN with the server, etc)

Hopefully that should cover the necessities and enjoy seeing more than one PlayFabEntity in your MongoDB once you get it working. Anyway I will now go back to suffering as I try to DIY the multiplayer.

[Frankystorms]

There is a fork of the single player that supposedly has multiplayer working. I messaged the guy (it's Owen) that made the fork and he said that it should work but he hasn't had anymore time to work on it.

I tried compiling his version of the code but I had a ton of errors and I know almost nothing about backend coding...

[brokeNdb]

Thanks for all the info, very helpful! Would be amazing if you could get the fork working. The best I could hope for would be to just have me and a couple of buddies drop in together even on Lan 👍

[Jakh33-2]

I've created a branch of (it's owen)'s repository, updated with the latest updates and compiled it. Seems to be working in singleplayer.

[FinnenHawke]

@Jakh33-2 I’ve tested your fork, and it seems to work well in Single Player mode. I was also able to successfully host a server on my VPS + have the MongoDB running online. My friends could connect without issues, and the database was correctly populated with unique entries for each user.

However, we’ve encountered several problems when trying to actually play together:

1. There doesn’t seem to be a way to invite players to a squad. The friend list doesn't work, and players don’t see each other at the station.
2. When one player initiates deployment, it triggers deployment for all connected clients, regardless of their current state or location.
3. Other players are automatically deployed to the same map without any prompt.
4. Despite all players deploying at the same time and to the same map, each one ends up in a separate game session/instance - they can’t see each other in the world.
5. If one player extracts and queues up again, it forces all others still on the planet to redeploy, without warning, and they lose their current gear.

So while basic connectivity and database syncing seem to work, actual multiplayer gameplay is currently not functional due to session desync. I think the way Owen set it up with his latest commit ("squad-fix") is that the game sends a SignalR broadcast upon deployment to all clients connected to the server. Literally everyone gets that and starts deployment - regardless of where they are.

Maybe if we managed to actually join the squad, it would work, but I have no idea how to do that. Getting squads to work is probably a huge thing to fix, because the actual Friend List component would need to be implemented (unless there is another way to invite that I don't know of).

Another way to handle playing together would be to create a workaround without actually being in the squad:

1. Disable the global SignalR deployment broadcast - each player deploys manually without triggering deployment on other clients.
2. When a player chooses a map and starts deployment, the server checks if there's an active session for that map (e.g. another player is already playing it). If yes, the player is added to the existing session/instance and drops into the same world. If not, a new session/instance is created for that map.
3. The session remains active until the last player extracts or dies.
4. Once the last player leaves, the session is destroyed/expired, and a new deployment to that map starts a fresh session.

Unfortunately, I don’t currently know how to implement that session logic, and it seems the game may still fallback to offline mode or ignore the session ID in some cases.

[Ondario]

@FinnenHawke I fixed all of those issues in my fork except squads. I am still working on that but local LAN play was restored. It's very buggy but it works. https://github.com/Ondario/Prospect/tree/Feature/Steam-Local-LAN

[FinnenHawke]

@Ondario Oh, wow. From what I see, that was a monumental amount of work. I've compiled your repo locally, used your loader and booted your server API locally. I deployed solo for the test, but for some reason I could not move after deploying (I could open the inventory, but I couldn't shoot or move). I probably made some mistake somewhere. I will definitely test it more!

BTW, if you're still working on the squads, then how does LAN play actually work here? Does it automatically deploy everyone in the same instance when one person starts deploying? What's the logic so far?

[Ondario]

@FinnenHawke So I modified the matchmaking and the server sessionstate handling to detect who is hosting the API server and to make that client act as the "server". The other clients instead of running the normal matchmaking and launching into their own session, Instead they attempt to connect to the ip of the "server" client. That gets you into the same session, but like i said there are so many bugs from doing this it really isnt worth doing. I'm trying to see if I can deal with these bugs but its slow going,

[FinnenHawke]

@Ondario I skimmed through your code and yes, I found that logic and made sure that I am specified as the host - still, after many tries, while I connected to the map each time, for some reason I couldn't even move, so indeed, it seems very buggy.

That said, I assume this LAN/CO-OP approach would come with a typical limitation: if the host closes the session, everyone else gets kicked. Which is obviously expected — but in the context of an extraction shooter, that makes the experience potentially frustrating because:

1. If the host extracts first, the entire session closes, so other players die and lose their gear?
2. If the host dies first, they're sent back to the station automatically, which also ends the session and causes everyone else to die/lose gear?

It’s obviously not ideal, but still a viable way to play together. I think it's even the same with "that other unofficial multiplayer solution" for "that other popular extraction shooter". ;) I guess the only way to "fix" it would be some sort of API that triggers creation of a headless server on the player's machine concurrently to the game, so even if the host dies or extracts first, the session is still alive for other players inside. Easier said than done!

For online co-op potentially the API could be running on a VPS while the actual host for the game server would be a different IP - one of the players with open ports. I’ve been even thinking about implementing a more dynamic approach to matchmaking, so it’s not tied to a single predefined host. Something like this:

1. On deploy, the system checks whether there’s already an active session on the selected map.
2. If yes, the client connects to the host IP stored in that session in MongoDB.
3. If not, the client becomes the host and a new session is registered in MongoDB.

It might be enough to just have a single activeSessions collection that has an entry for each map and current IP that is hosting it. The game could look up the entry for the requested map and attempt to connect to the IP stored in MongoDB. If the host is responding, connect to it, otherwise become the host itself and update the IP in activeSessions for other players to join. That way, we avoid having a hardcoded host, and anyone can dynamically take on the hosting role unless someone else is already doing it for that map.

It's just an idea for the future, though. Right now, like you said, this is still not stable enough to think about improvements like that, considering how buggy the basic interactions are, but I am very much looking forward to seeing your future code. I appreciate the effort you're putting into this.

[Ondario]

The biggest problem is that the client was never intended to be a listen server and I assume this is what is breaking most of the logic. I need to construct an actual dedicated server.

[Ondario]

@FinnenHawke I forgot to add that you need to modify the LUA mods to force the end of the intro transition to allow movement. You can do this by heading to the game directory that contains the prospect.client.loader and browsing to the mods > prospect > scripts > and opening the main.lua file. You can uncomment the lines 68 - 86 to allow movement and some functionality.

[FinnenHawke]

@Ondario I see! That makes sense, I figured there was something about it. Thanks for mentioning that. I'll get back to it once I have a bit more time on my hands.