#Megacity Metro ThinClients in Headless mode
1 messages · Page 1 of 1 (latest)
But it seems like besides in !headless mode, the ThinClients don't have a visual representation and do not move.
Hey Felixx, can you clarify what you mean by this? IIRC if not in headless mode, there should be some IMGUI showing thin client worlds, and whether or not they're connected. They'll 'follow the leader' i.e. connect to any worlds your rendering client is connected to (via in-game UI).
So when in headless mode the ThinClients seem to be invisible for other clients. When not in headless mode everything works without problems.
Ah okay; can you elaborate on "invisible"? I.e. In headless mode:
- Are you certain they're successfully connecting to the server? What confirmation do you get for that?
- If they are connecting, maybe they're not correctly sending some RPC to trigger spawn?
Apologies: I don't have time to diagnose this in the near future.
the red circles around them are shown, but the spaceships are not rendered. They don't lose health if they are shot.
- Only the first "New connection ID:xx" ist shown in console, but not the "Client: xxxx() has joined the game! (Thin = True)". So I assume there is something broken.
- could be possible.
What I am trying to do is to create a headless player with no main world but only thin client worlds. They should be able to connect to my own specified server. From the code of the megacity metro project I assume most of this should have worked at one point. (but some of the code was commented out)
And also the server crashes whenever 70+ players try to connect in the same frame, which is unfortunate.
The game is also not playable whenever more than 60 clients are connected and the player is looking at them. (Tested with 64gb ram, geforce 3050, i7)
Even though the quality is set to low, the npc car traffic is disabled and the textures are set to 1/8 size
Use the profiler to find the bottleneck. The Megacity DGS is relatively lightweight, but thin clients have overhead, particularly in the editor with burst off and debug on.
Check UTP transport sendqueue and receivequeue sizes, sounds like that issue.
But I'd be surprised if Megacity sample didn't commit using larger values.
The other clients and the server were running on a different device.
From the profiler it seemed like the rendering played a big role