Ela Talaj

If this is indeed the first try, it looks pretty neat. Your only error is that object names are not keys they are strings. A key is a special kind of string, 36 bytes long which is used for objects (or agents) uuid's only: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" As it is still a string, the compiler is pretty liberal to assigning a string value to a key variable and vice-versa but at run time it may create problems. I modified your script in a slightly different way than Rolig, to demonstrate that there're many ways to skin a cat default{ collision_start(integer num_detected) { integer i; for(i=0; i< num_detected; i++) if(llDetectedName(i) == "PlatformOne") { llSetColor(<0,1.0,0>,ALL_SIDES); llWhisper(0, "Correct!"); } else { llSetColor(<1.0,0,0>,ALL_SIDES); llWhisper(0, "Sorry, that's incorrect!"); } }}

Go to the Marketplace and get my Scripter Resource Kit A It is free and contains open source menu API to make a menu to use either for main menu or a submenu.

All states are equal, Stephania, and none is more equal than others. "default" is simply where the server starts execution after it loads the script in its memory. It is basically the same as "main" in C/C++. When a program is booted the loader looks for "main" to start execution, but more often than not main simply creates child processes which run on their own and never return to main. By the same token LSL default state may immediately pass control to another state and the thread never returns to default unless llResetScript() is executed. Each state consists of events processing, there is nothing else to it. An "event" is simply a signal processing function. When something occurs, like an object is touched or collision is detected or a message is received the server sends a respective signal to the script in whatever state it may be. The server always sends all signals but whether or not they are processed by the script depends on if there is a processing function in the state the script is in. For instance in your script there is changed event in the default state. So if the script is in the default state, this event will be processed and control will be passed to Exterior_teleport_call() user function. However if change occurs while the script is in a state other than default, it will be ignored because there is no user processing function.in those states. That's where most probably your error is. There should be changed event in each state.

Your script appears to listen to linked messages and do something when a certain link message is received. But who is it received from? Who issues linked messages? Is there another script?

This is not entirely clear. An HUD can take camera controls but an HUD position in-world is the same as a position of the avatar it is attached to, so such an HUD would simply duplicate camera controls available in the viewer.

It would depend which profile data you want to access. Some you can, some you can't

I'm not sure what the problem is either because this sentence makes no sense to me: If i switch the state so the object does not rezz on tp and the tp around, when i then call the objectt the script is locked to the exterior tp call function when it should use the summon function. However your code is very poorly written, which may well be the reason it doesn't work. Let's look for example at this snippet: link_message(integer sender_number, integer number, string data, key id) { if (number == 2002400) { llGetListLength(gFormList); llGetListLength(gOffSetList); gFormList = llDeleteSubList(gFormList,0,-1); gOffSetList = llDeleteSubList(gOffSetList,0,-1); gFormList = llParseString2List(data, ["|"], []); state readNotecard; } else if ((number == 2002100) && (data == "SummonTTC")) { Exterior_summon_call(); state noRezz; } else if ((number == 2002700) && (data == "noRezz")) { state noRezz; } } llGetListLength(gFormList) and llGetListLength(gOffSetList) are both meaningless because they don't store result in a variable; if you don't need the result (and you don't) why call the method? gFormList = llDeleteSubList(gFormList,0,-1) and gOffSetList = llDeleteSubList(gOffSetList,0,-1) clear respective lists in the most convoluted way. What is wrong with gFormList = gOffSetList = []; In fact you don't even need to clear gFormList because the very next line overwrites its previous value anyways. You don't need any "elses" there either because if the condition is satisfied your code changes states. So the snippet should look like this: link_message(integer sender_number, integer number, string data, key id) { if (number == 2002400) { gOffSetList = [ ]; gFormList = llParseString2List(data, ["|"], []); state readNotecard; } if (number == 2002100 && data == "SummonTTC") { Exterior_summon_call(); state noRezz; } if (number == 2002700 && data == "noRezz") { state noRezz; } } I know it is not very helpful in respect to the problem, but perhaps if you restate more concisely what the problem is I could look more.

your code (very bad in style btw) is only going to work if getRefund() argument, which is expiration is Unix time also (number of seconds since Epoc), which I assumed would be the case. Apparently not, otherwise you would not be getting huge numbers.

Try this: integer getRefund(integer expiration) { expiration -= (llGetUnixTime() / 86400) *( RENT_RATE / 7); return llRound(expiration*0.8); }

