Another person with the identical object in his inventory will have another pointer to the same data on the asset server. 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. Locke 29 : assets are designed to be static. Of course, as long as the script is not restarted or reset, it’s internal state (variables) is kept. The best way to store persistent data from a script is indeed on some sort of external storage system. 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. 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 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. Re: storing persistent data : the way the asset sever works, a UUID is a unique identifier to an asset. 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. Objects that used and depended on the | character would break if taken into inventory. The fix here was the scripted setting of the obejct name and description to make everything consistent. LSL WIKI OFFLINE CODEThe code everywhere else assumes it’s not there. I don’t believe that use of the | character was notified.ĭrako 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. Miles 14 : the notifications went out to people who were found to have particularly long names or descriptions. Guess everyone in sl needs to rent a website that supports php. that discussion exceeds the scope of this thread. such capabilities would provide the ability to grow secondlife into a platform that does more to protect intellectual property. What we really need is a robust metadata design to allow us to define the metadata necessary for objects. 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. Seems rather complicated when dumping state to a notecard would serve the purposes. the database gateway object would handle the http requests. my recommendation is to use a router type device to queue the messages which are then transmitted to the database gateway object. So you will have to rely on shipping data out to the internet and use your own databases for persisting memory. persisting state data to a notecard would be much more efficient, faster, and more reliable provided the asset system is stable. Giddy looks like you will need to develop your own tiered system to ship data in and out of secondlife. 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. 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. 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. Previously, this was possible, but once again these characters would be lost if the object were taken into inventory. Similarly, the object name and description can no longer be set to include the pipe (|) character. 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. 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. Previously, these functions would let you set longer names and descriptions for objects rezzed in-world. With the new 1.19.0 server, these limits are enforced when the fields are set using the llSetObjectDesc() and llSetObjectName() LSL functions. The name field is limited to 63 characters, and the description field is limited to 127 characters. There have always been limits on the length of the “Name” and “Description” fields on objects.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |