Function to change/set inventory item names
tracked
Xaviens Mizin
As seen here: https://wiki.secondlife.com/wiki/LlSetInventoryName
llSetInventoryName( string old, string new );
Changes inventory object 'old' to 'new'.
Feature has been requested repeatedly since 2009, it would be useful for data storage, version control, and customization.
Log In
Nelson Jenkins
The only risk I can think of is using this in conjunction with remote script loading to create an object that duplicates a script in its inventory forever, with obvious griefing implications.
The problem is, that's actually the biggest reason I'd use this function, kind of.
I have a prototype computer with a "task manager" that starts and stops scripts that act as programs. The scripts are tracked internally in the filesystem, so the script name is never exposed to the user, it's just shown as an executable "file" with an arbitrary name.
The trouble is, you can only have one copy of each "program", since they are loaded via llRemoteLoadScriptPin off of external media and kept not running unless and until they are "executed".
That introduces two big problems. First is that script name collisions are possible for different third-party programs that just happen to use the same script names. So if two third-party devs design a software package with a script named "foo-exe", there's no way to install both of them to a single computer at the same time. Kinda lame but unique to this use case.
Second, and probably more applicable for most people, is that there's no way to run two distinct copies of a program. For example, the console program starts automatically on boot, but it's possible you might start another program with it, which itself then wants to start the console program. How do you retain the state of the "parent" console but also use the same script to present a separate "child" console? I waste a lot of time and memory doing context switching in the background so that a single script can have multiple virtual "instances" of itself. If I could just keep all the scripts organized dynamically and create multiple running copies as needed - which is only currently not possible because there's no way to rename the scripts - that problem solves itself in a much more intuitive and efficient way.
Anyways, there are other more obvious use cases here, but this function would be a big improvement for me.
Nelson Jenkins
Running into this problem yet again. I'd prefer the requested function, but I'd also accept a version of llRemoteLoadScriptPin with the ability to rename the new copy of the script.
Signal Linden
tracked
Bugs Larnia
We would need to prohibit changing no-mod items and I am trying to think through whether the script should be able to rename itself (that sounds very iffy).
Other than that, I can see use cases for this.
Not sure how much impact this would cause server-side though, since a name change creates a new entry; perhaps after they change the inventory listing to http (https://feedback.secondlife.com/feature-requests/p/move-object-inventory-listing-to-http-capability), this can be performant.
Bleuhazenfurfle Resident
This is another very common wish, and one that we've been scratching our heads trying to figure out why it's not there already. Users and bots can do it. There might be some security reasons to not implement this. I can kind of feel something in the mists of my memories…
But being able to at least undo those counters that get added on name collisions, would be hugely beneficial. (Would also be good if those counters were marked so as to differentiate them from a number at the end of the name. Like being preceded by an otherwise illegal character…)
rhet0rica Resident
Bleuhazenfurfle Resident It's a good question. Personally, I always assumed that object inventories, like avatar inventories, had to be fetched from the inventory server after every update (hence the brutality of refreshing the Content tab) and that people abusing llSetInventoryName() to create configuration files would be really hard on it. (See also: that one time Kitty Barnett made an animated group tag and got reprimanded for hammering the user database.)
Furthering this belief, I've also noticed that inventory refreshes are sometimes
wrong
—dropping an object into a container while it's already refreshing will show you the wrong thing until you switch to editing another object, no matter how many times you refresh it! To me, this smacked strongly of some kind of spaghetti-code UUID-worshipping pseudo-immutable linked-list nightmare that is already nerve-wracking to alter... and woe be upon ye who would attempt to automate such an action in any sort of predictable manner!But if moving object inventories being over UDP really is the only reason that refreshes are so nasty, it's possible that the object inventory system is actually something sane and reasonable, and this missing functionality is just due to LL's attention being elsewhere. Consider that it took almost two decades for us to get native functions for llOrd(), llChar(), and llReplaceSubString(), which would be considered absolutely fundamental in almost any other language, and should probably have been part of the original language spec.