Ela Talaj

Hmm... I dunno... guess just a matter of preference. I would suspect llGetUsername() is a wrapper for llKey2Name() anyways because that's how I would've implemented it with llKey2Name() already existing but who can read minds of LL programmers...

I don't really know how they impemented http between objects, that is whether it is a bona fide http via the cloud or some shortcut within the grid. It is a very interesting question.

I somewhat doubt that periodicly converting keys to names via llRequestUsername() is more efficient than immediately acquiring a name via llKey2Name(). The latter method doesn't use any resources to speak of while the former returns the result via dataserver. Besides, storing names takes less memory than storing keys as most names are shorter than 36 bytes so more could be stored.

Scripts in worn attachments are run by a region the avatar is currently in. On agent's arrival these scripts are loaded into the regional server memory and booted to run. There used to be a bug in mono scripts loading that would momentary freeze a region on agent's arrival especially if the agent was wearing many scripted attachments. This bug appears to be more or less fixed. The exception to the above is when an agent crosses sim boundary on foot. Then the previous regional server still runs the scripts until the avatar penetrates the new region deep enough, like 40m or so. Theoretically orphaned scripts are entirely possible and would happen when due to some software glitch the region fails to unload the scripts upon an object being deleted or taken into agent's inventory or moved to a new region if worn by an agent. A way to get rid of them would be a periodic audit by the server but I don't know if such audit is run and if yes how often. As it is a common software design practice I would assume it is run in some shape or form. In practice to get rid the effect you describe would be a handshake between the front end in-world object and the back end web server. An object id is delivered to the back end on handshake and the back end further processes queries arriving only from known ids.

Correct. Didn't notice that each conditional writes the same variable so the last value remains. Late at nite when seeing several if's in a row and no else's, one might assume they would write into different variables

Messages between objects never leave the SL servers grid, regardless if the objects are in the same region or not. In the latter case "email" between objects is actually implemented via instant messaging and therefore is even more secure than instant messaging between avatars, because those do leave the grid to end up in the viewer. The same applies to objects being in the same region and communicating via llRegionSayTo(). One should probably start thinking about secure communications when messages do leave the grid, which includes HTTP to off-world backends, like web servers etc but, to think of it, the gain of intercepting such communications is pretty miniscule as compared to effort.

An interesting thing here is that if left as is it should always rotate around all 3 coordinates because xyz = <whateverstring> evaluates to TRUE so condition if(xyz=<whateverstring>) (with "=" instead of "==") is always satisfied.

Such a seemingly trivial application and yet reveals the pitfalls of real-time programming in a nutshell. That's where 95% of real-time bugs come from: by the time the data is used it is not there any longer but overwritten by something else. Too often such bugs in complex systems are hell to find. So what if you must respond to an interrupt (touch event in our case) after a specific delay but don't want to disable more interrupts while on timer? Would be something like below. See how complex things have suddenly become? And the code below doesn't even address the issue of repeated touches by the same user. integer intChannel = -38654;integer intListen;list objects; list queue = []; default{ state_entry() { integer num_drinks = llGetInventoryNumber(INVENTORY_OBJECT); integer i; for (i = 0; i < num_drinks; i++) { objects += [llGetInventoryName(INVENTORY_OBJECT, i)]; } } touch_start(integer num) { intListen = llListen(intChannel, "", llDetectedKey(0), ""); llDialog(llDetectedKey(0), "Pick Object:", objects, intChannel); } listen(integer channel, string name, key id, string message) { llInstantMessage(id, "Your item, " + message + ", will be delivered in "+ (string)llFloor((30.0 - llGetTime())) + " seconds."); llListenRemove(intListen); queue += [id, message, 30]; if(llGetListLength(queue) == 3) // first entry llSetTimerEvent(1.0); } timer() { integer n = llGetListLength(queue); if(!n) { llSetTimerEvent(0.0); return; } integer i; integer t; for(i=2; i<n; i+=3) { t = llList2Integer(queue,i); if(--t) queue = llListReplaceList(queue, t, i,i); else { if(llList2String(queue, i-1) != "") llGiveInventory(llList2Key(queue,i-2), llList2String(queue,i-1); queue = llDeleteSubList(queue, i-2,i); i-=3; n -=3) } } }}

