Scripters, watch out in new version

Looking at it just as a scripting problem, I like DoteDote's idea. What if in the main script, the touch event used llSetScriptState("listen script", TRUE). The "listen script" has the listen or multiple listens in state_entry. The listen event recieves the message and chops it as shown, sends the llMessageLinked. Main script lnk_message recieves message, llSetScriptState("listen script", FALSE) & processes message as usual?

Looking at it just as a scripting problem, I like DoteDote's suggestion. Changed it around some and came up with this:

default
{
    touch_start(integer n) {
        llOwnerSay("Type something and I will say it");
		llSetScriptState("listen script", TRUE);
    }
    link_message(integer sender_num, integer num, string str, key id){
        llOwnerSay(str);
    }
}

integer msg_length = 255;


default{
	state_entry(){
		llListen(0, "", llGetOwner(), "");
	}
	listen(integer chan, string name, key id, string msg){
		msg = llGetSubString(msg, 0, msg_length); 
		llMessageLinked(LINK_ROOT, 0, id, msg);
                                msg = "";
		llSetScriptState("listen script", FALSE);
	}
}

Nice, simple and works fine:
[6:46] You: Mary had a little lamb and it's fleece was white as snow. Everywhere that Mary went, the lamb was sure to go. Mary had a little lamb and it's fleece was white as snow. Everywhere that Mary went, the lamb was sure to go. Mary had a little lamb and it's fleece was white as snow. Every here that Mary went, the lamb was sure to go. Mary had a little lamb and it's fleece was white as snow. Everywhere that Mary went, the lamb was sure to go.
[6:46] Object: truncated message = Mary had a little lamb and it's fleece was white as snow. Everywhere that Mary went, the lamb was sure to go. Mary had a little lamb and it's fleece was white as snow. Everywhere that Mary went, the lamb was sure to go. Mary had a little lamb and it's fl

1.) I see the crippling of message relay/broadcast systems and journal recorders as at least as big an issue as security holes that can merely cause scripts to crash (crashes aren't as serious as, say, a hole that allows someone to be debited L$ erroneously...).

2.) Actually, each character takes up 2 bytes. So you have to have at least 2 kB free to handle a full length chat now, and you could store a maximum of about 8 of them. Bad news for #1, above.

3.) There are plenty of cases where filtering on listens cannot be very specific. For example, scripts are often written to be able to accept commands extensibly from attachments or plugin object/scripts. If we could filter based upon the OWNER or GROUP of an object, rather than just its own key or name, we might be able to filter more specifically, but as it is, plenty of listens need to simply have an open filter. If you haven't encountered situations like this, you will. Trust me.

Or the cases where an object has to be able to react to anyone around. You make it touch based and set up individual listeners, but the script could run out of listens if several people are around, all interacting with the object. And I'm not sure if opening one listener per interacting user is good design either.

In this case, the simpler (and probably more elegant) solution is an unfiltered listener on a fixed channel. Not much you can do to protect that.

And it's pretty easy to break a script that tries to protect itself by filtering on object name - just create an object, set it to the specified name, and make it say the long string on the channel.

You can still use some sort of pre-filtering here -- have a list of AVs who recently touched the item (keep it trimmed to whatever length is suitable) and only process the input if the name/key is found on this 'registered speakers' list.

That won't protect against "kill the script by saying a long string on the listener's channel", will it? The script will die before executing the listen handler.

You will need enough memory to fit long input in the memory yes, it's more of a protection against trying to parse it then in whatever way.

Agreed. I guess we're saying the same thing Validating the input once you're in the listen handler is, of course, a good idea. I was commenting on some of the suggestions above for ways to have the listen event fire for trusted input only, and pointing out a scenario where it would be cumbersome (if not impossible) to do that.

If you make a separate script to parse your listens, even if you don't truncate, you'll have plenty of memory to do whatever you want with it, including parsing a list from a grief string. The part that sucks is that you have to make this separate script to begin with. But I shouldn't be complaining any more than I already am, you already have to break things into many numbers of scripts for any serious project.

That's a good point. And I recently added a similar split to one of my projects. Though it looks funny to have a 50 line listener script driving a 700 line worker script

ugh Didn't anyone actually look at posts #24 and #26?????????????

Guess not

heehee. Guess next time I should repeat "Can't see the forest, for all the trees" over and over again instead of "Mary had a little lamb....."

But sometimes the simple solutions end up being the most elegant.



What would be really interesting is seeing if dividing it up like this may actually be faster?
Don't know. I'll probably try it sometime just to see.

*shrug* In my case, it's a product with a ton of options/commands. So the processing just moved from a listen handler to a link message handler, and the listen script does some basic validation and then passes the command on to the other script. So, in my case... I doubt it. I split it mostly because I needed two levels of timers, and the thought of adding counters to that script crossed my ugly-code threshold.

If you need extra timers you can use llSensorRepeat() simultaneously with llSetTimerEvent().

Lol!!!