[KatNotDinner]

Hey guys. I coded a plugin for my gamemode. It replaces NWVars.
It is for GMod 13 only though.

nwvars.lua ( server side): http://pastebin.com/6bXDm0HA

cl_nwvars.lua (client - side): http://pastebin.com/HDsiYdni

Feel free to use it in any script but give me credits.

Credits to people who helped me:
Divran - pointing out mistakes and suggesting solutions, not being an ass
MadDog - a good suggestion which I'm working on

Note: Both files have to be loaded first (right after the init/cl_init) or there must be no nwvars set before the files have loaded. Else the set nwvars will break.

If you are seeing no point in this, get out instead of rating me boxes and being a pure idiot.

[Chessnut]

At the bottom, it should be _R.Entity.SetNetworkedBlah = _R.Entity.SetNWBlah.

This wouldn't even work as players who join after you don't get your info.

[KatNotDinner]

Don't get my info? What are you talking about? There's a hook that sends the stuff to them.

Also it would be really nice if you said something like "Nice" or "I like it" instead of pointing out unexisting error ( "Players won't get your info" ).

[Splambob]

Why so defensive? If anyone levels criticism towards your work it's usually because they want to help. You won't find "trolls" who take the time to read through your script.

IIRC the new net library exists because it's more efficient than networked variables. I haven't tackled networking in GLua though, can someone confirm/deny? It's a hole in my knowledge I'd like to mend.

[Divran]

You're using table.Add to try to add the player or entity to a table called "nwents", which won't work. So Chessnut was correct.

/*---------------------------------------------------------
   Name: table.Add( dest, source )
   Desc: Unlike merge this adds the two tables together and discards keys.
---------------------------------------------------------*/
function table.Add( dest, source )

	// At least one of them needs to be a table or this whole thing will fall on its ass
	if (type(source)!='table') then return dest end
	
	if (type(dest)!='table') then dest = {} end

	for k,v in pairs(source) do
		table.insert( dest, v )
	end
	
	return dest
end

Line 8 will trigger and nothing will happen.

[KatNotDinner]

Splambob posted:

Why so defensive? If anyone levels criticism towards your work it's usually because they want to help. You won't find "trolls" who take the time to read through your script.

IIRC the new net library exists because it's more efficient than networked variables. I haven't tackled networking in GLua though, can someone confirm/deny? It's a hole in my knowledge I'd like to mend.

I made this replacemnt using the net library cause it (should) improve performance in scripts that rely on NW vars and it is aslo easier to write one simple function instead a few lines of code and then calling net.Receive on the other side.

@ Divran: Ok, looking into the issue.



Ok, I think I fixed it. I also made it so that if there are nwvars stored in a player and the player disconnects, the script won't attempt to send these nwvars to the next player joined.

I will make actual NWInt functions but it might not be possible to post them today.

Edited:

Updated the code. Here's a small changelog:
1. Removed lots of useless code on the client which would prevent this from working;
2. Added all NWInt functions;
3. Made it so that if a player disconnects he goes away from the nwents table in order to prevent errors;
4. Removed table.Add. Wrote a small function to do what I needed.

[Divran]

It's still wrong. What you're doing now is copying all the values stored on the player/entity into "nwents". You need to copy the player/entity itself, not all their values.

Example

function _R.Entity:SetNWString( str, val )
    if not nwents[self] then nwents[self] = true end
 
    if !self.NWvars then self.NWvars = {} end
    if !self.NWvars.String[ str ] then self.NWvars.String[ str ] = {} end
    self.NWvars[ str ] = val
    net.Start( "String" )
        net.WriteEntity( self )
        net.WriteString( str )
        net.WriteString( val )
    net.Broadcast()
end

EDIT: There's a lot of other things that could be improved with this, but I'm going to play Starcraft 2 with some friends now :)

[Hentie]

another one?

[KatNotDinner]

Divran posted:

It's still wrong. What you're doing now is copying all the values stored on the player/entity into "nwents". You need to copy the player/entity itself, not all their values.

Example

function _R.Entity:SetNWString( str, val )
    if not nwents[self] then nwents[self] = true end
 
    if !self.NWvars then self.NWvars = {} end
    if !self.NWvars.String[ str ] then self.NWvars.String[ str ] = {} end
    self.NWvars[ str ] = val
    net.Start( "String" )
        net.WriteEntity( self )
        net.WriteString( str )
        net.WriteString( val )
    net.Broadcast()
