Dora Gustafson

How are the sittings organized? Is it one script for all sitters or one per sitter? Anyway you must realize that any person sitting or getting up will trigger the changed link event The same event handling you do when the driver sits down will be repeated(the driver is sitting om the same SitTarget) when someone else sits or gets up and that should include requesting permissions for animation and camera control It sounds to me as if the camera control is revoked possibly because a new permission is requested without requesting the camera control at the same time :smileysurprised::smileyvery-happy:

Nice catch The raw vectors are global With your addition they are made local which is most likely what is wanted with a vehicle on a track The other option to have the vehicle stay on track is to rotate it before the motion

I took a shot on this See Rounded Turn for KeyFramed motion in the LSL Library The wiki pages are closed for editing so it can't be found there :smileysurprised::smileyvery-happy:

Function computes relative moves and rotations for a Key Framed Motion Function takes arguments: in-going velocity, out-going velocity and radius of circle sector The turning can be in any plane in space. Plane given by the two vectors 0° < turning < 180° // frames for turning motion, script by Dora Gustafson, Studio Dora 2014 // function computes relative moves and rotations for a Key Framed Motion // function takes arguments: in-going velocity, out-going velocity and radius of circle sector // the turning can be in any plane in space. Plane given by the two vectors // 0° < turning < 180° // v1.01 tuned // v1.02 base rotation included list framesForTurn( vector Vin, vector Vout, float Radius ) { // Compute circle center and first position float sinv = llSqrt(0.5*(1.0-llVecNorm(-Vin)*llVecNorm(Vout))); vector Center = llVecNorm( llVecNorm(Vout)-llVecNorm(Vin))*Radius/sinv; if ( Vin*Center > 0.0 ) Center = -Center; vector startRadiusVector = llSqrt(Center*Center-Radius*Radius)*llVecNorm(-Vin)-Center; // Compute time per step float arch = PI-2.0*llAsin(sinv); float steps = (float)llRound(arch/(10.0*DEG_TO_RAD)); float curvetime = arch*Radius/llVecMag(Vin); float dT = curvetime/steps; if ( dT < 0.11111111 ) dT = 0.11111111; // initialize loop list KFMlist = []; vector axis = Vin%Vout; rotation baserot = llGetRot(); vector U = Center+startRadiusVector; rotation rotU = baserot; vector V; rotation rotV; float step = 0.0; while ( step < steps ) { step += 1.0; rotV = llAxisAngle2Rot( axis, arch*step/steps); V = Center+startRadiusVector*rotV; rotV = baserot*rotV; KFMlist += [V-U, rotV/rotU, dT]; rotU = rotV; U = V; } return KFMlist; } default { touch_start( integer n) { llSetKeyframedMotion( [], []); llSleep(0.2); // 90° left turn in the X-Y plane, EXAMPLE llSetKeyframedMotion( framesForTurn( <0.5, 0.0, 0.0>, <0.0, 0.5, 0.0>, 1.0), []); } }The function needs a thorough testing and I would like to know if something needs fixing :smileysurprised::):smileyvery-happy: Edit: script updated with tuned version. Base rotation included

Yurtiel wrote: If I may though, is there any reason it was expecting me to reset it every time to use the for loop in it? The for loop you made will loop forever and keep the script busy That means the script can do nothing else until it is reset The loop will never stop because cnt will always equal cnt, cnt is identical to itself :smileysurprised::smileyvery-happy:

The LL viewer has an alignment tool, which may be helpful: Select face Choose 'Planar' for all involved faces Make settings for the master-face Select all faces by clicking while holding down the shift key Select the master-face last Check 'Align planar faces' :smileysurprised::smileyvery-happy:

You are right about using full-bright on building walls is a bad, bad idea The way you describe what you see makes me think that your graphics is set Low or Mid and your midday sun is set right above your head With a higher graphics setting, that use advanced lighting things will look better With a wind-light sun set to 9 am or 3 pm it will get even better It is also possible to add specular and bump maps which can make the scenery even more real When you don't know what you customers want you could give them the possibility to set full-bright on and off Finally you may have a gamma-setting option in the graphics setting With gamma you can change the mid-range luminance between high and low to match your taste better :smileysurprised::smileyvery-happy:

Same thing for me, I get no edit option Someone introduced a bug :smileysurprised::smileyvery-happy:

I don't pretend to know the answer but are you sure you didn't make a recursion? Linked messages are received in the transmitting script as well as in other scripts in targeted prims :smileysurprised::smileyvery-happy:

I was unsure if I should take that step but decided not to because it is not asked for in the opening post Anyway it is nice to have for completeness, somebody might want it Tell me why you normalize the arguments for llRotBetween()? I don't and I see no reason to do it :smileysurprised::smileyvery-happy:

The rotation computed is correct Just apply it to the rez function: // script by Dora Gustafson, Studio Dora 2014string target = "maal";string bullet = "stang";default{ touch_end(integer n) { if (llDetectedKey(0) == llGetOwner()) { llSensor( target, "", ACTIVE | PASSIVE, 50.0, PI); } } sensor( integer n ) { rotation rzrot = llRotBetween( <0.0, 0.0, 1.0>, llDetectedPos(0)-llGetPos()); llRezAtRoot( bullet, llGetPos(), ZERO_VECTOR, rzrot, 2); } no_sensor() { llOwnerSay("No target found called: "+target); }} Working script:) :smileysurprised::smileyvery-happy: Edited to point with Z axis and not X

