Phil Deakins

Something is cheating only if it's doing things that are against some rules but apparently there are no rules against moving as fast as you can there, so I don't see what the other people did as cheating. The best for you to handle it is go there when there are no speed people - or get a motorbyke .

My first thought was to change sit targets but I quickly found that changing a sit target doesn't move the avatar that's on it at the time. I'll read Strife's thing though - and thank you - again

&Rolig:- I was refering to the "LSL Wiki" site, not the LL's LSL wiki. PRIM_ROT_LOCAL isn't to be found in the LSL Wiki site. The fix in the jira worked a treat! And PRIM_ROT_LOCAL does work with my setup. What I'm doing is writing an MLP-type thing but wihtout using poseballs. A recent thread sparked my interest and I decided to get stuck in. I don't know if I'll see it through to finishing it or not but it's something to occupy me for now. The avatars on the furniture will be controlled as linked prims, of course, which is why I'm doing this linked prim manipulation. The current testing is with an actual linked prim instead of an avatar, to make the testing quicker - I don't have to sit every time - I can just watch if the actual prim does what I want it to do. From yesterday's thread that I started, I thought you would have realised that it will ultimately be an av and not a prim. I mentioned it there. I'll open all those links you provided, and read. Maybe I'll finally get grasp of thew whole rotations thing.

Innula, you're an angel! Thank you In the years I've been in SL, I've rarely needed to programme rotations so I've not got used to it and, when I have needed to, I've always struggled to actually grasp the whole concept. It doesn't look like PRIM_ROT_LOCAL has made it into the LSL Wiki yet but it's included in the jira, so I could use it if necessary. I'm not sure it will be suitable though - it may be but I don't know yet. When this testing is finished, the prim will be an avatar, as you may have realised and, from what I read in the LSL Wiki 'rotation' page, local is relative to the target prim's rotation but, for an avatar, it needs to be relative to the root's rotation.

I'm struggling with rotating a linked prim - again. I want to rotate a linked prim around the z axis and have it end up rotated to the root's rotation plus some extra rotation.. This is my current code (the extra rotation 'rotTarget' is 90 degrees):- // Get the root's global rotation rotation rotRoot = llGetRot(); // Set the prim's target rotation relative to the root // (so the prim's final rotation is root's rot + target rot) rotation rotTarget = llEuler2Rot( <0,0,90 * DEG_TO_RAD> ); rotation newRot = rotRoot * rotTarget; // Rotate the prim relative to the root's rotation llSetLinkPrimitiveParams(2, [PRIM_ROTATION, newRot]); What that code does is this (in 45 degree root prim jumps - the target prim's starting rotation doesn't matter):- Root rotation 0,0,0 - it does rotate the linked prim 90 which is where I want it to be. Root rotation 0,0,45 - the linked prim ends up at 225 degrees (root 45 + the added 90 + an unwanted 90). Root rotation 0,0,90 - the linked prim ends up at 0 degrees. (root 90 minus the added 90). Root rotation 0,0,135 - the linked prim ends up at 135 (it doesn't change). Root rotation 0,0,180 - the linked prim ends up at 270 which is where I want it to be. I won't go round the rest of the 360 because the above numbers show how I'm struggling. I've tried various things, including adding the 2 rotations instead of multiplying them, switching them round when multiplying, and even local rotation but local isn't what I want. I just don't know how to make it work. Help please?

That's interesting, Innula. An avatar goes to the end of the object's links list but another object in inserted right after the root prim. For me in this case, having the added test prim as #2 instead of going to the end makes no difference, as it doesn't matter which number I specify as long as the test prim is the one acted upon. But it was darned confusing, particularly since Phoenix shows the wrong number until the whole object has been taken into my inventory and rezzed again. But I won't do that. I'll just work with prim #2.

Interesting, Innula. Thank you for finding that. Having link numbers in Phoenix turns out to be a negative aspect of the viewer. It certainly wastes people's time occasionally, like it did today. I treated it as a big positive, which I'm sure it was at one time. If they do another Phoenix update, which is probably unlikely, they need to get link numbers up to date or remove it altogether. As it is now, it can mislead people into wasting their time - and not just a few minutes of time.

Sorry. My brain went out briefly. Yes, the last one to be selected, when linking a whole set, becomes the root. I worded it badly, but I was meaning when adding a prim to an existing link set. I expected that last one (the added one) to have the highest prim number like an avatar has, but it doesn't - at least not necessarily.

Bloody hell! That's the answer, Innula. Thank you! When operating avs on the main object, I used the prim count, which is fine. When an av gets on, it becomes the highest numbered prim. I assumed that adding a real prim to an object causes that last addition to be the highest numbered as well, but it doesn't. The test object is working as expected. The last added prim is actually prim #2. Phoenix reports the wrong link numbers. I wonder where it gets them from - and why, since they don't have any use.

I tried just changing the highest prim's colour, as per you first bit of code, Innula, and I get the same results as I do with rotations. To change prim #6, I have to set n to 2. Setting n to the the primcount (6) changes prim 5. I'm at a complete loss. ETA: I should say that avs on the object have been working fine. It's just that I want to do it with actual prims for ease of testing (me needing a fair amount of testing when it comes to placing a prim/av in a rotation with respect to the root prim, regardless of the root prim's rotation), and it's just not working.

To try it without the rest of the script, I made another 6-prim object (just flat prims) and, with a few changes to make it stand alone, I put that tiny bit of script into the #2 prim (#1 being the root, of course), and I'm getting some strange results. I actually managed to rotate the highest prim by putting 2 instead of n in the llSet... line. I removed the script from prim #2 and put it in the root. I still get the same oddities; e.g. setting n to 2 rotates prim #6. I should say that I'm getting the prim numbers from the Edit box in Phoenix, but prim #6 was the last to be added to the object so it should be #'6 and phoenix reports it as being #6. If anyone fancies playing with this test object and script, you are more than welcome to do so. Right now, it's a mystery to me.