end

EDIT: There's a lot of other things that could be improved with this, but I'm going to play Starcraft 2 with some friends now :)

Thanks, that was useful.
But Somehting is bothering me. Are you allowed to insert "self" into the brackets ([])?

And yes Hentie, another one.

Edited:

Updated the code.
Also Divran, I want this to work, I will improve it myself.
My point is that I would love to hear anything positive rather than just pointing out errors. I mean, I appriciate it but please say something good. I have put time and effort into this.

[Divran]

KatNotDinner posted:

But Somehting is bothering me. Are you allowed to insert "self" into the brackets ([])?

Yes. It's more efficient than looping through the entire table just to see if this player/entity is in nwents or not. But you will most likely have to change the PlayerInitialSpawn loop to reflect this change.

EDIT: Nevermind, you already did.

[KatNotDinner]

Updated the code. made a huge optimization. I had used net.Broadcast in the InitialSpawn hook by a mistake.
I want to ask garry to PLEASE get back the simple editor for OP. The current one fucks up everything (see OP). I will fix it later cause I'm lazy and I don't have time right now.

[Banana Lord.]

it seems useless to use the net library where usermessages can still be used

[Map in a box]

Net library is less overhead iirc

[KatNotDinner]

Banana Lord. posted:

it seems useless to use the net library where usermessages can still be used

I was actually thinking about that. I mean if you are sending 64 fucking KBs of data then you are doing something wrong. I will fix it.
Does anyone see any use of this? I use it in my script but I want to see someone else using this code.

[Falcqn]

Banana Lord. posted:

it seems useless to use the net library where usermessages can still be used

You can send much more data with the net library iirc

[DarKSunrise]

Azur posted:

You can send much more data with the net library iirc

You shouldn't be sending more than 256 bytes of data for a single networked variable in either case.

[wizardsbane]

DarKSunrise posted:

You shouldn't be sending more than 256 bytes of data for a single networked variable in either case.

Why not, exactly? How many dial-up Garry's Mod players are there?

[Ruzza]

wizardsbane posted:

Why not, exactly? How many dial-up Garry's Mod players are there?

Because it is stupid?

[KatNotDinner]

Ruzza posted:

Because it is stupid?

You do realise that you are kinda requesting limitation? Fuck logic!

[Banana Lord.]

if you are using NWVars with more than 256 bytes of data you're really doing something wrong/shouldn't be using NWVars

[DarKSunrise]

wizardsbane posted:

Why not, exactly? How many dial-up Garry's Mod players are there?

In most situations it's a lot more effective to just use plain user messages instead. Large networked variables are usually slow and might contain a lot of data that the client could already have. There's no point sending that over and over again.

[kp3]

DarKSunrise posted:

In most situations it's a lot more effective to just use plain user messages instead.

Why didn't the 3 posters above you didn't want to answer his question?

Why is it more effective by the way? If it's more effective for long strings shouldn't it be more effective on short ones too?

[wizardsbane]

Banana Lord. posted:

if you are using NWVars with more than 256 bytes of data you're really doing something wrong/shouldn't be using NWVars

DarKSunrise posted:

In most situations it's a lot more effective to just use plain user messages instead. Large networked variables are usually slow and might contain a lot of data that the client could already have. There's no point sending that over and over again.

I'm having trouble seeing how sending 32 bytes of data is crippling/bad practise if you're not using a computer and network connection from 1998.

[KatNotDinner]

Ok guys, added pastebin links.
Please say your opinion if I should use usermessages or net.* messages.

[Banana Lord.]

wizardsbane posted:

I'm having trouble seeing how sending 32 bytes of data is crippling/bad practise if you're not using a computer and network connection from 1998.

it's wasteful and inefficient to send more than you need to

[Big Bang]

From what I can tell the code that I am seeing isn't any more efficient than NWVars mainly because it is using the exact same scheme than NWVars regardless of if it's using the Net library as opposed to the Usermessage library. The difference in efficiency between both of them is negligible. If you change how and when the variables are sent or updated then you would most likely see a performance increase.

Also

local table, net, nwents = table, net, {}

Stop it.

[wizardsbane]

Banana Lord. posted:

it's wasteful and inefficient to send more than you need to

Oh, alright, so this is more of a pragmatic programming thing than an actual harm.

[Banana Lord.]

wizardsbane posted:

Oh, alright, so this is more of a pragmatic programming thing than an actual harm.

