I want to use my entity's SetupDataTables() to network a single integer in the range [0,7].
Theory suggests it'd be better to network it using 3 bits (in the form of 3 different booleans) that represent said integer in binary. But common practice suggests to just use a single integer and be done with it - which makes me wonder if loading the entity's datatables with 3 different booleans is somehow less efficient than using a single integer due to some internal implementation fuckery.
I know a single integer doesnt seem like much reason for all the fuzz, but I got a bunch of entities (count can even be in the hundreds) constantly networking data together, and I want to minimize loads as much as possible
Using an integer should be fine. Assuming this is for your vFire addon, what exactly do you need to network an integer for? The flame's health? Something else?
Can you predict the fire? Can you predict when it's going to get off? Do you worry that much about people somehow modifying values to clear visibility? The big problem with fire are it particles
What I would do if there were hundreds of fire running? I would cut my throat since playing with fire just ends in someone's cpu burning, or just send the seed generation of fire and then translate it to client and do calculations and predictions there
Not really sure what you're talking about
Yeah, this is for vFire - the only thing currently networked is an integer which represents its size (sizes are discrete in vFire's case)
You can use dtwatchent to see how many bits are used for transmission.
You could set up a quick server and try to test the impact when you have dozens of fire entities. There should not be a huge impact imo, as the game internally networks tons of stuff by default.
Why do you need to network that info if you can predict it from client too, if you can't, then you're not thinking it correctly, but networking that many entities are not good, neither doing expensive calculations, it's a limitation from the start of the ages in videogames sadly
For example, if you create a fire with 64 size, you can network that 64 to the core fire and then you do a share function with the spreading, you create a seed, imagine it like a kind of descriptor about how your fire will be, it can be something like "410h291h08ha", but that random word will mean that your fire will grow in x direction, will die in y seconds, everytime you need to create another fire, you do the same thing about seeds, built correctly you can create awesome fires by predicting where the fire will be with the less networking needed
In the worst case, it will impact fps the double you can imagine with all that calculations in both realms, fire sucks i know, i've seen what you're doing and it's fucking dope, i really hope you find how to solve the networking issue
Can you explain what will the integer be used for? 0 - 7 does not seem like something needing a constant change.
Oh, yeah fire life is dependent on the server-side realm, prediction is unfortunately not an option for what I'm looking for. The networking problem is solved though and it's quite efficient already, I'm just looking to improve what's already there
Sure, each fire has 7 different possible states that reflect its size: 1 for tiny, 2 for small, 3 for medium, 4 for big, 5 for huge, 6 for gigantic, and 7 for inferno (thats actually 7 values, not 8, woops). Each fire enters its appropriate state through a server-side floating 'life' value (affected by what's being burnt, fire merges, time, etc). The client never knows the life value and it doesn't care for it as well: all it needs is the size of the fire, so that's the only thing being networked.
It depends.
Depending on the networking implementation, those three booleans could be sent down the wire as a whole byte each. If Source automatically optimizes it down that's great, but you're never going to send less than a byte down the wire.
Also consider that the packets that contain your entity's informational updates have multi-byte overhead.
You put my thoughts into words, and the packet overhead point is correct. Since I'm using data table variables, I'm unsure how I'd be able to store it as a byte as you suggested.
With all that in mind, the reason I wanted to minimize the networking in the first place was because I wanted to add more data to whatever is being networked (such as shouldRender, or shouldDrawLight, etc) without actually adding more data variables.
But now I realized that I could in fact use a single integer to represent my x-bit worth of data using math.IntToBin and math.BinToInt, meaning I could use this integer to pass a whole bunch worth of booleans as I need (and it's guaranteed to be passed as a single 'packet', lets call it, as well instead of potentially 3), which is great!
I guess I can mark this as resolved, what I wanted to get rid of ended up being my solution :V
Do you not have the ability to work with individual bytes directly? I'm not familiar with Lua but being forced to deal with 4-byte integers as the smallest datatype seems like bad design
The core net library lets me network a string of bits and use them as I want, but from the looks of it there is no equivalent solution when dealing with the built in entity data variables (which are a bit too convenient to pass on), I'd be glad if someone could correct me
You'll network bytes, not bits individually. If this is the only thing you're networking, and you want *the smallest* footprint. I'd recommend net.WriteUInt. 8 bits/1 byte will give you 0-255 range, and it's technically the smallest information you can send.
DTVars don't let you set the size of your data. A DTVar boolean is 1 byte but you can't get a value from the getter that would be anything more than true or false. And a string will have an extra byte for the null terminator. Anything else I think is bigger than a byte.
Set up like 3 or 4 small hooks to send the data, one on the client to receive/update, and you should be good.
Theoretically, your range is 0-7, 3 bits. You could use the other 5 bits in the byte to store any other combination of 5 bits of data. 5 booleans, 3 booleans and a 0-3 integer, etc.
I hope I understood the problem properly.
Thank you for this, keep learning new things. Funnily enough then it seems that string would be the smallest footprint for a DT var. If I'll abandon DT vars then I'll definitely go for the unsigned integer, but I guess I should compromise towards convenience a bit for now.
Setting up net messages sounds complicated at first, but it's pretty intuitive and you get good control of when things are actually networked. I don't remember, but I think DTVars are constantly networked in PVS. A quick net message setup will only network when you tell it to.
Sorry, you need to Log In to post a reply to this thread.
