Innula Zenovka

I wish LL would make some sort of official pronouncement -- I've just had this come round one of my groups, and I don't think it's the last time we'll see this sort of spam warning: CHECK UR LOST AND FOUND FOLDER, IF YOU HAVE A FOLDER CALLED ADAM & EVE AVATARS OLD, DELETE IT DO NOT OPEN IT, GET RID OF IT... ITS A VIRUS GOING AROUND, I HAD IT IN MY LOST AND FOUND FOLDER TOO, DELETE IT FAST, THEN EMPTY TRASH Alot of us had it

This is probably overcomplicating stuff (and I can't really visualise the build) but would PSYS_SRC_OMEGA be any use in this project? I've had quite some fun with that in the past, particuarly with fountains.

As Rolig suggests, you could probably get someone to make you a custom skin, but I've always found that -- admittedly sometimes at the cost of quite some time shopping round and then subtly tweaking my shape (particularly my face) to suit the skin -- I've been able to alter my look to my satisfaction without dramatically changing my overall appearance.

Thanks. I hadn't realised that the reason I subtract my position from my target's postion is to make the rotation relative to me rather than the region corner, but now it all makes sense.

Try llRotLookAt(llRotBetween(<0.0,1.0,0.0>, llVecNorm(llDetectedPos(0)-llGetPos())),1.0,0.4); or, if you want to constrain the rotation to one axis, try something like vector detected = llDetectedPos(0); vector pos = llGetPos(); llRotLookAt(llRotBetween(<0.0,1.0,0.0>, llVecNorm(<detected.x,detected.y,pos.z>-pos)),1.0,0.4); As is so often the case with rotations, I don't really understand why I need to use llVecNorm(target_pos - my_pos) there other than that's the way it works, but I'm hoping someone can explain why that's the right thing to do.

Thank you so much for that clarification, Cerise. I'm not sure yet if it solves my problem, but it certainly explains persistent apparent inaccuracies in my testing, which were a major reason for my confusion. I'm working on a tank turret for someone, which the gunner wears. I've got the turret and the barrel moving independently without too much difficulty, but my headache is calculating exactly where the barrrel ends up pointing when I come to fire stuff, and then rezzing it in the right place and moving in the right direction. I'm wondering if I'm going at it the wrong way, and if it wouldn't be simpler to rez my missiles from the prim on which the avatar is seated, since at least there's no doubt about where that is, though I'd still have the problem of knowing exactly where the barrel prim in the attachment is pointing. I know how I've told it to rotate, of course, but since it's attached to an avatar sitting on the prim, I don't know exactly where it is in space, I don't think.

piecheese wrote: I'm on an XP.:matte-motes-asleep: EDIT: Also, I don't speak endless strings of random letters and numbers. :matte-motes-angry: What I would suggest is that you work back from the end and look for where it starts to say "ERROR". Then post here what it says the error is. In my experience, the error messages are usually in pretty clear English ("Can't find such-and-such" or "Such-and-such doesn't exist" or whatever), and even if you don't know what it signifies, someone here might do. At the moment, all you've told us is that SL repeatedly crashes very early on in the start up and that you're using Windows XP. We don't know what viewer you're using or your graphics card or anything. That really isn't much to go on.

You can't write to a notecard by script, at least not directly. There is a way of doing it using a bot (that is, a "scripted agent", or avatar run from a special viewer that will accept scripted commands and make the avatar do stuff), which I have seen demonstrated ages ago, but I've no idea how it's done.

In that case -- if you are using Windows 7 -- look for a file called SecondLife.log in C:\Users\<your windows username>\AppData\Roaming\SecondLife\logs. Open it with Notepad or something, go right to the end, and start scrolling up in the hope of finding something going wrong.

Void Singer wrote: I took it to mean invisible thing in the way of clicking and alt-focus camming (because it canges the center of the cam rotation to a point nearer than expected) That's what I thought at first, too, but then I thought, if it's invisible, what does it matter what the texture offsets and repeats are?

I've been doing some experiments, and certainly reading the child prim's rotation seems to work -- it's using that rather than mine -- but I'm getting the formula wrong somehere. I'll carry on kicking it and see what happens.

Bastian McConach wrote: 33. The slice begin and end are your friend. Remember that next time you want a light beam coming down from that ceiling light. Combine the right slicing with the correct offset and repeat - you're in business. Stretch it to the ground and leave a default of 1x1 repeats and you've annoyed my camming habits. I don't quite understand this, particularly the reference, in context, to "camming habits".

Am I correct in thinking that, if I want to rez something from a child prim in an attachment and I want to do it all from the child prim, I calculate the offset based on llGetPos()+llGetLocalPos()+offset That is, where I am, plus where the prim is, plus the offset? And, if I am, do I multiply the lot by the child prim's PRIM_ROT_LOCAL or do I do something like (llGetPos()+llGetLocalPos()*llGetRot())+offset*llList2Rot(llGetLinkPrimitiveParams(LINK_THIS,[PRIM_ROT_LOCAL]),0) I'm getting very confused. I'm going to be seated when I rez stuff, and the attachment attaches to my pelvis, so I'm not too worried about animations messing me up.

Take a look at your crash logs -- go right to the end of the very long text file and then start scrolling back to when things seem to start going wrong (when the log starts saying "Error"). Does that give any indication what the problem is?

Voreian wrote: I don't get why everything on SL isn't free,.. get a real damn job ya losers Doesn't matter if it's free or not. If I've made it, it's for me to decide what to do with it, not for you to take a copy if you feel like it.

As the others have said, more information is needed. "My viewer keeps on crashing" is a bit like "my car won't start" -- could be anything. If you're using 2.7 or .2.8, then try turning off dynamic shadows before you log in. Those can cause issues, I know, on log in with some systems, no matter how good the graphics card.

Thanks, Void. I've always wondered why the volume detect trick isn't more widely used. I only found out about it by accident, and, because it's so much simpler than the normal "phantom child" script, I wondered if it was unpopular because it's unreliable. I know you can't toggle between phantom and non-phantom using it, but, other than that, it's always seemed to me a much easier way of doing the same thing.

Coincidentally, this bit me yesterday when I made something that uses the Advanced version of the Phantom Child script in the wiki library. This tries to preserve the prim's texturing when it works its magic, by reading and then reapplying llGetPrimitiveParams(PRIM_TEXTURE), but if the object isn't full perms it removes the texture altogether. I'd been thinking of trying to revise that script using llGetLink and llSetLinkPrimitiveParamsFast, so I didn't have to put a script in each child, but I guess this rather snookers me.

Assuming you want the prim to rotate around its own local z axis (that is, around the blue arrow when the ruler is in local mode, rather than world mode, and you're looking at that particular prim using "edit linked parts" rather than the whole object), try llTargetOmega(<0.0,0.0,1.0>*llGetLocalRot(),1.0,1.0);

If you make any prim other than the flywheel the root prim, then the flywheel should behave as you want. llTargetOmega makes the individual prim rotate unless it's called from the root prim, in which case it turns the whole object.

From what they have been saying in their respective forums and blogs, the developers of both Cool VL and Singularity (both based on the old 1.2n code) seem pretty confident that they will be able to display mesh reasonably soon. Only time will tell if they are correct, of course, but it's by no means certain that 1.2n viewers will vanish from the scene if people want to use them.

llDetectedTouchFace

There are several in-world classes. NCI and Builders Brewery both offer them, to name but two. For what it's worth, I got started by doing some of the self-paced introductory tutorials at the College of Scripting http://slurl.com/secondlife/Horsa/43/236/84 and then finding a simple project that interested me (at the time, as I recall, I was trying to make windows switch between being visible and invisible and getting doors to open and close) and asking lots and lots of questions in the College of Scripting's in-world group and the Scripting Tips Forum. And I studied -- still do -- both the old LSL wiki and the "Official Wiki". I don't mean to be discouraging, but I really think making decent breedables might be an over-ambitous first project for a beginner. They really are rather complex pieces of work, requiring a very detailed knowledge of a lot of different types of scripting.

The message you're getting, I think, means the script is trying to play an animation without having the necessary script permissions. It's nothing to do with your AO or anything like that. Scripts need permission animate your avatar. If the script is in something you're wearing (or sitting on), the request is granted silently and automatically, but the request still has to be made in the script. Normally, a script in an attachment will request PERMISSION_TRIGGER_ANIMATION in the attach event, which fires when you attach the object, not unsurprisingly. Off the top of my head, the most likely reason you'd suddenly start getting this sort of error is if you've reset the script while you're still wearing the object (it shouldn't happen if the script had proper error handling but not all scripts do). But detaching it and then reattaching it should fix that, I would have thought. If it doesn't, try rezzing it on the ground, then resetting the scripts (and ignoring any error messages) and then take it back into your inventory and wear it. If that doesn't work, you might ask about it in the scripting tips forum, and see if anyone there can suggest anything.

Quite how you synchronise the two animations depends, I guess, on whether you're intending to start both animations simultaneously or to synchronise them if you're already dancing and then invite someone to join you. Either way, I would have the main script -- the one that handles the sensor and dialog -- also get permission to animate the wearer when it's attached, so that's one less thing to worry about. Then, send a link message to the second script, when you've selected your prospective dance partner, with the uuid of the avatar with whom you want to dance. In the run_time_permissions event of the second script, if the invitation's been accepted, start the animation and send a link message to the first script telling it that the invitation has been accepted, so do stuff to start the wearer dancing/synchronise the two, or, if the invitation's been declined, send a link message to pop up a dialog asking the wearer what to do next. ETA --come to think of it, probably it would be better, when the second script obtains permission to animate your partner, to have it send a link message to LINK_THIS and then start (or try to synchronise) both animations in the link_message event.