Profaitchikenz Haiku

You're almost there. You don't need to set the two scale figures for rotate. ALL_SUDES should be replaced by the specific face, and to change the direction it spins, either specify a REVERSE mode flag or set rate as a -ve number. Try this (not tested inworld) llSetLinkTextureAnim(LINK_THIS, ANIM_ON | SMOOTH | ROTATE | REVERSE | LOOP, side, 0, TWO_PI, 2*TWO_PI); It might be worth while checking the value you have set for side is actually the face you are looking at. If for some reason side = 2 is pointing at a blank face you will see nothing hapenning // get the specified face number of a prim // drop this in the actal child to be worked on touch_start(integer num) { integer face = llDetectedTouchFace(num - 1); llOwnerSay("Face is " + (string) face); }

Well, the attitude is certainly that of an 8-year old ... You'll need to look through the other scripts to find out how to determine which gear, then in the above script, set force to 0.0 if in neutral, or -ve if in reverse. Without the rest of the scripts nobody can help more that this much.

Have you checked that they're compiled to Mono rather than LSL?

The simplest method seems slightly cumbersome but is at least predictable: Cast the float to a string. get the length of the string. Test the last character, if it is a zero, reduce the length of the string by one Test again, until the character is not a zero. Then go back by one until the character is a zero. Return the portion of the string from start to that last position. I can't see any value in trying to remove RHS zeros from a float, I would only apply this method when what you need is a string representation of a float for some purpose.

^^^I can't stress how important this is.^^^ When you're trying to compare different script methods, you either have to wait until this period has elapsed before taking script time for the new method, or, you can try taking the difference between consecutive script time readings and tracking that change. Bear in mind that because of that 30 minute averaging period, there will always be a skew one way or the other, unless there is no significant change. Also, bear in mind that waiting 30 minutes before performing the next set of readings might mean there has been a change to the region and more or less activity going on would also have some bearing on the readings. Ultimately,. to compare method A with method B you are best writing timestamps at the start and end of the test and using the difference between them to assess the methods.

It is possible that there are differences in the Hud angle: since you are rezzing from a Hud the object will get the initial rotation from that hud. Try debug statements to examine the Hud rotation just before rezzing, and the arrow rotation immediately on rezzing before any other correction have been applied and look for a difference there.

Not in any controllable way, animations are played client-side, so what you observed was purely on your computer, somebody else watching would not necessarily see the same thing. You could try playing around with Niran's pose maker in Black Dragon and see if there's any way in there of pausing or freezing an animation.

The only way I know to do what you want is to set a rotation or position for each bone that isn't to be moved, it only needs to be 1 or 2 degrees of rotation but that will cause that bone to retain the position you give it. The bone will need that rotation for each frame, so be careful you don't have inverse kinematics on and move it as a result of some other bone movement.

The listen event will get the uuid of the object it has heard from via the third argument, id. Use this uuid in llGetObjectDetails(id, [OBJECT_OWNER]); the first item in the list it gets will be the key of the owner of the object, this is what you need for the instant message listen(integer ch, string name, key id, string msg) { list params = llGetObjectDetails(id, [OBJECT_OWNER]); key talkTo = llList2Key(params, 0); llInstandMessage(talkTo, .... }

Something interesting and unexpected today: I was wandering around with my Alt account, when he got the "Darn, you have been logged out" attempting a TP. I logged in as myself, and saw he was shown as online, so I sent him an IM. No response, obviously. Two minutes later I sent a followup IM. This time, I got the "user not online" as I expected. So in addition to losing track of where the avatar was, what windows they had open, etc, SL is also not even able to change the status of one of these in-limbo souls? It seems to me slightly odd that a user should be logged out of SL and yet their status isn't then set as being offline?

"I'm a bot" "No, I'm a bot, and so is my wife!" (Always look on the bright side of SecondLife)

You wait till ChatGPT starts posting to these forums...

Whatever is happening seems specific to SL: I am getting these "Darn---" messages several times a day in SL, but I have never seen them in any of the other grids. But they're also nothing new so can't be used as a stick to clobber AWS. I have an two occasions seen this TP fail when trying to go from one location to another point in the same region, and in both instances the region was empty so it doesn't seem to be due to avatar-loading, and due to the nature of the regions it wasn't due to breedables, AMT's vehicles, or any of the usual suspects.

Most definitely. It is essential to have a "home" position to which the object can be safely moved to by llSetRegionPos, and in a changed event for Region restart, kill all KFM motion and set position to home before resuming KFM.

I'm guessing hoping he means what happened about 18 months back when "changes to configurations" got rid of all those scripts run % low figures? It cured the really appalling performance issues I was seeing in puppeteered objects but I live in fear of it starting up again.