Estelle Pienaar

Wow, big thanks! The touch event is (at least according to my scripting experience) the only lsl use case when it makes sense to change states. If your request would be properly implemented, LL could finally get rid of lsl states entirely. States unnecessarily confuse and put off newcomers who are interested in scripting. My first big progress in LSL was the realization that states exist to be ignored... (ok, so far with the exception: touch events on/off).

If this is a one time non-commercial project, I would consider using different SL groups for different access levels and people need to wear their group tag. So there would e.g. be the "RP area - Access Level 1", "RP area - Access Level 2", and "RP area - Access Level 3" groups. The llVolumeDetect(TRUE) script only needs to check for the active group title and opens (or not) accordingly. The advantage would be that a future administrator only needs to give or take away group access and does not have to fiddle with a server or unique keys. The downside is that you need to pay a bit for setting up the groups and it is a bit cumbersome for the user to change the active group just to get door access (but not much more cumbersome than the step to search for an item in inventory and wear it).

Does it really make sense to have a dust effect over prims? You don't know what the prims represent. You won't have too much dust on a skyscraper roof. Or it could be a cloud/fog prim. It would look funny if you fly over a prim-bird and suddenly there is dust all over the place...

Yes, now I want to see it too!

Option 4: Put a collission prim (llVolumeDetect) with a diametre of 2m next to the door . When the prim is hit by an avatar, it sends a message on the fob-channel via llWhisper to a potential fob. If there is a fob that hears the message, it sends a message on the door-channel back via llWhisper to the door: "Open Sesame!" Pros: Only two messages exchanged. Very low on resources. Cons: Let me know. Can't think of any.

If you would like someone to script it for you, you should post your question in the "Inworld Employment" forum. This forum is for scripters who have questions that they encounter during their projects. This job should take an experienced scripter 5 to 10 minutes (testing included), so don't pay to much for it...

Congratulations! Since you are using the display name, you will sooner or later realize that some display names will not work. THe reason is that objects cannot be named to special characters. Here is a script solution that you can use to circumvent this limitation:

🤔 So let's say that I would like to script a hand to hand combat weapon (let's say a sword) one day. What would be the best solution to raicast and see if the weapon has hit someone? I probably should not raycast from the attachment...

One of the best advices I have ever received on this forum (thank you, Rolig) was to use llParseString2List when two scripts communicate with each other. That way you can communicate a set of data with one link message. It has become a standard feature of all my inter-script communications. You probably know this trick already, but maybe it is helpful for someone on the forum.

This is not really the aim of the forum but now you made me curious: Where can I find your sim and/or product? I think it would be cool to experience what is or is not possible when creating games with LSL tools.

I am not experienced enough a coder to argue on the programming part of your statement. But from the logic/mathematical POV (and I insist that your attribution of "philosophical" is misleading), not the result can or cannot be a paradox, it is the question that is the paradox and that cannot be solved. Not matematically and not by code. (and the name of this thread is "Could we use code to solve this..."). In other words, your code gives us a result (plus I really like it and it has taught me something), but it does not solve the puzzle in any meaningfull way.

I have tonight looked a bit more at the OP and the answer from Mollymews. It's fascinating as both pretend to give a defined question and a defined answer but the question is not sufficiently defined. As I couldn't say it better with my own words, I am posting an answer from puzzling: So if you try to solve this problem mathematically/logically, you will end up in an unsolvable circle. Therefore there is no way to solve solve this question in code, only the first half which Molly has done. I also realise that the OP has edited his post, deleting the question if the problem could be solved with code. Probably he realised it was a non-solvable question.

As the situation in your shop is not the typical user case in SL, I can imagine that people don't understand that they need to click the signs. However, you should keep it as simple as possible for everyone involved. In my eyes the most practical solution would be to add a "teleport" option to the dialog menu. If people click on it, then the public chat tells them to click on the sign at the base in order to teleport to the vendor and buy the object. Then they do what they would usually do in a shoping situation and get as a result the information what they need to exceptionally do in order to get there... 😉

if you have questions on your way or if you run into problems, don't hesitate to ask them here!

