|
|
|
Well, maybe it isn't a simple path, but it would seem to me, if 13 objects were dropped at once, that should only trigger a single change event, but would generate a list associated with that change of all the items added.
It would seem bad to have it not be able to queue at least a few. Not only that, but it seem that the second object being able to make it into the inventory would be dependent on someone's code in LSL (possibly in multiple scripts), which that really seems like a case for disaster. Quite a few people write VERY BAD LSL code, myself included occasionally Hmm, even with a list, the memory overhead of that could be very large as well. I have a "TV" with a slideshow of some 521 pictures, with a script to allow me to switch categories etc. If I were to put 100 more pictures into that script, the list describing those new items would be huge without some kind of throttling (to prevent the items arriving until feasible) as I described.
I see the scaling problem. Maybe there could be another piece of information (like email has) stating that there is more data to be recieved. That way a certain number could be queued (say 10-20) and put in the list, and the rest of the list could be gotten with detected sequence or another method.
Or maybe a function to call on a changed event to get more change information like. llGetChanged(integer number) that allows you to get information on the changed items (like llDetectedKey and others). I would also guess there would be other issues because if you drag a large number of objects into an Agent's inventory you get a message saying something about preview being disabled or some such. I'm not sure how that would factor in. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
additional change event information
1. Request sent to simulator to add item 1 to object A
2. Simulator accepts and triggers the changed() event in all scripts
3. Once scripts have completed, the simulator returns a success message to the client
4. Request sent to simulator to add item 2 to object A....
ie - each item is sent one-by-one and another is only sent once the changed() event has completed executing.
This way the object never misses a changed() event, though it slows down dropping of large lists of items. It would then make such a facility as you're suggesting more workable, as you could then call llDetectedKey() to get the avatar who triggered the event and things like that. Plus an llDetectedSequence() perhaps which (in the case I described) would let us know if this changed() event is one of many that are coming, and how many more will be coming.