![]() ![]() That method can be useful if you are reading, say, a data set for a a vehicle that's going to follow a long KFM path, like a tram, and you only need to stay twenty steps ahead of the notecard reader.Īn extended version using states to do this cleanly The helper script is therefore staying just ahead of the main script, "prefetching" data that the main script will need shortly and cleaning out data that are no longer needed. In fact, if your script memory is too small to hold the entire contents of the notecard at once, you can have the helper script read chunks of data at a time and then delete data that the main script has already used. Once that's done, the main script can go ahead and start using those data, while the helper script takes its time reading the rest. As long as you don't need all of the data from the card at once, the idea is to let the second script read the first few lines that you need immediately. What I suspect Qie had in mind was something a little more subtle, probably involving using a second script to be the card reader. That's what I meant when I said, " Most scripters will opt to read a notecard once, during a setup sequence at the start of a script, and never do it again.". The advantage with KVP is that once the information is loaded, you can access it instantly at any time from any script in the Experience. You access those when you need them with llReadKeyValue. ![]() ![]() If you are scripting something that will run in an Experience, you can store your information in KVP records. Then use llMessageLinkedand some carefully-written routines to access specific bits of the saved information later.Ī final option - one that I prefer but is restricted - is to forget notecards entirely. As long as you don't need the information during the first 10 seconds after startup, you can do other things for a while in your main script while you're waiting. As long as you don't ever reset the script, the information will remain in the script's memory.Īnother option is to use a separate script to read the notecard and store the information in itsmemory until you need it. Most scripters will opt to read a notecard once, during a setup sequence at the start of a script, and never do it again. So, if you have 100 lines to read off a notecard, you can expect it to take a minimum of 10 seconds on a lag-free region. ![]() If you look at the entry for llGetNotecardLine in the LSL wiki, you'll see that the function has a built-in 0.1 second delay. We are also rescued by the invariant that objects cannot have the same name in the inventory which eliminates hash collisions on same names. Since 293 does not equal 289, it deletes 289 such that the description reads:Īs you can see, by XOR-ing with the position of the character in the name of the notecard we can avoid collisions in palindrome cases. In case we now delete the notecard named aab, the script will start to compute the hash of the notecards in the inventory. If we read the baa notecard, the description will now read: If we now add a different notecard, named baa, the dropbox script will update the description to: After reading, the script will update the description to: Now suppose that we read the notecard by touching the object and requesting it. The script will thus update the description to: This allows us to determine which notecard was deleted because, in case of a deletion, the string in the primitive's description will not have the same hash numbers such that we delete from that string whenever we have a mismatch.įor example, suppose that we drop a notecard named aab into the dropbox. Whenever a notecard is read, we generate that hash and concatenate it in the primitive's description. More precisely, for a notecard named aaac the hash stored will be 296. Secondly, to track "read" notecards, every time a notecard is sent to an agent, we generate a hash of all the characters of the notecard name, using Pedro Oval's Ord function, plus its index in the name. To address the first challenge we use key-value data storage to store a CSV serialized string in the primitive's description, thus making sure that the data is still there after a simulator restart. Secondly, LSL does not report which notecard has been added or deleted - it only triggers the changed event handler and with the INVENTORY_CHANGED flag we can only know that something in the inventory has changed. Firstly, if we were to use the script memory to store the notecard names and their read status, after a restart that data will be gone. There are some particular challenges to this script. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |