Jump to content
  • 0

Multiplayer Lagging on LAN


globojim

Question

13 answers to this question

Recommended Posts

  • 0

If you don't want to deal with source side alts, a suggestion from Steve over in the discord crew: Try tossing

$Platform::backgroundSleepTime = 0;//don't let it sleep

in your:
(in the case of 3.x builds) core/scripts/client/defaults.cs
or
(for 4.x builds) /game/data/defaults.tscript

Link to comment
Share on other sites

  • 0

I am doing a localhost multiplayer test with a host and a client. 

For some reason, most versions prior to 3.10 have a high ping rate around 180.

With 3.10 particularly 3.10.1 hotfix, it is just 0 or lower than 20.

I don't see any major changes in the release notes about networking other than this:

Quote

Fixed a typo where the value of outBytesWritten was being clamped incorrectly

and I'm using pre-built binaries from github, so not sure and could be how I just build my torque project.

I would like to know if there is a major improvement in networking with 3.10 or 3.10.1 in particular.

Edit: I also read somewhere that IPv6 support was a recent addition so could just be this thing.

 

 

Edited by globojim
Link to comment
Share on other sites

  • 0

So just to be sure I'm following the configuration:

You're using a version before 3.10 and you have one machine that is hosting the game AND connected to it, and then a second machine connected to the first as a client. And even though they're on a LAN connection, you're seeing 180ms ping.

That about right for the reproduction steps?

If so, I'll see if I can reproduce the circumstances on my LAN and see where that takes me.

Link to comment
Share on other sites

  • 0

Hello @JeffR

It's actually on 1 machine to test both server and client. I'm running the executable twice where one instance is checked as host and the other client with Join. I have yet to try an actual remote server and client and don't have any clue on the ping rate so I would assume they would be the same.

Recently and so far I also found out that I also get high ping rate again when building 3.10.1 from source with the default generateAllProjects.bat.

With that now I'm curious on how the T3D 3.10.1 window binaries were built, as this is the one where the ping rate seems to be accurate or in place as far as I know.

 

 

Link to comment
Share on other sites

  • 0

Ah, if it's on one machine then that probably explains it.

There's logic in the 3.10 and earlier versions where if the window is unfocused, then it utilizes less CPU time. You can see this in action if you have the game window unselected, and have the metrics(fps) command so you can see the framerate. It'll normally run at whatever FPS when focused, then go down to 5 or 10 fps when unfocused. It's to keep the CPU draw low if you're not 'actively playing' but this means it impacts the packet processing as well, so it expresses as high latency. If you try with two machines I'd expect to not see that happen.

Link to comment
Share on other sites

  • 0

Thanks @JeffR I see and did a few more test with my 3.10.1 build.

What I find a bit odd is that with the GitHub specific 3.10.1 Windows binary release is if you switch to joining the client while the host is running, the ping rate is 0 or lower, but if you join the client after the server is loaded and ready, it also has the same effect like other 3.10.1 builds or prior versions with a high ping rate. So I'm curious on how it got build that way.

Is there a way to toggle or disable this so you can test networked objects or scripts visually in real time with one machine?

 

@Duion Yes and I think you are talking about  priority which is under Task Manger Details tab, but apparently it does not work even if you set it to real time.

 

Edited by globojim
Link to comment
Share on other sites

  • 0

https://github.com/TorqueGameEngines/Torque3D/blob/6605ddc66ab6cffb5df7c82db6fa06e19895bcdc/Engine/source/app/mainLoop.cpp#L626

https://github.com/TorqueGameEngines/Torque3D/blob/6605ddc66ab6cffb5df7c82db6fa06e19895bcdc/Engine/source/platform/platformTimer.cpp#L35

So by default it'll call setBackground to set the app 'in the background' and that causes a a time delay between updates, which is where the slowdown is coming from. So you can change it so it doesn't go in the background and that should resolve the behavior for your testing purposes.

Link to comment
Share on other sites

  • 0

Thanks @JeffR I did notice now the console messages on those parts like: "Window focus status changed: focus:" and  "  Using background sleep time: " when it was lagging.. will try this asap.

So do I just force and set mBackground to always false in platformTimer.cpp?

 

Edited by globojim
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...