Also, a notecard can be edited right in the object, no need to remove the notecard, edit, delete, and replace, just edit the notecard in place.
And.. you can sense a changed notecard, so instead of having a dialog choice to re-read the notecard, you can use the changed event...
default
{
// your code...
changed (integer change)
{
if (change & CHANGED_INVENTORY)
{
// someone edited the NC...
NCQuery = llGetNotecardLine ("your notecard name", 0); // get first line of NC....
}
}
datatserver (key query, string data)
{
if (query = NCQuery)
{
if (data != EOF) // still more data in NC
{
NC_list += data; // add the data to a list
++count;
NCQuery = llGetNotecardLine ("your notecard name", count); // get next NC line (retrigger dataserver event);
}
}
}
}
Also, instead of using notecards at all, depending on how much configuration data you need to save, you can achieve persistent data storage by simply scripting your script to store the settings in the object's description field. Object descriptions persist data if the sim crashes, or if you take/re-rez an object. So, if you're just saving settings, I'd recommend going that route. To do it, you must come up with a storage/retrieval convention, such as:
setting 1
etting 2
etting 3
etting 4
and write your data as a string, with some sort of separator, such as a colon in my example, then write it with llSetObjectDescription()
then, code your script so that on state_entry, it checks the object description, and reads the data in from the object description in the same order as it was written, and (I personally) usually parse the data to a list, then read the items off the list, for example
string settingsString = llGetObjectDesc();
settingsList = llParseString2List (settingsString, [":"], []);
then...
string setting1 = llList2String (settingsList,0);
integer setting2 - llList2Integer (settingsList1);
etc...
I use this to store the timezone offset, hours and minutes, and the state of the chime (on or off). It works great.
One used to be able to store upwards of 8k of data, but that was too good of a thing, so LL chopped it down to 127 measly bytes. Still, 127 bytes is plenty if you're just storing a handful of settings. So, if you can assemble a string of 127 bytes or less including separators for your settings, its the easiest for the end user, as they simply need to make menu choices, and that's it, and there's no fussing with notecards, especially for just a few measly settings. Bear in mind, object descriptions are visible to anyone who edits the object, so as far as storing information, you'd never want to store sensitive information, like email addresses, passwords, etc, using this exploit, or hack, or whatever you want to call it.
One last bit of advice using this sort of system.. create two functions, one called readSettings() one called writeSettings(), because when you're coding, you may find that you need to read/write the settings more then once. For example, a patrol bot I'm working on stores it's current next-waypoint in the object description (and the fact that the bot is up and running), in the object description after it hits each waypoint, so I'm reading/writing quite often. Also, it's good to read the current set, make the change you need to, then write the set. That way, you'll keep the other settings the same, as you're reading/writing the settings as a whole.
