Two Questions For The Gurus (plural? Guru, Gurees, Galkjdfw?)

Okay, two questions guys. First, in my effort to reduce any lag caused by my scripts, I am specifying listen() events to as specific as I can while still having a minimal number. So I'm wondering if there is a way to listen for a message using llToLower(). Say I wanted to listen for the word 'bob' with any capital letters the user chooses to include, I wouldn't want to have llListen(0,"",owner,"BOB", llListen(0,"",owner,"BOb", llListen(0,"",owner,"Bob", and so on. I tried llListen(0,"",owner,llToLower("bob"), not expecting it to work, and it didn't. Any ideas. The way I was doing it before was:

llListen(0,"",owner,"")

//then in a listen event:
string str = llToLower(message);

However, I really want to avoid doing a llListen(0,"",owner,"" for lag reasons.


Okay second question. I asked this before and one of our scripting scriptees or all scripters Jeffery Gomez answered, however I am still not sure ( ). I asked if llGetPos() is affected by physics. Jeff said no, and LSL wiki doesn't even mention it. However, in a script, if you put your mouse over the function, it says that it "gets the position (if the script isn't physical)". Whatsup?

Unfortunately, there isn't any way to filter listens any better than a single string, and case matters.

Just run llListen(channel, "", owner, "" and filter them. Listens aren't so terrible that doing so is going to break much. Seriously, don't be afraid to use them when they're necessary.

I'm not sure what you're using this for, but I'm guessing it's something to do with looking if the owner has said a certain word somewhere in chat, not a specific command? If it IS a command, and you're that worried about lag, would it be possible to use a channel other than 0? Remember that you can also create gestures to intercept chat on your client before it gets sent to the world. I have a number of scripts that I access by typing "/getpos" (for example) and then my client pretends I've typed "/12515 getpos".

As for your second question, llGetPos will return the current position, regardless of physics status. That tooltip is wrong.

Try it for yourself:

default
 {
 	touch_start(integer total_number)
 	{
 		state timeron;
 	}
 }
 
 state timeron
 {
 	state_entry()
 	{
 		llSetTimerEvent(1);
 	}
 	
 	timer()
 	{
 		llOwnerSay((string)llGetPos());
 	}
 	
 	touch_start(integer total_number)
 	{
 		state default;
 	}
 }

EFB sort of ^^^


As far as I know, listening for one key word is just as laggy as having an open listen on channel 0. One listen per channel is always the least laggy, after that its all up to conditionals in the listen event to decide what to do. for instance:

main state
{
   llListen(0, "", llGetOwner(), "");
}

listen(integer channel, string name, key id, string message)
{
   if(channel == 0 && llToLower(message) == "bob")
   {
       do whatever here
   }
}

to further decrease lag you can declare your listen as an "integer" and remove it when necessary. So, in a touch event:

integer i; //global

touch_start(integer total)
{
   i = llListen(blah de blah de blah);
}

then in order to remove it later via voice command or touch or something:
llListenRemove(i)

Actually, a tightly constrained listener, say "llListen(10,"",owner,"bob" will only trigger the listen event when its owner says "bob" on Channel 10.

A looser one, such as "llListen(0,"","",""" will trigger the listen event every time it hears chat, leading to unnecessary work filtering the message in the listen event every time someone or something speaks within range. Listeners have a minimum overhead, but to say that one is as laggy as another is not correct. Only if the listeners never hear anything would that be correct.

Right, though of course, in this example, you wouldn't want to bother with the "channel" check, since there's only one listener on a single channel.

Catherine, for the love of god, don't promote listeners
The other day there was this guy on my sim who had a theater. Every god damned chair had poseballs on them, and they all had active listeners. A tiny parcel with like 100 listeners on it. Jesus.
I've said it before, but I'll say it again. If you're working on a product, and you intend to have any degree of success, you need to realize that your product will be spread all over the grid.
Whatever amount of lag it causes will be multiplied by your success.
Your voice-activated candle with "just one listener" will inevitably end up in some noob's love nest copied 100 times all over the place. Ditto for timers, sensors, etc.
There is such a thing as a responsible use of them, of course. If at all possible, always use touch-activated or sit-activated listeners / sensors.
Don't use sensor repeats or timers with intervals of 0.2 - that's insane.
Voice activated interfaces have been around since beta. We can do better than that. Touch-activated dialogs... prim UIs with link messages... heck, you can even rez and derez the fancy control panel UI from a single prim... Be creative, and code efficiently.
At least until we get Mono and the new script scheduler

I said when necessary!
Yes, listeners should be considered a last resort when communicating, and should contain a toggle. I'm not going to say they don't have their place, just that their place is not in every attachment and poseball you own.

i know listens are laggy and that's the reason I'm doing this. I'm switching as many things that I can to link_message(), however, I know from experience that sending a lot of messagelinked() to one script will not work on the receiving end. Well, thanks for the help all, I'll just have to find a place to message link one more thing, if it's possible .

Oh, just curious, what's more laggy, filtered sensors or listens on non 0 channels?

You can have up to 64 events in the event queue, waiting to be processed. As long as your link_message() event can keep up with that, you should be fine.Whichever recieves the least amount of chat.

Sensors receive chat?
I would say that sensors have the potential to be less laggy than listens, because with listens you can't specify an interval - they're always there.
With sensors, you can sense once every 5, 10, 60 seconds, or even just fire it once.
If you expect to constantly sense multiple times per second, though, they should be even laggier than listens. Sensors always fire an event whether or not they sense something, listens fire only when there's chat.