Jump to content

Rolig Loon

Resident
  • Content Count

    39,869
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Rolig Loon

  1. Nope. Virtually all computers sold after about 2004 have chips that use SSE2, and a vanishingly small fraction of SL's resident community have computers that old. When LL made SSE2 compatability a requirement a couple of months ago, it hardly created a ripple of complaint, so I think they are pretty confident that they made the right move.
  2. I do not use a Mac myself, but I have watched this question come up several times in forums for the past two weeks. So far, I have not heard of any serious problems with the Lion OS and SL. See, for example http://community.secondlife.com/t5/forums/searchpage/tab/message?filter=location&location=Category%3AForums&q=Lion
  3. Um.... (1) People are not vegetables and (2) People are not minerals. Therefore, by elimination ..... (3) People are animals. Next question?
  4. The & operator is a bitwise AND. In this case, it is masking the bitwise_integer with 0x7F8, which is 2040 decimal or 111 1111 1000 binary. Wherever there is a "1" in both the bitwise_integer AND the mask, the result is a 1. otherwise, the result is a zero. So, if your bitwise_integer is 11 0101 1100 (decimal 860 or 0x35C), for example: 0x35C & 0x7F8 = 11 0101 1100 & 111 1111 1000 = 11 0101 1000 (856 decimal or 0x358)
  5. I haven't received any messages about suggested friends, so I can only hope that you are right. When I look at the Recommendations tab in my own profile at my.secondlife.com, it says, "There are no recommendations available. Try adding some interests to your profile." I'm ignoring that advice and staying invisible to the FB/Twitworld community.
  6. Yeah, we could use PRIM_POS_LOCAL to match PRIM_ROT_LOCAL. Maybe someday. All is not lost, though. Local position is just a position relative to the root prim, so you can calculate it easily if you know both of those values in global coordinates. ..... vector Gpos = (vector) llList2String(llGetLinkPrimitiveParams(linkno,[PRIM_POSITION]),0); vector Lpos = ( Gpos - llGetPos() ) / llGetRot(); You can then move your child prim by adding an offset (corrected for the root rotation) to Lpos and then use llSetLinkPrimitiveParamsFast(linkno, [PRIM_POSITION, Lpos]);
  7. Hmmm... If I had known that this was a homework assignment, I probably would not have sent you that script. Look back at my post (#8) in which I said I was sending you a demo. The demo, which included this script, consisted of three linked prims, with the root prim as the bottom one. If your three prims are not linked, the script won't work. After all, that's what llSetLinkPrimitiveParamsFast does. The second example that I sent you later last night consisted of a base object (with no script in it) and two unlinked rotating prims (with a separate script in each one). Those prims are not linked, because of the peculiar trick I had to use for making a particle stream update to track the rotation of a prim. Let me explain........ When we use llTargetOmega (or PRIM_OMEGA) to spin a prim, nothing is actually moving, as far as SL's servers know. All of the spinning is a visual effect, done by your own graphics card. That's fine if all we want is a rotating prim, but you asked for a rotating prim that spews particles. Unless we tell the servers to really turn the prim, the particle emitter will always point in the same direction. Therefore, I had to write a script that makes the servers turn the prim by calculating a new rotation in steps and using llSetRot, and then overlay that with llTargetOmega to tell your graphics card to make the apparent motion smooth. If you watch that second demo carefully, you'll see that the prim rotates smoothly but the particle emitter jumps ahead in 10 degree hops. (If you are really interested, this is the principle used in the popular Smooth Rotating Door script used by many builders.) So why not link the prims? Because calculating and updating the local rotation of child prims is a real bear to do. It is much easier to leave the prims UNlinked and use two separate scripts with llTargetOmega. Unless you are likely to move the structure around, it doesn't make any difference whether the prims are linked or not. Also, if they are unlinked then you can attach other things to each of the rotating prims without messing up their spinning, as you discovered. Again, if you look back in this thread you'll see that I pointed out this difference in my first response to your OP. I will be back in world again this evening if you need more help.
  8. Duplicate post. Asked and answered at http://community.secondlife.com/t5/LSL-Scripting/rotation-script-help/td-p/997943/page/2
  9. I think your friend is thinking of a different script. Yes, it is possible to rotate linked prims separately using llSetLinkPrimitiveParams and the parameter PRIM_ROT_LOCAL, but that is a relatively tricky bit of scripting and it makes for a rotation that is choppy instead of nice and smooth. Only llTargetOmega, which does its work client-side, will give you smooth motion. The X, Y, Z values in the script that you have are between the < > brackets. That vector describes the orientation of the rotational axis of the prim you want to set spinning. In that first command, for example, you are telling prim #2 to rotate around its Z axis (X = 0.0; Y = 0.0; Z = 1.0). The other command is doing the same thing for prim #3. I can't imagine why that script isn't working for you unless, of course, your three prims aren't linked.
  10. Much of what you're asking is answered very nicely in the stickies at the top of the old (now archived) Texturing forum. In particular, take a good look at http://forums-archive.secondlife.com/109/32/80851/1.html and the answer to the question "Why do I see a white halo around my partially transparent images in SL?" I really wish that someone would take those very helpful informational posts and copy them into a sticky in this forum. Chosen Few put in a lot of time writing and updating them. They are just as valuable today as they were when he first posted them.
  11. Cool! We usually have to explain how to do that when people have appearance issues and need to start over. So, add your favorite shape, skin, and attachments and you'll be back to normal.
  12. You could create a Display name >>> http://community.secondlife.com/t5/English-Knowledge-Base/Display-names/ta-p/700173
  13. Feel free to add more detail to your question by clicking on the Options link in its upper right corner and selecting Edit. Right now, we can't figure out what you mean.
  14. Here's the same script with no timer event ... integer gPose;default{ attach(key id) { if(id) // If the device is attached, initialize and request perms { gPose = FALSE; llRequestPermissions(id,PERMISSION_TRIGGER_ANIMATION); } } run_time_permissions(integer perm) { if (perm == PERMISSION_TRIGGER_ANIMATION) { gPose = TRUE; llStartAnimation("chinup"); } } touch_start(integer total_number) { integer perm = llGetPermissions(); if (perm == PERMISSION_TRIGGER_ANIMATION) { if(gPose) { llStopAnimation("chinup"); } else { llStartAnimation("chinup"); } gPose = !gPose; } }}
  15. You don't want it to go on and off every second? I thought that was your goal. If not, you don't need no stinkin' timer....
  16. Well, for one thing, no matter what the dimensions of your original image were, they get reduced on upload so that the maximum in X or Y is 1024 pixels in SL. My guess is that your original image is HUGE, so you should expect to lose resolution when it's downsized. My own general rule is not to worry about super resolution on backgrounds or things that people won't normally spend much time looking at. I rarely dimension anything larger than 512 x 512. Big textures rez slowly and are truly annoying. People will either move on before they rez (so they never see your beautiful work) or they wait and wait and then say, "Oh, crap! I thought it was going to be something important."
  17. It's a pretty useless device. It was created (actually several versions of it were created) because prim skirts look really stupid when you sit down. They keep pointing down, cutting through your legs, the chair, the floor....... What this device does is rotate the skirt forward so that it's parallel to your legs when you sit. It's a nice, simple idea, but ..... It also flips the skirt up when you do anything else that SL interprets as a sit ..... like sitting on a poseball to dance, or to step onto a pose stand. It's really embarrassing to start to danc and have your skirt flip up in front of you. Also .... think about this for a second ..... when the skirt rotates forward, what happens to the waist? Well, the front part digs into your stomach and the back part slides down. Depending on how the skirt is made, that leaves you with some really ugly stuff sticking out your back or your butt crack showing. That might be OK if you're sitting in a nice overstuffed chair, but not if you sit where people can see your back. Some of these devices adjust for what happens to the skirt when you start walking, so that it doesn't fly out behind you like a sail. That's a nice idea, although one that a good designer can largely avoid by taking care with flexi settings. I've beeen making and selling skirts for over 4 years, and I won't put one of those scripts in my work. Like most women who wear prim skirts in SL, my solution is not to sit down very often. Or if I do, I don't worry about what the #*&^ skirt does.
  18. The point is that you can set DPI to anything you like. It makes no difference whatsoever unless you are printing the image. How many "dots" there are per inch on your screen depends on the style of monitor you have, what its resolution is set at, and how much you have zoomed in to the image.
  19. It's a really labor-intensive and frustrating method too.
  20. Or ... integer gPose;integer gON;default{ attach(key id) { if(id) // If the device is attached, initialize and request perms { gON = FALSE; gPose = FALSE; llSetTimerEvent(0.0); llRequestPermissions(id,PERMISSION_TRIGGER_ANIMATION); } } run_time_permissions(integer perm) { if (perm == PERMISSION_TRIGGER_ANIMATION) { gPose = TRUE; llSetTimerEvent(1.0); } } timer() { if(llGetAttached()) // If the device is worn { if(gON) { llStopAnimation("chinup"); } else { llStartAnimation("chinup"); } gON = !gON; // Start/Stop anim in alternate timer cycles } else // If the device is dropped { llSetTimerEvent(0.0); } } touch_start(integer total_number) { integer perm = llGetPermissions(); if (perm == PERMISSION_TRIGGER_ANIMATION) { llSetTimerEvent(1.0 * (gPose = !gPose)); // Toggle timer on/off with touch } }} I assume that the reason you wanted to have llSetTimerEvent there is so that the animation triggers on and off on a one-second cycle, right? If so, you actually need a timer event and you need a toggle in there too. That's what my gON is.
  21. No se puede hacer. Eso es una cosa muy buena, porque de lo contrario habría un montón de problemas de los intimidadores.
  22. Yes, in fact there was a very high-profile case within the past four months in which a person was banned from SL for revealing the identities of alts.
  23. Link all three... root prim on the bottom, and put the script in the root prim. I just sent you one in world as a demo.
×
×
  • Create New...