Jym Nova

True, just adapt it: instead of grabbing them all list my_list = llLinksetDataListKeys(0,-1); grab segments: list my_list = llLinksetDataListKeys(0,20); //llLinksetDataListKeys(integer first, integer count);

It's only live on certain regions: Aditi Mainland regions: Blake Sea - Arabian Blake Sea - Atlantic Blake Sea - Beagle Blake Sea - Binnacle Blake Sea - Black Gothlauth Jigglypuff Mauve Moonberry Sapas Smithereens

For a use case such as cache, you could simply just store those values like normal, ( llLinksetDataWrite ), and for your functional values use protected ( llLinksetDataWriteProtected ). Then just run a loop to clear the "cache". clearCache(){ list my_list = llLinksetDataListKeys(0,-1); integer i = 0; for(i; i < llGetListLength(my_list); i++;){ llLinksetDataDelete(llList2String(my_list,-1)); //using "-1" for hopefully obvious reasons } } It's not perfect, but it'll get the job done. (Of course I would hope that if protected keys are returned they would silently fail with this example to not stall the script)

Does that mean Agni? or all regions on Aditi?

Pretty sure my concerns have been addressed one way or another. I just want it live on Agni now. LoL

I love this idea! OK, I will gladly stand down from my suggestion to negate Protected Data from llLinksetDataReset. I didn't even think to do it in reverse. I could definitely include a script to re-add the linkset data for recovery purposes.

I agree with this 100%, however; let's say I want an object to be modify for something like resizing "without" a resizer script or resizer functions plugged in to the existing script. Why should "my" script suffer at the expense of someone experimenting with scripts and wiping protected data "my" script needs to effectively operate in the object? I'd have no objections to including a standalone script in the same package as the product to use something like: "llLinksetDataResetProtected(string pass);" (if its implemented) if the end-user decides they don't want my script in it, so they can recover the full 64KiB of LSD. I'd also have no objections to including a copy that doesn't have a script in it all, depending on what it is.

I do get your point, mostly, however; if your use case would allow for stale kvp to be removed then you'd also have no reason to use: llLinksetDataWriteProtected(string name, string value, string pass); llLinksetDataReadProtected(string name, string pass); llLinksetDataDeleteProtected(string name, string pass);

And you're missing my point: We also need a way to protect everything.

Don't use a password you're going to forget.... (you're probably going to have a variable in your script with the password anyway, what's the harm?) Or maybe some other alternative that disallows "end-users" to possibly corrupt a modifiable object if they decide to add a script with llLinksetDataReset. like: llLinksetDataResetProtected(llGetInventoryCreator(llGetScriptName())); That's a terrible example, but something that won't let an end-user wipe your data. I still stand by my original suggestion: llLinksetDataResetProtected(string pass);

Not 100% unless your "object/linkset" is no modify for next owner.

This is great to an extent, I was going to say, I read through the first 4-5 pages and didn't see my concern(s). Of course I'm not seeing the details of the 3 new added functions either. I strongly disagree with "Protected keys are removed by a call to llLinksetDataReset." Maybe negate protected keys & values by adding: llLinksetDataResetProtected(string pass); #1 is Security, should I decide to distribute a "modifiable" object, anyone can read the data. `llLinksetDataRead` which appears you have managed a solution: `llLinksetDataReadProtected` What about: llLinksetDataListKeys? are protected keys negated or still fed in to the list? > Not good if the data is meant to be private. (I foresee this being great for HUD's though, since they will almost always be no modify) (I don't care if they want to count how many keys I have or know how much data is available) #2 is Persistence, should I decide to distribute a "modifiable" object, anyone can wipe the data. > Not good for modifiable objects if you want persistent data. `llLinksetDataReset` currently would wipe all data, even the protected keys.

@Patch Linden Closer SL/LL integration could maybe lead to Direct Delivery like the marketplace? "Out with the drop boxes!!" Would be a nice upgrade/improvement. (At least for CasperVend)

Too many reasons and risks to just downgrade to basic automatically. If you had a Linden Home and let's say a few mainland parcels, 100's or even 1,000's of objects on these parcels. would you want all the land seized and your objects returned? And then there's the business aspect, the income loss for those people who get that free month before the land is seized and objects returned.

Well.... I'd like to add some of my own input based on the original post since so many have strayed and are now posting random and irrelevant information.... It's great you're reducing tier on Private Regions again, but now you're getting too close to Mainland pricing, so you really should reduce mainland pricing again as well. Although this really only benefits large estate holders to an extent. Being this is a public announcement, I am sure there will be many "Residents" who are going to assume and might even think tier prices should be reduced for them as well. Which actually makes it more of a burden based on the fees that have increased to accommodate the new tier prices. I can partially understand increasing the Premium prices, but at the same time it is a disappointment since MMO's that also have a subscriber base aren't raising their's. However, I am not against it if it's worthwhile. You have added a lot to premium perks, but you don't know if that's what we actually want. Speaking for myself, I would have preferred a larger stipend say 500L$ rather than 300L$, I appreciate the 1024 vs the 512 free land capacity, can't say much for the new Linden Homes since I can't get one, not all of us use experiences (some lack the knowledge to do so), I don't care about animesh (as premium we get 1 additional attachment? Who really cares?), and lastly, I personally don't need 10 more groups. Now speaking of groups... I completely disagree with limiting Basic members to 35 (from 42 - 7 group difference) and rewarding Premium members 70 (from 60 + 10 group difference) when you clearly state - and I quote: "groups really are quite a strain on our back end for a variety of painful historical reasons, including overloading group functionality instead of having other tools". If this is such a problem, fix it... You'll likely have better results with the Basic members which severely outweigh those of us whom are premium. I'm not suggesting being "Robin Hood" taking from premium to give to basic, rather that you just leave that alone. Process Credit Fees: Not even sure where to start with this, I realize cost of living increases and such annually, but the prices are getting a bit absurd. This is the second time you're raising the fees in the last 2 years and it's not a little change, you're doubling it. From what I can remember, it started at 1.5%, $3 minimum, $15 Maximum, moved to 2.5%, $3 minimum, $25 maximum, and now 5%, $3 minimum and NO maximum. As a business owner, I may have to raise my prices to stay in business and hope my customers understand the reason why I am doing so and I will need to hope they also remain loyal so that I won't have to close my doors. P.S. What's taking so long with getting the last name change ability?