Offline
1
2
3
4
5
2
3
4
5
player(id,"x") player(id,"y") player(id,"tilex") player(id,"tiley") player(id,"rot")
Forum
CS2D
Scripts Does player(id,"<name>") increase network traffic?
Does player(id,"<name>") increase network traffic?
10 replies
1 
DC:Thank you for the fast response.
It is because
movetilehook seemed unreliable because high ping clients usually trigger it more than once and it breaks some of the scripts I made.
So, I used ms100 hook instead to check and verify if players changed tile position.
My concern was that this might increase network traffic.
mozilla1: That's because of TPS. Your script had to interact with CS2D API too frequantly, so Lua script had to wait for the response from the API each time on hook event.. it's only single-threaded. Try considering some kind of caching/optimizing or ms100 as you mentioned. 
movetile works by comparing the player position with the previous position on movement. If the tile (tilex/tiley) changed then movetile is invoked. If now movement packages arrive out of order (which they can because they are sent in an unreliable and unsorted way - which is probably CS2D's biggest network design flag) movetile may be invoked multiple times depending on the order of the packages even though the player actually moved from tile a to tile b only once.@
Gaios: That explanation doesn't make sense to me. TPS = transactions per second? Didn't we just clarify that there are no extra network transactions going on? movetile itself also doesn't cause extra traffic. Furthermore all CS2D Lua calls are synchronous (because it is a single thread like you said correctly) which means that the results are always returned instantly without any waiting time. The only problems (which come to my mind) related to that could be that the scripts are too heavy for the server to keep up a healthy tick rate - which shouldn't cause trouble with movetile being called multiple times. Or that the hooks invoke Lua methods which cause traffic - which may cause network lag and could indeed lead to problems with movetile. DC: DC has written@user Gaios: That explanation doesn't make sense to me. TPS = transactions per second? Didn't we just clarify that there are no extra network transactions going on?
Gaios has writtenYour script had to interact with CS2D API too frequantly, so Lua script had to wait for the response from the API each time on hook event
addhookin CS2D scripting, the server registers a new event listener, in this case for the "movetile" event, which is triggered every time a player moves on the map. Additionally, within this function, as you mentioned, there are API queries like
player(id, "<type>")that fetch information about the player.
So, when a player moves even by just 1 pixel, the "movetile" hook is triggered. This hook is designed to perform a logical operation, and the server has to wait for a response from this event. Simultaneously, executing
player(id, "<type>")commands also involves fetching data from the server to the Lua script, causing the server or script to freeze until a response is received. Importantly, this process is synchronous, not asynchronous, meaning that one operation has to complete before the next one can start.
In summary, the combination of the "movetile" hook and the
player(id, "<type>")commands leads to a synchronous execution, causing potential freezes or delays in the server/script until the necessary data is retrieved. This can impact the performance, especially with frequent movements or API queries.
Ranu has written Gaios has writtenYour script had to interact with CS2D API too frequantly, so Lua script had to wait for the response from the API each time on hook event
I just wanted to mention that I'd appreciate it if we keep the conversation friendly and avoid unnecessary remarks. I find it offensive.
Ranu: Please stay friendly.
§3.1 - No posts which offend/provoke/insult (flame)@
Gaios: Some of the things you said are a bit misleading Quote
So, when a player moves even by just 1 pixel, the "movetile" hook is triggered.
It is only triggered when the player moves from one tile to another tile. In other words when tilex or tiley changed with the movement. All movements inbetween do (under normal circumstances) not trigger
movetile.This shouldn't be confused with
move which actually triggers on each movement. Quote
and the server has to wait for a response from this event
Technically true but it's important to note that this is not a network response. It happens instantly without causing extra traffic. There isn't any explicit waiting. But since it's single threaded the game only continues when all hooked Lua scripts have been executed.
Quote
Simultaneously, executing
player(id, "<type>")commands also involves fetching data from the server to the Lua script, causing the server or script to freeze until a response is received.
Again just to make that very clear: No network request/response going on here since Lua is running on the server. It's near-instant. But yes, it is synchronous and yes, if you run A LOT of Lua it can lead to noticable drops in FPS / tick rate. The delay caused by getting a few positions shouldn't even be measurable.
@
mozilla1: If your server has FPS / tick rate drops then the problems might be caused by too much Lua being executed. Otherwise they are most likely caused by CS2D's network protocol & bad client connections as I described earlier. Gaios: I'm aware of the nature of Lua code in CS2D, specially that it is synchronous and single threaded.
My question on this thread might be a little ambiguous since I asked how player data fetch commands works, and right now I'm concerned with performance and optimization on my server.
Thank for your response in this matter.
@
DC: Suppose the following:
A player walks into a certain position in map.
That position is cached in double array on my script like this.
1
2
3
4
5
6
2
3
4
5
6
function movetile( id, x, y ) if area[x][y] then -- Stuff wrapper_function(x, y) end end
I did some tests as localhost, and also using this software called clumsy to test in high ping environments (and of course on the live server too).
http://jagt.github.io/clumsy/
the
wrapper_function(x, y)is actually called twice or more in some occasions, and even more if I use
setpossomewhere in the wrapper function.
It consistently trigger more than once on players with 200+ latency.
So my "solution" is to track player position consistently and compare its position every time.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
for i = 1, 32 do
tilex[i] = 0
tiley[i] = 0
end
addhook("ms100","ms100")
function ms100()
for index, id in pairs(player(0,"tableliving")) do
local x, y = player(id,"tilex"), player(id,"tiley")
if tilex[id] ~= x or tiley[id] ~= y then
tilex[id] = x
tiley[id] = y
movetile(id, x, y)
end
end
end
It greatly reduces the issue, however movetile can still trigger more than once because server can still receive "past" positions since network packets are out of order.
That aside, as you can see, player data is fetched every 0.1 seconds.
This is why I'm concerned about network traffic.
mozilla1: Try that. This shouldn't make much server freezes. Also it has no performance reason to check if xor
ychanged to assign new values - especially if you don't use
movetilefunction.
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
for i = 1, 32 do
tilex[i] = 0
tiley[i] = 0
end
addhook('move', 'onMove')
function onMove(id, x, y)
tilex[id] = x
tiley[id] = y
end
How does the
movetilefunction look like? What do you want to achieve by the way?
mozilla1 has written1
2
3
4
5
6
2
3
4
5
6
function movetile( id, x, y ) if area[x][y] then -- Stuff wrapper_function(x, y) end end
mozilla1: What you're doing is basically what movetile does. Only that movetile checks each movement instead of only checking the position every 100 ms.As you already mentioned your implementation has the same problems as movetile: Out of order packages will still cause trouble. You reduce the likelyhood by reducing the rate in which you do the check (only 10 times per second vs on each movement) but you also reduce precision that way. Tiles could be skipped for instance.
I'm afraid there's no good/reliable way to fix this with Lua. It would have to be fixed in CS2D's network protocol.
You could remember the tiles which were visited recently and prevent that those tiles trigger your function again. But this would also lead to wrong results as people going back and forth wouldn't be registered properly. Depending on your needs this might be an improvement or make things worse...
@
Gaios: I don't see how this is helpful- your code doesn't do what
mozilla1's code does. It only caches x and y positions in tables-
move params contain the pixel position not the tile position. Storing its x/y params in variables called tilex and tiley is misleading/wrong- it probably causes more CPU load as multiple movements can happen every frame.
ms100 is only executed 10 times per second.Again: Getters like
player(id,"tilex")do NOT cause any network traffic and are relatively cheap on the CPU. There is no real difference between getting the position via
move and via player. A good rule of thumb is: If you can call Lua less frequently ( move is called more often than ms100 in most gameplay situations) then go that way.Caching x and y positions of players can make sense but only if you read these values many times per frame. Otherwise the caching process itself will cause more CPU load than simply calling
player a few times. 1