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
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
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]
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 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
--
[ 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
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
7 matches
Mail list logo