Having Trouble With Attachments, Offsets, Rotations, My Head Exploding

hi all. i have an attachment and i want it to rez an object when clicked. i'm ok so far, got that working. thing is, i want to control the rez position relative to the attachment and it's killing me.

llGetLocalPos doesn't work with attachments (huh?) so i'm stuck with llGetPos but that seems to give the position of my avi, not the attachment. ok no problem, i'll just put in an offset. oops, that only works if i always face the same direction. i guess i need to consider my rotation too so throw in llGetRot. but how do i mash together my rotation, my position and the offset i want? i'm an artist. i'm not good at math.

i've been working on this for hours and no success. i got close with llGetPos() + offset + llRot2Fwd(llGetRot()) but when i rotate it doesn't rez in the same position relative to the attachment. llRot2Fwd looks helpful but i don't really understand what it's doing.

i don't want someone to do the work for me but can i get some pointers in the right direction please?

edit: this story has a happy ending. read below.

The LSL Wiki is your friend. You want to look at vector/rotation math which is done with operators.

I think, from your question, that you want something like

vector offset = <0.5, 0.5, 1>;  // half meter in and side and one meter up
vector rezPos = llGetPos() + (offset * llGetRot());

But it's been a while. Good luck.

thanks for the reply Malachi. the wiki is my friend for sure but there's alot there i plain old don't understand. it could use illustrations too.

i tried your suggestion and it works pretty well. one very weird thing is when i turn myself clockwise and click the attachment my offset rezzes the object just to the right of the attachment. when i turn myself counterclockwise and click it the object rezzes about a meter left of the attachment. how is that possible? isn't facing north the same rotation no matter what direction i turned to get there?

edit: did some more playing around with it and apparently it's not the same rotation. when i turn counterclockwise the rotation has a negative number for the Z axis. i'm guessing it's the same for looking up and down and such. so here's what i did to fix things....

rotation myRot = llGetRot();
myRot.x = llFabs(myRot.x);
myRot.y = llFabs(myRot.y);
myRot.z = llFabs(myRot.z);

and then llGetPos() + (offset * myRot) in the llRezObject thing. that works but wow it looks clunky. is there no way to get the absolute value of a rotation without all the gymnastics?

In principle, it should be (I think). You've now exceeded my understanding of rotations though. *head explodes*

sorry about your head Malachi but misery loves company muhahaha!

edit: i dunno what happened but i didn't change a thing and now it's back to where it was before. clockwise, rez slightly to the right. counterclockwise, rez a meter to the left. still got the same thing in there changing the rotation positive. it worked and now it doesn't.

actually it feels completely random now. sometimes it rezzes just right and then i barely tap the side arrow, try again and it rezzes behind my back.

ok i seriously am confused. i made a box and sat on it so i could turn myself more exactly and after a couple of times around in circles the script started working correctly again. fine. great. love it. the thing is, it now works perfectly when i'm sitting on a box and turning the box but it's completely screwed up and random seeming when i'm standing on my own feet. what the hell is with rotations?

edit: oh and now if i don't do the part where i get the absolute value of the rotation it does the opposite of what it did before. back then if i used plain old llGetRot() and turned clockwise it rezzed slightly to the right, counterclockwise rezzed a meter to the left. now if i do that it's clockwise it rezzes slightly to the left, counterclockwise it rezzes a meter to the right. i'm not changing anything in the script except what i use as the rotation for llRezObject and the same thing is giving different results.

have you tried something like this?:

vector fwd= llRot2Fwd(llGetRot());
fwd = llVecNorm(fwd);

llRot2Fwd will return a forward pointing vector direction that is not normalized (i.e. still has magnitude) of a given rotation.

llVecNorm will return a normalized vector. Basically a vector with no values greater than 1 or less than -1.

This means that you can easily get the rotation or direction of something by normalizing it. Basically to achieve the effect you want, you'll have to convert your normalized vector direction into an appropriate rotation and position for your rez object. I suggest actually taking a popgun (or any of the other free weapons) apart as many of them have to do this to properly rez a bullet.

Also you might try changing your method for rezzing the object. Clicking on yourself might be changing your rotation simultaneously. You may have noticed while editing things close to yourself that your avatar does some weird stuff. This may be why your script works while you sit, but not when you stand. It could be fine. So play with either a voice command or a mouselook leftclick option.

thanks for the input Siro. i tried that out but i couldn't get it to do it's thing. turns out i forgot to add llGetPos() so it was trying to rez somwhere on the other side of the sim. hehe, oops. after fixing that it almost worked for me but wouldn't stay centered on the right point. i dunno why that was. i'm barely intelligent enough to be retarded at scripting.

but! i found the solution. i took your advice and ripped open the Linden gun as a guide and they were doing it way simpler than me. i guess i convinced myself it was a super hard problem so i was looking for a super hard answer.

the point i want to rez things at will always be in the same place relative to me and will move with me as i turn. so that means it will make a circle around me. turns out that using offset * llGetRot() + llGetPos() as the position for llRezObject does just that. this looks almost just like what Malachi said but for some reason that was twitchy and this is perfect. does the order you put it in matter? is it sunspots? i dunno. i'm just glad it works.

thanks again for the help Malachi and Siro. and a hearty "damn you" to any quaternions who are reading this. y'all are whack.