I would say that JSON is so slow you should never even think about using it in real time tasks For updating a scoreboard it would work fine although you might notice a difference llListReplaceList() is used to replace one or more list elements at a time Used with llList2List(), llList2Integer(), llList2Rot() etc. it may be used to modify one or more elements at a time :smileysurprised::smileyvery-happy:

You could consider using JSON JSON will give you a simpler cleaner code, but unfortunately JSON in LSL executes slowly :smileysurprised::smileyvery-happy:

Syle Devin wrote: So it was as simple as multiplying velocity by llGetRot. Is there an explanation behind that? Also thank you, I now understand the numbers that I was getting back for llGetRot, the radians I should say. My main objective is now fixed, thanks again. Also thank you Miranda for the explanation of converting radians to degrees. Edit: So I've run into something else. How come when I multiply velocity by the root objects angle it goes in the forward direction but when I multiply by a different angle the ball's direction is not effected? For example in aiming I got the angle between my avatar and a point that I clicked on the lane. Then I multiplied the velocity by that angle but nothing changed. There is an explanation behind this, but I doubt you will find it simple if you never new quaternions and their use for rotations Read more here: http://wiki.secondlife.com/wiki/Rotation and link on to quaternion Be prepared that this is the kind of maths you can't understand with your mind, but the rules formulas and equations are very useful

You don't say if the land in question is owned by you and land you are selling If it is the easiest way to remove your objects is to sell land and keep ownership of objects See: http://wiki.secondlife.com/wiki/Land_Windows#Sell_Land :smileysurprised::smileyvery-happy:

The llSetAnimationOverride() can override the built-in animations with animations of your choice but Each built-in can be overridden by one and only one animation The function do not provide for layered overrides, so if you need that you must do it the old way [you can override "sitting" with a stand, fly, walk or any animation] :smileysurprised::smileyvery-happy:

llSetAnimationOverride() is good for this. My guess is that it is not firmly grown in most scripter's minds yet :smileysurprised::smileyvery-happy:

Aha:smileysurprised: It is not easy to stay updated, Thanks for telling me :smileysurprised::smileyvery-happy:

If I remember right you need a sensor event handler to go with the no_sensor to make it work It may be very simple though, like: sensor(){;} :smileysurprised::smileyvery-happy:

You can't compare vector sizes like you do You can compare vector magnitudes: if( llVecMag(llGetPos()) < llVecMag( openPos)) If that will do is not easy for me to say when I don't know what you want to do :smileysurprised::smileyvery-happy:

Well done! Great! :smileysurprised::smileyvery-happy:

Methodios wrote: I followed the steps with the scripts given but it doesnt work. Can anyone tell me what i'm doing wrong? but it doesn't work??? Given the question I can say: you did something wrong I can't be more specific :smileysurprised::smileyvery-happy:

Interesting! I never tried this setting before now I made it for my boat and I find it doesn't make much difference to what I new before It doesn't shift the camera to look at me from the front When I get it to look at me from the front it doesn't stay there for long It ends up looking at me from behind when I sail away Sorry to be such a killjoy but either I don't know all the story or your suggestion doesn't work :smileysurprised::smileyvery-happy:

llSetCameraParams() can not set a position in front of you when you are on a moving vehicle The best you can do is to set CAMERA_BEHINDNESS_ANGLE, 180.0 With this setting the camera will not move when it starts out in front of you or your turn you vehicle 180 degrees, but it will change position when the vehicle moves on a straight line: the camera will end up behind you llSetCameraParams() can not set a position right over your head on a moving vehicle The closest you get is 10 degrees from vertical Set CAMERA_PITCH, 80.0 With llSetCameraAtOffset() and llSetCameraEyeOffset() or llSetLinkCamera() you can set any camera position relative to the prim you sit on, also a position in front of you The camera stays in the same relative position to the prim no matter how the prim moves This approach has disadvantages: The cam position is taken when you sit on the prim and can not be changed while you sit The cam position is locked and can't even be changed with the mouse-wheel

Try this: rotation NormRot(rotation Q){ float MagQ = llSqrt(Q.x*Q.x + Q.y*Q.y +Q.z*Q.z + Q.s*Q.s); return <Q.x/MagQ, Q.y/MagQ, Q.z/MagQ, Q.s/MagQ>;}uMoveTo(list keyframes){ iTarget = llTarget((vector)llList2String(keyframes, -3), 0.05); vector offset = llGetPos(); rotation orientation = llGetRot(); vector newFramePos; rotation newFrameRot; integer i; integer length = llGetListLength(keyframes); for (i = 0; i < length; i += 3) { newFramePos = (vector)llList2String(keyframes, i) - offset; newFrameRot = NormRot((rotation)llList2String(keyframes, i+1)) / orientation; offset = (vector)llList2String(keyframes, i); orientation = (rotation)llList2String(keyframes, i+1); keyframes = llListReplaceList(keyframes, [ newFramePos, newFrameRot, (float)llList2String(keyframes, i+2) ], i, i+2); } llSetKeyframedMotion(keyframes, [ ]);} Your code is changed in the lines in red This should give you the relative change in position and rotation between keys provided your list holds absolute positions and rotations