LSL does not have a concept of passing by reference, it puts a whole object on the stack so there is no elegant solution for the list selection. In my own practice when this matter comes up I do something like this: list list1 = ["A","B","C"];list list2 = ["D","E","F"];integer int = 1; // or 2string str; string getItem(integer listnum) { list wlst = list1; if(listnum == 2) wlst = list2; return llList2String(wlst,0); } default{ touch_start(integer total_number) { str = getItem(int); }}

May also try this

Excellent project! To send HTTP to a web server that would be an interface to VMware units is rather trivial as others already commented. I wonder though, in the in-world simulator are you going to simulate actual routers user interface?

llDetachFromAvatar() on attach event will do the trick. My demos can be worn only once; if rezzed on the ground they die.

I don't use RLV nor do any LSL support for it, yet my understanding is that that thingy works via llOwnerSay() text strings. That means it will not accept any commands from the cryptonite because it is owned by the attacker. A victim must wear some attachment (or an HUD, which is the same thing); then cryptonite talks to the attachment and the attachment (owned by the victim of course) sends llOwner() strings to the RLV. Yet in such scheme the RLV part may not be really needed. In our InteractiveWear BDSM addon we are able to immobilize the wearer ("lock in place") without any RLV, purely by means of LSL... hmm...sorry, "Restrained Addon". Used to be called BDSM but it's a too adult term

My only excitement is that advertised changes do not appear "significant". This is very good because the word "significant" usually scares the living daylights out of ppl in engineering world as it inevitably means that something that has worked before will quit working and usually in a totally different part of the system. But as long as Lindens add parameters to the particle system and make a few animation wrapper functions I suppose we would be safe... Yet I've been wrong before

Very material You may get 20 of 4-s in a row, all with different fractions; they are all less than 5.0 so in a simulator like this a coin would flip the same 20 times in a row. That is not what should be happening.

No. The odds of having a sequence of numbers 2.2350 and 6.6789, which would produce the desired result are exactly the same as the ods of having a sequence 2.2350 and 2.6789, so a long sequence of 2-s is entirely possible with this approach. All what's needed there is to look for random integers instead of floats.

Ahhh... should've said so to begin with... lol The agent profile URL is formed like this: string url = "http://world.secondlife.com/" + (string)agent_uuid + "/"; where agent_uuid is a global variable which value you assign in the touch event as agent_uuid = llDetectedKey(0); and then you'd need to send anhttp_request and process it via http_response event. There is some info that you can retrieve from the profile and some that you cannot (whatever hides behind meta-tags). You can use API's from http://www.sluniverse.com/php/vb/scripting/72302-slnode-lsl-parsers-more.html to get some info that is not accessible directly You'd never be wasting professional's time for as long as you pay the price

Innula, most random numbers generator algorithms do not treat the integer part and the fraction separately. I don't think the LL one is any different.

In most of my projects I use separator ",,," as I'm yet to see an SL name that includes three commas in a row. This of course does increase memory usage by 2 bytes per name which may be relevant if strings or lists are long so a script operates within a thin red line between stack and heap In those projects where a separator indeed may turn out crucial, I use weird unicode characters from non-latin sets, those of course must be translated back and forth but it is pretty trivial.

Not all of it is necessarily true Rolig. Scripted wearable attachments do increase Avatar Rendering Cost and therefore do contribute to a sim lag. You can actually see how ARC changes depending upon a number of scripts in wearable attachments via info panel (turns on/off in Rendering) and if you wear resizeable hair and then take it off the difference is profound. So the number of worn scripts matters. The used memory is a different story; it is more or less meaningless. I can write a few lines script that would either crash a sim or at least significantly impare it. On the other hand, a full 64K script if correctly written would add no lag at all.

if (llFrand(10) < 5.0) // 50% chance it will suddenly yodel is not going to work for you very well. It returns a random float of less than 10.0 so a series of results like 4.25, 4.004, 4.78,... etc. is perfectly legitimate and would happen quite often as a matter of fact. What you need is a coin toss simulation. Look for a user function at http://wiki.secondlife.com/wiki/LlFrand

I've no idea what this means "pull the UUID of the avtar that touched the board, ideally translate that UUID into a URL" as there is no relation an has never been between an avatar UUID and any URL. In respect to UUID, my advice would be that if you don't know how to retrieve an agent UUID on touch and stuff in a message, don't spend a single hour more. Order your script from a friendly professional in your neighborhood

You can get the Networked Donation Boxes here

Your action variable is a string, not a list, so try: length = llStringLength(action); instead integer length = llGetListLength(action); // incorrect, action is a string