Okay. Maybe Mike will code up a SendPropBinaryBlob for you guys to mess around with. And possibly a SendPropVariableLengthBinaryBlob.
Yahn -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, November 20, 2007 9:33 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] SendProxy_String_tToString can't send wide-char string data I can see how from that perspective it would have been thought that there'd be no need for sending wchar data across. That's a good explanation. Of course in my case what I'm sending isn't really localized string data, I just used wchar as a description because it has lots of embedded 0s in it. As I mentioned previously, in reality it's an array of 1000+ integers. Like I said though, it's possible to work around this limitation with base-128 trickery, so it's not a big deal. At 2007/11/18 07:00 PM, Yahn Bernier wrote: >Again, the sending of a binary blob is discouraged, and instead, it's >better to go with the EMBEDDED stuff and define the subfields using the >known SendProp* primitives. In general, we don't support arbitrary >sizes for sending stuff. You could always use a usermessage for that if >you can't refactor it to use the existing architecture. > >Yahn > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of OvermindDL1 >Sent: Saturday, November 17, 2007 11:34 PM >To: hlcoders@list.valvesoftware.com >Subject: Re: [hlcoders] SendProxy_String_tToString can't send wide-char >string data > >Isn't there a way to just send your own pre-built binary stream and >have it received and deserialized manually in your classes? > >On 11/17/07, Yahn Bernier <[EMAIL PROTECTED]> wrote: >> We haven't added this to the server side since the preferred method is >> to network the internal string (or better yet, an index, etc.) and use >> it as a look up (vgui::localize()->Find) in the xxx_language.txt files >> since each connected client can be using a different language. >> >> Yahn >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> [EMAIL PROTECTED] >> Sent: Saturday, November 17, 2007 10:41 AM >> To: hlcoders@list.valvesoftware.com >> Subject: Re: [hlcoders] SendProxy_String_tToString can't send >wide-char >> string data >> >> Unfortunately using the array of items is not possible here. As noted >> on http://developer.valvesoftware.com/wiki/Networking_Entities a >single >> array of X items count X times towards the 1024 limit on the number of >> variables associated with a single entity. So if you wanted to send a >> manual array string of size 1025, it won't work. >> >> As far as base-128 goes - if you look at the code snippet I pasted >> previously you may notice I cheated slightly because I'm sending data >in >> groups of 16bits, so I lose very few permutations. So actually it's >not >> really base-128, but base-128 would be the simplest way to explain it. >> >> Oh well, it's possible to work around in client-code, but it's >> surprising with all the internationalization garbage in the SDK that >> they don't support this. >> >> >> At 2007/11/12 05:14 PM, OvermindDL1 wrote: >> >Well since no one else seemed to bother looking (and I actually got >> >some time to look), the only thing the above function does is just >> >fill in the passed in variant setting it as a string. Looking at the >> >varient it supports an array of a base type (such as wchar/Int16, >like >> >you would use). Will have to do the serialization manually (but that >> >will be what... less then 10 lines of code for what you are doing, >> >just put it into your own function to encapsulate it), but if the >> >array in the variant works (I do not see many places it is used) then >> >it would be perfect. Honostly though, SendProxy_String_tToString >> >seems like a rather weird function to use, I only see it defined in >> >one place and only used in that class's prop definition. >> > >> >Still that is a hack, it seems like it would be far *far* better to >> >juse serialize it fully and hand it off manually (as a binary stream, >> >usual term being a binary blob) instead of using a variant, that way >> >you could set up string compression, string tables, etc... etc... for >> >effective and easy network bandwidth reduction. There would be no >> >sendblob function as you just give it a char array with a length to >> >let it send across the network. Also, you should not need a base-128 >> >converter, but rather a base-255 converter would be best if you >wanted >> >to continue doing it your method. >> > >> > >> >On 11/11/07, [EMAIL PROTECTED] >> ><[EMAIL PROTECTED]> wrote: >> >> Well there is no SendBlob sort of function anywhere in the dt_send >> and various other networking files. It's not a huge deal, I just had >to >> write my own base-128 encoder, so that there wouldn't be any 0s in the >> data that went over the wire. It just seems that Valve would want to >> support this natively. >> >> >> >> At 2007/11/10 10:53 PM, OvermindDL1 wrote: >> >> >Could just send it as a binary blob and not as a string (pretend >it >> is >> >> >opaque binary data, and not a string, use binary functions, not >> string >> >> >functions). >> >> > >> >> >On 11/10/07, [EMAIL PROTECTED] >> >> ><[EMAIL PROTECTED]> wrote: >> >> >> Well it would be nice if there were a version of string >networking >> that was binary-safe. >> >> >> >> >> >> At 2006/09/03 08:33 PM, Aaron Schiff wrote: >> >> >> >-- >> >> >> >[ Picked text/plain from multipart/alternative ] >> >> >> >You could use a networked string table as well as the index of >> the string in >> >> >> >the entity network table. Then you can specify the string >length >> in >> >> >> >AddString for the user data. >> >> >> > >> >> >> >On 9/3/06, [EMAIL PROTECTED] >> <[EMAIL PROTECTED]> >> >> >> >wrote: >> >> >> >> >> >> >> >> I thought there was a forum or mailing list thread on this >once >> before but >> >> >> >> I can't find it. Basically it seems that the close-source >side >> of the >> >> >> >> networking does a 0x00-truncated data copy. So you can't >send >> strings along >> >> >> >> the wire that contain a 0x00 byte in them, such as wide-char >> strings etc. >> >> >> >> >> >> >> >> Anyone know of a work-around? (Short of encoding the >base64ing >> the >> >> >> >> strings or something like that.) >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> To unsubscribe, edit your list preferences, or view the list >> archives, >> >> >> >> please visit: >> >> >> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> >-- >> >> >> >ts2do >> >> >> >-- >> >> >> > >> >> >> >_______________________________________________ >> >> >> >To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> >> >> >http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> >> >> >> _______________________________________________ >> >> >> To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> >> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> >> >> >> >> >> > >> >> >_______________________________________________ >> >> >To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> >> >http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> >> _______________________________________________ >> >> To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> >> >> > >> >_______________________________________________ >> >To unsubscribe, edit your list preferences, or view the list >archives, >> please visit: >> >http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > >_______________________________________________ >To unsubscribe, edit your list preferences, or view the list archives, >please visit: >http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >_______________________________________________ >To unsubscribe, edit your list preferences, or view the list archives, please visit: >http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
