Jenwen Walpole

I have some code I wrote that might help some understand how to use llGetNotecardLineSync Please feel free to comment. ///// // Generic llGetNotecardLineSync Notecard reader by Jenwen Walpole // Given freely // // This will read a notecard and insure notecard line read happens succesfuly // no matter if the notecard is cached or not. // The code will make use of cache reads for as long as the notecard is cached and use llGetNotecardLine when not. ///// integer iNoteCardLine; string sNotecardName = "mynotecard"; key kCurrentDataRequest; default { state_entry() { } touch_start(integer total_number) { iNoteCardLine = 0; // reset back to zero in case there was a prior read // first line read is conventional llGetNotecardLine read to make the server cache the notoecard. kCurrentDataRequest = llGetNotecardLine( sNotecardName, iNoteCardLine ); } dataserver( key kQuery, string sData ) { if (kCurrentDataRequest == kQuery) { if( sData != EOF ) { llOwnerSay(sData); } else { llOwnerSay("EOF"); return; } iNoteCardLine++; while (TRUE) { sData=llGetNotecardLineSync(sNotecardName, iNoteCardLine); if (sData == NAK) { // on a NAK reread using llGetNoteardLine // this will both re-cache and succsesully read the line llOwnerSay("NAK"); kCurrentDataRequest = llGetNotecardLine( sNotecardName, iNoteCardLine ); return; } if (sData == EOF) { llOwnerSay("EOF"); return; } else { llOwnerSay(sData); iNoteCardLine++; } } } } }

this is what development is all aobut - onward and upward! interesting how the scripts errors out when you have to re save..good that it does that when the fuction changes, it makes you think aobut it.

I vote 1 and 2 - see details in my earlier message on linkset_data action codes.

additional note / thoguht: you could also be a bitmaped response for linkset_data event action - but i suppose(and just by accedent) 1 and 3 responses above allow it to be ANDed with a 0x01 to determining any write occured. ... if thats an intentional thing then it sould be called in the docs with an example or just make the responses bitmaped 0x01 0x02 0x04 0x08, bitmap might make more sense then you could have the following LINKSETDATA_RESET 0x01 The linkset's datastore has been cleared by a call to llLinksetDataReset. LINKSETDATA_WRITE 0x02 A key in the linkset's datastore has been wiritten to llLinksetDataWrite LINKSETDATA_DELETE 0x04 A key in the linkset's datastore has been deleted. Either through a call to llLinksetDataDelete or llLinksetDataWrite with an empty value LINKSETDATA_CHANGE 0x08 A key in the linkset's datastore has been assigned a new value with llLinksetDataWrite where on a change both LINKSETDATA_WRITE and LINKSETDATA_CHANGE bits would be set. and if it was written to but not changed only the LINKSETDATA_WRITE would be set. this way a simple 'AND' in your event logic can filter for whatever you want. seeing as your most likely filtering your event anyway... (edits for typoo's)

I suppose you could give just as much creedence updating a KVP with the same value just to force an event.don't get me wrong, its nice to know of a KVP changed vs just was written to and there is no change. if you were going to do this at all, then why not have the event state if it was a new value or not. linkset_data action constants example: LINKSETDATA_RESET 0 The linkset's datastore has been cleared by a call to llLinksetDataReset. LINKSETDATA_WRITE 1 A key in the linkset's datastore has been assigned the same value with llLinksetDataWrite LINKSETDATA_DELETE 2 A key in the linkset's datastore has been deleted. Either through a call to llLinksetDataDelete or llLinksetDataWrite with an empty value LINKSETDATA_CHANGE 3 A key in the linkset's datastore has been assigned a new value with llLinksetDataWrite (typo edits)

I am for whatever will give the better performance. If there has to be an internal read before write to acomplish not generating the event and if that read will slow down the wirte / delete performance then id rather generate the extra events if event handling is enabled. Though i think that the scipter should have the option for not generating events in the first place for given write/delete operation (asumeng there is an event handler).

added it as an aternate proposal to the jara

i had a re-think on this, see the proposed llLinksetDataWriteNE, llLinksetDataWriteProtectedNE, llLinksetDataDeleteNE, llLinksetDataDeleteProtectedNE fuctions. the reson i am thinking this is better is that it likely saves a read of the flag which is likely stored with the key and would ahve overhead. alternatly it could be a flag on the fuction to indicte generating and event or not. like Function: integer llLinksetDataWrite( string name, string value, integer flag ); but that would be hard to implement later, and would need to be done before release otherwise people ahve to re-write code. the NE fuctions i proposed above could be added now or later without much fuss.

@Rider Linden @Tapple Gao and anyone who is interested i've had a think on the whole linkset_data event overflow situation on mass updates.. what i think would be an easier to implement and more flexable soltuon is to have write and delete fuctions that do not generate events. so you can simply use those fuction when nessisary and still have events when you want / need them. SUMMARY. Becasue linkset_data event is for any keys updated or deleted. unwanted or events not needed can be generated. in example, if updating a large nubmer of keys at once you could over run the event queue. or if you only need events for specific keys, So there are times when you want to update or delete keys but do not want to generate events. the llLinksetDataWriteNE, llLinksetDataWriteProtectedNE, llLinksetDataDeleteNE, llLinksetDataDeleteProtectedNE functions work the same as llLinksetDataWrite, llLinksetDataWriteProtected, llLinksetDataDelete, llLinksetDataDeleteProtected except they would NOT generate events. Function: integer llLinksetDataWriteNE( string name, string value ); Function: integer llLinksetDataWriteProtectedNE( string name, string value, string pass ); Function: llLinksetDataDeleteNE( string name ); Function: llLinksetDataDeleteProtectedNE( string name, string pass ); Thoughts? (edits were typo fixes)

My view is that having an all or noting event structure for keys would be a bit to broad if have 1000's of keys. Your scipt could spend a lot of time ignoring events it dosnt need and pootentaly shortening your event queue un nessiarly. i would invision having both the first and second methods, but there use would be for diffrent reasons. you may need an event handler for just one key or a small number of keys, Also being able to diable all linkd date events for situations like mass updates to prevent event queue overrun. i would agree you would not want to use tirning off single key events in a methodilogy to disable all the key events by disabling them one at a time.

Because you can have so many keys, it be nice if you could just enable/disable events on specific keys. Also along those lines perhaps the abilty to enable / disable all linkset_data events so that when your doing mass updates to many keys your can disable generating events. Thoughts?

i've tested this and I can confirm that the data does survive a shift + drag copy

great work kahda, one of the things i am curious about is if the amount of space effects performance at all, though i suspect it will have no impact. I mgiht check that anyway. i also noticed perormance variations run over run. when doing them conscutivly .. i just asumed that it was the luck of the draw on the slicing and other thigns takign up scipt time. I see the iops go down as expected as the data size goes up..but the bps goes up. it be interesting to graph for the bytes per sec or kbps. I .just did a rough calcualtion for and if my calulations are right you were about 10x higher data thoughput at 1024 over 8 bits, even though the number of operations/itterations droped to 1/10th

wow ... it is a LOT faster then i expected. back of the matchbook testing ot me 1,000,000 copies of a 10 char linkset data to a local var in 0.085416 milliseconds and just for fun, becase it was so fast i did the same copy but from global to local var in 0.000156 milliseconds just to see the comparison. ymmv This is going to repalce a lotta link message stuff i am doing and config file handling. PLUS the extra fuctionality of persistant data and more var space. .. my head is spinning wiht ideas

thanks