I have this weird thing in the back of my head every time I mess with networking variables, and I want to get it cleared up before I drive myself nuts. I remember reading somewhere that constantly networking variables is poor practice, and you should only do it when necessary. I'm working on an entity right now, and it has around 10 properties to it that I will need to add, subtract, divide, and get the values of periodically. Now, for an example, let's say all 10 of those properties were going to networked to a clientside screen for the player to view. What is a good method in practice to network these properties throughout the script.
Right now, this is my setup: In the server realm, I have all the properties set to local variables bound to the entity itself. self.Stage, self.Timeleft, self.Quality, etc. On the Think() hook (Not sure if a better option exists) (You're also gonna laugh at this.) I do.
[lua] self:SetNWString('unpack', ' '..(self.Stage or 1)..' '..(self.Timeleft or 1)..' '..(self.Water or 1)..' '..(self.Quality or 1))
[/lua]
Which essentially packs the variables into the string and saves it to the entity so it can be unpacked clientside using string.Explode.
[lua] local nwstring = self:GetNWString('unpack')
local unpacked = string.Explode(" ", nwstring)
local stage, timeleft, water, quality = unpacked[2], unpacked[3], unpacked[4], unpacked[5][/lua]
It may look extremely tedious, but I've sorta used this for a while. My reason to use this is because I feel I can increase the efficiency of the script if I only send the NW Variables when I need them, instead of every living second. Also, it seems a lot less dirty. With this method, I can control exactly when the updated variables reach the client realm - not that it matters [I]that [/I]much.
My biggest question is: Should I be setting and getting networked integers (through SetNWInt, GetNWInt) constantly throughout my entity if I plan on eventually transfering them between the client and server realm, or is that a poor habit to get into? I'm sure someone is going to just say that what I'm doing is a complete waste of time, and there is nothing wrong with the other method, but that's the clarity I'm looking for.
have the variables in the shared realm and update in the shared realm so it gets updated for both server and client?
post your entire code you have now that you want help with, not snippets.
I have a few examples: [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_systems/simple_currency_system/simple_currency_system.zip[/url] -- Simple currency system with helper functions ( excluding load / save code ) which networks data to client when Set* is called on server. On client it updates the variable...
Second example is a super basic networking system: [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_systems/simple_networking_system/sh_basic_networking_and_data_system.lua.html[/url] -- It does support private values but it doesn't have the flag / category system like the large networking addon does. I added in ( hardcoded ) private variable subscriptions so any entity that has .Owner ( such as Swep / props that use it ) the Owner will receive private value updates while no one else will, and vehicle private data will only be relayed to the driver.
Simple but effective system if you just want to manage variables which can be broadcast to everyone, or simply sent to one or kept private on the server. It has a basic sync system for when the client first connects to the server but it doesn't prevent net messages while the user is connecting ( like the full net addon does to prevent possibility of overflow with too much data ) -- this one should also only update data if it changes. remove .html to view .lua...
Full system: [url]https://bitbucket.org/Acecool/acecooldev_networking/src/[/url] ( Converts NW / Global / etc vars to the flag system. Converts umsg to net messages. Converts various umsg functions [ SendLua / BroadcastLua / SendUserMessage / and possibly a few others ] to use net instead. Only networks data if data changes )
Honestly though... I'd recommend a system such as the currency system where when the server updates the var it updates the client if you only need to do this for a few entities at max. If you have a few more then my lightweight net system will work ( use _ent:SetFlag( _name, _value, _private_bool ); and _ent:GetFlag( _name, _default, _private_bool ); or data:Get/SetFlag( _ent, _name, _value_or_default, _private_bool ); for setting / getting values )... If you have a game-mode that has a lot of user-messages or uses a lot of NWVars, etc.. and you're experiencing lag as a result, use the full system.
[QUOTE=AnonTakesOver;47523359]have the variables in the shared realm and update in the shared realm so it gets updated for both server and client?
post your entire code you have now that you want help with, not snippets.[/QUOTE]
That's not how shared works.. :v:
[QUOTE=Karp;47522953]I have this weird thing in the back of my head every time I mess with networking variables, and I want to get it cleared up before I drive myself nuts. I remember reading somewhere that constantly networking variables is poor practice, and you should only do it when necessary. I'm working on an entity right now, and it has around 10 properties to it that I will need to add, subtract, divide, and get the values of periodically. Now, for an example, let's say all 10 of those properties were going to networked to a clientside screen for the player to view. What is a good method in practice to network these properties throughout the script.
Right now, this is my setup: In the server realm, I have all the properties set to local variables bound to the entity itself. self.Stage, self.Timeleft, self.Quality, etc. On the Think() hook (Not sure if a better option exists) (You're also gonna laugh at this.) I do.
[lua] self:SetNWString('unpack', ' '..(self.Stage or 1)..' '..(self.Timeleft or 1)..' '..(self.Water or 1)..' '..(self.Quality or 1))
[/lua]
Which essentially packs the variables into the string and saves it to the entity so it can be unpacked clientside using string.Explode.
[lua] local nwstring = self:GetNWString('unpack')
local unpacked = string.Explode(" ", nwstring)
local stage, timeleft, water, quality = unpacked[2], unpacked[3], unpacked[4], unpacked[5][/lua]
It may look extremely tedious, but I've sorta used this for a while. My reason to use this is because I feel I can increase the efficiency of the script if I only send the NW Variables when I need them, instead of every living second. Also, it seems a lot less dirty. With this method, I can control exactly when the updated variables reach the client realm - not that it matters [I]that [/I]much.
My biggest question is: Should I be setting and getting networked integers (through SetNWInt, GetNWInt) constantly throughout my entity if I plan on eventually transfering them between the client and server realm, or is that a poor habit to get into? I'm sure someone is going to just say that what I'm doing is a complete waste of time, and there is nothing wrong with the other method, but that's the clarity I'm looking for.[/QUOTE]
One thing I can think of is your TimeLeft variable, you can use CurTime as both client and server return the same, so instead of setting how much time is left just set the time when it will time out.
And you might wanna seperate the data so its not required to network the entire dataset if you change a single value within.
Edit: I should mention NWVars will only transmit data if the value changed, so if you set something constantly which however holds the same value as before it will not send anything.
If you only set the time it expires, you're limited in what information can be derived from it. By setting the start time and duration, you'll be able to have an accurate progress bar or derive any of the time-scales such as time left and time elapsed.
So, if you only need the value for an anti-spam style of script then you can set the expiry only and you'll be able to pull time left from that but not time elapsed which wouldn't be needed for expiry-only-logic.
If it is something like a plant growing or similar, then start time and duration would be better suited.
Sorry, you need to Log In to post a reply to this thread.
