Scripters (myself included) have long bemoaned the lack of any way to write text to a notecard. You can read text from a notecard (although it’s a PITA due to LL’s non-blocking dataserver lookup; and it’s also apparently not possible with notecards that have any embedded inventory items like landmarks), but there’s no way to write to it. That means you can’t save script settings or data to a notecard so that they persist between script resets.
Scripters, being naturally clever folk, have instead relied on the fact that you can change an object’s name and description. So, just save the settings/data to the object’s description, and it’ll be there the next time the script runs! This was especially handy because the servers have previously allowed much longer descriptions to be saved than they were supposed to.
Of course, anyone who has been following the Linden Blog should now be aware that the name/description size limits will now be enforced. I won’t say much about that, except to note that this is another instance of “Very useful exploit-turned-essential-tool that occasionally caused problems, so the Lindens removed the tool rather than fixed the problems”. See also: Megaprims.
What I’m more interested in right now, is the excuses the Lindens give about why we’re not allowed to write to notecards. For example, Prospero Linden wrote:
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.
I call bullshit.
Recent Comments