|
|
|
I agree. The limit to 64 characters was a drop by four orders of magnitude. A bit extreme.
Even very large scripts have at least 2 to 4k free. Object name is limited to 63 characters and description to 127 characters.
I warmly second this... My boards are using object description to pass parameters among link set in a consistent way, and 127 chars are not enough to pass a "board page" which if using utf-8 (and especially llEscapeURL, since lindens now DONT allow using utf8 in a consistent way in object description). So a simple 50 internationalized string might overflow easily the limit (1 char can be 9 real chars when urlencoded: %e2%e8%ec or something like this)...
Should I file also a request for re-allowing utf8 characters in object description? 
Won't finish - The sizes where chosen deliberately - the fields aren't designed for long data storage.
Re-Opened
I understand that you need to limit the size for storage in mySQL. However there is no reason to limit it this small when in-world. In fact it could hold an unlimited amount inworld until last year when someone lowered it. For years now people have been making scripted items that pass or store information as part of their processing in the name and description. Alternativly you could let us create global valiables that can be seen by other scripts. ie. Until we have a shared memory space between scripts the quick fix is to let us have longer in-world names as we previously did. It is more than just limiting the size for storage. It was also causing inventory loss (SVC-674) and being exploited to crash other scripts (see Scripters : Object Name and Description Changes
 . The script crashing would only happen if you cramed around 8k of data into the name.
Most legitimate uses of it were putting 1-2k of data in there. the same amounts that we see in HTTP responces and emails. There is no reason an in-world onject cant be permitted to store 2k at the most. Eventually LL cuts off all possibilities to store in a simple way some prefs for a scripted object and does not gives us any alternative. That's somehow frustrating. Can you understand that?
I beg to differ when you say "there is no reason" Darling. When the user hovers their mouse over the object the name has to be transmitted, a short name can fit in a single packet but a longer name and description may take several. This in turn decreases response time, and increases lag. Possibly the worst part about this is the information being stored isn't even intended to be read by a user; so when a user stumbles upon it, they are left saying "WTF???" which isn't a good user experience.
Lets examine the score: Pros:
Cons:
I feel the pain here, but this isn't the right solution to this problem. We need some form of persistent script memory. Lag? Are you kidding me? what are the odds that someone will however over it while the data is being passed though the description?
...anyway, those in the know use a child prim so the data is not confusing, and so link messages transmitting it can have their scope limited. the rest of the cons are irralavant because they are true for long or short names. I agree we need some kinda of meta data storage for objects that can be set by scripts, but until we get it we have to use what we have. More to the point the unnessisarily harsh changes have broken content when they didnt need to. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Object name and descroption limit is now too small
Many of these scripts clear the description after they have finished, which is why I was not sent a warning email and why my grid wide teleproter network failed without warning.
Clearly long object descriptions dont corrupt the asset servers as they have existed for many years now, so there is no reason why we cant have 1k or 2k of memory space in the description to prevent legacy scripts from failing.
This is not only an issue of having extra memory space, it is about the ability to reset a script and still have some dynamic startup perametors, as apposed to static startup parametors that can be read from a notecard.
Darling Brody - Teleporter scripter, sadly known for making a weapon