HiSpeedDStream -- My attempt to slim down datastream
48 replies, posted
[QUOTE=LauIsFun;17498044]One solution besides using datastream / remixing it.
Make your own networking.[/QUOTE]
That does the same thing as datastream? Serialization and sending?
[QUOTE=Jawalt;17498149]That does the same thing as datastream? Serialization and sending?[/QUOTE]
Datastream sends a string of data, so a color object of [0-255] domain, becomes "r255g255b255a255".
[QUOTE=LauIsFun;17498336]Datastream sends a string of data, so a color object of [0-255] domain, becomes "r255g255b255a255".[/QUOTE]
That could actually do with improvement, it'd probably be more efficient to send the information to construct the table in integer values unless needed, and then send the values as ints or strings.
[QUOTE=Jawalt;17498371]That could actually do with improvement, it'd probably be more efficient to send the information to construct the table in integer values unless needed, and then send the values as ints or strings.[/QUOTE]
*facepalm*
BRB - finishing smsg.
[QUOTE=LauIsFun;17498436]*facepalm*
BRB - finishing smsg.[/QUOTE]
Facepalm? You're going to be doing the exact same thing with a usermessage only the way to construct the data is sequential and handled by Lua. If you were to send that same info on connect for each stream instead of on send it'd save alot of network traffic, but be much more complex to use and less flexible than datastream. Actually I just thought of a way to keep the flexibility of Datastream, but the speed of Usermessages.
Wait, people use datastream? I thought that was just a joke, you know, just like the leafblower?
In all honesty, it's about time someone came up with a challenging competitor library. I like where you're headed mate. :smile:
Good job.
Sorry for the stupid question, but I must ask: What does datastream offer that can't be done already?
Sending tables of large data. Umsgs can only hold 255 bytes of data.
[QUOTE=Doug52392;17502981]Sorry for the stupid question, but I must ask: What does datastream offer that can't be done already?[/QUOTE]
Nothing, its a wrapper. It attempts to make moving packets of data from client to server (and vice versa) easier.
[QUOTE=Gbps;17503198]Sending tables of large data. Umsgs can only hold 255 bytes of data.[/QUOTE]
Is that in the wiki somewhere?
[QUOTE=MadDog986;17508573]Is that in the wiki somewhere?[/QUOTE]
[url]http://wiki.garrysmod.com/?title=datastream[/url]
Datastream, I've found, breaks often and is much less reliable than usermessages, but it is a reliable way of sending large amounts of data (tables, especially) as well as sending lots of client data to the server.
[QUOTE=Gbps;17511125][url]http://wiki.garrysmod.com/?title=datastream[/url][/QUOTE]
I wasnt talking about datastream...
[quote]Umsgs can only hold 255 bytes of data.[/quote]
[QUOTE=Jawalt;17498671]Facepalm? You're doing static networking like you just said? <datastream rant> Actually I just thought of a way to keep the flexibility of Datastream, but the speed of Usermessages.[/QUOTE]
lolwut at last sentence.
[QUOTE=MadDog986;17513087]I wasnt talking about datastream...[/QUOTE]
it's not documented (I think), but yes the cap is 255 characters.
Try it, send a umsg with 266 characters and tell the client to print() it.
[QUOTE=Entoros;17512074]Datastream, I've found, breaks often and is much less reliable than usermessages, but it is a reliable way of sending large amounts of data (tables, especially) as well as sending lots of client data to the server.[/QUOTE]
stop spreading FUD.
it never broke for me...
the only thing that tends to break is people using AcceptStream wrong, i.e. addon conflicts
that's why i'm a bit opposed to Gbps adding that to his datastream on both ends.
that's even one more thing that can break.
[QUOTE=TomyLobo;17548006]stop spreading FUD.
it never broke for me...
the only thing that tends to break is people using AcceptStream wrong, i.e. addon conflicts
that's why i'm a bit opposed to Gbps adding that to his datastream on both ends.
that's even one more thing that can break.[/QUOTE]
To my knowledge, Datastream doesn't work normally on dedicated servers. There [i]is[/i] a way to fix it, but it requires a bit added to the code, I can't quite remember what it was, but I saw it somewhere. Will cite reference if I find it.
[editline]09:16PM[/editline]
Found it.
[QUOTE=Levybreak;17486254]Datastream is broke on dedicated servers. You can fix it with this: (Serverside)
[lua]
--Redistributable datastream fix.
local META = FindMetaTable("CRecipientFilter")
if META then
function META:IsValid()
return true
end
else
ErrorNoHalt(os.date().." Failed to fix datastream fuckup: \"CRecipientFilter\"'s metatable invalid.")
end
[/lua][/QUOTE]
that applies to everything, not just dedicated servers...
but it's easy to work around, so who cares?
function _R.CRecipientFilter.IsValid() return true end
Nice to see people using my code.
Anyway, it's fixed in the next update, which seems to be taking a while to arrive.
Sorry, you need to Log In to post a reply to this thread.