255 is maybe a reasonable cap, I dunno. Mainly I'd be most interested in the API exporting whatever values are needed so that the user code can programmatically ensure the DLL_MessageEnd never occurs.
At 2007/03/04 11:52 PM, Yahn Bernier wrote: >The internal buffer's are much larger (~2500 bytes) since they are used >for other possible messages. I'll see about setting the exact sizes so >the GetBytesRemaining would be correct. > >We can see about raising the limit on UserMessage sizes at the same >time. Still, the splitting thing you mentioned is a good workaround for >very large payloads. > >The limit is enforced on the server, so I think you'll get all 255 for >payload. The bf_read sounds like it has been pre-parsed up to the start >of the payload. > >I'll check this out in the next few days since I've been messing around >with the public code a bit. > >Yahn > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >[EMAIL PROTECTED] >Sent: Sunday, March 04, 2007 12:14 PM >To: [email protected]; [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 > >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 > > >_______________________________________________ >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
