LovingAndRejected

Jenni Darkwatch wrote: You can always have people "call" the script via linked message, returning the result with another linked message. Easy enough. yes but thats an asynchrounous call, and it's heavily limited by the length of the message queue.

true. What you really want is a synchronous call to a dynamically linked library function. However, such a concept has not been implemented in LSL.

additionally you can restrict the listener by saying llListen(MENU_CHANNEL, "", id, "");

ok, thanks for the input. i think i'll go with making the object mod-copy, leaving the scripts transfer-only.

steph, what i mean is, i have two seemingly conflicting goals (1) I want the user to be able to configure the application. Configuration must be persisted. Configuration must be user friendly. (2) I want the application to be non-modifiable to avoid user error and reverse engineering.

The only thing introducing lag is the loading of the texture. I cannot see how to avoid that.

OK, thanks. I think the easiest is to make the scripts somewhat dependent on the environment, and to release the objects as copymod. Still experimenting because on the recipient's side the permissions are all wrong. They are shown as no-mod, no-copy, no-transfer but the object is modifiable, but not copiable. Probably because the scripts inside are no-copy. Sigh. They really make it hard.

Thanks Rolig for the suggestions. Regarding the sending of notecards, are you referring to llGiveInventory()? I read on the wiki page "If destination object is not modifiable then inventory is not transferred and a Blocked by permissions error is shouted on the DEBUG_CHANNEL". But communication over a channel woulde be viable. The solution with a separate Mailman object would work no doubt. I'm just worried about the usability aspect. Don't forget I want to sell this solution, and configuration should be very very easy for the John Doe user...

Hi, have been searching for a while but seem not to find a solution... my use case first: i'm trying to create sellable objects that need non-trivial configuration. The only way I have found (correct me if you have a better idea) is to add full perm notecards because I want the user to be able to change it, and I want to persist those changes across script resets. I haven't found a way of persisting settings under script control either. The old trick of using the description field won't work due to the data volume. So notecards it is. First i thought full perm notecards in a no-mod object would do the trick. Unfortunately it appears that the user cannot modify full perm notecards in a no-mod object. But setting the object permissions to modifiable opens a can of worms: the user can then mess up everything, so basically I must make it copiable, too. The user cannot view the scripts, but he can reverse engineer the message link protocol by adding new scripts, and he can copy/transfer/delete the existing scripts. So I'd really like to avoid making the object modifiable. Is there any way around it?

queenkhaleesi wrote: How to set a particle to appear above and falls down to the ground? Need to make a rain or snow. Thanks The magic is in the parameters of llParticleSystem(). Admittedly the number of parameters is a bit daunting. The good news is, there is a cool Particle Lab in-world where you can study this effects of each parameter.

I spoke too soon, after some further changes the latest version started freezing too. I is not always deterministic, where the freeze occurs. it even happened inside llListSort() once. However. I did observe one thing I believe is the key: In addition to the currently processed item I kept an eye on llGetFreeMemory(). On one occasion I observed how the freeze coincided with free memory extrapolating to zero. According to the Wiki this should resoult in a script error "stack heap collison" being reported, but that does not happen for me, The quest continues...

shymus Roffo wrote: I have found the gimp plugin for GIMP that creates the one letter per face but i'm looking for the two letter face. If there is a plugin for photopshop, GIMP, or any other graphics program. Where can i find it? i know of the ones for zzText (note they're smaller than the xyText ones). I haven't tried it, but by moving to 1024x1024 you might get the number of textures down to 10... http://wiki.secondlife.com/wiki/ZZText

Thanks for all the advice and suggestions. In the end I refactored the code to make the data structures smaller. It now runs successfully with the given data volume. Regarding timeouts: that also is a valid point. However, it doen't quite explain the freezes I had experienced because the script should still react to touch events in the case of an outstanding dataserver event. I have in fact implemented a reaction to a dataserver timeout in the timer event, but ultimately I will only print an abort message. The problem is that all events have so little context at runtime that they must operate on global data structures, which is intrinsically dangerous in an event-driven concurrent environment (luckily the events are serialized in LSL but it is difficult enough). Neither do the events have knowledge about other events waiting in the queue, or can manipulate them. I am not saying it is impossible, but any proper solution of this issue will not adhere to the KISS principle that should be the basis of any design. As for the question in the title: it seems spraying llOwnerSay over the code is the only way of debugging, if the term "debugging" is even applicable in this case.

revochen Mayne wrote: . Because the dataserver event doesnt trigger when you use an invalid avatar key. cool. I'll investigate in that direction. This is definitely important information, whether it is the casue of my problem or not. Thanks.

Dora Gustafson wrote: It is hard to tell exactly what goes on without seeing some scripts My first guess is that you have an event buffer overflow Size of event buffer is 64 The way to debug in LSL is to insert lines(llOwnerSay()) at strategic points in the code, that report data status :smileysurprised::smileyvery-happy: ok, thanks, i'm doing the llOwnerSay already. My event buffer should not have more than one event in the queue at any time...