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...

I seem to have this issue with a few of my scripts (particularly those collecting data). The present one freezes in initialization phase. In the test scenario it generates roghly 300 dataserver events, sequentially (ie. each new request is created in the dataserver response to the previous event). First roughly 100 llGetNotecardLine(), then 100 llRequestAgentData( ... , DATA_BORN ), then then 100 llRequestAgentData( ... , DATA_NAME ). The data are stored in strided lists. it appears that after 250 events or so the script just freezes. No output on the debug console. What are my options to debug the situation and get a better understanding of the nature of teh problem? if it's the data volume i could probably make the lists smaller by moving from key indices to integer indices, but I would really like to understand what is going on first.

LepreKhaun wrote: Your logic is flawed in that you are failing to see how the llListenRemove(); call at the very first of the touch_start() event handler precludes another listener from being registered. As I said, you need to study this a bit more deeply. OK, you are right that in the wiki code a later touch event will remove the listener for a previously created listener belonging to another user. Therefore in the wiki code the issue of multiple open listeners will not occur. In that respect my analysis was wrong. What will happen of course is that the dialog will go dumb on the users that have clicked on the prim beforehand and whose dialog is still open. That is poor user experience by design. To me it is still preferable to create a single listener at initialisation time. Not 65. I apologize to all those people who were so alienated by my attempt to be helpful that they felt the need to become condescending.

It's not an either or, since mathematical logic is an art in itself... Programming definitely is an art, hence Donald E. Knuth titled his classic books "The Art of Programming" Truth is, there are wildly different ideas about what a good program should look like, or what programming paradigm is best. To me the essence is that everyone tries to attain a certain sense of beauty. A program is good if and only if it is beautiful. If it looks and feels like spaghetti, or the labyrinth of the minotaur, it most probably is faulty, too ^^

Thanks Cerise for pointing that out. Yours was the most helpful comment so far. I have worked out how to sign in and I have added a paragraph on the "disussion" tab. Depending on the feedback i might edit the main page at some point, contributing to an overall improvement in content quality.

@LepreKhaun: sorry, i have you know it is you who hasn't understood the issue yet. it is irrelevant if you preventively remove the listener whose handle happens to be present in gListener in the touch_start event. The problem is this: at any point in time you can have multiple listeners attached because any number of users can click on the prim. But your script has only one global variable to keep track of it. The tutorial you pointed to is flawed in the same way as the llDialog documentation. @Rolig Loon: thanks for trying. My idea of a fixed version would be similar to this: // When the prim is touched, give the toucher the option of killing the prim. integer gListener; // Identity of the listener associated with the dialog, so we can clean up when not needed default{ state_entry() { // Set up a listener for potential llDialog() calls // it might seem like a waste at this stage, but overall it is way more efficient // than trying to track listeners on a per-user basis gListener = llListen(-99, "", NULL_KEY, ""); } touch_start(integer total_number) { // get the UUID of the person touching this prim key user = llDetectedKey(0); // Send a dialog to that person. We'll use a fixed negative channel number for simplicity llDialog(user, "\nDo you wish this prim to die?", ["Yes", "No" ] , -99); } listen(integer chan, string name, key id, string msg) { // If the user clicked the "Yes" button, kill this prim. if (msg == "Yes") llDie(); }}

erm, I think a few posters here are getting the wrong end of the stick. (1) Yes i am aware it is my responsibility as software developer to take care of it and i am perfectly capable of doing so. The obvious solution is to create a static listener llListen(menuChannel, "", NULL_KEY, "") to avoid the tracking of listeners per user, which is relatively clumsy in LSL. (2) The point was that the wiki contains bad code which undoubtedly has been copied many times because the flaw is not obvious (3) Regarding the wiki content: there is no edit button. Therefore my question how to go about it. If I were to correct it, I would insert the solution outlined under point (1).

for instance, http://wiki.secondlife.com/wiki/LlDialog contains a code snippet // When the prim is touched, give the toucher the option of killing the prim. integer gListener; // Identity of the listener associated with the dialog, so we can clean up when not needed default { touch_start(integer total_number) { // Kill off any outstanding listener, to avoid any chance of multiple listeners being active llListenRemove(gListener); // get the UUID of the person touching this prim key user = llDetectedKey(0); // Listen to any reply from that user only, and only on the same channel to be used by llDialog // It's best to set up the listener before issuing the dialog gListener = llListen(-99, "", user, ""); // Send a dialog to that person. We'll use a fixed negative channel number for simplicity llDialog(user, "\nDo you wish this prim to die?", ["Yes", "No" ] , -99); // Start a one-minute timer, after which we will stop listening for responses llSetTimerEvent(60.0); } listen(integer chan, string name, key id, string msg) { // If the user clicked the "Yes" button, kill this prim. if (msg == "Yes") llDie(); // The user did not click "Yes" ... // Make the timer fire immediately, to do clean-up actions llSetTimerEvent(0.1); } timer() { // Stop listening. It's wise to do this to reduce lag llListenRemove(gListener); // Stop the timer now that its job is done llSetTimerEvent(0.0); } } This code is fatal when more than one user have a dialog open at the same time, as there is only a single global variable to hold the active listener handle. The last user to click on the prim "wins" in the sense that whoever closes the dialog first will remove his listener. All other listeners remain active till kingdom come. If you don't believe it you can verify it with the following snippet: integer menuChannel; integer menuListener; default { state_entry() { menuChannel = 9; } touch_start(integer num) { llSay(0, llDetectedName(0) + " has touched the box"); key user = llDetectedKey(0); menuListener = llListen(menuChannel, "", user, ""); llSay(0, "menuListener = " + (string)menuListener); llDialog(user, "When to remove the listener?", ["Now", "Timer"] , menuChannel); llSetTimerEvent(15.0); } listen(integer channel, string name, key id, string msg) { llSay(0, name + " has selected " + msg); if (msg == "Now") { llSay(0, "removing menuListener in listen event = " + (string)menuListener); llListenRemove(menuListener); llSetTimerEvent(0.0); return; } if (msg == "Timer") { llSetTimerEvent(0.1); return; } } timer() { llSay(0, "removing menuListener in timer event = " + (string)menuListener); llListenRemove(menuListener); llSetTimerEvent(0.0); } } with this snippet every user can check if his listener is still working by saying /9 test. The same fundamental flaw is present in the tutorial http://wiki.secondlife.com/wiki/Dialog_Menus Question: how to address this issue to the Wiki authors? --||-