Yet Another Networking Variables Question

[ThrowAwayAcct]

Yes I've done the search, read the wiki, and gotten a few suggestions but no definitive answers.

I have an addon. It stores values for a player that are frequently set serverside ("bleedout", "stamina", etc).
There are five of them for each player.
They are changed frequently (at most once a second).
It is not necessary for all clients to know of each player's values (aside from the server, only each player needs to know of his own).

Up until now I've been using NWInt NWString NWFloat etc. Worked gorgeously in SinglePlayer, worked beautifully in local/listen server, but I put the code on a real server and suddenly [b]none[/b] of my clientside scripts can get ahold of [b]any[/b] values. Everything works properly serverside, but all my HUDs are blank/zero'd, binding intercepts don't work, on and on.

Check it. This does not work one bit:

SERVER:

ply:SetNWInt("Holy_Horse_Dongs",340)

CLIENT:

print(ply:GetNWInt("Holy_Horse_Dongs"))

I see the value set on server, and on server I can retrieve it perfectly. On client it's 0 every time no matter what.

Can I fix this, or am I using the wrong approach? I've tried endlessly to find a way to create a SetupDataTables kinda thing for players, with NetworkVars, like I do with my SWEPs, but it's never worked. Player classes, nothing. I suppose I can always resort to using the net library, but Garry said this shouldn't be used for shit other than events and not for things that change frequently. Doing this with usermessages would be such a pain in the ass. I also want to take advantage of prediction and everyone says to avoid NWVars. Can I SetupDataTables for a player? Everything that looks useful on the wiki is marked as internal. Any solution?

[Eldar Storm]

This used to work, but now it does not seem to propagate the variable over to client any more.
Having the same issue basically.

[AIX-Who]

Make sure that ply is valid, or even just try it with LocalPlayer() just in case it is being weird.

If you want to do your own way of making variables then you could make your own way of updating using net messages, here is a [B]really really bad[/B] example of how you could do it as it uses WriteTable and some other issues i am sure exist with it...

-- Server side code

util.AddNetworkString("Update_Player_Variable");
local Meta = FindMetaTable("Player");

function Meta:UpdateVariable(Var,Data)

   self.StoredData = self.StoredData or {}
   self.StoredData[Var] = Data
   
   net.Start("Update_Player_Variable")
      net.WriteTable(self.StoredData)
   net.Send(self)
   
end

-- Client Side Code

net.Receive("Update_Player_Variable",function(l)
   LocalData = net.ReadTable()
end)

-- Example

-- Server

function Meta:SetMoney(Amount)
   self:UpdateVariable(Money,Amount)
end

ply:SetMoney(500)

-- Client

print(LocalData[Money])

[B]As i said this is just an example and there are much better ways of achieving this![/B]

You could use Mista-Teas NetVar Library which can be found here;

[url]https://github.com/Mista-Tea/netwrapper[/url]

It offers a very effective way of networking data and only updates when changed, saving you from using NWVars :)

If you can't be bothered to read his documentation then using it is as simple as putting it into your addons folder and then using

ENTITY:SetNetVar(Name, Data )
ENTITY:GetNetVar(Name, Default if not found )

[Pyro-Fire]

+1 on [URL]https://github.com/Mista-Tea/netwrapper[/URL]

Haven't had any problems since i've started using it.
Very effective.

Also lets you network tables.

[Acecool]

You don't need to network stamina!, Stamina can be derived by a shared hook so the client and server will be in sync without having to network it... The only times you will need to network something is when you reset the value..

Take a look at my basic and extended Stamina systems: [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_systems/basic_stamina_system/sh_basic_stamina_system.lua.html[/url] Remove .html to view .lua

[url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_systems/basic_stamina_system/sh_extended_stamina_system.lua.html[/url] Remove .html to view .lua

For "bleeding out" you also don't need to network it unless you want to do something very special but then you can simply set up a simple 1 time message which defines how many times the player will be damaged ( or until death ), when it expires, etc...

Here's an old example of "bleeding out": [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/takedamageinfo_example.lua.html[/url] Remove .html to view .lua

I do have a new example somewhere which supports bandaging ( remove the timer ), etc... but I'll need to locate it.

Also, NW Vars are PUBLIC meaning all players receive them so use them sparingly.. If you want to set up something where a vehicle has Fuel / Battery / etc... I'd recommend my lightweight system ( which hard-codes data-linking; the addon version doesn't -- lightweight data-linking basically defines all private data is networked to the _ent.Owner if it exists, or the vehicle driver ): [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_systems/simple_networking_system/sh_basic_networking_and_data_system.lua.html[/url] Remove .html to view .lua

You'd basically use: _v:SetFlag( "fuel", _value, true ); // 3rd arg defines private or public; true for private, false or nothing for public ( public is broadcasted only when data changes and private is only networked to the owner if the data changes )
For the HUD you'd use _v:GetFlag( "fuel", _default, true );

[Willox]

[QUOTE=Acecool;47702286]You don't need to network stamina!, Stamina can be derived by a shared hook so the client and server will be in sync without having to network it... The only times you will need to network something is when you reset the value..

Take a look at my basic and extended Stamina systems: [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_systems/basic_stamina_system/sh_basic_stamina_system.lua.html[/url]

[url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_systems/basic_stamina_system/sh_extended_stamina_system.lua.html[/url]

Remove .html to view .lua

For "bleeding out" you also don't need to network it unless you want to do something very special but then you can simply set up a simple 1 time message which defines how many times the player will be damaged ( or until death ), when it expires, etc...

Here's an old example of "bleeding out": [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/takedamageinfo_example.lua.html[/url]

I do have a new example somewhere which supports bandaging ( remove the timer ), etc... but I'll need to locate it.[/QUOTE]

If you don't use DTVars you're missing out on Source's prediction system. Any hiccup on the client's connection to the server will de-sync you code.

[Acecool]

Under certain circumstances I'd agree that prediction is king but because this is bound to a synced value ( CurTime ), and because it is using a shared movement hook ( executing every frame ) there should be no issue. This system is also being used on several servers and no one has complained of any issues to date.

Now, if a small amount DOES desync, then it likely won't matter a whole lot because it will recharge back up to full while resting or you'll hit 0 from running ( which also slows you down gradually instead of a non-subtle-jerk )... and then we'd need to consider the cost / overhead to see if it is worth networking the data to every player every frame ( or when data changes ) when a solution exists which works with negligible ( if any ) desync.

[Dear_Matt]

[QUOTE=Acecool;47702841]Under certain circumstances I'd agree that prediction is king but because this is bound to a synced value ( CurTime ), and because it is using a shared movement hook ( executing every frame ) there should be no issue. This system is also being used on several servers and no one has complained of any issues to date.

Now, if a small amount DOES desync, then it likely won't matter a whole lot because it will recharge back up to full while resting or you'll hit 0 from running ( which also slows you down gradually instead of a non-subtle-jerk )... and then we'd need to consider the cost / overhead to see if it is worth networking the data to every player every frame ( or when data changes ) when a solution exists which works with negligible ( if any ) desync.[/QUOTE]

Just because something runs every frame doesn't mean it can't derail, you are missing the point here Dr. Acecool.

[Eldar Storm]

[url]https://github.com/Mista-Tea/netwrapper[/url] worked for me so far.
Any news if Networking variables will be fixed again, or is this now a feature and not a bug.

[Dynn]

[QUOTE=Eldar Storm;47706839][url]https://github.com/Mista-Tea/netwrapper[/url] worked for me so far.
Any news if Networking variables will be fixed again, or is this now a feature and not a bug.[/QUOTE]

Update your server