Ela Talaj

The most important thing in your code is that llSleep(0.005) is totally meaningless. You are asking the server to do something for 5 msec.That would require at least a 1msec system timer. It is very uncommon for a soft real-time system such as a SL server to implement a 1msec timer. Usually they have 100 msec timers. In which case the smallest timing window you can get is 200 msec. So the server simply substitutes 0.2 for your 0.005 anyways. The least important thing is that your code is not going to work whatever the timing window is because llSleep() tells it to ignore all events including the touch event. To keep your program design you might want to do something like below. Your design however is a very mediocre to begin with. I'm sure you can come up with a better one. //TRISTAN MADE A BAD SCRIPT! YAYYY //HI PERSON READING MY SCRIPT! float red = 0.0; float green = 1.0; float blue = 0.0; integer touched = FALSE; default { state_entry() { llSetColor(<0, 0, 0>, ALL_SIDES); llSetText("Touch to Start Color Cycle!", <1,1,1>, 1); } touch_start(integer detectednum) { if(llGetObjectDesc() == "0") { llSetObjectDesc("1"); llSetText(" ", <1,1,1>, 0); llSetColor(<red, green, blue>, ALL_SIDES); } else { llSetObjectDesc("0"); llSetColor(<0, 0, 0>, ALL_SIDES); llSetText("Touch to Start Color Cycle!", <1,1,1>, 1); } while(touched == TRUE) { //Becomes Red while(red < 1 && llGetObjectDesc() == "1") { red = (red + .01); llSetColor(<red, green, blue>, ALL_SIDES); llSleep(0.2); } while(green > 0 && llGetObjectDesc == "1") { green = (green - .01); llSetColor(<red, green, blue>, ALL_SIDES); llSleep(0.2); } //Becomes Pink while(blue < 1 && llGetObjectDesc() == "1") { blue = (blue + .01); llSetColor(<red, green, blue>, ALL_SIDES); llSleep(0.2); } //Becomes Blue while(red > 0 && llGetObjectDesc() == "1") { red = (red - .01); llSetColor(<red, green, blue>, ALL_SIDES); llSleep(0.2); } //Becomes Teal while(green < 1 && llGetObjectDesc() == "1") { green = (green + .01); llSetColor(<red, green, blue>, ALL_SIDES); llSleep(0.2); } //becomes Green while(blue > 0 && llGetObjectDesc() == "1") { blue = (blue - .01); llSetColor(<red, green, blue>, ALL_SIDES); llSleep(0.2); } //Cycles } } }

True in C, used to be true in LSO LSL but makes no difference in Mono, dunno why.

As comented by others above, there is no need of such user function because there is llListFindList() system call. There is however another problem with your code which I point out in here in hopes people would note and not repeat any longer. You call a system method to determine the list length in each loop iteration: for(i=0; i < llGetListLength(data);i++) {... } This wastes much resources. For instance if your list has 50 elements you are going to make 50 system calls. But only one is enough! integer n= llGetListLength(data); for(i=0; i < n;i++) {... } Some compilers are smart enough to catch a thing like that and optimize but not the LSL compiler.

My Freebies Vendor MPV-F does exactly that. https://marketplace.secondlife.com/p/Freebees-Vendor-MPV-F/593119 However I do not have a commercial vendor that would sell via the menu. This approach proved unfeasible as it is as easy or even easier for a customer to just scroll to a desired page using vendor's manual arrows and buy from that page.

There is no LSL method to change item permissions.

https://marketplace.secondlife.com/p/Freebees-Vendor-MPV-F/593119 This product may be configured to do exactly what you need

It is possible. Would be a variation of the infamous cage thingy. Make a transparent physical cage around an avatar then move it to target...with the "content" inside. A cage could be made on collision by firing a lil bullet at a nearby avatar. But I don't want to make a thingy like that, even if asked nicely