the actual harm is that you think it's okay to use bad practices and you're wasting bandwidth.

[wizardsbane]

Banana Lord. posted:

the actual harm is that you think it's okay to use bad practices and you're wasting bandwidth.

It's not me. Oh! Heavens no. I'm just putting forth that if such a practise doesn't cripple or harm the systems and clients it interacts with, it shouldn't be demonised or decried so quickly. This is not to say that I'm going to look at someone's code sending a 32 byte object every tick and think "a deity must have coded this amazing block of text." I can see where you and DarkSunrise are coming from, and I agree: no one should ever need to send 32 bytes of data every tick, but actually doing so is somewhat valid as it has no real negative impact on the systems or clients that it functions on.

[KatNotDinner]

Big Bang posted:

From what I can tell the code that I am seeing isn't any more efficient than NWVars mainly because it is using the exact same scheme than NWVars regardless of if it's using the Net library as opposed to the Usermessage library. The difference in efficiency between both of them is negligible. If you change how and when the variables are sent or updated then you would most likely see a performance increase.

Also

local table, net, nwents = table, net, {}

Stop it.

Ok. Can you give me an example how would I send stuff in a different way?

[Banana Lord.]

wizardsbane posted:

It's not me. Oh! Heavens no. I'm just putting forth that if such a practise doesn't cripple or harm the systems and clients it interacts with, it shouldn't be demonised or decried so quickly. This is not to say that I'm going to look at someone's code sending a 32 byte object every tick and think "a deity must have coded this amazing block of text." I can see where you and DarkSunrise are coming from, and I agree: no one should ever need to send 32 bytes of data every tick, but actually doing so is somewhat valid as it has no real negative impact on the systems or clients that it functions on.

the point isn't that it doesn't impact users, it's bad practice and still a waste of bandwidth.

[wizardsbane]

Banana Lord. posted:

the point isn't that it doesn't impact users, it's bad practice and still a waste of bandwidth.

Yeah. Like I said, I'm agreeing to this. However, as you admit it has no impact, it is still valid to use. It may not be a proper, pragmatic, or effective use, but it is still acceptable to utilise fully.

[Banana Lord.]

wizardsbane posted:

Yeah. Like I said, I'm agreeing to this. However, as you admit it has no impact, it is still valid to use. It may not be a proper, pragmatic, or effective use, but it is still acceptable to utilise fully.

My last statement to this extremely dumb argument, but I never said it had no impact. Once again the impact is wasted bandwidth, processing time, and bad practices.

[wizardsbane]

Banana Lord. posted:

My last statement to this extremely dumb argument, but I never said it had no impact. Once again the impact is wasted bandwidth, processing time, and bad practices.

I suppose it's extremely dumb, because it's impossible for there to be alternatives to your mode of thought.

You continue to say that it has no actual impact, and then turn around and say that its impact is "wasted" bandwidth. What is "wasted" supposed to mean, exactly? If the use of all 32 bytes does not impact performance or completely cripple the connection involved, this argument is completely irrelevant. The same applies to the "wasted processing time" argument. If there isn't an impact, there isn't an impact. It doesn't matter if it's inefficient or not. The viability of using all 32 bytes should be determined on its impact, not on whether it's a programming pearl or not is all I'm saying.

[KatNotDinner]

Can someone point out where am I sending 32 bytes of data every tick?
Also Banana Lord, read the OP. You voted me boxes just because you don't like my script.

Edited:

Is there gonna be any difference if I use usermessages? Also do you think that client side NW Vars should stay client side?

Edited:

Updated code.
I added a third argument:
1. If you don't parse anything as a third argument server-side stuff will be sent using user messages, else it would be sent via net message;
2. If you don't parse anything as a third argument client-side the nwvars you set will stay client-side, else it will be sent to the server and then to all clients.
Note: SetNWString is going to use net library if the string is 255 bytes or more when sending strings to clients no matter what.
It is also going to use net.* library under certain conditions (it calculates lengths).

I think everybody should be satisfied now.

[Jcw87]

wizardsbane posted:

I suppose it's extremely dumb, because it's impossible for there to be alternatives to your mode of thought.

You continue to say that it has no actual impact, and then turn around and say that its impact is "wasted" bandwidth. What is "wasted" supposed to mean, exactly? If the use of all 32 bytes does not impact performance or completely cripple the connection involved, this argument is completely irrelevant. The same applies to the "wasted processing time" argument. If there isn't an impact, there isn't an impact. It doesn't matter if it's inefficient or not. The viability of using all 32 bytes should be determined on its impact, not on whether it's a programming pearl or not is all I'm saying.