I use the fast version for actual use. This is just an extra test button to make sure the right prim is rotated. In use, the highest numbered prim will be an avatar but I wasn't having much joy with it, so I stuck that bit of code in to make testing the system simpler. The programme is to rotate the av with respect to the root, plus the av's rotation. Using a prim to test with, I can set the prim's rotation much more easily, which makes testing the combined rotations much easier.

This is the code: }else if(button == "test"){ rotation rot = llGetRootRotation(); integer n = llGetNumberOfPrims(); llOwnerSay("test button: " + (string)n); llSetLinkPrimitiveParams(n, [PRIM_ROTATION, rot]);} It's self-contained, so there's nowhere for there to be a logical error. If I use an integer instead of n, the prim below the integer will rotate. E.g. if I put 4 instead of n in the llSet... line, prim 3 will rotate and not prim 4.

I'm trying to use llSetLinkPrimitiveParams() to change the rotation of a linked prim. It's a 6 prim object and the script is in prim #2, prim #1 being the root, and this is the line I'm using:- llSetLinkPrimitiveParams(n, [PRIM_ROTATION, rot]); 'rot' is acquired from the root prim (the root prim's rotation) and it correct. The problem is that it rotates the wrong prim (one prim down); e.g. if 'n' is 4, then prim #3 is rotated. I'm trying to rotate the highest numbered prim (#6) but I can't rotate that one at all. If I set 'n' to 6, then prim #'5 rotates. If I set 'n' to 7 to allow for the 1-prim-down oddity, no prim rotates. I think I'm right in thinking that, with multi-prim objects, the prims are numbered from 1, so instructiong prim #6 to rotate in a 6-prim object, the highest numbered prim (#6) should rotate. Anyone got any thoughts?   

The *really* bad thing about those little icons turning red, is that it caused Charolotte's beautiful picture to disappear

Thank you for that, Gadget. If I hadn't come across the method of using an external editor, it would have been good to try, but the external editor solution is much better than having the script editing floater open in any viewer. I'm using it right now.

As far as I know, it's a general purpose account (not a person) that is used to own the parts of mainland that aren't owned by a user. Maybe it's used for other things too but it's not a person.

Fair enough. I've programmed in VB6 a lot (not in recent years though) and that's what I was thinking of.

16 wrote: famous is maybe the wrong word but we ended up in a thread called famous q: (: legendary maybe then from an historical perspective. if we want to put a name to stuff that we take for granted today I have to disagree with you again. To be honest, I think that some of your posts in this thread are the only ones of yours (that I've seen) that I've actually disagreed with. Your posts are always extremely sensible. Anyway... "legendary" and "famous" mean pretty much the same thing. There may be subtle differences but they both mean 'well-known among the general population'. The examples you've been putting up are examples of well-know things, but the people behind the things aren't well-know at all, imo. SexGen, for instance, is a well-known think (system), but the people behind it are only known by a relatively small number of people, so they are not famous, legendary, or well-known. Another example is the Ivory thing. It's quite well-known but the person behind it isn't.

Saphira Nuyasaka wrote: I also just noticed a bit of irony. As a "consequence" to creating this forum topic, I'm now a recognized resident. I know it's only a forum rank and doesn't actually mean anything, but I think the name is ironic to what I'm trying to not accomplish. Not only "recognised" but now "honored"

I've got a solution (someone in another thread provided it). We can set an external editor for editing scripts and notecards (a programme on our own computers). Doing it that way allows me to have the editor on one screen and SL on the other. Saving a scipt/notecard in the external editor, updates the SL version. It's not perfect but, by comparison to nothing, it's brilliant.

Innula Zenovka wrote: You save it to disk by choosing Save As in the editor (and giving it a sensible name and not the key that SL gives it). Aha! Excellent! Many thanks, Innula :heart: ETA: I just saw the addition to your post. Yes, I can choose which monitor a programme opens in - it's the monitor it was in when it last closed. Programme windows can be simply moved across the screens, just as they are moved across a single screen. Having two monitors is exactly the same as having one very wide monitor - when the right side of a window starts to move off the right edge of the left screen, for instance, that side start to appear on the right screen. Placing a window on the edge of one monitor shows even the window's shadow on the adjacent edge of the next monitor.

Freya Mokusei wrote: Despite being a requested feature for years (Excuse the lack of a JIRA link) there's no way to move floaters out of the SL application. This is mostly because SL floaters are UI elements, rather than actual windows (they don't have any OS-based management system). External script editting of course bypasses this limitation in the same way external web-browsers do. LL could do it easily enough. When a child window is programmed, it is set to be either bound by the parent window or free to be moved outside the parent (I forget the exact terminoligy). It's just a simple property setting for the child window, and each child window has its own setting. It doesn't require any additional programming.

I tried it and the external editor is excellent! It's a long way towards the ideal of freeing the window from the parent viewer; i.e. I can have the editor on the next monitor, and the viewer's edit window minimised until I need to run the script after changes. I don't know about it saving to my own HD though. Saving updates the viewer's copy, which is excellent, but the external editor didn't ask for a filename, so it mustn't have saved locally. At least it's a 'live' local copy and is there should anything untoward happen inworld.

That sounds excellent, Innula. I'll definitely have a look at that option. I don't suppose there's a debug setting to release windows such as the script editor from the parent (viewer) window, is there? It would be great if I could move it out of the viewer and onto the next monitor.