Handarido Optera

Keep an eye on a possible bug: When the input to a list is a string then llList2Integer, llList2Float, and llList2Key work perfectly fine and return the appropriate type. Not llList2Vector: default { touch_start(integer total_number) { list my_list = [] + "<2.0, 2.0, 2.0>"; vector result = llList2Vector(my_list, 0); llOwnerSay((string)result); // returns ZERO_VECTOR result = (vector)llList2String(my_list, 0); llOwnerSay((string)result); // returns <2.00000, 2.00000, 2.00000> } } You need to use llList2String and then cast it as a vector.

I finally succeeded in moving a prim around the side axis, or to be more precise, around the middle of the smaller side of a prim. The door script is available on marketplace now, with automatic detection of the smaller x or y side, it works at any angle around the z axis, in both directions. No menu, no notecard, no setup, no second axis prim, and foremost, no cut prim, no mesh tricks, no tutorials, just drop the script into a full prim or mesh object, linked child or unlinked single / root. Any amount of combinations of doors / windows simultaneously working gridwide is possible. Whoever is interested, contact me in-world, I am glad to pass on free examples for testing.

Thank you all for the valuable information. You all are dealing with the term itself, suggesting altered variants, different approaches, and logical backgrounds of your suggestions. Thank you very much. But I am sorry to maintain that all are missing the point: The SAME code works in the SAME prim in ONE script AS INTENDED, in the OTHER script NOT AS INTENDED. Or in short, the SAME code (yes I did copy and paste, it IS the same code) has DIFFERENT results. In one case blocking BOTH "//" and " ", in the other ONLY " ". SAME code. My point was not about the logic of the term, it was about the logic that the same term resulted, so to speak, in YES in one script, in NO in the other. So I finally figured the problem was somewhere else in the code. I think I got it now, it is about naming variables. One tends to name variables easy and descriptive. So for instance, "name" for a name. All works fine for weeks with the growing script until one day you get problems. You test and test and read and blog and go forums a.s.o. a.s.o. The code looks clean and perfect as given in the working examples, whereas your hair is a mess from raising. A search for each variable names in the whole script reveals finally the matter: One of the variable names you picked is used as a parameter name in a function you recently added. You may say, what a noob, this is self-evident. But especially as a noob, you might run (as I did) into this problem of name clashes when sticking to the tutorials, wiki explanations, given examples. Even unintentionally, despite carefully naming your variables differently. To give an example, look at these events according to the wiki: listen(integer channel, string name, key id, string message ) link_message(integer sender_num, integer num, string str, key id ) Works all fine until one day you add a condition if(id == ...) The script gets confused and that results in that the script does not execute code properly. Once confused, it refuses even to execute a condition where the code is perfectly fine and has nothing to do with the clashing variable name. That makes bug detection and testing an infinite journey because the bug is not there where the code does not work. So for instance, I write now always link_message(integer sender_num, integer num, string l_message, key message_id )

In a notecard reader I want to exclude lines starting with // as well as empty lines (or lines that appear to be empty containing only spaces). Until now this worked for me: if(llGetSubString(data, 0, 1) != "//" || llStringTrim(data, STRING_TRIM) != "") In even a most simple stand-alone script now lines starting with // are not excluded, only empty or space filled lines are. To the contrary, in earlier even very complex scripts lines starting with // are excluded. In even the same prim this code does exclude // lines in one script, but not in the other.

Thank you very much for your help!

Awesome, it works when the door's physics shape is Prim. Then the method explained in the video with creating a temporary mirror door, creating a triangle, adjusting it, creating another box aligning it to the door aso aso is w a y too complicate and not necessary: Just design the vertices of the door in that you have got an extra vertex at the bottom of the door. All you need is one simple step then: Drag the vertex into the opposite direction of the door until the distance is equal with the width of the door. Then the extension is just an edge and there is no need to take care of faces of this extension. The lonesome edge is invisible. I had used Blender until it was recommended to use Jass which I use since then. Ok, got now Blender again ... will take some time to become familiar with it.

Yes that is the trick I referred to. I had tried that not knowing that this was common knowledge.To make sure what I say here I went back and made a simple mesh door with jass-magic-1.1.4 and Collada File 1.4. There is the door, and there is the one face on the very bottom. But you cant step over the bottom face, the prim takes the whole bounding box. And therefore eventually pushing people with the invisible part when rotating. I will look at the video if there is an option to avoid this.

The "secret" behind this first try is to find a way for a door script where you dont cut a prim in half and move it around its axis. You can do that with a prim but not with a sculpted or mesh door. There is a trick to make half of the sculpted door invisible but it is still there and in the way. Door scripts with an axis do move a prim properly, but those dont work as intended when linked to the main object. If you want a linked door of a sculpted or mesh prim then this prim needs to travel along a quarter circle and, of course, needs to change the angle as well. So as a beginning to understand what is going on I started with the quarter circle.

Thank you for your comment and help. I understand now why it moved 10m. I am sorry but I cannot find llSetKeyframedMotion() on the list of functions. Perhaps my long search was bad but I have not found even any hint not to speak about an example script about moving a prim along a circle. So I tried it today with the for loop and the old Pythagoras. Going for the roation thing next after I managed to understand the functions. I mentioned that I did try first with llSetLinkPrimitiveParamsFast(...) but the result was that the prim traveled quickly to the end point and not along a circle. So I used llSetPrimitiveParams(...). Yes to the timer unless it is not occupied otherwise. Timer needs the llSetLinkPrimitiveParamsFast(...) of course.

And I figured my mistake by realizing that the negative value would happen with any given radius. I did not consider for the calculation of the x axis that the prim travels. Here comes the version which works. I still had a short disappearance of the prim when the loop started. So instead llSetPos(...) I used llSetLinkPrimitiveParamsFast(...). That was, however, too fast. The prim took a quick direct way instead of the circle route. So I ended up with llSetPrimitiveParams(...). Got it! float distance; float unit; float r = 0.5; vector home; vector travel; default { touch_start(integer total_number) { home = llGetPos(); distance = 2*llSqrt(r*r/2.0); float a = llPow(r, 2.0); integer i; for(i=1; i<=20; ++i) { unit = (distance/20.0)*i; float b = llPow((distance-unit), 2.0); // <-- the distance decreases travel.x = home.x + llSqrt(a - b); travel.y = home.y - unit; travel.z = home.z; llSetPrimitiveParams([PRIM_POSITION, travel]); } } }

Ah yes thank you very much for pinning the problem. Brillant. Yes, if a math error occurs, a script can go crazy anywhere. And yes, I should not use integers when floats are around. They dont like each other, and integers tend to drag floats to their side. Floats below zero get nasty then and take revenge with the other famous math error, the division by zero.

This script was intended to make an object moving along a quarter circle. The object does move that way but unexplainably the last waypoints also a significant distance along the z axis without any obvious reason defined in the script. Can anyone tell where my mistake is, or is this a bug? float distance; float unit; float r = 0.5; vector home; vector travel; default { touch_start(integer total_number) { home = llGetPos(); distance = 2*llSqrt(r*r/2); integer i; for(i=1; i<=20; ++i) { unit = distance/20*i; travel.x = home.x + llSqrt((llPow(r, 2.0) - llPow(unit, 2.0))); travel.y = home.y - unit; travel.z = home.z; // <-- the z axis remains unaltered during the loop runs llSetPos(travel); llOwnerSay("waypoint = " + (string)llGetPos()); // <-- to describe what happens in-world } } } waypoint = <134.47880, 114.89070, 3901.00000> waypoint = <134.47500, 114.85540, 3901.00000> waypoint = <134.46870, 114.82000, 3901.00000> waypoint = <134.45960, 114.78470, 3901.00000> waypoint = <134.44780, 114.74930, 3901.00000> waypoint = <134.43280, 114.71400, 3901.00000> waypoint = <134.41450, 114.67860, 3901.00000> waypoint = <134.39230, 114.64330, 3901.00000> waypoint = <134.36570, 114.60790, 3901.00000> waypoint = <134.33360, 114.57250, 3901.00000> waypoint = <134.29430, 114.53720, 3901.00000> waypoint = <134.24460, 114.50180, 3901.00000> waypoint = <134.17690, 114.46650, 3901.00000> waypoint = <134.05080, 114.43110, 3901.00000> waypoint = <133.70750, 114.13810, 3891.01000> // <--- from here the object moves waypoint = <133.36420, 113.84510, 3881.02100> // in steps of about 10m! waypoint = <133.02090, 113.55200, 3871.03100> waypoint = <132.67760, 113.25900, 3861.04100> waypoint = <132.33440, 112.96590, 3851.05100> waypoint = <131.99110, 112.67290, 3841.06200>

For any initial scripting information I found it very helpful to google "lsl" and then the command. First hit is in most cases the Linden Scripting Wiki which has a ll the details including examples. In your case I google "lsl llEmail", first hit is http://wiki.secondlife.com/wiki/LlEmail further down this page you will find the chapter Prim 2 Prim Email with the basic code which makes the thing work. At the bottom of the page are links to the related commands. You can also google in addition "lsl free scripts llEmail" which brings you to a variety of ready made solutions.

You will find that prims which are located on different sims can communicate via llEmail() and that a prim's email name is its UUID. Please consider in your scripting project at any time that---unlike an avatar's UUID which stays the same for the whole life time---a prim's UUID is created anew every time it is rezzed from inventory, even if the prim is no copy. Your scripting project might need a work-around or even an alternative solution due to this prim property. Maybe this hint has no relevance for you but I drop this comment here because if I had realized the matter early enough I would not have lost hours and hours of work. Good luck!

All the advice about counter actions in SL against stalkers is certainly valuable and recommended in the first place. Period. Silence. BUT. Meet the advanced methods. Face professionalism. Learn that the fun for the stalker begins only after you have applied all these counter measurements. (1) Is there any method not to get involved with any of your own avatars and attack and spam your target by innocent others? Yes, there is. Simple, when you know how. (2) Is there any method to spam a place with any text or picture, defaming or RL disclosure, despite all is shut off, except public access (due to the nature of your stay in SL, and not because you like drama)? Yes, there is. Simple, when you know how. (3) Is there any method to defame you to a rapidly growing group of the same people? Yes, there is. Simple, when you know how. Is there any help against this? ARs seem not to work. Scripting your own anti-griefer tools is of some help. I do not mention how (1) and (2) and (3) work or worked or still work, for the obvious reason not to "inspire" griefers. I do not advertise my scripts here or anywhere else. The solely purpose of this answer is to tell that griefing goes beyond all simple counter measurements and beyond all ARs. It has become a form of entertainment, even a form of addiction to adults. And it looks that LL cant cope with it. It is, however, a certain relief that members of the community think about and work on forms of help and counter measurements.