Changing DataTables often, does it make the server lag? - Developers

I'm wondering, because DT vars are already included in Entities, if I were to change a DT var every 3-4 seconds would it make the server lag a lot? I mean, normal entities already exchange lots of information with the like their position and stuff and it doesn't lag (except when abused).

I believe changing a DT var is the same as changing the base properties of an entity; things like it's color, material, weight.

[QUOTE=Crazy Quebec;18792403]I believe changing a DT var is the same as changing the base properties of an entity; things like it's color, material, weight.[/QUOTE] Do you think it's the same as changing it's health?

Yes. Exactly the same. DTVars are simply elements of the entities' datatables that Garry added and that are networked. They work just as any base networked values of entities like color, health and what not.

[QUOTE=Crazy Quebec;18792660]Yes. Exactly the same. DTVars are simply elements of the entities' datatables that Garry added and that are networked. They work just as any base networked values of entities like color, health and what not.[/QUOTE] So techinacaly if I don't abuse them (changing them every Think) I should be alright with tons of them.

You can't really make tons of datatable variables, only 4 of the one data type, and there are 6 different data types you can choose from (int, float, vector, angle, ehandle, bool)

[QUOTE=Delremos;18796335]You can't really make tons of datatable variables, only 4 of the one data type, and there are 6 different data types you can choose from (int, float, vector, angle, ehandle, bool)[/QUOTE] 4 x 6 per entities, it's perfect for my needs.

No, unlike garry's NWVars system that uses usermessages (I believe), datatable vars are an optimized part of the source engine. Datatable vars can be changed at any time and still manage to be pretty efficient. Serverside on Tick, the game checks the current value of the DT var against the value of that var at the last tick. If there is a change detected, the variable is sent to the client. Additionally, the var won't be sent at all if the associated entity isn't visible (determined via the player's node's PVS) to that player. When the entity does become visible, then the DT vars are sent to that player. I'm not sure if all the DTVars are sent or just the ones that have changed since it disappeared from the player's view. You should take a look at the HL2 Pistol's code in the SDK sometime. They actually have a variable used to calculate the pistol's bullet spread that is updated around 15 times after a single shot is fired. Itemforge uses Usermessages as well, but instead of sending the variable ASAP I try and simulate the source engine's networking and send on tick. Here's what itemforge is outputting for the pistol: [code] OUT: Set Float (PrimaryNextAuto) to 107.3450012207 - Item: 1 - Player: theJ89 OUT: Set Float (LastAttack) to 106.8450012207 - Item: 1 - Player: theJ89 OUT: Set Float (Penalty) to 0.2 - Item: 1 - Player: theJ89 OUT: Set Float (SecondaryNextAuto) to 107.3450012207 - Item: 1 - Player: theJ89 OUT: Set Float (SecondaryNext) to 106.9450012207 - Item: 1 - Player: theJ89 OUT: Set Float (LastPrimaryDelay) to 0.099999999999994 - Item: 1 - Player: theJ89 OUT: Set Float (PrimaryNext) to 106.9450012207 - Item: 1 - Player: theJ89 OUT: Set Char (Amount) to 17 - Item: 3 - Player: theJ89 IN: Set Float (PrimaryNextAuto) to 107.3450012207 - Item: 1 IN: Set Float (LastAttack) to 106.8450012207 - Item: 1 IN: Set Float (Penalty) to 0.20000000298023 - Item: 1 IN: Set Float (SecondaryNextAuto) to 107.3450012207 - Item: 1 IN: Set Float (SecondaryNext) to 106.94499969482 - Item: 1 IN: Set Float (LastPrimaryDelay) to 0.10000000149012 - Item: 1 IN: Set Float (PrimaryNext) to 106.94499969482 - Item: 1 IN: Set Char (Amount) to 17 - Item: 3 OUT: Set Float (Penalty) to 0.18500000033528 - Item: 1 - Player: theJ89 IN: Set Float (Penalty) to 0.18500000238419 - Item: 1 OUT: Set Float (Penalty) to 0.17000000067055 - Item: 1 - Player: theJ89 OUT: Set Float (Penalty) to 0.15500000100583 - Item: 1 - Player: theJ89 IN: Set Float (Penalty) to 0.17000000178814 - Item: 1 IN: Set Float (Penalty) to 0.15500000119209 - Item: 1 OUT: Set Float (Penalty) to 0.1400000013411 - Item: 1 - Player: theJ89 OUT: Set Float (Penalty) to 0.12500000167638 - Item: 1 - Player: theJ89 IN: Set Float (Penalty) to 0.14000000059605 - Item: 1 IN: Set Float (Penalty) to 0.125 - Item: 1 OUT: Set Float (Penalty) to 0.11000000201166 - Item: 1 - Player: theJ89 OUT: Set Float (Penalty) to 0.095000002346933 - Item: 1 - Player: theJ89 OUT: Set Float (Penalty) to 0.080000002682209 - Item: 1 - Player: theJ89 IN: Set Float (Penalty) to 0.10999999940395 - Item: 1 IN: Set Float (Penalty) to 0.094999998807907 - Item: 1 IN: Set Float (Penalty) to 0.080000005662441 - Item: 1 OUT: Set Float (Penalty) to 0.065000003017485 - Item: 1 - Player: theJ89 OUT: Set Float (Penalty) to 0.050000003352761 - Item: 1 - Player: theJ89 IN: Set Float (Penalty) to 0.065000005066395 - Item: 1 IN: Set Float (Penalty) to 0.050000004470348 - Item: 1 OUT: Set Float (Penalty) to 0.035000003688037 - Item: 1 - Player: theJ89 OUT: Set Float (Penalty) to 0.020000004023314 - Item: 1 - Player: theJ89 IN: Set Float (Penalty) to 0.035000003874302 - Item: 1 IN: Set Float (Penalty) to 0.020000003278255 - Item: 1 OUT: Set Float (Penalty) to 0.0050000043585897 - Item: 1 - Player: theJ89 OUT: Set Float (Penalty) to 0 - Item: 1 - Player: theJ89 IN: Set Float (Penalty) to 0.0050000045448542 - Item: 1 IN: Set Float (Penalty) to 0 - Item: 1 [/code] The network can handle a lot of data, but don't take this for granted. Whenever possible try to optimize the networking (and really other things too like drawing routines and entity thinks) - you never know who's going to be using your creation, how fast their computers are, or how good their connection is. Additionally, if you leave plenty of bandwidth available then you've got plenty of room for anything else you might want to do (or in other words, your project will [i]scale[/i] well). Also, you don't know how much bandwidth other addons on their server are taking up, so best to make yours work with as little data as possible - after all, the animal that eats the most food is the first to die in a famine, right? You want yours to keep working well even if the others aren't.