First off to explain some info that you haven't gotten yet. Animations are all handled by the client, as is avatar size to a point. This means that there is no way (presently) for a script to find where the object may appear to be physicaly (to the physics engine and scripts you look like a non animated block of boxs; makes me laugh to imagine it, thats why attachments aren't physical). When i found this out i was really annoyed as i wanted to build a giant scripted mecha's, (and then have them fight; ohhh it was going to be soooo cool, it was my first script project when i was a noob; i was so put off).

this is what the silly default noob revolver uses to rez bullets, i've mod'd it some to fit nicely in one code block.

vector  offset = <0.5, 0.0, 0.0>;
offset += <0.0, 0.0, 0.84> * 2 / llGetAgentSize(llGetOwner());

float   gBulletSpeed = 30.0;

rotation    my_rot = llGetRot();
vector      my_pos = llGetPos() + ((gEyeOffset + offset)  * my_rot);
vector      my_fwd = llRot2Fwd(my_rot);

llRezObject("Bullet", 
    my_pos, 
    my_fwd * gBulletSpeed,
    my_rot,
    1);

i'm kind of against helping weapons designers with scripting weapons

one other thing i found and i dunno if this is my ignorance or if it plays off what Strife said about how we look to the physics but it seems like when you're in third person view the direction you see yourself pointing is only approximate. when i rez objects in mouselook they're exactly right but if i switch to third person without turning or moving then they rez at slightly weird angles, not straight out in the direction i look like i'm facing.

sorry to say but nothing is going to be *perfect* there are folks in SL who might help you out more but they are in the business of selling guns...

i haven't seen many (read: any) well made guns that are full permissions.

what exactly are you making, i seem to have assumed your making a weapon.

Also you shouldn't be playing with the actual numbers in rotations directly. To understand them seems to require a degree in mathematics (which i don't have) or being a rocket scientist works too (nasa is big with quaternions)

thanks for the input Strife. that's nice seeing the code all pretty and organized like that for once. i've been giving quaternions a hard time but really all i want is a good simple explanation of them that wasn't written for a programmer or math genius. they can't be that hard to understand or they wouldn't be such a big part of the supposed to be easy scripting. right? *crickets*

why the objection to helping people if they are making weapons? as a mad scientist aren't you all into destruction and doom?

okay *takes breath* simplest explanation of quaternions I can give without delving into realms of math I'd rather not. First the difference between a vector rotation and a rotation rotation is that a vector will use euler degrees for angles (which you're more familiar with from the build tools). A rotation type uses radians for determining angle. Now normally a radian is 57.295 degrees or it is equal to an arc equal to the radius of the circle (or so dictionary.com says). However, as I was discussing earlier with normalized vector directions, the rotations in SL seem to have values between -1 and 1 on the x, y, and z axis. The 4th number seems to be a combinational inverse (if your x value is -1, your s value is usually going to be 1 and so on). Beyond that the Wiki ( www.badgeometry.com/wiki ) has some really good entries under rotation and quaternions.

Now the objection, at least the one I have, to helping people make weapons is that more often than not a new player winds up getting their hands on it and blasting me to kingdom come. It's just too easy to make something so powerful that it's not really fun anymore and it can also get the person that uses it in a lot of trouble if they use them in safe areas.

What Siro said about noob weapons i agree with. But also i've found that most weapons programers produce the must inefiant and ugly code in SL. As a result i hate working with them. No offense intended.

I'll try to keep the explination of quaternions (the form sl uses for rotations) as simple as possible. The reason SL uses them is from a programing perspective they are easier to work with then Euler rotations (vector degree/radian format). Euler rotations have a problem with gimble lock and smoothly moving between two arbitrary rotations. So while you can represent any rotation with a Euler it's not a practicle way of holding it. A quaternion on the other hand can move smoothly between arbitrary rotations and does not suffer from gimble lock. The trick to working with quaternions isn't to work with them directly but to use the helper functions. The wiki is your friend. There is no way that i'm aware of visualizing them. The cold hard truth is if you can understand quaternions you can be a programer (not saying it's a requirement). What you were doing above with taking the absolute value of the parts i have no idea as to exactly what that would do.

And to the question about the mad scientist title, yes i do make evil weapons from time to time (before they patched the bug i had a gun that would shoot sim crashing bullets, later i found bugs in the build tools that reliably crash sims. Also built a sim mapper that if improperly used could take out a good portion of the grid in just a few min; most of the bugs (that crash things) have been fixed)

if this shoe fits, wear it. if not then i'm not talking about you.

1. thanks for assuming i'm making a weapon.
2. thanks for not giving me the benefit of the doubt and assuming i'm a "noob" out to blast people and cause trouble.
3. by not helping weapons programmers you're sure not doing anything to fight inefficient and ugly code.

unrelated now...
4. what's gimble lock?
5. i read somewhere that a quaternion is three numbers that describe the axis of rotation like a vector and a fourth number that is the magnitude of rotation. but i also read that the first three are the amount of rotation and the fourth is like the cosine of half the angle or something bizarre. what do the four number really represent and are they similar to a vector at all? i kinda assumed so because you can combine them in different ways, but i just assumed it was the amount of rotation around XYZ and then the fourth number was...well i just ignored the fourth number.

I'm sorry about the weapon misunderstanding. (i have a couple weapon designer acquaintances i help with code from time to time and i end up cleaning and rewriting their code, usually from scratch; a little anal-retentiveness goes a long way with coding)

Gimble lock is where two axis overlap.
example x=0, y=90, z=0; both x & z overlap, this is bad. I'm not good at explaining this :-/ best try some of the articles. All the articles on quaternions listed on the wiki are good articles.
http://www.badgeometry.com/wiki/Quaternions