Add an alternative to 'llGetLinkNumber' that allows you to specificy a link name as an argument.
tracked
Kinda Vile
Hard coding link numbers into scripts is usually bad practice. So it's often best to search for something more concrete like the name of a linked prim and assign it to an integer using a loop by using llGetLinkName and comparing it to the link name you want to find. This isn't very friendly to new scripters who want to work with linked prims.
A function that checks all of the prims in a linkset and finds the first instance of a specified link name would make scripts like this much easier.
If I wanted to find the first instance of 'door left' in a linkset this could look like; llFindLinkNumber("door left");
Log In
Bleuhazenfurfle Resident
This is certainly a QoL idea… I generally just watch for CHANGED_LINK, and run a function (also at state_entry) that scans the link set once, taking note of any links that I know I'll be wanting to find later.
It does eat a bit of script memory, though, especially for objects with many child prims, or when you have several scripts all needing to keep track of the same many prims — so for that reason alone, this would indeed be a useful feature.
Inoue Katsu
A lot of link change scripts deal with multiple prims that have the same name so returning a list would be best IMO. If you only want the first one or know that there will be only 1 result you can always do llList2Integer(llNewFunction("PrimName"),0) instead of going for a loop.
The 'only return first' might be a bit too niche and prone to scripting headaches when the link set changes.
I also like the wildcard idea but lsl doesn't really do wildcards .. at all.
Bleuhazenfurfle Resident
Inoue Katsu: Ahhh, wildcards… I have a request floating around for pretty much every new search-adjacent command to get a simple integer argument accepting the type of match to perform; exact, regex, prefix/postfix/inner, case insensitivity (could also add anti-matching), reverse matching (maybe not for regex), and as a bonus option, wildcard (glob) matching — and even better, if implemented as intended, adding new search options adds it to EVERY command supporting it simultaneously — because we already have THREE different search methods being requested (exact, wildcard, and regex — noting that regex is horrible if you want to allow your users to specify part of the name to search for, not to mention a whole new language on it's own).
It was actually accepted initially (back in the jira days), then someone apparently decided "nah", when I re-raised on here it a bit back.
Maestro Linden
tracked
WolfGang Senizen
About a third of the time I use a pool of prims with name x
So maybe 2 functions, something like
integer llGetFirstLinkNumberByName(string name_regex);
list llGetLinkNumbersByName(string name_regex);
The methods could maybe be made more generic, and take more parameters to allow testing for properties other than name...
SamanthaTekcat Resident
Instead of having it return an integer, why not a list of all matching link numbers?
dantia Gothly
SamanthaTekcat Resident Because Loops are slow, having it return a direct value would be faster.
SL Feedback
Merged in a post from dantia Gothly:
Title: New LSL integer llGetLinkIndex(string Link_Name);
Details: Please add this function into LSL.
Currently, performing tasks that rely on link names in a linkset requires iterating through the entire set. This is less than ideal, as link numbers in a linkset are prone to change during edits, making hard-coded link indices unreliable.
To address this, we propose a function that retrieves the integer index of a child link based on its name with a single call. This would significantly reduce the need for iterative loops, streamlining common operations.
In cases where multiple child links share the same name, the function should handle this scenario gracefully by either returning the index of the first matching instance, raising an error, or implementing a mechanism to support both outcomes.
MythElyrynn Starforge
This would change my life in scripting, and also allow for much smoother running and lighter weight scripts, I believe. This would be among the most handy functions I can think of, at current. Especially if I can use link name to pull back the link that is named such and use that information to apply certain things like particle effects, materials, sounds, etc. using the link NAME instead of the number.
This would solve a big issue, as well, regarding how link numbers change drastically when you add or subtract a link from the set. This would help you not have to reset all the link numbers every time you change the link set.
PLEASE do this, LL!