Why does Entity's SetNWVector skips networking values in some cases ?

Garry's Mod coding
#1

I was coding the new TA snap implementation and noticed a strange behavior of ENT:(Set/Get)NWVector. I am setting the spawn position here and reading it here. Obviously it is SERVER --> CLIENT with the same key “ray_intersect_pos”.

  1. When I reload the source with saving the file it transmits one vector and then stays the same.
  2. I am transmitting the information from the SV to CL
  3. No matter what I change vector offsets to it does not wanna change.

I am having the following output with “set” on SV and “use” on CL:

SET 6778.269363634 525.186646 1215.082520 -12285.862305
USE 6778.2767429686 369.156250 528.343750 -12285.843750
SET 6778.2822110742 525.186646 1215.082520 -12285.862305
USE 6778.2898019144 369.156250 528.343750 -12285.843750
SET 6778.295283459 525.186646 1215.082520 -12285.862305
USE 6778.302789505 369.156250 528.343750 -12285.843750
SET 6778.3082320123 525.186646 1215.082520 -12285.862305
USE 6778.3156779024 369.156250 528.343750 -12285.843750

It seems hat this guy has similar issue here:

#2

Use SetNW2Vector

#3

Thanks!

Em, What’s its deal? Is it some kind of temporary fix or a permanent api ?

#4

It was supposed to be merged into NWVars when the system was finished, but the person originally working on them has gone inactive.

#5

Or he started from work in sandbox ;-;

#6

I’m referring to _Kilburn, although Willox did a little work too.

#7

This is dumb. The NW2Var system is better than NWVar and according to everyone I’ve seen it’s already 100% working and complete. Why isn’t it just merged as-is?

#8

Now, if these were fixed, they could be merged as-is.

#9

Alongside the few bugs there’s one difference, though I doubt it’d cause any bugs, just player information may update a bit slower.

#10

To be fair, NW/DTVars shouldn’t really be used for immediate networking for entities outside of the PVS. Unfortunately, a lot of people use them in lieu of regular networking for things like points, names, or other variables not updated regularly or in unpredicted instances, which updating to NW2Vars would cause issues with. Much like SetNW* originally not doing any type checking, things will break from improper usage.

#11

Just to note that setting the key on NW to nil on SV returns nil on CL, which is neat.
I am using this to draw the vector given and if I say like:



  local ePos = oPly:GetNW2Vector("ray_inter_relaypos")
  local eAng = oPly:GetNW2Angle ("ray_inter_relayang")
  if(ePos and eAng) then
    -- Do some stuff with the vector and angle when located
  end

It draws the layer as expected when there is a vector available and skips if it’s not.

#12

I think that might be a bug. It’s documented to always return a vector, which is what the fallback is for.

#13

Yep, vector, checked again I had other conditions for not drawing. This wasn’t NW2 fault :wink: