Jump to content

Estelle Pienaar

  • Posts

  • Joined

  • Last visited

Everything posted by Estelle Pienaar

  1. Thank you very much, for making this evident. It is rather poorly explained in the wiki. There are these integers in the example script, but not at all explained in a clear way. However when you said it, I understood it in an instant.
  2. I have a little script that should perform a function when the left mouse button is clicked. However, no matter how quickly I try to click the left mouse button, the control event is triggered at least 3 times per qulick. If I keep the left mouse button pressed down, I get an even greater amount of triggered events. How can I change my code, so that the control event will only be triggered once per mouse click? key ownerK; default { state_entry() { ownerK = llGetOwner(); } attach(key id) { if (id) { if (id != ownerK) llResetScript(); else llRequestPermissions(id, PERMISSION_TAKE_CONTROLS); } else llReleaseControls( ); } run_time_permissions(integer perm) { if(PERMISSION_TAKE_CONTROLS & perm) { llTakeControls(CONTROL_LBUTTON, TRUE, TRUE); } } control (key id, integer level, integer edge) { Detected = []; llOwnerSay("Debugging: I have been clicked"); } }
  3. I would definately support a feature request. However it would probably be more usefull if LL would fix pathfinder. Then the "fix" to raycasting your NPCs way would probably not be (as) necessary.
  4. Thanks a lot, animats. The objects didn't have physics shapes. Riddle solved!
  5. Hi everyone, I am playing around with llCastRay. Trying to script a melee system with NPC oponents. That's why animesh objects would need to be detected. But llCastRay seems not to be able to detect animesh objects? The following script is in a weapon that the avatar is holding. The ray is cast from the avatar (to the direction the avatar is facing) four meters forward. It works for all objects. But it does not detect animesh objects. key ownerK; default { state_entry() { ownerK = llGetOwner(); llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS); } attach(key id) { if (id) { if (id != ownerK) llResetScript(); else llRequestPermissions(id, PERMISSION_TAKE_CONTROLS | PERMISSION_TRIGGER_ANIMATION); } else return; } run_time_permissions(integer perm) { if(PERMISSION_TAKE_CONTROLS & perm) { llTakeControls(CONTROL_LBUTTON | 0, TRUE, FALSE); } } control (key id, integer level, integer edge) { list rotL = llGetObjectDetails( ownerK, ([OBJECT_POS, OBJECT_ROT])); vector posV = llList2Vector(rotL,0); rotation rotV = llList2Rot(rotL,1); list results = llCastRay(posV, posV+<4.0,0.0,0.0>*rotV,[RC_DETECT_PHANTOM,TRUE,RC_DATA_FLAGS,RC_GET_ROOT_KEY,RC_MAX_HITS,1]); //I a have taken all possible filters out: RC_REJECT_TYPES,RC_REJECT_PHYSICAL|RC_REJECT_LAND|RC_REJECT_AGENTS key target = llList2Key(results,0); llRegionSayTo(ownerK,0,"HIT: " + (string)target + "."); } } Am I doing something wrong or did LL forget to make animesh detectable by llRayCast? (well, I hope it is me...) You should be able to copy the above script in any attachement and then do the test yourself.
  6. A question: Do you use llEscapeURL for all data which is sent to php? If you don't use it and the data contains a letter or an expression that is forbidden or reserved in PHP or SQL, then the script will fail and the data will not be added to the database.
  7. Originally there was no force sit function with experiences. It was only added several months later by the Lab. They probably just haven't updated the permissions dialogue...
  8. Yes, I think scripters tend to forget quite quickly how hard it is for absolute beginners (especially if they have no previous experience with other scripting languages) to find really exhaustive descriptions on how to tinker with the basic LSL functions. I have bought this as an e-book and it has helped me a lot: https://www.amazon.com/Scripting-Your-World-Official-Second/dp/0470339837 Even if some info is outdated, it gives a quite exhaustive introduction and not just some snippets here and there that you need to puzzle together yourself. However if you have been able to make sense of the llSetPrimitiveParams all by yourself, then maybe you'll get there without the book...
  9. EDIT: Oops, I haven't seen that Quie answered in the meantime. Too late to delete... I think what Qie wanted to communicate to you is that any talented and ill-intending scripter can do almost all the same things to you via furniture or teleporters as he/she can with experiences. So it is not very reasonable to be afraid of experiences if you are not afraid of furniture... 😉
  10. I am happy for you that you could sort things out. I still would have some open questions. Yes, it is a good thing to check the http_response by the key that was created by the llHTTPRequest. And to communicate an additional sufficient complext identifier back and forth (it can be UUID as it will work for a first unique registration process - even if the UUID of the object will change whenit is taken into inventory and rezzed again). However does that really solve the fundamental problem in your LSL-PHP communication, or haven't you just not run into another case yet? Can you specify a bit more what is happening in the steps 1-3? You are using method POST via an llHTTPRequest in order to send the SL data to a PHP script. The script then does (1) enter the data into the database and (2) SELECT the created data entries and print/echo it in the html_body. The LSL script then receives that http_response and "saves" them to global integers. Is this correct? Only if my assumptions are correct, then this is my guess to what is happening: What seems to have created your problem is that two llHTTPRequests arriving at almost the same time receive the same html_body in their http_response event. I can think of two reasons for that: (1) Your PHP script is having a bug, for example: sometimes new data is not entered into the database but the last entry is selected and so it sends the previous information a second time. This is very likely the reason behind your problem (if my assumptions are correct). (2) There is a bug in the LSL-PHP pipeline so that a second call might get the response of the first call. That is rather unlikely. So if (1) is the reason for your problem then your "solution" will only result in a new problem: A new breedable sends it's information to the database, it does (for whatever scripting reason) not registerd in the database, the php script sends the previous entry. The breedable script sees - because of UUID - that the information does not fit and discards it. Well, then this new breedable will again have a problem: no data. You need to find out why your PHP script sometimes does not save the new entry to the database. Maybe add a php confirmation to your PHP pipeline that an entry has been saved (which is checked by LSL script) and a notification if it has not been saved (and make your LSL script communicate this error).
  11. Ok, I clearly have to stop scripting for today. llClearLinkMedia is the call to reverse llSetLinkMedia... Doh!
  12. If I witch a prim face on a HUD to a media face via llSetPrimMediaParams, I can reverse the effect by calling llClearLinkMedia. But what do I need to do if I called the media face via llSetLinkMedia. Is there also a function to reverse this effect on linked prims?
  13. I was having the idea to use llSetCameraParams for a story HUD in order to get movie like shots when parts of the story are told. But as far as I can understand, the existing parameters for llSetCamerParams, only allow to create static camera positions and shots (as long as the avatar does not move) and I can't do dollie shots, zooming in and out of scenes?
  14. This is close to what you want: https://www.outworldz.com/cgi/freescripts.plx?ID=930
  15. This forum is for scripters that help each other when running into problems while scripting. If you are looking for a specific script, you can ask in the "wanted" forum. If you want to pay someone to write such a script for you, you can ask in the "Inworld Employment" forum. This is actually a very nice first project for starting scripting. If you want to use your idea to start scripting in LSL, I will give you a few hints. (1) in case that you have never learned a programming language before, read some (very) general introductions into programming, especially procedural languages. (2) look for one of the available tutorial on LSL, that resonates with you and learn the very basics. (3) Get the logics of your script right: I need a script (in an object worn by an avatar) that (a) tests if the avatar is typing and (b) then sends a message to the object which is a lantern when the avatar starts typing and sends another update when the avatar is not typing animore. You need a second script in the lantern that (c) receives the message and then (d) switches the lantern on/off accordingly. For the very first step on how to test if the avatar is typing, you can refer to the answer of Rollig in another forum thread: https://community.secondlife.com/forums/topic/383261-typing-animation-script/ . Only instead of playing an animation, you would then send the message to the other object. EDITED: And in order to understand and learn what all the events, functions and variables are actually doing, read the relevant information of the lsl wiki attentively. (If you want this in Spanish, use Deepl.com (my recommendation for best AI translation) or translate.google.com. Good luck.
  16. You cannot add a person to a group with LSL. So it is not possible to create such a script easily. You would have to combine LSL scripts with bots and servers in order to achieve such a task. It would be very complicated to create (therefore very expensive if you want to hire someone). It's certainly not worth the hassle to create a script-bot-server environment to achieve the effect that you are looking for. Better stay with paid groups in order to give gift access. If you have lots of money to spend and want to go for it, then post a request in the "Inworld Employment" forum.
  17. Ok, that seems to make sense for some cases. Now I wonder how relevant this is for me. Out of curiosity: what do you mean with "object". A prim or a linkset? It does not seem to make much sense if scripts in linked prims get active from a dataserver call in another prim, but from your statement I guess that it is the case? Anyway so far I have succesfully avoided having more than one script with a dataserver event handler or http_response event handler in a linkset as I prefer a very clear seperation of responsabilities between my scripts in objects or HUDs. It's probably my specific use case but in my HUDs the scripts (1) do read every now and then from notecards and not just one time and (2) manage several tasks in order to keep script count as low as possible. If I would create a state without a dataserver event handler, then I would therefore have to dublicate 500+ lines of code into the new state. Then the script needs much more memory (I am pretty sure that it would run out of memory too). And if I put the notecard reading in a seperate script, then there is one more script than necessary. All in all switching states seems to demand more resources than just leaving the existing (EDITED:) event handler idle until used again.
  18. Of course you can use states, but that doesn't mean that it is more conveniant. I haven't seen any convincing examples so far appart from touch_event on/off. However my statement will always stay an unfullfilled wish anyway. Because of legacy content... 😉 And at least I can chose to ignore states and maybe ignore them even more in the future thanks to your JIRA. EDIT: Do you (or anyone else) have a concrete example for this use case?
  19. I am late and maybe you found already a solution. I have seen just this weekend a really great boat ride and it was created with this coaster creator. You can make your own custom builds with it. https://marketplace.secondlife.com/p/Limited-time-Sale-Coaster-Creator-Log-Flume-Build-your-own/5779572
  20. One thing to consider is if the object should be clickable at all as long as someone else is playing. I prefer to have a floating text stating that the object is in use by another player and only make it clickable again after the turn of the previous player ended (one state with touch event and another state without the touch event). After all, if other people can click the object but nothing happens, then they might think that it is broken. Even if they get a message, they might be confused on when they should or should not click again.
  21. 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).
  22. 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).
  23. 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...
  24. 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.
  • Create New...