lsl feature request llListenPrefix

[primerib1]

I think we will all appreciate a version of llListen() that matches for prefixes.

Maybe the signature will be:

integer llListenPrefix( integer channel, string name, key id, string prefix, integer flags );

The flags can be made up of a bitfield such as:

PREFIX_CASE_SENSITIVE = 0x1;
PREFIX_NO_AUTOTRIM = 0x2;

So the default, 0x0, means a case insensitive matching done on a trimmed message. Which is kind of what's needed by 80-90% of scripts that needs prefixes.

This reduces the amount of code needed inside the listen() event, as the code now no longer needs to implement the boilerplate code of trimming and casefolding. But at the same time also reduces scripts needing to wake up just to go to sleep again because whatever is said in the channel being listened is "not for them".

What do you think?

Edited December 7, 2022 by primerib1
Formatting, mostly

[primerib1]

Oh we can add one more flag:

PREFIX_NO_AUTOCHOMP = 0x4;

So if autochomp is enabled (flag not specified), the prefix will automatically be removed before the message is given to the listen() event handler. But if the flag is specified, the message will be delivered as is (after the autotrim takes place if not suppressed).

[Wulfie Reanimator]

Can you also give an example use-case where a script will listen to prefixed commands?

[primerib1]

2 hours ago, Wulfie Reanimator said:

Can you also give an example use-case where a script will listen to prefixed commands?

A quick example is OpenCollar.

OpenCollar listens to channel 1, and it needs to accept commands from others ("owners" + "trusted users" + OpenCollar remote), so you can't limit it to listen only for messages from a certain UUID.

If there are multiple OpenCollar wearers in talk distance, all OpenCollar script will need to wake up.

To ensure that the OpenCollar knows which collar the command-giver is trying to access, it prefixes its commands with the first letters of the collar wearer's firstname and lastname. (So if the wearer's name is "Claire Magic", for instance, the prefix will be "cm"). So the full command is "/1cmmenu" which will pop up the OpenCollar menu for the collar worn by Claire Magic.

This means that if there are like 5 OpenCollar wearer within talking distance, 5 scripts will wake up but only 1 will continue processing while the other 4 sleeps again.

This not just limited to OpenCollar, though. A lot of bondage restraints work in the same way. For instance, "DHB Armbinder" listens on channel 22 but needs a prefix; "DHB Pony Head Harness" listens on channel 49 but needs a prefix, and so on.

(And I'm not sure of other collars such as Peanut Collar or Whim Collar, but I think they work in generally the same way.)

If llListenPrefix() is implemented, instead of 5 scripts waking up, only 1 script will wake up. Thus helping reduce the script load of a sim.

So that is the scale out benefit: Lots of scripts can all listen on the same channel, but only 1 wakes up because it sees its prefix.

-----

Another purpose will be items that listen on channel 0 but responds only if someone prefixes their words with a pre-set prefix.

Rather than the script getting awakened for each and every line said on channel 0, it can sleep -- and not load the server -- until a command with the proper prefix is said in channel 0.

(I can't give a solid example off the top of my mind, but I've seen this happens several times... so it's like in sci-fi shows where you need to prefix commands to the computer, "computer, open hailing frequency". Without the "computer," prefix, the computer just won't respond.)

This is the scale up benefit: One script listening on a busy channel, but not loading the server at all until there's a prefixed line.

(As it happens, OpenCollar can also do that, i.e., listening on channel 0. I personally disable that feature.)

-----

(Plus point, of course, is if the "prefix" can be replaced with a full-fledged regex instead. But that might be more difficult to implement properly, so let's just start with a simple autotrimmed & autochomped "prefix").

Edited December 7, 2022 by primerib1

[Quistess Alpha]

~I like it, I assume by "trim" you mean, removing spaces before and after the prefix so that '/1 cm menu' and '/1cmmenu' might both trigger the listener?

You can always file a new feature request, even if getting the SL devs to implement anything they didn't think up is a pretty slim chance: https://jira.secondlife.com/secure/Dashboard.jspa?null

[primerib1]

1 hour ago, Quistess Alpha said:

~I like it, I assume by "trim" you mean, removing spaces before and after the prefix so that '/1 cm menu' and '/1cmmenu' might both trigger the listener?

You can always file a new feature request, even if getting the SL devs to implement anything they didn't think up is a pretty slim chance: https://jira.secondlife.com/secure/Dashboard.jspa?null

Yup, correct.

Okay I'll try making a ticket there. Who knows I'm lucky

Edit: Feature Request filed: https://jira.secondlife.com/browse/BUG-233039

Edited December 7, 2022 by primerib1

[primerib1]

Yay! Ticket accepted!! So happy!!!

[Rolig Loon]

Just for clarification... A JIRA report is "accepted" for review unless it is clearly inappropriate (as in, for example, a report that should have been filed as an Abuse Report).  Once accepted, it sits in the queue until assigned to some LL developer for evaluation and possible work assignment. Once the work is done, it goes through a QA process before being approved for release.  Each of those steps takes an unknown amount of time, depending on how high a priority it is given, and may also involve periods of review outside of QA.

[primerib1]

2 hours ago, Rolig Loon said:

Just for clarification... A JIRA report is "accepted" for review unless it is clearly inappropriate (as in, for example, a report that should have been filed as an Abuse Report).  Once accepted, it sits in the queue until assigned to some LL developer for evaluation and possible work assignment. Once the work is done, it goes through a QA process before being approved for release.  Each of those steps takes an unknown amount of time, depending on how high a priority it is given, and may also involve periods of review outside of QA.

At least the first hurdle has been overcome and it's not rejected outright 😊