Scripters : Object Name and Description Changes
Friday, February 1st, 2008 at 3:58 PM by: Prospero LindenThere have always been limits on the length of the “Name” and “Description” fields on objects. The name field is limited to 63 characters, and the description field is limited to 127 characters.
With the new 1.19.0 server, these limits are enforced when the fields are set using the llSetObjectDesc() and llSetObjectName() LSL functions. Previously, these functions would let you set longer names and descriptions for objects rezzed in-world. However, the names and descriptions would then be truncated if the object were taken into inventory, or in some cases if you edited the object. A couple of weeks ago, residents identified as having objects with long names or descriptions were contacted through e-mail to let them know that this change was coming.
Similarly, the object name and description can no longer be set to include the pipe (|) character. Previously, this was possible, but once again these characters would be lost if the object were taken into inventory.
We are aware that some scripts have used the name and description fields as a way of storing state information, and that the 1.19.0 server may break some scripts in some circumstances. The reason for the changes in 1.19.0 is to make the behavior consistent and predictable at all times, whether the object is rezzed, in-world, taken into inventory or given away. These changes also fix an exploit where a script could use excessively long object names to overflow the memory of other scripts that listened for chat messages.
February 1st, 2008 at 4:17 PM
Well… that’s good and not so good…
good cos it means stability, but not so good cos there’s no means of writing data to storage properly…
in any programming language, its possible to write to txt, and i would have thought that scripts could write to notecard, but won’t which is silly since it can read…
I would have thought that you would have provided us with some means of writing our data before incapitating our scripts/objects…
So, i’m not pleased… no… not at all.
February 1st, 2008 at 4:20 PM
Though would cause a little trouble in the beginning, but I think that’s worth it. It’s a good step in the long run.
February 1st, 2008 at 4:21 PM
is this how the ‘atms’ of those ‘banks’ got robbed?
February 1st, 2008 at 4:22 PM
they’ve told us before writing notecards creates an asset so they are not going to let scripts create notecards.
February 1st, 2008 at 4:26 PM
I’m happy that the lengths of the fields will be consistent now. The fields were already truncated if someone so much as moused over the object, so I think this will just prevent unexpected problems.
I don’t understand the pipe character thing though.
February 1st, 2008 at 4:32 PM
Giddy looks like you will need to develop your own tiered system to ship data in and out of secondlife. persisting state data to a notecard would be much more efficient, faster, and more reliable provided the asset system is stable.
So you will have to rely on shipping data out to the internet and use your own databases for persisting memory. my recommendation is to use a router type device to queue the messages which are then transmitted to the database gateway object. the database gateway object would handle the http requests.
seems rather complicated when dumping state to a notecard would serve the purposes. however, overloading database columns is not very smart at all and the associated LSL functions should have matched the database column lengths and rules to begin with.
what we really need is a robust metadata design to allow us to define the metadata necessary for objects. such capabilities would provide the ability to grow secondlife into a platform that does more to protect intellectual property. that discussion exceeds the scope of this thread.
guess everyone in sl needs to rent a website that supports php.
sounds rather absurd.
February 1st, 2008 at 4:32 PM
Thats excelent because it represents more stability
Thanks LL
February 1st, 2008 at 4:44 PM
@peter lameth: there’s no need to create a notecard in script. rather, let us put blank ones in and write to existing assets. seem’s like a no freaking brainer
February 1st, 2008 at 4:54 PM
thank you. i just finished to get all my products from my vendor network into the vendors description to have a fair chance against rezzed to buy prim masses in the new search. this is a hard drawback. i hate this stupid decisions made behind the curtains.
February 1st, 2008 at 4:56 PM
wait what?? so instead of just fixing the (|) character, youve made it so it just cant be used? well htats dumb, some scripters use it to seperate Data saved in the description field
February 1st, 2008 at 5:02 PM
This is just broken.
Fix it the right way.
http://jira.secondlife.com/browse/SVC-1406
February 1st, 2008 at 5:03 PM
I get the length stuff - no worries there - but why remove the pipe character?
February 1st, 2008 at 5:04 PM
3 DAYS or rolling restart !!!
How about you get it right now ?
How are we supposed to run our businesses ?
February 1st, 2008 at 5:06 PM
“A couple of weeks ago, residents identified as having objects with long names or descriptions were contacted through e-mail to let them know that this change was coming.”
I did not receive that email. And I’ve spent a LOT of time the last two weeks building products that use the Timeless Linked Door script, which relies on Name and Description for data storage.
Words cannot express how angry I am. It’s understandable that changes must be implemented at times. It is not understandable why you cannot communicate your plans effectively.
February 1st, 2008 at 5:08 PM
Prospero Linden wrote: With the new 1.19.0 server, bla bla bla…
This is the first time I’ve heard about a new server…is this covered somewhere I haven’t seen?
February 1st, 2008 at 5:11 PM
@ Ann Otoole
As long as you have a decent caching system for php (XCache) and actually setup caching in MySQL a site can handle a pretty decent amount of requests per second (of course you would need a good host that doesn’t overload their servers or have a horrible “fair use” policy that shuts down your site).
The most that a page takes to generate on my site is about 170ms (average is ~30ms), which means that that site can handle about 7*(number of php processes) per second or higher. Being able to handle a large number of objects shouldn’t be too hard.
February 1st, 2008 at 5:14 PM
Miles @ 14 : the notifications went out to people who were found to have particularly long names or descriptions. I don’t believe that use of the | character was notified.
Drako @ 10 and Sindy @ 12: the | character was not supposed to be an “allowed” character for names or descriptions, which is why you can’t type it in the client, and why it doesn’t show up in your inventory. The code everywhere else assumes it’s not there. The fix here was the scripted setting of the obejct name and description to make everything consistent. Objects that used and depended on the | character would break if taken into inventory.
Wyald @ 15 : The new server release is what we’ve been working on getting out this week (with, obviously, some fits and starts) with the rolling restart.
Re: storing persistent data : the way the asset sever works, a UUID is a unique identifier to an asset. If you change anything, it has to be a new asset– because if somebody else, say, had the same notecard before it was changed, you don’t want your edits to go to this other person’s notecard. It can happen that different people with the same object in their inventory in fact just point to the same UUID in the asset server. If you were to be able to write to a notecard from the script, *every* write command would create a new asset, which would create a load of additional problems. The best way to store persistent data from a script is indeed on some sort of external storage system. Of course, as long as the script is not restarted or reset, it’s internal state (variables) is kept.
February 1st, 2008 at 5:17 PM
The description field is (was) an excellent storage for saving data, if the scripts failed/crashed/whatever and the variables got lost, data from the description was still there and available to be loaded. It could contain sensitive data as well by putting it after 127 characters.
Did you even think how much use the description field was to many?
Obviously not.
Writing to a notecard would be preferable and it would be easy to create the asset beforehand, just as reading from assets don’t create it out of the blue.
Please, listen to us and implement ability to write to existing notecards or other easy to use in-world data storage BEFORE you remove the ability to use the description field.
The need for reliable and easy data storage is BIG and more widely used than you seem to know.
February 1st, 2008 at 5:19 PM
why don’t disallow scripting. they might change how things should work in you clean and proper visions. or better, charge people who like to script or build. ll, you just need just a view scripters but way more smooth consumers. wait a minute.
February 1st, 2008 at 5:20 PM
@15
http://blog.secondlife.com/2008/01/29/second-life-server-code-upgrade-tue-jan-29/
February 1st, 2008 at 5:26 PM
again.
the thing really is, that the description field with the about 8Kb was very excelent for descriptions of vendors content cause the new search engine index the description field, the products in the vendors got found in the new search engine.
data storage was also a good side effect but is not meant to stay in a description field anyway.
February 1st, 2008 at 5:31 PM
Adding some sort of persistent key:value array storage ability to objects would be nice. Particularly if these values could be optionally made available to user-editing in an extra object tab (ie a scripter-defined ‘prefs’ tab for the object). Save a lot of futzing about with notecards and better UI in many cases.
February 1st, 2008 at 5:33 PM
3 day in a row i’ve been on my land and got a restart region message. This is now becoming a pain in the ass.
I pay a lot of money + “VAT” to be able to use SL.
Every time you restart my land, seems to be when i have guests and visitors over………….. Sort this out now or i may think about spending my money elsewhere
February 1st, 2008 at 5:34 PM
Ok, fair enough, but since we can’t write txt files, could you PLEASE provide some other way to save data so it is not lost every time the sim crashes or the script has to restart? It is really not fair to expect everyone to host a separate data site. If not the description field, perhaps some OTHER prim property, like “persistent prim data” or some such thing.
February 1st, 2008 at 5:36 PM
Huh.. Never noticed pipe wasn’t an allowed character.. Guess I won’t miss it much!
TY for answering, Prospero!
February 1st, 2008 at 5:38 PM
sorry to put this message on here. i wish you would open more blogs for us to comment , that way we may get some real info as to what is going on…
February 1st, 2008 at 5:38 PM
so wait you got rid of (|) umm animation overrider’s use this commonly to separate animations of th same field, and as i see above so did a few others peoples scripts. so since you deleted our pipe what are we sapost to use instead?
February 1st, 2008 at 5:42 PM
OK, as of the last five hours or so, things are not right, suddenly all objects(non phys) that rotate via llTargetOmega fail to respond to changes via command messages until EITHER the object has been selected then released OR your AV TP’s out and in again(this will make the correct function appear) SO the messages are getting to the objects but the translation of movement function is not producing visible(in world) results until AV intervention. This effect can be reproduced regardless of region. Termination of llTargetOmega via message seems to work though and does in fact cease movement. WHAT IS GOING ON?????
Any light on this anyone????
Cheers folx
February 1st, 2008 at 5:56 PM
Seriously, people using pipes… just use CSVs for chissakes.
And as for data in the description, I’ve never trusted that insofar as the way it jolts whenever you so much as touch the object or take it. There’s no persistent data storage, and it’s a nightmare either way.
Let us write to existing notecards. That would solve this issue. No new asset created, merely an asset altered. Or can that only be done “in-world”, and not “in-inventory”? Is there something that could be fundamentally broken if you let us write to notecards? Because I don’t see anything.
February 1st, 2008 at 5:58 PM
I’m not sure what the big deal is about storage space; it’s still going to be there, only now the limits are actually going to be enforced. It’s not like you CAN’T use the name or description. :p
Anyway, we get more storage space with Mono! Woo!
February 1st, 2008 at 6:00 PM
SL offers to let me install RC 1.19.0 but that version’s not listed on the Release Notes page. It also gave 5+ dll errors on installation for mozilla components.
February 1st, 2008 at 6:00 PM
Prospero @ 17:
My Name fields have no “|” characters. They have too many characters, yet, I did not receive the email.
The Timeless Linked Door script uses Name and Description to store the rotation data, and 63 characters is not sufficient for that. (The Description field has sufficient space for its rotation data.) As you probably know, a LOT of people have products that rely on this script.
February 1st, 2008 at 6:18 PM
When I downloaded 1.19.0 It would not let me use, I had to redownlaod 1.18.6 when I downladed that i was told to download 1.19.0 i was in a loop could not use either version
February 1st, 2008 at 6:31 PM
Locke @ 29 : assets are designed to be static. When you have an object in your inventory, the inventory itself doesn’t have the object, but a pointer to something in the asset server. Another person with the identical object in his inventory will have another pointer to the same data on the asset server. As such, you can’t modify things in place. (There are also serious performance and asset store design issues associated with all of this.) Persistent store of data for scripts is something that some geekfolk like myself at Linden are well aware of; indeed, some of us have ourselves used the sleazy trick of sticking persistent data in the object description. It’s not a simple problem, it turns out, so there’s nothing immediately planned to solve it, but we are definitely aware of it.
Those who downloaded 1.19.0 RC client : that wasn’t supposed to be released yet, and was briefly offered because of a glitch. It should no longer be offered anywhere. Watch this space next week to find out if there is any more information forthcoming….
February 1st, 2008 at 6:32 PM
@30 Tyken: in-script storage is volatile, so the increase with Mono doesn’t help here.
@29 Locke: llList2CSV doesn’t work right. http://jira.secondlife.com/browse/SVC-68
Writing to existing notecards or creating new notecards is an irrelevant distinction: they both create new assets. That’s why SVC-1406.
February 1st, 2008 at 6:35 PM
Prospero: external storage is not acceptable, unless you think it’s OK to have thousands of people’s builds break because some guy’s server went offline. Unless Linden Labs were to provide the storage, of course.
February 1st, 2008 at 6:37 PM
It would solve a lot of storage headaches if there were a new container in a prim…. a meta-data storage string– a modest amount say 512 or 1024 chars? Make it so only the scripts native to the prim can read and write it. And a password lock would be nice to prevent rouge access to it. I’ll JIRA this idea…
~HS~
February 1st, 2008 at 6:44 PM
Prospero, it’s entirely feasible to *update* the asset (i.e., create a new one with the old pointer) when the object is “taken” back into inventory. This may not simple from some points of view, but would be triggerred by a dataserver event designed to flush the data written to the notecard back into the asset it pointed to. It would, in fact, be identical to the user opening an existing notecard and changing its content. To throttle scripted overload, make the dataserver event that saves the notecard once written trigger a 2 second sleep. Or, even a 20 second sleep. Since it’s hard data and is, in effect, read only, why not ?
February 1st, 2008 at 6:45 PM
Multi byte character was not able to be used as well as the thing that the pipe character was
not able to be used.
It came to have to encode URL to write it in Description only in ASCII character.
However, the number of bytes triples by encoding URL.
To record only one character, it is necessary by nine characters.
The limitation of 127 bytes is too small.
February 1st, 2008 at 6:46 PM
Oh, and that idea follows onto the idea of not *creating* notecards in a script, but writing to an existing one.
February 1st, 2008 at 6:49 PM
‘Volatile’ seems to be a fuzzy word. The object name and description are just as subject to things going bad as the scripts are, especially if you’re doing things that exceed the normal limits.
February 1st, 2008 at 6:53 PM
@37 Han: SVC-1046
February 1st, 2008 at 6:55 PM
@40 Ryu: That’s the problem: when a use modified an existing notecard, they ACTUALLY create a new one right then.
February 1st, 2008 at 7:01 PM
Miles@32… yup, I’m one of *many* people that have been affected by this change (destruction) of functionality with no notification. I use the Timeless Door script, and it has worked great and flawlessly for a very long time. The doors continue to work in existing products, but if the script is reset… the door’s open / closed positioning information gets truncated. Grrrrr.
February 1st, 2008 at 7:07 PM
Well, the name and description field can be used for data storage, but anyone who has builds using the Timeless Prototype linked door script is hosed. The data fields are 100 characters long. I have quite a few houses out that use that script. Guess I have some re-writing to do.
Once again, LL to Resident communication falls to the wayside. If this was a planned “fix” in 1.19, and it appears to be since “emails were sent out” why the hell wasn’t something said here in the blog??
While most of the builders who use this tool were given a surprise in this post, I bet dollars to donuts Electric Sheep knew about it.
One more time I truly wonder about who LL thinks about when things are done to code for Our World, Our Imagination. Bots still buy land as fast as anything comes available, a few select builders get referred to when LL is contacted, and things that effect all of us trickle down the comm pipe like bio diesel in Maine.
We ask for a way to store data, we get voice. We ask for good communications, we get fancy skys.
While I look forward to the Havoc upgrade and Mono coming on the scene, I wonder, how much of this place will it break, and what will that impact be on those of us who create content for SL, but are not in the graces of LL as ESC is.
Oh well, I guess I need to look at some scripts.
DRD
February 1st, 2008 at 7:23 PM
@ 34
Ty Prospero for the elaboration but I think every scripter reading this will agree that we need a functional and reliable method of persisting certain essential data to *permanent* objects if LSL is ever to grow beyond the limited functionality set it currently offers.
I echo everyone’s comments when I ask — why can’t each base prim created after a certain point in time include this functionality? Can it not, in a certain sense, be just an additional prim parameter? Perhaps a pointer to a separate dataserver farm who’s sole task is to retain and retrieve these specialized database values?
And yes, please add a hard delay if that will throttle requests sufficently. Surely someone at LL want’s to take this on as a project?
February 1st, 2008 at 7:42 PM
I’m certain I had objects with long desc’s because now my scripts break. I’m also certain I never got an email notifying me of the change. This change was just plain poorly executed.
This change is, IMHO, the worst idea I’ve seen yet. As many others have pointed out, lack of even modest in game nonvalatile data storage severely limits the usefulness of LSL.
And I’m sorry, as a professional computer programmer, I just don’t buy the idea that it wasn’t possible to fix the bugs without limiting these fields.
February 1st, 2008 at 7:57 PM
strange i woulda thought it would be easier in the client side like when microsoft fixed the same exploit in internet explorer but maybe thats just me
February 1st, 2008 at 8:09 PM
My products have always required persistent storage. For most use cases the UUID of the object which doesn’t change unless the object is taken back into inventory and rezzed again is enough information to provide an off-grid server to persist data for you. (I know that cost is not an option for a lot of folks and could represent an opportunity for others).
The one case where off-grid storage fails, however, is the ability to uniquely identify instances of no-copy objects across rezzes. Leaving hacks and schemes to use alternative object data fields (of any sort) as the only available option (I am aware of). I’ve always considered that “solution” risky territory since those can be altered by users and other scripts.
A single read-only field that stores a UUID and is guaranteed to persist across rezzes and script resets for no-copy objects would fill the gap IMO.
Oh, and on the use of the pipe character.. can someone please point me where valid characters (or invalid ones) are documented, I need to choose one that isn’t going to be deprecated. The | character looked good until today.
February 1st, 2008 at 8:16 PM
>> Similarly, the object name and description can no longer be set to include the pipe (|) character. Previously, this was possible, but once again these characters would be lost if the object were taken into inventory.
I can certify on my honour, sirs, that this is patently false information.
February 1st, 2008 at 8:17 PM
I have updated the Timeless Prototype Door to allow the storage of the important info in the fields as now defined. It removes the Scaling or size change function, but otherwise works as before. I simply removed the scale function, and changed the storage of the rotation to a Euler Vector instead of a Quaternion which brought the string length under the limit.
If you want a free copy, I will put a giver out at my shop in Yelas 216,201,42
Hope it helps.
DRD
February 1st, 2008 at 8:24 PM
>> Prospero Linden Says:some of us have ourselves used the sleazy trick of sticking persistent data in the object description.
And the non-sleazy alternative would be, um??? What you term sleazy, every other computer application that has ever troubled a CPU of any ilk would term as basic as air: the storing of persistent information.
You are a game attempting to dress yourself up as an application platform. so what are you? It’s time to sh*it or get off the pot, as we say here in rural Canada. Pardon mon francais.
February 1st, 2008 at 9:15 PM
With a little advance communication, a lot of grief could have been avoided on the grid today.
Tens of thousands of users were affected by scripts failing. Even three days notice would have been enough for us to change our scripts to stop using the pipe character, send out upgrades, and notify our customers. Why, pray tell, weren’t we given the courtesy of a blog announcement on something as critical as this? Its not that we added functionality, we took it away!
I have no problem with Linden Labs deprecating functionality (storage of descriptions using the pipe character) if we’re given fair and PROMINANT warning. In other words, please give us the level of customer service we expect to give OUR customers inworld. Please!
I suspect that this was rushed out to fix a security exploit. Fair enough on buffer overruns using the description field. BUT removing the pipe character arbitrarily and without warning? Unless there was an immediate risk, we simply demonstrated a complete lack of professional courtesy.
I am disappointed. Not in the change. Change happens. I am disappointed in the lack of adequate notice and lack of transparent communications on something this critical.
Lily
February 1st, 2008 at 9:25 PM
My Two Cents - Why restrict it to 128? 256 was good enough wasn’t it? Give us something to store data in that isn’t affected by resetting scripts, and is retained with the object when rezzing, making copies, and taking back into inventory.
February 1st, 2008 at 9:28 PM
While im all for making Scripting run faster less resorces on servers etc….I am a little concerned that in furture you might break stuff i own or have sold and people will get bombarded with requests from people saying my item is broke please fix.
I take it the changes you will be implententing will be minor and not as drastic as to completely change code of scripts?
February 1st, 2008 at 9:56 PM
oh crap. You mean all those cupboards I’ve created - an inventory of about 20 different types - most with multiple doors, and all using the Timeless Door Script will have to be remade???
That’s hours - no DAYS - of my time (that I don’t have) that I”ll have to spend.
I can’t believe this change has been rung in with absolutely NO prior warning.
February 1st, 2008 at 10:18 PM
There’s already 255 characters of persistent storage if we could just get to it… the float text of a prim. We have a way to Set that text… why on EARTH don’t we have a way to Get that text? If we had a llGetText() command, we’d have very simple and fast storage of 255 chars of info…
February 1st, 2008 at 10:33 PM
i sure hope your gonna refund my all teh bloody money i spent on vendors taht are FLIPPIN USELESS NOW!
February 1st, 2008 at 10:53 PM
Wow, if I had realized that so many people needed a way to store data, I might have done something sooner. I use a server on localhost (on my machine) that I talk to over http to keep data.
It is written in Ruby, and is about 8 lines of code. I know that is very difficult to handle, and could probably make it less. The code is public domain. IM me if you would like it.
February 1st, 2008 at 11:01 PM
Each time a script sets an object name and/or description is a new instance of that object created in the database? I don’t believe that happens.
Why not create a new type of object that extends the current object, but has a new extra field called data. This field can be set to a a size of lets say 1024 bytes. At least two new functions will be needed: llSetData(key uuid, string data), and “string llGetData(key uuid)”
This type of object should only be able to reside inside a normal object. Scripts shouldn’t be able to create them. And you can even limit of how many can be inside the object inventory, lets say 16.
February 1st, 2008 at 11:05 PM
It is a shame that this kind of change (especially the one regarding the pipe “|” character) is documented *after* the fact rather than days or weeks in advance.
Our products make extensive use of the pipe character in the description field of objects to exchange data between scripts, and as a consequence of the server updates, all of them stopped working suddenly. Lots of customer calls, lots of hours spent in debugging a defect that was *not* in our code. Shame.
What is even more shameful is that no run-time error is thrown when a pipe character is used in an object’s description. Any engineer knows that a silent failure is the worst kind of failure, since it is extremely hard to track down and you don’t notice the problem until some time has passed. The new server code allows llSetObjectDesc() to take pipe characters, but then they are written to the object’s description field as question marks. No error, no notice. This is just pathetic, something that would guarantee very bad marks to one my first-year programming students. Shame shame shame.
Your engineering practices suck, Linden Lab.
February 1st, 2008 at 11:08 PM
So… this means that people have been using these Name/Description db fields as a form of 8K persistant storage, within a system that was not designed to do write backs to the data base.
And we wonder why the assest servers are suffering.
February 2nd, 2008 at 12:31 AM
Garth FairChang Says:
3 DAYS or rolling restart !!!
How about you get it right now ?
How are we supposed to run our businesses ?
So Your sims been down for3 days restarting?, Sure it’s not your PC, I only seen my sim restart twice and it was back on line in under 2 minutes, and despite popular belief I didn’t lose a days sales everytime the sim restarted.
February 2nd, 2008 at 12:59 AM
Can we PLEASE have a damn list of UTF-8 characters we can use in names (Especially descriptions) in the future that won’t be removed?
Now I have to rewrite lot’s of scripts, waste time repairing already deployed systems with clients (For those small items that don’t have auto-update scripts)
I dread the compatibility issues we’re going to have when Mono is deployed in the main grid.
Congratulations on, yet again, pulling the rug from under our feet.
February 2nd, 2008 at 1:04 AM
Look, just put in a new field that is not name or desc but “Data” make it max one k in length (or whatever is reasonable) and LET US WRITE TO IT!!!
It is comepltely inconceivable to have aprogramming language/environment with no WRITE feature.
We don’t care HOW you do it, if notecards don’t work MAKE SOMETHING THAT DOES.
Come on.
Relying on outside services for storage is completly out of the question. I would never buy a product that relied on that. Guaranteed that in 6 months the user and their service will be gone and my product partially or compeltely non-functional.
February 2nd, 2008 at 1:14 AM
Surprises like these bother me a lot and should anyone involved in (or seriously considering) development of mid to large scale projects in-world.
February 2nd, 2008 at 1:18 AM
Way to break content guys! Not only truncating something that is HEAVILY used in alot of doors but removing the |, something known to be a decent delimiter as it’s not often used for much else.
But killing the doors, thats an amazingly bad decision that smells once more of the Lindens not testing things.
You fixed the Avatar as part of a linked set (Poseball-less sit) so this time around you need to fix the description right. All my doors now fail when they are rezzed, and thats alot of doors.
February 2nd, 2008 at 1:21 AM
[...] last couple posts on Object Name and Description Changes and Wednesday Maintenance seem to contain nothing but “sucks comments”. There really is [...]
February 2nd, 2008 at 2:19 AM
<<<>>>
This comment above is indeed concerning. I am trying to get a big project underway and am now extremely concerned about trusting any bespoke script I buy. What if the scripter disappears. Something very expensive will be useless if arbitrary changes can be made.
The Lindens treat their world as a toy. There are desperately poor customer relations as is demonstrated by the bad feeling generated in the 70 blogs here. In world and Linden customer relations should follow rw standards.
Blimey, it seems to me that this business is heading for a take over by someone like Google or, worse still, Microsoft … if it hasn’t already happened.
Business ethics are missing here and some specific Linden should be responsible for policing their own activities and decisions.
February 2nd, 2008 at 2:24 AM
I absolutely love this fix!
Mostly because the bug was causing many of my rezzed objects to be destroyed (I think after restarts), so the problem was actually much worse than LL claims.
Regarding data storage; wouldn’t it be possible to have some sort of “database” solution built into SL? Just give each owner his own area of data on a server which each script (s)he owns can write to. Then limit the amount of usable data for each script to keep traffic down. This way you could have static data whilst keeping it all on the servers. Basically llPutData(string data, integer index), string llGetData(integer index), llClearData(integer index), llClearAllData() and perhaps integer llGetFreeData(), where the total amount per script (or perhaps per object) is limited? I’m experimenting with using a MySQL DB as static storage through HTTP, but obviously not everybody has a DB online. Just thinking out loud.
February 2nd, 2008 at 2:25 AM
And i used the descriptionfield as datasource for other objects, which reads them per llGetObjetcDetails(). Was a nice way to broadcast informations without using chat and storing this data in the requesting objects again. So back to stoneage… thanks
So please, if there is a replacement (like the properties) make them readable form other objects.
February 2nd, 2008 at 3:13 AM
Yesterday in Second Life: Second Life Daily News
Linden Lab provided a helpful update on the changes to scripting that were made during one of the updates this week. A few scripters we know are having to redo some of their work, but the impact seems relatively minor.
February 2nd, 2008 at 3:17 AM
[...] Second Life Blog Scripters : Object Name and Description Changes Quote from the site - There have always been limits on the length of the “Name” and [...]
February 2nd, 2008 at 3:38 AM
This is “event” is extremely disappointing, frustrating, and causes me to think twice about the amount of time and effort that I have spent “Playing” in SL. Your attempts to defend this scare me worse than the fact that you did it.
1.) Using the only data storage option available is “a slimy trick”????
2.) E-mails were sent out??? ( frankly I think this is a pure lie.. I just don’t believe that you would take all the trouble to search and send e-mails and yet not even blog it - comments closed.)
3.) The PIPE is an “unallowed” character??? Since when? Where is the list of allowed characters???
Show some courage and admit your error.
Then get to back to business and DO SOMETHING. Read @57 you could code, TEST, and implement that before the rolling restart finishes.
February 2nd, 2008 at 3:52 AM
Well. To make a short comment that covers most others here: LL Seem to lack of the understanding that the 90 percent users of SL are the NONE creating/scripting ones. The last 10 percent are the ones that use alot of time on developing items, objects and scripts that makes the 90 percent mass having a good SL.
10 percent that is actually the mass of agents in SL that developes most of the “game’s” visual experiences for the 90 percents, are completely treated like we are kids. Wouldnt it be a good time now for LL to start showing a little respect to the agents in SL that actually helps them to show off a good platform to count on ???
Make a storage possibility for persistent data now or start losing MORE building residents.
February 2nd, 2008 at 3:54 AM
Diabolical communication once again. Thanks LL.
Another possible solution would be to let a script change its own name (and/or) description in the same way a script can change its containing objects name or description. Then we could put a couple of data scripts into an object and have them write the data required into 2 or 3 of these data scripts descriptions instead of cramming it all into the objects description. The info can be communicated back and forth to the main script via link messages. No new assets need to be created like writing to a notecard would require. Data storage would be limited to how many scripts you put into an object, making it far more scaleable than it currently is.
For example, the Timeless door script which everyone is complaining about could have one script for door position, one for scale, one for rotation. The data would be persistant should a restart or reset be required.
Seems like a fairly simple solution to me and since the code is already written for llGetObjectName, llGetObjectDesc, llSetObjectName and llSetObjectDesc it cant be that hard to make a few llGetScriptName, llGetScriptDesc, llSetScriptName & llSetScriptDesc commands.
February 2nd, 2008 at 4:21 AM
@57 — damn nice post - no problems , just a SOLUTION - maybe LL should give you a job in there “think tank” - which is currently grossly understaffed
February 2nd, 2008 at 5:06 AM
I have to disagree with everyone who is saying the Lindens have broken “functionality”, this was always a hack, albeit a necessary one for some applications. I know if you were forced to use this hack this will be devastating, but what we need is a real solution for persistent storage, not a reversal of this fix, and I for one am glad that the behaviour is now more consistent.
February 2nd, 2008 at 5:13 AM
Sorry to double post, but I just realised that one of the commands for my solution in fact already exists. llGetScriptName is already there, so you just need llGetScriptDesc, llSetScriptName & llSetScriptDesc to provide all the persistant storage we require.
You could use these as permanent variables with the script name being the variable name and the script description being its value.
Problem solved.
Linden Labs, you can pay me in L$ or via PayPal.
February 2nd, 2008 at 5:21 AM
@78 Jabath: When you write “I have to disagree with everyone who is saying the Lindens have broken “functionality”, this was always a hack, albeit a necessary one for some applications.”, you’re mistaken in your belief.
A huge amount of functionality in SL started out as “necessary hacks”. Invisiprims. Tinies. Warp Move. The Lindens have gone out of their way to avoid breaking them. They need to do that again.
February 2nd, 2008 at 5:36 AM
LOL@LL For Kicking Scripters In The Gonads
Now They Are Going To Do The Same In Return…
This Will NOT End Well
February 2nd, 2008 at 5:36 AM
As usual one step forward, two steps back. People used the pipe in various scripting ways. It should not be removed.
I agree with the majority that wrote in regards to needing script info storage. If the Desc, Name fields are removed, or if it is tampered with in any way, it breaks far more than Linden is obviously aware of.
Not just positioning for such scripts as doors etc.. but many other types of scripts that use the desc/name fields.
I’ve read what the position is on not allowing scripts to write notecards but honestly, something is needed to store this information. It’s a big issue and anytime something is messed with things break.
A poster wrote:
“why don’t disallow scripting. they might change how things should work in you clean and proper visions. or better, charge people who like to script or build. ll, you just need just a view scripters but way more smooth consumers. wait a minute.”
You take scripting an object out of SL, there is no reason to be in SL.
As far as charging for scripting and building, what do you think tier fees are? People are paying to build and script. You make little sense.
-Tracy
February 2nd, 2008 at 5:42 AM
Wed the Server Changed, Fri the notice comes out. The order should have been reversed! If you making drastic changes, put the Notice BEFORE the change! We can always re-script, that’s not the issue. Making our users and scripters scramble AFTER THE FACT is! I’ve talked with all kinds of people that use those long desc’s and NO ONE seems to have seen the email that was referenced. YOU HAVE to do better informing your user base. What your doing is NOT WORKING! FIX IT. This is not rocket science!
February 2nd, 2008 at 5:59 AM
A few things
* Pipes in names and descriptions, as well as names longer than 63 characters or descriptions longer than 127 characters, were already broken. You could set all of those things in an in-world object with scripts. However, if you took the object into inventory and re-rezzed it, the names and descriptions would have been truncated, and the pipes would have been silently removed. Yes, I understand that people were using objects in-world that used longer names/descriptions and/or pipes, but the behavior was inconsistent. The new changes make sure that only object names and descriptions can be set that will continue to work even if the object is edited, taken into inventory, given to another user, etc.
* We did make an honest and sincere effort to identify those residents who had objects that would be affected by at least the length truncation change, aware that it would affect some people. We did this through e-mail because we knew that some people using objects built or scripted by others might not even be aware that they had objects that would be affected– and not everybody reads this blog. This investigation showed that it was going to be quite a small number of people who would be affected. I am currently investigating how we might have missed a (large?) number of people to be forewarned, and will provide more information as I have it.
* As I mentioned above, we are well aware that the having some kind of persistent data store is something that would be a great boon for scripters. At the moment, our effort on the scripting front is the vast improvement in the infrastructure that Mono will bring, and on making sure that the introduction of Mono doesn’t break existing scripts. As such, while we don’t have concrete plans for providing a persistent data store, we do fully understand why it’s a desired feature.
February 2nd, 2008 at 6:09 AM
llPleaseRead()
I was looking for anything that would help out of the posts. This person has some good ideas that would help assist with this issue.
Farallon Greyskin Says:
“Look, just put in a new field that is not name or desc but “Data” make it max one k in length (or whatever is reasonable) and LET US WRITE TO IT!!!”
This makes sense and would be a real asset. I think maybe the limit might be on the small side, but allowing this “Data” field for storage would help. And I agree that using outside resources for storage is not at all a good idea.
Still not as good as a notecard, but at least it would work.
-Tracy
February 2nd, 2008 at 6:13 AM
I always limited myself with the persistent data I put on objects. Nothing past 20 characters. Sure. This works for small, simple things only. Maybe some people can fix their stuff without losing functionality by using some kind of coded words instead of full words. Of course, not everyone could and the bigger projects would be left out of this because the lines would still be too big, even if using shrunk words.
In a non related note, By the way LL. Don’t forget to add glow parameters to scripts when (or if) Windlight makes it as official viewer.
February 2nd, 2008 at 7:41 AM
My proposal for persistent data is SVC-1406
February 2nd, 2008 at 8:07 AM
The above posting that suggested using an inverse function of “GetText” for the prim’s float text sounds like a good short term solution, provided they create a set of servers dedicated just for this traffic.
February 2nd, 2008 at 8:29 AM
Banning the pipe is a interresting insight into the Linden Server software and makes me wonder what damage could be done with ~ or ` signs
Well I will behave - I promise.
To have the field length consistent everywhere is a good move because it also makes it easier for the ones who are doing external data storage of prims in there databases. Looking at “competitors” mainly ‘OpenSim’ Linden somehow does establish a standard here and setting a hardwired limit will make it easier to have these worlds connected in the future.
February 2nd, 2008 at 8:29 AM
———–
WE NEED TO GET THE llTargetOmega BUG sorted out PLEASE !!!!
Since Havok4 these called functions FAIL !!! (without AV interaction, select>deselect/tp out>in)Many are very much aware of this as you will see on jira.
Do LL expect all users of this function to stick another line of code to every llTargetOmega(another client side effect) to kick start this????, That sounds like a massive hammer to crack a very small nut. We have tested this all over SL with different machines, users, viewers and different connections, this is very real and should be a priority, we simply cant have a system that decreases in functionality(and stability)over time, that is not progress its madness.
I NEED SOME REASSURANCE FROM A LINDEN ON THIS URGENTLY AS DO MANY OTHERS !!!!!
———–
February 2nd, 2008 at 8:33 AM
Prospero,
It would be nice to have a well publicised breaking changes page somewhere (the LSL Wiki, perhaps?), so that scripters could have some advance warning of any up and coming changes to the scripting language.
If that’s too much work to set up, could you please make sure that when you’re emailing residents that own objects that are going to be affected, you also email the creator of those objects, so that they at least have a chance to create and rollout a patch prior to the change?
Thanks in advance,
Kirri
ps. Perhaps the artificially low count of residents affected is due to their objects being currently stored within their inventory (and hence, have a currently truncated description)?
February 2nd, 2008 at 8:38 AM
Count me in as one of those that did not get notified. I now have several hundred security systems out in the field to upgrade, a process that would have been much less painful had I known this was coming.
February 2nd, 2008 at 9:10 AM
I just found out that somehow the perms on the updated door scripts got changed. My apologies. I have made sure now the the script at my store is full perm. If you got a no mod version from the giver, please come back and get the full perm version. Sorry for any inconvenience.
Yelas 211,210,46
DRD
February 2nd, 2008 at 9:18 AM
It seems like the vast majority of people on this thread, including myself, would like some sort of persistent data storage - be it writing to notecards, a general use storage built into each object, or some sort of extensive variable(parsing single strings for multiple values is easy enough).
I count at least 15 people mentioning that on this thread. Is LL just going to continue to ignore everyone’s cries for change, and proceed in their own designs, regardless of the wishes of the community, as usual?
I don’t particularly care about this change, it won’t affect me in the least. I would have liked to know about this sooner because it may have saved me a lot of trouble and time scripting and coding PHP, but I suppose it’s good now that you’re botching this too.
February 2nd, 2008 at 9:22 AM
@Doofus Mayo
Actually you can do a similar thing now by having any prims in a linked set change or read their name / description via linkmessage. You still need to abide by the now enforced limits per prim, but in a multi prim object, it could add quite a bit of data storage. Not elegent for sure, but does add some non volitile storage.
DRD
February 2nd, 2008 at 9:28 AM
LL are you hearing us??? We NEED some form of in object non-volitile data storage. Hacks make for cumbersone, memory intensive, laggy code. Adding multiple scripts or objects with scripts just to store data is a mess.
DRD
February 2nd, 2008 at 9:47 AM
Some things that would help right now:
Raise the llObjectDesc() length to 1024. Enough storage for URLs (which often run more than 127 characters by themselves) and for vectors and rotations.
Allow linked prims to read each other’s descriptions fields. That would mean simple access to up to 255*1024, or 255K, per linked set. More than enough storage.
February 2nd, 2008 at 9:53 AM
I do see the fuss about the | character. I’m a bit lucky that I separate my stuff with a # sign :3
As for out of world storage, this is a non-problem and it is easy to do. I’d think one would be taking it too far to call it outrageous that reliable storage of large data has to leave LL into a web server.
What I’m currently waiting for, is an easy way for objects to message one another. Much like llInstantMessage having the characteristics of xml-rpc but without the xml,e-mail,http fuss.
February 2nd, 2008 at 10:40 AM
geeezzzzz….. what a bunch of whiners. Bummed because a hack no longer works??? What? Are you new to this? Must not be scripting/programming in the real world.
yeah… we need somewhere to write our data out LL. Throw us a bone. I’d settle for doubling the size of the description field to a whopping 255.
February 2nd, 2008 at 10:43 AM
BTW, your 1.19.0.0 upodate is broken - it freezes any time the world map is opened. The duration is from 10 seconds to forever (you should have received crash reports by now).
And, please, if you have time to tinker with the UI, perhaps you can assign some folks to come up with a decent extensible non-volatile storage for scripts. Look, we really need notecards to be writable. Too many educational needs alone should make this a high priority item.
And yes, *committing* a notecard is an asset server update but a commit need not be tied to every write. You can make this an efficient operation if you choose a cached architecture.
Help us here with our plea soonest.
February 2nd, 2008 at 10:44 AM
Cool. never knew that. but why not try to get a Teengrid Beta Grid? or let us are yours?
February 2nd, 2008 at 10:49 AM
All in all, Linden Labs, very poor show. Don’t alienate your developers. IBM did that 20 years ago, and learnt the hard way that if you do, someone from Seattle is likely to buy them a coffee and have a chat.