Ulysses
Ulysses Stuff => General Chat & Help and Support => Topic started by: danhaynes9 on November 22, 2016, 04:42:04 PM
-
This sub-forum is only for help or discussion regarding projects created by Team Ulysses. If you are requesting help, please search the forums FIRST to make sure your question has not already been answered. If you still need help, fill in the following information.
My ULib/ULX versions (run "ulx version" in console):
ULib Most recent
ULX Most recent
Game mode(s) I am having this problem on: darkrp
Lua errors shown in console, if any:
<insert errors here>
So basically whenever I get around 70+ players on my server the server lags a lot when people connect/disconnect. I downgrade to another version of ulx/ulib and it fixes the problem. It lags when even a couple people are on but it is really noticeable with over 50 players. I am also using the MySQL ucl.lua if that helps. Thanks!
-
Could be your server specs
-
Do you happen to have any autopromote-like addons? Having a users database over a certain size causes a lot of lag on player connect/disconnect, IIRC, so you should probably avoid autopromote addons.
-
No I do not use autopromote for that reason. I ensure you it is not the server specs because I run off a very good dedi.
-
No I do not use autopromote for that reason. I ensure you it is not the server specs because I run off a very good dedi.
I would still check the size of your users.txt and groups.txt files, just to make sure they're not abnormally huge.
Also, define "very good dedi[cated server]," because (iirc) Garry's Mod's multicore support is lackluster if existent.
There could also be some laggy operations running on PlayerConnect or PlayerInitialSpawn, etc. You might want to look into your addons and see what's hooking to those. Though that wouldn't explain lag with only a high amount of players.
-
How many users in users.txt?
And have you tried without SQL connections running.
I've no idea about your current SQL implimentation, but remember previous SQL=>lua libraries could not continue until the connection was made, info loaded, and parsed, before the next script code would function.
That was over 4 years ago though.
I've no idea if current SQL scripts will run concurrently.