Why the 255 character limit on chat strings?

Question:
I'm wondering why we cannot send more then 255 characters in llSay/llWhisper/llShout on a non-zero channel. I mean, if you can send more using llMessageLinked, why the limit on the chat functions?

Attempted answer:
I talked to Andrew Linden about it in world. He told me that the limit is an arbitrary one set by Cory. He said he didn't know exactly why Cory set it to that value, but it could've been to make sure script chat doesnt influence simulator performance too much.

Suggestion:
I think the limit should be expanded, perhaps to 1024 characters. A sleep time perportional to the amount of characters sent in the say could also be implemented to offset the performance hit of sending a large string.

==Chris

Because it piggybacks off the regular chat system. It's probably a combination of things.

For one, the char* buffer that's used is probably coded to 256 chars.

I imagine it's set so small to prevent some jackhole from entertaining him/herself by crashing an event and sending a whole bunch of 1023-char garbage strings. Using the chat system for something other than chatting was probably an afterthought that came about long after the arbitrary number was already set.

I'll take this opportunity to point out that if object<->object e-mail were stable and fast, or if XML-RPC were fully implemented, it would be a non-issue.

I can see the problem with the char buffer, but isn't this backwards? Since the script chat system is so complex (0 to 2 million, -2million to 0 channels) wouldn't the regular chat system piggyback on *that*?

I can see why they limit chat on channel 0, but why do it on the other non-zero channels?



Yes. (only that they limited llRemoteDataReply to 255 chars too )

I have to agree; longer chat strings would be great. If it's an issue of scripts flooding chat on chan 0 then just keep the limit at 256 on chan 0 for scripts. Raising the limit for AV's and all other chan's.

but it does bring up an interesting issue. For scripts that are close to the memory limit and use listens not bound to commands; could result in script memory overflows.
back in 1.3 if you set a name of an object and then used a say command right after it the name would be the string you set it to and not a truncated form of it; i managed to fit 15k in the name and have scripts listening register the 15k.

If you think about the real difference between a link message and chat is ..... (ready for this? ... really? ...its the source of a lot of the 'problems' in second life....) .... sim borders.

A linked object's position is essentially the parent's position (despite disagreements between interfaces and llRezObject) so a linked message is always within the same sim. However chat has a very high likely hood (especially if you are shouting) of crossing between 1 and 3 sim borders. It is my understanding that the limitation is tied to how messages are passed from one simulator to another. It seems very likely (standard OOP practice) that a standard messaging protocol is used to send all information between simulators and that it is a limitation in this code that is the reason for the 255 char limit.

Does anyone else find it extremely bizarre that something as simple as a few lines of plain text can have such an impact on a server's performance?
What on earth is their architecture like, that they have to worry about a few lines of plain text?
God forbid someone ask LL to implement an IRC server. It would probably require a 4-way SMP box to run properly

Is the back end written in Java?

I know why listens lag the server. It's the math of calculating chat distances.

Just checking for if an object is in range of chat is lagging the sim. This is why there are 3 chat lengths. 8m, 32m and 96m (not sure about the exact distance for whisper) So chat is marked with a flag saying how far it can go.
For each listen you take it's pos and the chat center and subtract them. Then you take the vector magnitude and check it agains the flag. The trouble is taking the vector magnitude is going to be CPU intensive. Optimizations into calculating the chat distances are probably why sims will always be 256x256 meters.

Some Linden insight into how the chat system works would be very nice

I'd like to take a moment to correct myself here. Not only is llRemoteDataReply limited to sending a 255 char string, but (currently) *any* string sent to the script in a REMOTE_DATA_REQUEST is truncated to 255 chatacters.

Why is this? It isnt a limitation of the protocol, I do know that.

==Chris

Since when is a mere 30 or so vector operations considered heavy duty computation?
Considering the tiny amount of avs can fit in a sim, checking if one can hear it or not involves very little processing.
Besides, there are better ways to implement chat than the naive approach you are suggesting is used on the servers.


When did they change that? Last I heard, whispers go up to 10m, chat is 20(used to be 50 though), shouts are 100.

they havne't changed it by i've never looked at the exact numbers so i guessed
bad me. and i like powers of 2.

but considering you would have to 1 square root and 3 multiplications and 3 subtractions as floating point operations (unless your lazy and used integer aproximations) per listener per chat operation it would add up. not to mention an integer comparison for channel. Of course the fact that listeners running in a silent sim lag the sim suggests something totaly different -_-'

ah well doesn't matter; we only have to compain about it not fix it.

You can get rid of the square root by squaring the other side of the equation, so the distance comparison could be

if((x*x + y*y + z*z) > 10000) then deliver_shout();

instead of

if(sqrt(x*x + y*y + z*z) > 100) then deliver_sout();

Neat trick

Carnildo wrote:

> You can get rid of the square root by squaring the other side of the equation, so the distance comparison could be

Oooo, nice! Thats good timing, cos I implemented the chat system in a project I'm working on yesterday, and was wondering what optimizations could be possible.

Azelda