MySQL should work just fine if your in-world detector supplies queries correctly. A thing to keep in mind here is that if you want to restrict access not to a whole parcel but only to a part of a parcel, llGetAgentList( ) is not applicable so you'd have to detect on proximity. However llSensor( ) would return only the closest 16 agents so if the area is expected to be high traffic you'd have to make a moving sensor or get one here .

This is a very bad script - and I understand that you just inserted timer thingy in the OP's script - but the OP should've been made aware that should a second person touch while the timer is ticking, the second person is going to get the object but the first person would get nothing. Generally, only the last person touching while the timer is active would get anything. This is the case when either llSleep() should be used instead of timer or one has to queue touches.

Insuring that 10 year old Johnny can be detected trying to get into an Adult Private Area is not your problem, it is the Lab's problem. That is why they created Adult rating in the first place. Your problem is that you would not be able to store more than 500 names in a script and even this only if you are an adept in efficient memory usage in LSL applications. Many thousands of names may be stored in a series of scripts with parallel access but you must be a very advanced RL programmer to accomplish that. And still should a script crash (and it does happen though not very frequently, for instance on some server upgrades) all the names are lost. I would advise you to simply create a group and restrict parcel access to the group members. The group would be by invitation only and you'd have to add new members manually perhaps after an interview of some kind but you wouldn't need either walls or scripts.

I've made a device like that long time ago.

This is sad news. I cannot comment on the event itself without knowing particulars but Oscar was a qualified engineer and servers still need much work. I hope whoever takes over is no less qualified.

Who said it was in the middle of the night?

In fact it will change with every request explicitely made via llRequestURL() call unless your region runs out of URLs What is important to understand here is that you should not call llRequestURL() unless on rez and on sim restart events.

I must be missing something cuz this projects doesn't make much sense to me. If object A can hear an avatar and the avatar can hear object B, both object A and object B must be within 100 meters from the avatar. If this is true, why is object B needed at all?

By number of units sold my swimming products are the bestsellers. Yet by L$ volume my bestseller is Private Rooms Renting System . I've never thought there were so many whorehouses in SL.

There is a commonly used notation for a blank key, called NULL_KEY. So the first line instead of key user_key = "00000000-0000-0000-0000-000000000000"; should be key user_key = NULL_KEY; Further than that I didn't even look cuz things like that auto-fail my code review

An agent cannot have a negative balance, only a zero balance. A split payment script first collects into its owner account and then pays a percentage of the amount collected to other agents. Premises considered it has no need to check its owner balance. Of course half of the LSL "scripters" would not be able to insure that a split payment is always less than or equal 100% but that's another matter.

It can all be automated Sasy. The limit is how much a client is willing to invest in development

This is easily correctable, Rolig. The script should simply disable the tip jar if the debit permission is not granted so it would not take money from anyone. It could also send an IM to a hardcoded key (club owner) in such case.So Conrad's solution would work just fine if the tip jar is scripted correctly.

It's not trivial actually. The object will change the key (uuid) and/or url every time it is re-rezzed so there has to be a heartbeat between an object (node) and the central server object to keep track of nodes keys or url's. When one considers that the central server itself may change its key and/or url... the totally in-world grid-wide communication scheme could be devised with a high reliability but not a 100% reliability.

Is there any reason you feel entitled to free software?

Qie is right, that's about the only way to do it. If the script resides in the moving child prim, a link number for that prim to put in the function would be LINK_THIS. If a script resides in the root, you'll have to either find out the child prim link number manually and hardcode or have a special name for this child prim, then the link number can be found via the script. As for the sitting avatar, its link number would always be: llGetObjectPrimCount(key uuid) + 1

I'll make you those you want as soon as you convince me that gambling prohibition has been removed from ToS and on-line gambling is legal again in the United States.