I have employed a mixture of Mono and LSL2 scripts in several products mainly for the reason of decreasing a product overall memory footprint. I started doing it from the onset of Mono and it's been working fine ever since. However it appears communications between Mono and LSL2 scripts are somewhat affected by the recent and still ongoing OS upgrades on the servers. Seems as if some linked messages from Mono scripts are not seen by LSL2 scripts. The problem first appeared on LeTigre 11.11.30 upgrade and became rather accute on BlueSteel 11.12.0 upgrade. I wonder if anyone else noticed anything similar?

Go to my marketplace page at https://marketplace.secondlife.com/p/Scripter-Resource-Kit-A/1932506 and get Scripter Resource Kit A. It is available for L$0 there. It includes a dynamic menu building API.

As I mentioned a few times before, LSL does not have a concept of pointer, it puts a whole object on the stack instead of a reference to it. So if your Mono script calls a user function with a 10K list as an argument and from inside the user function calls another one with the same argument you end up using 30K, not 10. Then if your script calls an LSL list methods from the inner user function, you need 40K to process the original 10K list. Considering that the execution code takes memory too, a stack-heap collision is almost inevitable when operating on just a 10K list unless the program is designed very carefully with a full understanding of this limitation.

Keep listens open only when they are necessary. For instance if your object sends a menu via llDialog() on touch or any event other than in-channel command, close the listen after a response is received or the menu times out (always time the menu response). The implementation looks something like this: UserMenuMethod(key user_id) { string menu_text = ...; // whatever the text is list menu = ...; // whatever the menu list is integer channel; while(!channel) channel = (integer)llFrand(123456789.0); handle = llListen(-channel, "", user_id, ""); // global handle llDialog(user_id, menu_text, menu, -channel); llSetTimerEvent(USER_WINDOW); // global parameter I usually set to 120 sec } default // or any other state { ... ... listen(integer ch, string name, key id, string mes) { llSetTimerEvent(0.0); llListenRemove(handle); ProcMenuCommand(id, mes); // user function } timer() { llSetTimerEvent(0.0); llListenRemove(handle); } touch_start(integer num_detected) // or whatever event { UserMenuMethod(llDetectedKey(0)); } } If there are other things to time, it may become a lil more complex but still doable.

As the previous poster noted it might be hard to help you unless you post the code

Is there a specific reason to display as hovertext instead of in IM on demand?

Can you possibly cite an example of the Marketplace upgrade that affected in any way your or anyone else's dashboard L$ balance?

Why does an object need to be physical to simply move up and down? Seems server load would be somewhat lighter if just using a regular non-physical object. llMoveToTarget() used to be more visually gracefull than llSetPos() because of 200 msec delay in the latter but since it is now possible to set position via llSetLinkPrimitiveParamFast() with no delay, it is no longer the case.

There got to be some difference however subtle between an open door and an invitation to throw paper airplanes thru it.

I only visit these forums occasionally and don't need any help writing scripts, seems doing well enough on my own Void does seem a nice person so I'm sorry if she left and even more sorry to say she's totally wrong. The Lab does not assign any unpaid tasks to volunteers; they do it on their own with no gun held to head and no strings attached. The Lab has every right to control its web site (and the last I looked it is secondlife.com) and remove whatever content at its sole discretion. To bother a CEO of a multi-million company with per case removal complains is not a reasonable action regardless by whom originated.

RGB-HSL conversion is very useful. Someone was asking me about it a few weeks ago but didn't want to pay for development so I didn't do. As for the rest of it, I'm at a total loss. Are you all saying that a long time contributor has decided to quit over some trifle, like a deleted msg??

Basically the LL HTTP Server scheme allows a script to process communications initiated by the off-world server. Communications initiated by the script can still use a regular llHTTPRequest() / http_response() event pair

If you have a list of UUID's the Rolig's timer method variation would be: timer() { textures_uuid_list = llListRandomize(textures_uuid_list, 1) // provided you have the list in the global variables string texture = llList2String(textures_uuid_list, 0); updateParticles(); // Where updateParticles is your own function that calls llParticleSystem to create the particles }

I don't know your general "programming level" so forgive me if I'm too simplistic here. When your computer is idle, your SL viewer resides on the hard drive. When you click the SL icon on your desktop it take some time for the viewer to start up before you see the login window. During this time the program is read from the hard drive into RAM, where it resides while the program is in use. The RAM data are temporary, when you turn off the SL viewer the RAM is cleared so something else could be put there, for instance your browser program. So every time SL is turned on a new copy is moved from the hard drive to RAM. RAM is the short term storage while used, the hard drive is the long term storage while not used. There is no difference between the above general scheme and the way your scripts should work. The notecard(s) is the long term storage (like the hard drive), the script memory itself is a short term storage, like RAM. When the object is rezzed (or attached) all notecard data are read into the script memory where they are operated upon. When the object is de-rezzed, it is all gone, so a new copy must be read from the notecards. But it is read once on rez (or attach) and remains in the script while the object exists. If there is much data you may consider one script devoted entirely to reading data from notecards and keeping in memory. Other scripts which actually operate on data would call this script via linked msgs when they need something and it will return requested data via linked msgs. In my products there is almost always a separate script for reading and keeping notecards data, usually called <system_name>_Config.lsl and a separate script for operating on data, usually called <system_name>_Exec.lsl. There may be more scripts than that and usually is, but the main scheme remains the same: Config initializes the system, that is reads data from notecards, and Exec requests from it such data as required for its specific state and operates upon them.

Most of my systems read configuration from notecards so I made a generic card reader a long time ago, which can be reused to read any notecard, all I have to do is to modify a list of parameter names and storage types from script to script. Then it sends all needed configuration to operating scripts in linked msgs. As it is only active on rez, restart and content change, all rather infrequent occurences, it doesn't have to be either fast or very efficient. Yet lately I'm more and more leaning to making instead open-source APIs, where users can define their own lists and even some user functions, then it all can be delivered to operating scripts the same way via linked msgs.

OOD/OOP is mostly a state of mind A language is just a tool to deliver your state of mind to a machine. Having time and desire one can write object-oriented programs in assembler. Actually that is what happens when you write in C++ : the compiler would translate it into an assembler code. So there is your OOP in assembler But the compiler has time (our minutes are its centuries or even millenia) and people don't. So high-level languages were created to quickly implement OOD. Basically they all do the same basic thing: allow the user to define user own data types. That's what all those fancy C++ clases are, just user-defined data types. In these data types user can combine data and methods operating on data and therefore define a real world object. Then a hierarchy of the data types is established (inheritance) and so on... Yet C++ retains all features of C, including totally programmer-controlled memory management. (that is why no garbage collection). A true high-level object-oriented language takes care of most memory management on it's own, transparent to programmers. In this respect LSL is a true high level object-oriented language.

Guess all hacks think alike I started using polling object description 3 years ago inside tight loops in my first systems because I didn't want to use 500 msec or less timer. I'm still not convinced that polling object description is less efficient than using timers with less than 1sec period and seen no data to convince me.

An interrupt is simply a means to deliver some real world event to the software. Whether they stop everything or are queued or whatever else depends on a specific system architecture. In LSL all events have the same priority and that priority is equal to that of the user code, so they are queued in FIFO and processed when the currently executing user code finishes. All this has really very little to do with the "language" itself and much to do with a server architecture. To my knowledge the terms "script" came from writing Unix shell programs in the ancient times before Perl Since then the difference between "script" and "language" became kinda blurred. The LSL is a fully blown hi-level object-oriented language with its own compiler and its own advantages and deficiencies. One of them is that it does not have low-level facilities but then neither does Java. I guess it is called "scripting language" because it is not universal but only runs on specific platforms.