Talk:LlSubStringIndex

startswith, endswith

Me or someone should return to contribute correct-at-a-glance versions of the snippets that mean:

startswith(whole, part) -- returns true if whole starts with part, else returns false

endswith(whole, part) -- returns true if whole ends with part, else returns false

cf. http://docs.python.org/lib/string-methods.html

-- Ppaatt Lynagh 15 October 2007 (PDT)

Soooo cool. Someone else did jump in to contribute! Now naturally I look forward to me or someone implementing startswith like we've implemented endswith, and then comparing the space & time costs of the two startswith implementation choices. -- Ppaatt Lynagh 16:21, 16 October 2007 (PDT)

RegEx

Any chance of RegEx in the future?
Cron Stardust 23:32, 7 March 2007 (PST)

I would say, highly unlikely. It would break existing functionality. Best to request an entirely new function. Strife Onizuka 04:39, 8 March 2007 (PST)

In what way is llSubStringIndex not RegEx? -- Eddy ^{(talk|contribs)} 06:15, 10 August 2009 (UTC)

It only looks for complete matches of the search string. You don't have the opportunity to pass wildcards for certain words/characters or something like that. Like the first appearence of "I <WILDECARD> you" in a given string. RegEx are way more powerful than what llSubStringIndex provides. -- ^{(talk|contribs)} 10:45, 10 August 2009 (UTC)

Right? So you can search for what is in a string at a place defined by the kind of things you would expect around it rather than where in a string a CERTAIN thing is (or is not). That would save a lot of messing about. Thanx for the explanation Zai. I would have thanked you sooner but the wiki is playing up for me. Pages are not (resolving?) booting up. -- Eddy ^{(talk|contribs)} 11:19, 10 August 2009 (UTC)

But with RegEx it's a bit more complicated. With llSubStringIndex you can check the existence of a given search phrase. This is similar with the PHP function strpos.

Basic Example from the function page:

<lsl>

integer index = llSubStringIndex("string data","TEST"); if(index == -1) {

   llSay(0,"TEST was not found in the string");

} else {

   llSay(0,"TEST was found in the string.");

} </lsl> With regular expressions, i think, it's similar to the basic usage of preg_match, where you can search for real patterns.
senseless example:
We have a script that asks for your name and we know user-names can only have Latin alphabetical chars and numbers.

<php>

1. desc: preg_match(string $pattern, string $subject)
2. Searches subject for a match to the regular expression given in pattern.

1. [A-Za-z0-9] say it can have all chars from A to Z and a to z besides numbers from 0 to 9
2. the + behind is a special char (metacharacter) and say a character from [A-Za-z0-9] must occur once or more times.
3. the \s stands for a whitespace

if(preg_match("~[A-Za-z0-9]+\s[A-Za-z0-9]+~", "Kuraiko Yoshikawa")); # TRUE if(preg_match("~[A-Za-z0-9]+\s[A-Za-z0-9]+~", "Kuraiko Yo$hikawa?")); # FALSE </php>

In PHP, pregmatch can also return an array with the matches, so you have a "list" with all matched phrases. I guess this isn't realistic for LSL.
When LSL gets RegEx, we also need functions like preg_replace and preg_split on our wishlist ;).
Kuraiko Yoshikawa 13:26, 10 August 2009 (UTC)

*nods* oooh! pretty colors -- Eddy ^{(talk|contribs)} 13:43, 10 August 2009 (UTC)

Lindens

As far as I know, sensor()s can't find Lindens. I had a Linden confirm it when I was trying to set him up as a guest driver on one of my boats. Maybe the example should be changed so it's not misleading? I'm gonna go make sure the sensor() page mentions that. Stickman 18:23, 14 August 2008 (PDT)

According to Soft Linden you can sense Lindens regardless of administrative status ("God Mode" or Not) if they are in an adjacent region and in sensor range. -- Eddy ^{(talk|contribs)} 06:23, 10 August 2009 (UTC)

I didn't clean up that caveat because I didn't want to draw more attention to the intentional loophole. -- Strife ^{(talk|contribs)} 02:28, 11 August 2009 (UTC)

You want to remove the last 3 entries (Including this one)? -- Eddy ^{(talk|contribs)} 05:36, 11 August 2009 (UTC)

no point, very few people ever read the talk pages except editors, and I'm going to assume most of us were already aware of it via Soft's answering of the question and leaving it there.
-- Void ^{(talk|contribs)} 15:21, 11 August 2009 (UTC)

Hi Void. I agree. Not something that can really be hidden (just like Lindens! lolz). And it is a shame that such an amazing resource (this wiki) isn't more fully plugged in world. I only found it by wondering what "Help" I would get by clicking Help>Scripting Portal... Considering the wealth of knowledge and expertise found betwixt these walls (hypothetical walls) I'd've thought it best to advertise its existence far more widely. *shrugs* -- Eddy ^{(talk|contribs)} 16:30, 11 August 2009 (UTC)

"Fixed" bug in starts/endswith implementation

When haystack == needle these tools failed: the llDeleteSubString would return an empty string. I've "fixed" the problem by tacking on a blank space, but I'm pretty sure there are more optimal ways to do so - string concat can be expensive. Got any ideas? Cron Stardust 20:21, 10 March 2013 (PDT)

"startswith" is easily handled by: !llSubStringIndex(haystack, needle) and "endswith" can be achieved via: llGetSubString (haystack, -llStringLength(needle), -1) == needle). In practice one would not code a UDF for "startswith" and probably not for "endswith" either. And certainly not for "contains", they should be coded in-line. I don't subscribe to the argument that null needles should be handled. In the very rare event that I needed to handle such, I would add an initial test for the null needle. There would probably wider reaching consequences that needed to be tackled. Omei Qunhua 03:55, 11 March 2013 (PDT)