Difference between NWVar and NW2Var #2

I already asked about differenced between NWVars and NW2Vars.
http://forum.facepunch.com/showthread.php?t=1534636

But I’ve some questions now.
What are the advantages?
I saw that the NW2Strings have a higher limit than the NWStrings. (NWString: 199; NW2String: 511)
But are there any other bigger differences?

Can someone “help” me with that?

Will the NW2Vars ever replace the NWVars variables? If so, when will they be replaced?

NWVar is shit.
NWVar 2 is slightly less shit but it’s deprecated.

Wat? Do you know what “deprecated” means? NWVars are what is deprecated, NW2Vars are the new replacement for them. They should’ve replaced NWVars long ago but the devs won’t do this for some reason.

We don’t know when they’re gonna be replaced, all the crashes that happened with the initial implementations of nw2vars are gone so the only thing holding them back is whoever remembers to make the switch.

Oh and of course whoever wants to actually hear people whine about shit like this ent:SetNWFloat( “mymoney” , Entity(34) ) not working anymore (which is horrible but people do it anyway because the old functions don’t do type checking )

I swear to god I saw either Robotboy or Willow say that NW2 was a mistake and the reason it’s not documented on wiki is because its going to get removed eventually.

It’s not on the wiki because it will eventually get removed - after it replaces NWvars. I don’t think anyone ever said they were shit/a mistake.

I, too, don’t know why this hasn’t happened yet.

There are some things from the NW2Vars that are on the wiki.
But what are the other differences?

And why are the NW2Vars not replaced even if there are NW2Var functions that seems to detect the correct type (SetNW2Var/SetGlobal2Var)?

In the last patch notes, they wrote that many removed functions are now ‘in the game’ as aliases for their replacements (as example, dont know if they added them too though, umsg exist now as an alias for net messages). So I guess they’ll do the same with NWVar and NW2Var.

Bump.

By the way, these are the only things I found in the Wiki about the NW2Vars:

http://wiki.garrysmod.com/page/Entity/GetNWVarTable (Entity:GetNWVarTable() doesn’t exist. But Entity:GetNW2VarTable() exists.)

probably the biggest thing that coders will have an issue with is that nw2vars obey pvs and won’t update on off screen or far away entities until the player gets closer to them.

You cant exactly call a feature some issue, be happy PVS exists otherwise you will get alot of data dumped on you.

In normal cases you don’t want to network it over the entire map, if its a SENT you can still control it via http://wiki.garrysmod.com/page/ENTITY/UpdateTransmitState

If you want some source engine entity to always transmit consider parenting a SENT to the object.

I can imagine it being annoying for the “usergroup” NWString specifically. Would it be acceptable for a client not to be up to date with another client’s usergroup? Honest question, I don’t know.

[del]
How often is that going to change? Do other clients need to know your usergroup constantly when you’re out of PVS?

In a panel showing ranks (such as a scoreboard), a player has to be valid first before setting the string on a dlabel for instance.

Your own player entity is always valid and networked (except when the client itself joins a server, I know that), so for an admin that’s not going to be that big of a deal.

Also I know you like playing devil’s advocate but please let’s not turn this into a 4 pages thread on why garry’s shitty system is needed for some edge case.

(also please remember how godly unreliable garry’s nwvars are and used to be, when a server is up too long stuff like gmod_button would show hints as ???, sometimes strings wouldn’t network at all, and all that fun stuff I’m sure you’ve run into in these years)
[/del]

I realize I’m being somewhat of a dick right now so disregard this if you will.

Networking vars is necessary for gamemodes like TTT.
If the var is only updated if the players are near together then the gamemode wouldn’t be the same like it is now.

Also things like usergroups have to be networked to every user. (Necessary for admin mods.)

Under the hood Valve uses usermessages for such things, look at all the HUD specific code in the SDK u’ll find plenty usermessages just to tell the player whats up, they dont bloat each entity with variables where not needed, keep in mind that the more nwvars you add the more is being sent on a full network update and server owners suddenly wonder why their server lags like hell, a full update is caused when entering PVS or on join or on lag, so plenty scenarios.

And being right isn’t quite being a dick imho.

Would only make sense if the client has any authority, if a user wants to ban another user it still has to be relayed to the server to take action. And I highly doubt you understand anything about the TTT code the way you talk, ofc its necessary to network variables but it is important to know which ones and when.

For example:
Karma must be send to every player.
The information which players were identified have to be send to every players.

These two things must be networked to everyone everytime it changes. (The scoreboard needs these informations.)

I’m not saying you shouldn’t use nwvars, using them properly is the magic. In most cases its just easier to keep the state in some external table via entity id instead of the object, that way you have always the full data set regardless of packet loss or PVS visibility.

i never said it was an issue, i said some coders might find it as an issue. it’s not an issue in my mind, but some other developers do not understand how they work so it will probably cause some frustration among devs who don’t understand the new behavior.

For information shown in scoreboards and other uis, positions and distances between players and/or other entities are irrelevant. There should be some way to network things about entities without being stung by PVS. Luckily, there are through net messages, though you wouldn’t want to reinvent entity bound variables.

I reckon that the PVS bound behaviour is a very good default. After all, it would give you networking optimisations without having to think about it, and it will be appropriate for most cases. It would have to be documented, though. Being bound to PVS is a very important property. It can be extremely difficult to find out why you can set a var on an ent on the server without seeing that change on the client if you don’t know that the ent has to be in the PVS.

The current NWVars could be renamed or something as they would still serve a well defined purpose: networked data relating to a single entity that must at all times be up to date on every client, regardless of PVS. Examples would be usergroups, kill score points, statistics stuff.