Even the smallest amount of waste is bad. What happens when a server installs 20 addons that each waste a little network bandwidth? That small waste adds up, especially when the server has a lot of players on it. If you can make it more bandwidth efficient, do it. Don't waste bandwidth just because it's easier. Your script/addon/gamemode/whatever has to share bandwidth with other addons.

[KingofBeast]

Is there anything stating that the net library actually utilizes all of its network capacity if the message itself doesn't amount to that? If there is then I agree that for small things, umsg would be better for efficiency's sake. But, seeing as net.Receive tells you the length of the message, I'm led to believe that net only sends messages the appropriate size for the data within. Which means that it should be the preferred method of networking.

edit: If the case is true that net does utilize all it has, there's still a point where even for small things umsg shouldn't be used. Whether or not individual bits of data are small, given the count of those individual bits of data, net would propose a smaller impact on cpu usage. One net message or 100 usermessages?

[wizardsbane]

Jcw87 posted:

Even the smallest amount of waste is bad. What happens when a server installs 20 addons that each waste a little network bandwidth? That small waste adds up, especially when the server has a lot of players on it. If you can make it more bandwidth efficient, do it. Don't waste bandwidth just because it's easier. Your script/addon/gamemode/whatever has to share bandwidth with other addons.

Yeah, I totally agree. What I'm saying is, and this point is really in the details and not just the general point that Banana Lord kept pushing against me (which I understood and agreed to three posts ago) is that: while the practise wastes and is not the most efficient route of going about things, it's not a completely invalid method of getting things done. 256 bits is nothing when even the most basic 1Mbit connection can handle 1,000,000 bits. 256 bits is 0.03% of 1MBit. The impacts and waste being levied against ever using the practise are just code efficiency and programming pearl related concerns, they're not presenting any sort of real-world impact. The practise is entirely legitimate, even if it is inefficient, wasteful, and not suggested is all I'm saying.

[KatNotDinner]

Jcw87 posted:

Even the smallest amount of waste is bad. What happens when a server installs 20 addons that each waste a little network bandwidth? That small waste adds up, especially when the server has a lot of players on it. If you can make it more bandwidth efficient, do it. Don't waste bandwidth just because it's easier. Your script/addon/gamemode/whatever has to share bandwidth with other addons.

Jcw, you are an awesome coder (I have seen your projects). Could you point out my mistakes and suggest a solution?

Edited:

KingofBeast posted:

Is there anything stating that the net library actually utilizes all of its network capacity if the message itself doesn't amount to that? If there is then I agree that for small things, umsg would be better for efficiency's sake. But, seeing as net.Receive tells you the length of the message, I'm led to believe that net only sends messages the appropriate size for the data within. Which means that it should be the preferred method of networking.

edit: If the case is true that net does utilize all it has, there's still a point where even for small things umsg shouldn't be used. Whether or not individual bits of data are small, given the count of those individual bits of data, net would propose a smaller impact on cpu usage. One net message or 100 usermessages?

I have added the 3rd arguments so that you can chose between umsg and net. Although if net messages are more efficent I will make the net messages a default option but I don't know if they are.

[Jcw87]

wizardsbane posted:

Yeah, I totally agree. What I'm saying is, and this point is really in the details and not just the general point that Banana Lord kept pushing against me (which I understood and agreed to three posts ago) is that: while the practise wastes and is not the most efficient route of going about things, it's not a completely invalid method of getting things done. 256 bits is nothing when even the most basic 1Mbit connection can handle 1,000,000 bits. 256 bits is 0.03% of 1MBit. The impacts and waste being levied against ever using the practise are just code efficiency and programming pearl related concerns, they're not presenting any sort of real-world impact. The practise is entirely legitimate, even if it is inefficient, wasteful, and not suggested is all I'm saying.

You are assuming that those 32 bytes would only be sent once per second. With an actual server, you you are going to have many players who also need a copy of the data. If the data needs constant updating, it could be sent 20, 33, or even 66 times per second, depending on how you are sending the data and how the server is configured. Include several instances of this data (such as entities), and the amount of data per second starts to get significantly higher very quickly, creating a real-world impact.

This is why it is important to only give clients the absolute minimal amount of data that you can get away with, and only when they absolutely need it.