Lillani Lowell Posted November 19, 2022 Share Posted November 19, 2022 I wanted to start an additional thread on this, because I think it's an important topic. As someone who is building new, plug-in systems for items (like my Action Engine which is getting a linkset data update) I kind of want to give an overview of how I am treating linkset Data. When it comes to content creation, we often don't know what other scripts/plugins/etc will be included in our items-- we don't know what things we have to share resources with. So, being aware of your own Linkset Data usage and how it may interact with other people's usage is very important. In self-contained, no-mod items it's not really a worry... but in things like furniture, attachments, houses, etc, there are some serious things to take into consideration because Linkset Data is global. Here's my self-imposed rules for being a better contributer to the global eco-sphere and making my own scripting life easier in the long run: 1. Never use llLinksetDataReset(). This could, in many ways, break products you cannot foresee how people are using... or what scripts may be sharing your use of Linkset Data. You can't predict what plugins, modifications, or whathave you people are doing with your product. In a world of custom content, telling people "they can't" is bad form... so, if they can't, make your object no-mod, and be done with it. 2. Use your own, personalized identifiers... it might be nice to easily reference a entry called "uuid", but someone else's three other scripts could also be using that entry for other things. So, I will always be using unique identifiers in front of my keys like (example) "_dictLLEnt_uuid"; this makes the likelihood of someone else over-writing my uuid entry for something entirely different and unrelated much more unlikely. 3. Keep track of the keys you use, and delete them when you're not using them. If you are using personal identifiers like I do, to easily clean up your own script's keys you can then easily have a little function that looks up any key with your unique identier. For instance, all I need to do is find all my keys starting with something like "_dictLLEnt_" and delete them all instead of keeping track of each one, or using a linkset data reset. It helps keep the Linkset Data clean without having to a data reset. This will save you and others a lot of future headaches when Linkset data is shared across scripts. I mean, do you want your reset to break someone's product because of another script's use of the data? Nah, you don't want that on your hands. So, clean up after yourself, it's only polite. 4. Don't hog the linkset data. I know it's great to use new and shiny tools, but only use as much as you actually need. If you're not running into memory issues, or it's not reset critical. Why not keep it out of the linkset data? There's no need to keep owner uuids in a linkset... that's built into LSL, etc. Don't use it as a database to store a lot, or large objects if you ever expect your scripts to play nice with other scripts... sharing is caring. I know there's probably people wanting to build furniture engines using that; and I can give you 20 different reasons why it's a really bad idea from the start. Anyway, these are my own personal rules, but I thought others might take some wisdom from the perspective. And please feel free to add to this, if you feel there's something useful you can add to the shared use of linkset data to make all our lives a little easier with this shared object resource. 3 Link to comment Share on other sites More sharing options...
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now