I understood the OP in a way that he wants to have a generic "touch event" script that replaces the "sit event" script of AV sitter for the exclusive use of color changing objects. But for the sake of the argument: In your use case, Qie, I would propose to create a seperate script that only executes if the avatar who touches the object is at the same time not sitting on it. Then the scripts for the color change cannot run similtaniously and everything should be fine?

Hi YuukoC, by the way you break up the desired actions of your script, I guess that you don't have any LSL knowledge so far. This forum is for scripters to help each other with their projects. If you want someone to script you such a color change script, you need to ask your question in the in-world employment forum. If you want to learn to create such a script yourself, I would recommend to start with the LSL101 tutorial (links in the box on the right). In your script you need to call the function llDialogue in the event handler "touch_start". You will find all the necessary information here but it might be a bit overwhelming for a first scripting project: http://wiki.secondlife.com/wiki/Lldialog

I know, that's why I put law in quotation marks (which at least in my mother tongue marks that a word is not used it in the typical sense - I am not sure about English and other languages). 😉

English is not my first language and it is a long time ago that I have dealt with all these matters. What I have tried to do is giving you a hint that your bold claim "that you can't really use statistics to prove how random som ething is" is wrong. Yes you can. Or do you think that anyone can come up with a black box function pretending it simulates randomness and no one could prove him/her wrong? Yes you can. You do not even know the law of large numbers but you continue to make bold statements about other peoples' posts.

https://en.m.wikipedia.org/wiki/Law_of_large_numbers There is a number of other observations that you can make with "true" randomness. I have never looked into the frant function and can't say if it is "true" randomness or "simulated" randomness. However, if the observations (when it comes to a high number of trials) lead to (almost?) identical results, then it doesn't matter, does it? You can take the OP's script and change it slightly. Make it 1.000 or 10.000 runs, take the average every run and then see what you get. With 1000 runs I would expect you to "always" end up with anaverage of 9.8 or higher (or 10.2 or lower), with 10.000 runs you should "always" end up with 9.9 or higher (or 10.1 or lower). I am putting always in brackets because if you make a high enough number of such tests you will end up with a deflecting result. It is probability after all. But you can even calculate how high this probability is (thus how many runs you need to get a deflecting result from what I stated above). It's a long time ago that I have made such calculations so I don't feel competent to give a guess, but it should be rather improbable. That's why mathematicians speak of a "law".

You get into statistics territory here. And yes there is a rule that determines if there is a true randmonness or not. Just not after one run or a few. However, the more often you let the script run and take the average of all results, the closer this average should be to the expected result "10". That's a statistical/mathematical rule. And though it might take several thousand runs, sooner or later the average for each of the numbers should reach a value between 9,9999... and 10.0001...

I have written a script that selects the display name for processing if it is safe. And the user name when the display name contains characters that cannot be processed by certain scripts. AFAIK it's the best possible solution if you want to use display names: https://community.secondlife.com/forums/topic/353136-object-copying-avatar-display-name-or-username/

I think that your introduction to the problem is not clear. Who needs to be animated with a love/hate animation. The avatar that wears the HUD or the avatar that touches the HUD? Wolfie e.g. answered your question for the case that the avatar wearing the HUD needs to be animated. I understood that the person touching needs to be animated.

It's probably another case where animesh would be the most elegant solution and would save resources compared to omega rotations. But it would drive up land impact and therefore might not be an attractive option for such a product.

In the script there is a function call llDetectedKey(0) in the touch_start event. It's role is to get the unique key (UUID) of the avatar which touches the prim. As a result the script will ask the person who touches the prim for permission. In order to animate the avatar who WEARS the prim and not the avatar that TOUCHES the prim, you need to substitute this function call with another call that will get instead the unique key of the person who wears the prim. Now how to do that? In order to be able to wear a prim, you need to be the the owner. Therefore llGetOwner() is your friend... 😉 EDIT: You might need to do more changes to the script as the permission is automatically granted when attaching or sitting on a prim. So I would have to test myself if it works like that (don't have time to do now).