Scripters : Object Name and Description Changes

There 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.

This entry was posted in Bugs & Fixes, Scripting. Bookmark the permalink.

148 Responses to Scripters : Object Name and Description Changes

  1. Giddy Phillip says:

    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.

  2. Zulqadi Saarinen says:

    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.

  3. Bank Robber says:

    is this how the ‘atms’ of those ‘banks’ got robbed?

  4. peter lameth says:

    they’ve told us before writing notecards creates an asset so they are not going to let scripts create notecards.

  5. Day Oh says:

    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.

  6. Ann Otoole says:

    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.

  7. ZM says:

    Thats excelent because it represents more stability
    Thanks LL

  8. @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

  9. la le lu says:

    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.

  10. Drako Nagorski says:

    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

  11. Argent Stonecutter says:

    This is just broken.

    Fix it the right way.

    http://jira.secondlife.com/browse/SVC-1406

  12. Sindy Tsure says:

    I get the length stuff – no worries there – but why remove the pipe character?

  13. 3 DAYS or rolling restart !!!

    How about you get it right now ?

    How are we supposed to run our businesses ?

  14. Miles Beck says:

    “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.

  15. Wyald Woolley says:

    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?

  16. Kerik Rau says:

    @ 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.

  17. Prospero Linden says:

    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.

  18. Delu Elytis says:

    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.

  19. la le lu says:

    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.

  20. la le lu says:

    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.

  21. LaeMiQian says:

    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.

  22. Stick says:

    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

  23. Barbarra Blair says:

    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.

  24. Sindy Tsure says:

    Huh.. Never noticed pipe wasn’t an allowed character.. Guess I won’t miss it much! 🙂

    TY for answering, Prospero!

  25. Stick says:

    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…

  26. 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?

  27. turnip harvester says:

    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

  28. Locke Traveler says:

    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.

  29. Tyken Hightower says:

    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!

  30. SFFan2 LosAngeles says:

    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.

  31. Miles Beck says:

    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.

  32. Kandi Carnell says:

    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

  33. Prospero Linden says:

    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….

  34. Argent Stonecutter says:

    @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.

  35. Argent Stonecutter says:

    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.

  36. Han Sontse says:

    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~

  37. Ryu Darragh says:

    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 ?

  38. kundali Jun says:

    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.

  39. Ryu Darragh says:

    Oh, and that idea follows onto the idea of not *creating* notecards in a script, but writing to an existing one.

  40. Tyken Hightower says:

    ‘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.

  41. Argent Stonecutter says:

    @37 Han: SVC-1046 🙂

  42. Argent Stonecutter says:

    @40 Ryu: That’s the problem: when a use modified an existing notecard, they ACTUALLY create a new one right then.

  43. Grey Lock says:

    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.

  44. DR Dahlgren says:

    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

  45. Dacob Paine says:

    @ 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? 😉

  46. Doran Zemlja says:

    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.

  47. Lestat Demain says:

    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 😉

  48. 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.

  49. Chaz Longstaff says:

    >> 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.

  50. DR Dahlgren says:

    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

  51. Chaz Longstaff says:

    >> 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.

  52. LilyNeeAnne Hilite says:

    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

  53. 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.

  54. concerned says:

    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?

  55. Phaedra Basevi says:

    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.

  56. Solomon Devoix says:

    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…

  57. CC says:

    i sure hope your gonna refund my all teh bloody money i spent on vendors taht are FLIPPIN USELESS NOW!

  58. Nacre Swindlehurst says:

    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.

  59. rex cronon says:

    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.

  60. Anna Tretiak says:

    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.

  61. Satori Taringa says:

    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.

  62. Tegg B says:

    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.

  63. Viktor says:

    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.

  64. 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!!!

    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.

  65. blackcrow6667 Garmes says:

    Surprises like these bother me a lot and should anyone involved in (or seriously considering) development of mid to large scale projects in-world.

  66. Jayden B says:

    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.

  67. Pingback: Concerning Next Weeks Weekly Wrap Up | Second Life Sucks

  68. Gerald Wylie says:

    <<<>>>

    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.

  69. Tijn Erde says:

    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.

  70. Cale Flanagan says:

    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.

  71. Pingback: Massively

  72. Pingback: The Grid Live » Second Life News for February 2, 2008

  73. Sinuna Falta says:

    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.

  74. Zep Palen says:

    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.

  75. Doofus Mayo says:

    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.

  76. The Bat says:

    @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 🙂

  77. Jabath Steuart says:

    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.

  78. Doofus Mayo says:

    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. 🙂

  79. Argent Stonecutter says:

    @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.

  80. Milo Bellow says:

    LOL@LL For Kicking Scripters In The Gonads

    Now They Are Going To Do The Same In Return…

    This Will NOT End Well

    🙂

  81. Tracy Welles says:

    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

  82. Moose Maine says:

    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!

  83. Prospero Linden says:

    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.

  84. Tracy Welles says:

    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

  85. Hanumi Takakura says:

    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.

  86. Argent Stonecutter says:

    My proposal for persistent data is SVC-1406

  87. Satori Taringa says:

    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.

  88. 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.

  89. FIX ME !!! says:

    ———–

    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 !!!!!

    ———–

  90. Kirrineth Dragonash says:

    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)?

  91. Triple Peccable says:

    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.

  92. drdahlgren says:

    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

  93. Rob A says:

    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.

  94. drdahlgren says:

    @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

  95. drdahlgren says:

    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

  96. Lillie Yifu says:

    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.

  97. 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.

  98. foo foden says:

    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.

  99. Balpien Hammerer says:

    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.

  100. Aeper Jie says:

    Cool. never knew that. but why not try to get a Teengrid Beta Grid? or let us are yours?

  101. Chaz Longstaff says:

    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.

  102. Gellan Glenelg says:

    Prospero Linden: “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….

    On the login screen of 1.18.6 (4), there is still
    “UPDATE AVAILABLE
    Download 1.19.0.0 (link)
    This update contains the latest fixes and features. We always recommend upgrading to the latest version, but now the choice is yours. Remember, these updates are connected to the Main Live Grid. See you inworld!”

  103. Belshazaroth Fargis says:

    Give the people what they want.
    Build in a stack, or a heap, or a new data field.

  104. Satori Taringa says:

    Would the real solution to the persistant data problem have been to use a second linked script whose sole purpose was to save/send a string for other scripts to access. Since it would require a separate reset from the other scripts, it would be more reliable in maintaining it’s data.

    The original coders who created the description text trick, knew it was going to break one day.

  105. Ryu Darragh says:

    I use a persistant data storage technique in my builds that works well, even when the main script is reset. I use a super simple script as a data store device. So, main script can be reset and reads the data from the data store script when it needs that data. Haven’t had it fail in more than a year since I started using it. Until LL adds a “data field” to prims or, more elegantly, an “llWriteNoteCardLine()” function, it will do the job.

  106. Ryu Darragh says:

    Oh, and I have tested it in mono and now get upwards of 31K integers per data store cript as opposed to the not quite 5300 integers in LSL2.

  107. Lillie Yifu says:

    I tried this, sim crashes often put the two out of sync. Also not easily user editable the way Description is. The very reason for Object Description is that was not subject to the problems of a script, for example stack heap collisions corrupting all stored data.

  108. mcp Moriarty says:

    In all of the on-line documentation that I’ve used for scripting, it is clearly noted that using excessively long names, was a hack and should not be relied upon. Not only that, some docs state it could be changed without notice. So if you used this hack, you could one day find your stuff not working. Who’s fault is that? lol

    The upset residents should be yelling at the scripter for relying a hack in the first place that was not 100% guaranteed to remain in the first place.

    This is one of the few changes that you should of seen coming. A hack that was eating up server space. They want the lost space back. This change is a no brainier on their part. Fixing a hole that needed fixing.

    Where to place and store permanent data. That really is a separate topic. It should not be confused with this change, it was a known hack all along.

    As for the pipe character, if you didn’t notice them silently vanishing, etc. Or only appearing in certain places, should of been a clue. Don’t use them. lol

  109. Chaz Longstaff says:

    >> mcp Moriarty Says: In all of the on-line documentation that I’ve used for scripting, it is clearly noted that using excessively long names, was a hack and should not be relied upon. So if you used this hack, you could one day find your stuff not working. Who’s fault is that? lol

    I kept mine way under the limits. I am a very cautious programmer.

    >> As for the pipe character, if you didn’t notice them silently vanishing, etc. Or only appearing in certain places, should of been a clue. Don’t use them. lol

    Mine had no issue in a year of using them. Nor did anyone else I’ve heard from. Any reports of issues with pipelines appear to be apocryphal and perhaps made up now to do reverse justification.

    >> Lillie Yifu Says: I tried this, sim crashes often put the two out of sync. Also not easily user editable the way Description is. The very reason for Object Description is that was not subject to the problems of a script, for example stack heap collisions corrupting all stored data.

    Yes. What she said.

    Anyway, look bottom line, trying to store a few simple parameters *shouldn’t* cause developers to have to resort to hacks. Honestly, it really really is just a *basic* thing in any application development platform.

  110. Sierra says:

    “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.”

    Cure the disease by killing the patient?

  111. Crucial Armitage says:

    First I am not a scripter I make clothing and have at times set long descriptions and i was in fact notified via email that some of my items had long names and or descriptions a few weeks a go.

    Second as far as the pipe character is concerned please read what they are writing about the pipe character. The way i see it is If you were able to write the pipe character in the past by using a script to write it that was a bug. This behavior was never meant to be allowed to write this character in a description or name. And since what i read here from some it was used as a separator for data storage it will be come much less useful with the enforcement of the description length

    I will also point out any one that has been relying on very long descriptions must of know they were circumventing the description or name length limit and that some day LL would enforce the limit as they are doing now.

  112. drdahlgren says:

    @ foo foden / mcp Moriarty

    Must be nice to walk on water and be so good at LSL that you have never used a hack to get something to work. I will have to look in world to see your marvelous creations.

    As to a warning in the LSL that the hack might be fixed without notice, if you read the TOS, the whole SL world might be stopped without notice.

    And whinning, I don’t think so. In most of the posts while the loss of this function is lamented, the main thrust seems to be that:
    A: It should never have been required in the first place.
    B: Communication about it being “fixed” would have been nice.

    I think most of accept the fact that it is no longer available. I think most are just communicating their displeasure with a tool we need to use to create active content in SL, and the overall lack of communication from LL to those who create content.

    If that is whinning, then I guess I am a big whinner. I also guess your calling me one won’t in the slightest encourage me to stop.

    Now, guess it’s time to go see what you have added to SL besides name calling.

    DRD

  113. Chaz Longstaff says:

    >> Crucial Armitage Says:Second as far as the pipe character is concerned please read what they are writing about the pipe character. The way i see it is If you were able to write the pipe character in the past by using a script to write it that was a bug. This behavior was never meant to be allowed to write this character in a description or name.

    You must have better eyes than all the rest of us put together Armitage, if you can read something that was never ever, ever, ever, ever, written down somewhere :}

    @ drdahlgren Behind you 100% . Nothing is more annoying than having this fifth column of backbiters come out now and try to undermine what we are trying to communicate. But don’t worry guys, we’ll be sure to watch for the day we can return the favour :}

  114. mcp Moriarty says:

    drdahlgren wrote:

    “Must be nice to walk on water and be so good at LSL that you have never used a hack to get something to work. I will have to look in world to see your marvelous creations.

    As to a warning in the LSL that the hack might be fixed without notice, if you read the TOS, the whole SL world might be stopped without notice.

    And whining, I don’t think so. In most of the posts while the loss of this function is lamented, the main thrust seems to be that:
    A: It should never have been required in the first place.
    B: Communication about it being “fixed” would have been nice. ”

    You answered your own whining, if the TOS states that. They don’t have to utter a word before a BUG fix. lol

    Use a hack, take a risk. It’s not rocket science. You were warned in the various LSL docs and the TOS.

    A lot of complaining about bugs not getting fixed, they fix one and many are still unhappy. I’d say a potential 8k lost per script is a serious bug, spread that across x number of accounts, it’s a lot of server space lost. It needed to be fixed.

    I stick to the defined limit in my scripts, hence they work as before. No water involved. lol

    Don’t get me wrong, I’m for a permanent storage area, but this is not the proper way to do it. You need to lobby in the developers forum or however LL goes about taking suggestions. Whining here over a lost feature that was actually a bug ain’t gonna solve it. I use off site php and now I’m glad I did. 🙂

  115. Glox Parisi says:

    @84 Prospero Linden Says:
    >>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. (…) 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.

    Well, I guess you only checked name and description of root prims in linked objects. Doors using the timeless door script, for example, must not be the root prim — that’s how you missed a very large number of people. A bit of due dilligence at your end would make our lives a lot easier!

  116. Chaz Longstaff says:

    >> mcp Moriarty Says: I use off site php and now I’m glad I did. 🙂

    Your customers won’t be so happy when you walk off a curb, get hit by a bus, and snuff it. You are a single point of failure. When you go down, so does that off-site memory storage too. Customers should realize this.

    Unless you have a professional plan of course for someone to back you up in RL.

    Look at it this way. A side example, coming back to the point. A whole lot of people in North, Central and South America get really *irked* that Americans have the audacity to call themselves “Americans”, as if they are the only people on the American continents. But as an American friend once pleaded, well, what else do I call myself? Give me something else, and I’ll use it.

    We haven’t had anything else to use, and your attacking it is frankly unhelpful and perhaps I suspect not even done with helpful intentions.

    And as for off-site, like I said, when you go down, so does it. And the time when we go down comes for all of us. Thou too art mortal.

  117. Kirrineth Dragonash says:

    For anyone reading all of this and now wondering how to handle persistent storage, you might find this script on the forums a very good place to start:

    http://forums.secondlife.com/showthread.php?t=37866

    Kirri

  118. mcp Moriarty says:

    The same applies to non-off site storage. If you walk off a curb and get hit by car, how you gonna service your customers should any issue arise. Death is a bit extreme. lol It is game after all.

    Off site storage is the only way if you have large amounts of data.

    As any good programmer knows, in the real world, stick the to API or get burnt.

    Also SL is down more than my server.

    The comments about Americans, off topic, makes little if any sense.

  119. Doofus Mayo says:

    @95 drdahlgren
    You are right, you could use linked prims but that increases prim counts and therefore reduces scalability.that is why I suggested using scripts inside a single prim instead.
    The idea of just using a separate script and filling it with variables or lists or whatever is a good one and is one I have used previously to store large amounts of info, but these scripts have occasionally had to be reset and then the variable info is lost, that is again why I suggested being able to change the script name and description as this is more persistant.

  120. Argent Stonecutter says:

    moriarty: if my goods don’t require offworld storage, then even if I get hit by a car the people who buy them will still be able to use them in the future. On the othert hand if it uses storage in-sim then it doesn’t matter that the sim’s unreliable, any time it’s up, I’ve got everything I need right there. That’s why I will never buy a product in world that requires offworld storage, and there’s more than enough other people who think the same to make that a non-starter.

  121. mcp Moriarty says:

    That is assuming your script is 100% bug free, SL is 100% bug free, and they don’t change something else down the line without notice.

  122. Satori Taringa says:

    hmmm, let’s store important data on SL’s inventory system, we all know how reliable that is.

  123. mcp Moriarty says:

    Satori Taringa you make a good point, when SL takes a dump on my inventory, my off world data is not lost.

  124. la le lu says:

    let me focus again at the description field as a indexed field to the new google search engine and the use together in vendor systems,

    the only way to get products of a multi vendor visible is, to write the products name in the 8k space of the description field. thats cheap and worked well. take this option means a to cut of essential functionality from payed objects like multi vendors in favor to rez out each product to buy.

    there is no other way or function to pass keywords to the google indexer then the description field. if you know one, please tell us mortals.

  125. drdahlgren says:

    I am not sure why or how, but I have just found out that the copy of the timeless script I had out is not my modded version, but the original one. Now I understand why the perms were wrong earlier. Duh. Guess it was just too late last night.

    Anyway, I promise the updated version is at the shop, Yelas 212, 210 and if you IM me, I will just drop you a copy. Sorry again.

    DRD

  126. Viktor says:

    I still don’t see how the use of the pipe character is a hack. Obviously the length of data in the fields was a hack but the use of a common delimiter? (Even the Linden’s admit to it’s usage) and they STILL remove it despite knowing this? What possible technical reason could that be (You’re telling me you can’t even ‘escape’ the character some how?)
    Just because I can’t enter it into the Description through the client doesn’t mean it’s a hack. The client/avatar can’t speak on negative channels but a script can (and does), is that a bug too?

  127. d3adlyc0d3c says:

    For those of you concerned about being able to store data just place a ton of objects in the main object’s inventory, send them linked messages and have them store data in their inventory, then have them check the description to make sure that it doesnt exceed 127 characters whenever they recieve a linked message and if so have it send a linked message back to the main prim, then main prim sends data to the next object instead,etc,etc,etc. Sure it’ll be more of a pain in the butt but it’s workable and without notecards too.

  128. Ann Otoole says:

    oh how many times did i write data entry field validation code to remove any and all database wildcard symbols. then it got smarter and started putting the code in the keystroke action s the characters could not even be typed. pipe characters, percent signs, and certain other characters have special meaning to database systems unless the field is a blob type that is not intended for efficient search. presence of wildcard symbols and other special use characters always lead to data quality problems and data quality problem induced defects are a pain in the rear to troubleshoot and identify. don’t use special characters. you are attempting to overload a column. overloading a column is a bad practice. until such time as SL scripting (not programming) provides for data persistence then use an external website and database. if you are a merchant and making money then most likely you already have the infrastructure on one of your rl websites. me? i erred and choose windows hosting. an error that will soon be corrected so i can use PHP and MySQL. grrrr.

  129. Very Keynes says:

    @120
    Problem with that (storing data in script or child prim descriptions) is that the LSL2 VM has no dynamic memory allocation, so each script gets 16K even if it is just 2 or 3 lines of code. So to get 1k ~ 127*8 you would be allocating 128K of system ram. Add to that the fact that all scripts are allocated the same time slice, active or not and you are inducing considerable lag, relative to using the description field as people were doing.

    Using storage scripts with offline backup (http or email) may be a better balance until such time as LL gives is some dedicated in world storage.

    As for the vendors and the dress designers, I had not considered that angle, once again SL goes far deeper than any one of us can imagine, almost the butterfly in Hong Kong theory.

  130. Doofus Mayo says:

    I am still having problems with my vendors. Is it possible that any script that uses llGetSubString(???, ?, 255) as a way of reading the end of a string has also been borked by your truncation fix. I sell skins and my vendors read the description name (Which is a legal length) and use the llGetSubString function to read separate parts like skin tone, makeup style…
    Part of this includes a read to end of line (previously 255 as suggested by the wiki as string can only be that long) and anything under that should be truncated. This used to happen in a predictable way, but now my vendors are returning erratic results. Does this type of truncation simply no longer work predictably?

  131. Zi Ree says:

    Scripts were never limited or truncated to 255 characters. See here:

    http://www.lslwiki.net/lslwiki/wakka.php?wakka=string
    http://wiki.secondlife.com/wiki/String

    If you want to read the end of a string, use the negative position numbers as described here:

    http://www.lslwiki.net/lslwiki/wakka.php?
    wakka=llGetSubString

  132. Zi Ree says:

    @132: Strings, not scripts, sorry for the confusion.

  133. Nik Woodget says:

    @129: Whats wrong with .NET and SQL? Plus PHP and MySQL can be setup on windows anywho, Though I’m sure you know 🙂

    *loves the .NET HTTPListener class for writing -custom- webservices in .NET 🙂 *

  134. mcp Moriarty says:

    Be careful with .NET, if anyone has access to your code or server, they can decompile it rather easily back into source text. .It’s is a byte code interpreter and very easy to decompile.

  135. Gully Miles says:

    Prospero: whilst the fact that the existing handling of Description fields may have been “inconsistent”, that in itself is no reason to “fix” it if it ain’t broken. Consistency is not a quality that appeals to everyone — certainly not the many people who relied on that inconsistent behaviour to actually get their scripted solutions to work.

    This is all new territory, you know. It would be perfectly OK to retrospectively change the specification of the Description field to support the way that people were in fact using it. Many companies in your situation would have done this.

    I’m very concerned that, even after all this time, SL appears to have an architecture that still doesn’t allow scripts to write to persistent storage because of asset server load. Come to think of it, it still can’t support more than tens of people in the same place, it still allows inventory items to get lost because its inventory transactions aren’t atomic, it still can’t allow someone to be a member of more than 25 groups because of database load, and it still manages to randomly jam your shoes up your ass when you TP.

  136. Prospero Linden says:

    Gully @136 — in fact it wasn’t the inconsistency itself that drove us to fix this, although I would disagree that consistency is not a good goal. The old way things worked was confusing and unpredicatable; I think few would argue against a desire to have the name and description fields survive intact when an object is taken into inventory and re-rezzed. The real reason this was fixed was because of the security problems associated with the old way of doing things.

  137. Gully Miles says:

    Hi Prospero, thanks for your response.

    I certainly agree that consistency is a good goal, all other things being equal. It’s better to have names and descriptions survive intact when an object is taken into inventory and re-rezzed. But my point is that all other things are *not* equal in this case. It appears that many people were taking advantage of this “feature” in order to have some kind of persistent storage, and that’s why they are upset now.

    One way to make the behaviour easily predictable and consistent with the specification would be to amend the specification — to say something like “When an object is taken into inventory, its name will be truncated to 63 characters and its description truncated to 127 characters”.

    I appreciate what you say about the security issue. Perhaps that means that there needs to be *some* limit on the length of Name and Description, but I don’t see why it necessarily needs to be the same as the limit imposed when the object is taken into inventory.

    Alternatively, as a less ugly solution, is it possible that objects could be given some other property — e.g. “CacheData” or somesuch — which could be set / read from script as required but which would not survive being taken into inventory? There would be no need for this field to appear in the “edit” window, and from script it would replicate the former behaviour of the “Description” field in that its contents would persist until the object was taken into inventory. Presumably it wouldn’t cause any additional load on the asset server, as it would just be preserving functionality that existed until now…?

  138. Nibb Tardis says:

    I fail to understand why, in this day and age, characters such as “|” are considered illegal. Why do simple things such as the script editor, object names and descriptions still not support international characters ?

    So the pipe character was broken, but why did LL choose to disable it altogether instead of actually fixing names and dscriptions to support more than plain ASCII characters ?

  139. Tormented Twilight says:

    Hey! Your bugs no longer work! We’re Mad! Rawr!

    ^ _ ^

  140. Pingback: Notecard Writing: A Modest Proposal « Evans Avenue Exit

  141. Anatag Paperclip says:

    I am just learning scripting for SL. I am absolutely gobsmacked that there is no persistent storage. LL are making the reflections off water look nice but not allow objects to have state? SL is a toy.

  142. Anna Tretiak says:

    Prospero @17: You say that the pipe character was “supposed” to be avoided. What do you mean by that? Was that documented anywhere? It would be nice if you guys could provide a comprehensive, stable and serious set of documentation for LSL, including limitations like that, rather than letting us LSL *users* to reverse engineer the language and create the documentation ourselves. Never in my 20 years of professional software engineering practice I have seen such a nonsensical approach.

    Also, why can’t the pipe be used? Any decent database system is able to store *any* character into a text field. You only need to escape it appropriately when embedding it in code. That thing with the forbidden characters is jurassic.

  143. Bucky Barkley says:

    What is really needed is llGetInventoryDesc(), which would allow for inventory names to be treated as keys, and descriptions as values.

    Vote for https://jira.secondlife.com/browse/SVC-377

  144. B. Shinobu says:

    I script in SL, and I do use the name and description fields as a data-storage. Fortunately, most of my scripts don’t use anything excessively long, but LL has severely limited its use as a data storage possibility. My sentiments have been echoed by many, even most, of the people who have written here, in that we need persistent data storage. Personally, I’m more concerned about that than I am about mono. I would also like to re-suggest a very plausible idea that someone else mentioned, and which I’ve actually thought of before, along with several other scripter friends of mine: an llGetText() function to retrieve the text stored in the floating text parameter of a prim. It’s already in existence, it has 255 chars of available storage space, and 255*255 = 65025 chars of storable information. Plenty for a “quick fix” as it was called. It doesn’t change over rezzes, is copied along with the prim, and all in all is a perfect candidate until an actual information storage property becomes available.

  145. B. Shinobu says:

    The idea I posted above has now been JIRAed.

    http://jira.secondlife.com/browse/SVC-1754

  146. Yacobheimer125 Voom says:

    Of course, they have to be careful so people don’t start making chat loggers…..
    Too bad though – saving to memory would be a great addition to LSL.

  147. Pingback: After the 1st February blues « Ananke Media Systems

Comments are closed.