Thanks - can that internal value be exported somehow? bf_write::GetNumBitsLeft() doesn't seem to know about it, for instance, and thinks the limit is much higher.
The first 3 bytes of bf_read::m_pData always contain some seemingly somewhat random bytes of data, although if I recall correctly the first two were always 0x17 and 0x03 or something like that. bf_read::Read*() ignore those first few bytes because the m_iCurBit data member always starts out just past those bytes at 24 or so, so the API functions correctly from that perspective. It's just a concern that that extra data might steal at random from the 255 limit. At 2007/03/04 02:03 PM, Yahn Bernier wrote: >The internal #define is 255 characters. >Not sure what the 3 bytes of overhead is. Are you saying that when you >parse a message out of the bf_read, you have to discard the first three >bytes, or that the payload is only 252 bytes or less? > >Yahn > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >[EMAIL PROTECTED] >Sent: Sunday, March 04, 2007 10:33 AM >To: [email protected] >Subject: Re: [hlcoders] DLL_MessageEnd: Refusing to send user message %s >of %d bytes to client, user message size limit is 255 bytes > >I worked around this issue by implementing a queue system which sends a >max of X bytes in each user message per server frame, along with client >functionality to collect all the tiny messages and reassemble the >original larger message. > >There also seems to be 3 bytes of overhead at the beginning of bf_read >data buffer. So seemingly the max size available to the user is 252, >not 255? Those 3 bytes are unreferenced in the SDK as far as I can >tell, and seem to be internal to the closed-source size of things. > >I chose "200" for X to be safe since the 255 limit is seemingly >undocumented, and the scary extra bytes at the beginning might possibly >change at any time. It'd be nice if someone (Valve?) would confirm what >the max value really is, and/or what constant to use for the max size. > > >At 2007/03/03 11:54 PM, you wrote: >>Well in this particular case I am sending an arbitrarily-sized list of >RPG character related data to the user. Any fixed limit would be >undesirable. A larger limit (4K) would be acceptable, since, in >practice the maximum amount of data is probably about 1K. >> >>As I understand it, the string tables are sent to all clients. I don't >want to spam every client with this data, since it's only useful to the >client that it's directed at. >> >>At 2007/03/03 11:31 PM, LDuke wrote: >>>-- >>>[ Picked text/plain from multipart/alternative ] What kind of user >>>message is this? >>> >>>The MOTD messages are limited to 255 bytes for TYPE_TEXT. To use more >>>than that, you have to add the text to be displayed to the string >>>tables and use TYPE_INDEX (this method has a limit of around 4kb). >>> >>>On 3/3/07, [EMAIL PROTECTED] >>><[EMAIL PROTECTED]> >>>wrote: >>>> >>>> Whenever an attempt is made to send anything but the very smallest >>>> of user messages, the following error occurs: >>>> >>>> DLL_MessageEnd: Refusing to send user message %s of %d bytes to >>>> client, user message size limit is 255 bytes >>>> >>>> It doesn't have anything to do with the usermessages->Register >>>> specified limit. It also seems completely unrelated to the value >>>> the bf_write::GetNumBytesLeft reports, which is typically in the >>>> 2600 range or so. So the question is, where is this number coming >>>> from, and can it be increased? >>>> >>>> _______________________________________________ >>>> 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