[QUOTE=theJ89;18800266]No, unlike garry's NWVars system that uses usermessages (I believe), datatable vars are an optimized part of the source engine. Datatable vars can be changed at any time and still manage to be pretty efficient. Serverside on Tick, the game checks the current value of the DT var against the value of that var at the last tick. If there is a change detected, the variable is sent to the client. Additionally, the var won't be sent at all if the associated entity isn't visible (determined via the player's node's PVS) to that player. When the entity does become visible, then the DT vars are sent to that player. I'm not sure if all the DTVars are sent or just the ones that have changed since it disappeared from the player's view. You should take a look at the HL2 Pistol's code in the SDK sometime. They actually have a variable used to calculate the pistol's bullet spread that is updated around 15 times after a single shot is fired. Itemforge uses Usermessages as well, but instead of sending the variable ASAP I try and simulate the source engine's networking and send on tick. Here's what itemforge is outputting for the pistol: [code] code here [/code] The network can handle a lot of data, but don't take this for granted. Whenever possible try to optimize the networking (and really other things too like drawing routines and entity thinks) - you never know who's going to be using your creation, how fast their computers are, or how good their connection is. Additionally, if you leave plenty of bandwidth available then you've got plenty of room for anything else you might want to do (or in other words, your project will [i]scale[/i] well). Also, you don't know how much bandwidth other addons on their server are taking up, so best to make yours work with as little data as possible - after all, the animal that eats the most food is the first to die in a famine, right? You want yours to keep working well even if the others aren't.[/QUOTE] I don't know what to say, so much good information in a single post. Thanks for that.

[QUOTE=CrashLemon;18801624]I don't know what to say, so many good information in a single post. Thanks for that.[/QUOTE] Grammar nazi strike: Information isn't [I]many[/I], information is [B]much[/B] [editline]09:39PM[/editline] Also, to J89: What the heck is that console output? Is it all network traffic? On the server or on the client? Or both?

OUT: is a message from the server to the client. IN: is a message received on the client. Admittedly the pistol is one of the least efficient items in Itemforge, but I was more concerned with accurately emulating HL2's pistol.

DataTable variables are Garry's way of introducing CNetworkVars to Lua. Because they cannot be dynamically created and must be predefined prior to compiling, Garry simply added 4 generic variables of each variable type. Instead of depending on Lua to synchronize them between the client and server, they are fully managed by the Source Engine. They are similar to existing variables such as origin, angles, health, color, velocity and so on... so they are perfectly reliable and can be predicted. Can they lag the server? Sure. Just like spawning 500 barrels and blowing them up can lag the server. If used properly and in moderation you shouldn't notice much/any difference. You can read up on CNetworkVars here: [url]http://developer.valvesoftware.com/wiki/Networking_Entities#Network_Variables[/url]