Proposed change to llSay

llSay, llWhisper and llShout currently generate a script error if the text sent to them exceeds the max chat length of 255 bytes. I'd like to change that behavior to instead truncate the text to 255 bytes and to then say that text. Any objections?

No, I prefer that my script crashes.

Just kidding. Works for me.

... just before I devour Cory's brainpan.

I love this idea. Go with it. Er, the feature implementing, that is. [Though eating brainpans doesn't sound too shabby either...]

I make occassional sentance-fragment-combining scripts. Knowing that instances of 256+ character randomizes will NOT crash it is Happy News.

Unlike other recent behavior changes to some LSL functions, this won't break any existing scripts, and might even fix a few.

Go for it...

- Ace

I like.

HOWEVER, please PLEASE somehow alert the coder, user, or someone that this is occuring? Maybe make the alert a llSetStatus feature or something? Either by channel 0 warnings or IMs or something?

I Agree with Mole! Please alert the owner that this is hapenning! an IM might work best to stop chat spam.
Simply truncating the string with no warning would definately cause me some issues with a few games I'm working on.

Yes a llSetStatus flag would be a good idea (for showing warnings)

I don't see a good reason not to implement this. Makes life simple. Would there be a way for the script to catch the warning as well? Maybe an event? Or make llSay() return an integer equal to the number of letters it chopped off.

then you could right something like to dump entire strings with little hastle.

Say(integer chan, string msg)
{
    integer b=llSay(chan,msg);
    while (b)
        b=llSay(chan,msg=llGetString(msg,-b,-1));
}

I think the ability to turn warnings on in general would be neat, but not necessary in this instance. Nor do I think it's necessary to change the return type of llSay (knowing nothing about the LSL bytecode, I boldly predict that this would break all already compiled scripts that use llSay).

If you have the possibility of your messages going over 255 characters, it's easy to break up the message.

llShowWarnings(TRUE) ? I'd go with it.

Other then that, the llSay sounds good. Go gadget go.

If a function like llSay() were to return an error, it might really be nice to see a line number of the offending command.

I agree with Wednesday (I think). Truncate llSay silently. Add a warning feature to Possible Future Enhancements. I'm fine with having cookies and eating them, I dont need chocolate gateau

Azelda

integer stringlength = llStringLength(message);
llSay(0, message);

Adding error catching code should be your imperetive when designing your code. llSay does not need error catching code when so simple a debug is readily available. I'm all for having it truncate silently.

heck even this snippet of code solves the problem without patching it:

integer stringlength = llStringLength(message);
if(stringlength>255)
{
    message = llDeleteSubString(message,255, (stringlength - 1));
    llSay(0, "message too long, truncated");
}
llSay(0, message);
 

if you think some text might get too long and you just want to cut it off before it errors.

llSay(0, llGetSubString(message_text, 0, 254));

this will just cut it off if it is over 255 characters, otherwise nothing changes. doesn't require an if, doesn't add to your mem overhead much, and doesn't even require extra lines.

edited:

oh ya, if you lindens want to just integrate that functionality into the llSay,Shout,Whisper stuff, that's good. I'm for it.

Yes please, this is a great way to do it.

As some of you correctly guessed, changing the return type is a problem. Also, as has been posted elsewhere, we're really focused on bug fixes only right now, so I'm going to truncate llSays and put better warning controls on to the future enhancement page.

Sounds good to me. Better to have the SL servers ignore script errors since we have no way to handle or recover from such errors, so I'd say ignore all errors until we get error handling. In the case of llSay, just truncate it. If you exceed the number of characters, tough nuggies.

Much of the problem with warning messages associated with a function performing some kind of corrective action is unless a way is built in, we have no way of turning the warning off. This is why I earlier suggested writing your own warning code as part of debugging. Once you have your programming functioning in a set pattern, you no longer need any warnings and can remove the code.

SHHHH
the more work that is automaticly done by the server will speed things up with minimal loss for us. So if they want to make our lives easy for us that just fine with me


consequently could we get float-integer union commands?
it's such a hastle to build them on our end ^_^'

well I'm saying that it's temporary work... you don't NEED to do it in your script at all once you have it working right... I mean, do you really leave your debug messages up and running in scripts you sell? I don't. I would think any extra load on the server would be exactly that, an extra load. One which is unwarranted.

IMHO coping only 255 characters is easier then stopping a script.

depends on the script and if i give them rights. I usualy strip most debugging comments and comment out most debugging. So it's hit or miss on how many comments are in the code. Only the biggest projects usualy have comments left in them. Small projects like here just don't really need them. They do require instuctions for setup (that would be best placed in a notecard).

but ehhh, doesn't really matter. A status flag would be great for doing this.

How about truncating to 254 characters and adding an ellipsis on the end? That would indicate to the scripter that the output has been truncated, without requiring major changes to anything.

Absent error handling, it's not a bad idea. It would be good to have it say() a warning rather than silently truncating the string. Having the script crash because of a chat overrun is definitely not so great.

wait a second, changing a return type is a problem... ADDING a return type shouldn't be. Since llSay, llShout, llWhisper currently return nothing, having them return an int won't break scripts. Look at llListen, it returns and int, and a lot of people ignore that return value . You don't have to pay attention to the return value, therefore, won't break anything. Also llGetNotecardLine returns a key, which you can ignore...

llGetNotecardLine(...);

works as well as...

key query;
query = llGetNotecardLine(...);

Guys, the LSL way of raising exceptions is to trigger an event.

By all means issue a warning before destroying data, that's very sound engineering. But send the warning in an event (which everyone except us programming nutters can ignore), and then we can do useful stuff with it if we wish, and do it rapidly without needing to poll any silly status flags (which have to be reset, yay). That's old technology.

Events are efficient. That's good for everyone.

In a normal system an error event would be an interrupt.
The problem with raising an event is that it would be added to the end of the event que. So it would be practically impossible to catch the error and make a custom handler for it.

Just having the chat commands return the number of characters they chopped off is the easiest solution for all parties involved. Again i will say a status flag would be well worth it to enable/disable any runtime warnings.