Profaitchikenz Haiku

If and only if you are starting a new curve, you set b_i to 0 AND call coefisFirst to generate the values for P1,P2,P3 q1, Q2,q3, but subsequent iterations to use the P1,,,Q3 values first produced at the start of the curve. What you need is to enclose the b_i = 0 and coefisFirst() in braces What I am trying to point out to you is that when you are trying to do too many things at once it isn't only yourself that is going to be struggling in the serbonial sough, but those trying to make sense of your code snippets. It would help both of us if you scrapped all the TYPE stuff and only added it back once you have got the basic curve-generation working.

I can only repeat my advice, simplify your script, address one issue at a time. First of all get it working to output posittions and rotations forgetting about wandering, different type flights, etc. You are trying to debug oo many things all at once and risk getting bogged down in a serbonial swamp. I suspect you won't take that advice and will press on, but if it helps you, let me just consider this routine: If b_i == LiN or 0 you set b_i to 0, but then you call coefisFirst regardless, so if b_i was 3 or 4, instead of continuing from the last point, you are once again going back to the first point conditions.

/me want a "block any anime content" button There are some hidden dangers to the "ignore,mute" approach, and that is the risk of losing part of your internal adjustment mechanism that maintains a thing called "tolerance". If you don't keep mental functions up to date they can atrophy. Fresh challenges are an essential part of survival and evolution.

I would suggest you comment this out and instead set a test prim to nex_pos and newrot to debug your position generation, and once happy with that, go back to trying to get the wandering to work. There's far too much going on in there that could account for no movement or no rotation. Work on one thing at a time.

Yes, it might, but I dont see that statement in your code snippet either. I see you calling vec2Rot(nex_Pos) but is that the same? If Bez was adequate why would Dora have used dBez instead?

Looking at your snippet, that might be because you are not using the second bezier call (dBez) to calculate the rotation, hence there will be no change

You are aware that the function coefisFirst() simply sets up the initial start conditions for a set of Beziers but nothing else? Belay that, I got lost in a profusion of commented-out code What Dora is doing is using the range value as limits when ever any of the three random points for the bezier curves are generated, so it's done first of all, P0 i the starting point (assumed to be inside the range), then P1, P2, and P3 are generated randomly, and ussed by subsequent calculations. You are not doing this and so some points are going to be generated outside the range.

The OP did take pains to state none of the prims used alpha-blending or alpha-masking. I still think the best suggestion (JaylinBridges) is of other people TP-ing there to see if different Firestorm settings, or better still different viewers, might give a new insight into the issue.

Certainly I did, as did most of those I knew, mainly because the viewer tags at the time showed you who was using what. Subsequently LL banned the display of viewer information, I dont dispute their reasons r actions, but you could still see who was on Viewer2 most of the time because of the leaps and bounds.

Thinking ahead t the point where you have learned to crawl, got up off the floor and are starting to walk, I have seen a showstopper to the whole idea of using KFM to get around. It will only work on a dead-flat surface, because KFM will not only move your dragon to NewX and NewY, but it will want to move it to NewZ as well, and NewZ might be under the level of the physics surface at NewX and NewY, and I can't see an easy way to get the hieght at that position. I think you're going to have to go back to using methods that propel the Dragon in an X and Y combination of directions but rely on the underlying physics surface taking care of it's elevation...

Back in 2010 when I was a full-time RPer and most of us used V1 viewers, a strange new phenomenon emerged: a player would suddenly leap a few metres in the air instead of responding to what had just been posted. It turned out that they were using a new LL viewer, Viewer2, that implemented a "If you didn't click to set focus in the local chat window I'll assume you actually wanted to move around the world" dictum. What they had laboriously typed was not uttered and so they had to click in the chat window and equally laboriously type it in again. I puzzled over why Para-player were the least affected by this Viewer2 behaviour , but it turned out that most of them composed their posts in Word and then copied and pasted it into the chat window.

Ditto. I have no real gripes about the viewer, apart from When I've been going to and fro in the inventory and I then see something in world like a rapidly advancing train I need to get away from I'll tap the up arrow a couple of times but the ***** focus is still in the inventory and all the folder positions I've so carefully set up get lost as the entire inventory structure gets collapsed to one smug little top-level folder grinning at me with a "Now see what you made me do" expression. And I get hit by the train. Oh, and did I mention the camera controls? But neither of those would lead to me flouncing out of SL and going back to the train simulators. And if you think the SL interface is clumsy, go to something like Trainz where you need an A4 sheet beside you with all the key-presses on it...

Here is a one-shot bezier curve generator that outputs region position and rotations adapted from Dora's code. I have removed all the second and third parts, the dialogs, the particles, the movement, and the generation of times and deltas, and all code not required to generate and output the curves, this should make it easier for you to study the method of generating the curves. // One-shot Bezier curve generation to give region positions and rotations // within a 10m x 10m x 0m space centred around the containing prim // Adapted from the following work: // Bezier Key Framed Motion script by Dora Gustafson, Studio Dora 2012 // Build on Cubic(3.order) Bezier chain by Dora Gustafson, Studio Dora 2008 vector range = < 5.0, 5.0, 0.0 >; // ± half range for each coordinate in meters rotation refFrame=<-0.5, -0.5, -0.5, 0.5>; // points Z forward integer frames=16; vector P0; vector P1; vector P2; vector P3; vector Q1; vector Q2; vector Q3; vector LEFT=< 0.0, 1.0, 0.0 >; list PosRotList=[]; vector b1; vector b2; rotation r1; rotation r2; integer curvNumb=3; rotation homeRot; integer listLen; integer lastList; vector randomP() { return llGetPos() + < range.x*(llFrand( 2.0)-1.0), range.y*(llFrand( 2.0)-1.0), range.z*(llFrand( 2.0)-1.0) > * homeRot; } rotation Vec2Rot( vector FWD ) { FWD = llVecNorm( FWD ); vector UP = < 0.0, 0.0, 1.0 >; if ( llFabs(FWD.z) < 1.0 ) LEFT = llVecNorm(UP%FWD); UP = llVecNorm(FWD%LEFT); return refFrame*llAxes2Rot(FWD, LEFT, UP); } coefisFirst() { P0 = llGetPos(); P3 = randomP(); P2 = randomP(); P1 = randomP(); Q1 = 3.0*P1-3.0*P0; Q2 = 3.0*P0-6.0*P1+3.0*P2; Q3 = 3.0*P1-P0+P3-3.0*P2; } vector Bez( float x ) { return P0 + (Q1 + (Q2 + Q3*x)*x)*x; } vector dBez( float x ) { return Q1 + (2.0*Q2 + 3.0*Q3*x)*x; } string operation = ""; default { state_entry() { refFrame.s = -refFrame.s; } touch_end(integer n) { if ( llDetectedKey(0) == llGetOwner() ) { if (operation == "" ) { homeRot = llGetRot(); float liN = (float)frames; PosRotList=[]; lastList=0; coefisFirst(); b1 = Bez(0); r1 = Vec2Rot( dBez(0)); integer i; for ( i=1; i<=frames; i++ ) { b2 = Bez( i/liN); r2 = Vec2Rot(dBez( i/liN)); PosRotList += [b2, r2]; // [ b2-b1, r2/r1, dT]; b1 = b2; r1 = r2; } listLen = llGetListLength(PosRotList); operation = "New"; llOwnerSay("Touch me to see the list of points"); } else if( operation == "New") { //llOwnerSay("List is " + llDumpList2String(PosRotList, ",")); integer ii; integer iiMax = llGetListLength(PosRotList); for(ii = 0; ii <iiMax; ii+=2) { llOwnerSay("Point " + (string) ((integer) (ii * 0.5)) + " At " + llList2String(PosRotList, ii) + " Rot " + llList2String(PosRotList, ii+1) ); } operation = ""; } } } on_rez(integer param) { llResetScript(); } }

I'm struggling to see the relevance, you say this is not scripted anywhere but it obviously is, they are support routines called as required. I mentioned way back in this thread hat there are three parts to the production of the path: an initial move outwards from the starting point, a second stage of going from where stage one ends up to a new ending point, and a final third stage that goes from where stage 2 ended to where stage 1 began, thus closing the path. If you don't want to go around in a closed path then you can dispense with stages 2 and 3, (drop coefisnext and coefislast) and simply generate a bezier curve from where you are now to some now position. At the new position, repeat. So in Dora's code, look ate where coefisFirst is called, and from there look at all the subsequent calls up to but not including coefisNext and this will show you how those support routines are used to generate a path away from an initial position. ETA Just got inworld and had a look through Dora's code. of the routines you have posted, only sBez() is never called, Bez() and dBez() are both called when creating a new set of curves. Missing from your snippet is a function Vec2Rot() which is called with dBez as the input and gives a rotation that is the new direction in which the cube is to face and therefore necessary for your animal to turn in the appropriate direction as it goes along the path. Thinking about your hair flying off, what springs to mind is that your avatar is being made to move far too quickly and the attachments are then taking a while to get repositioned, are you perhaps trying to move yourself around by sitting on a pose ball and using llSetLinkPrimitiveparamsFast to shift the ball and yourself as an entire linkset to a new position?

Since all of us have managed to adapt to the existing range of UIs I don't think the UI as such is the off-putting thing for new user. What I do think is that there should be ways to simplify the controls so that a new user just gets what they need initially to move around, communicate with other, and rummage through their inventory. More complex operations could be activated once they actually get the need for them. What I think is one of the worst items of all is the default LL camera control, which is large and unwieldy for what it actually needs to do, grabbing a huge chunk of the screen with no ability to resize it or customize it to show only what the user actualy wants to be quickly available. However, I still think the biggest driver-off-of-newcomers isn't the UI, it's things to do, or lack of them.

No, I'm afraid I didn't. I'm not a very videoish person, more of a bookish one. My point is that Dora's code example gives you everything you need to work with on the task as you initially stated it. You can modify it to turn off KFM and simply get a list of points to feed to your beast in whatever manner works for you. The main thing is it is one of the best simulations of animal pathing you're likely to find. To do what I think you're now saying you want to do, I think it's a case of determining the general direction for the next movement, determining the actual amount of moment in that general direction and then getting an actual position and rotation from a call to a routine that generates a bezier curve between From and To. As far as siting on the beast or keeping your hair on I'm afraid that's best addressed after you get the pathing working.

The part of Doras script that is most impressive is how she generates a path that shows purpose and intent. Creating points along a bezier curv e is simply a matter of implementing a formula, constraining them within bounds a matter of setting range and limits, it's the coice of direction to move in that needs careful thought. With the exception of gas molecules in sealed containers or certain literary heroes in contrived circumstancs, most of nature's creatures do not go blindly to and fro with no apparent reason: for "sxeprion" read "exception". I can only wonder at my fingers.... Sharp changes in course are rare and suggest something out of the ordinary

My Cranial CPU sticker reads "Evil Inside"

No, even if you ignore, you'll still see something she posts if somebody else quotes it. You could look at the issue from a different perspective: somebody obviously thinks enough of you that they follow your every word. Me, personally, I'd be glad of somebody like that, Loads of times I'll respond to topics only to find that my post is the last one there, nobody follows on. I look back over all the threads I've closed down and feel like a murderer or a killjoy.

Live a little, go for 11

I'm going to risk doing a Jethro Tull here and ask what exactly is it in the picture that I'm supposed to look at and go "Oh that's a glitch" ? Is it the difference in the grassy texture on the two adjacent prims? If so, it's similar to the times I've spent trying to get textures to align seamlessly only to find that one of the two prims is rotated/profile-cut/path-cut differently with respect to the other and so needs a different set of texture parameters. Or when I've got the wrong set of parameters for the bump-maps. If no, then put me out of my misery, what's the burning issue? I can't sleep until I know now.

Not me, I've not mentioned object keys. are you perhaps referring to this? You are right in that the Keyframedmotion command acts only on the object it is in, but it can be given the essential data from an external source, so what I envisaged is you used Dora's code to generate a large list of position, rotation and time values What I was suggesting is that you modify Dora's code so that instead of generating a list of position and rotation deltas with times and whizzing off to show you what they looked like, it generated a list of actual region position and rotations and chatted that out or gave it to a prim that acts as a server, which stores it as a list ready for when the animal wants to start moving. Or, you could capture the output in a notecard and give that notecard to the server. What you would get is a list of position1, rotation1, time1, position2, rotation2, time2,... and so on You then work through this list taking them three at a time, and doing this: KFM_Position = list_position1 - current position KFM_Rotation = list_rotation1 / current rotation KFM_time = list_time1 the prim then chats those three KFM_values to the animal, which does a KFM movement using them. At moving_end, the animal does two things: Sends the server it's new Position and Rotation. Does any linkset re-arrangements. The server now increments the index to point to position2, rotation2, time2 and goes through the same process, sending three values to the animal, waiting for it to send back it's new position and rotation.

Should you find yourself facing this sort of problem again, the way to try and track down what's happening is similar to putting a trace or watch on a variable in a debugger: Go through the script looking for every place where that particular variable has a value assigned to it or it's value changed, and add an llOwnerSay statement to identify where in the script it is, and what the value is. Quite often, this exercise will uncover the mistake and you won't even need to run with the llOwnerSay outputs. The sort of situation you are looking for is where you have passed a global variable to a function and that function tries to alter it by assigning a new value to the input argument (questionable action), or where you have thought you are using a local variable with the same name ( one of the biggest recipes for disaster), or where you hav e assignd tthe right value but then in a subsequent function call, a default value is re-assigned as part of another operation. More often than not, however, the problem is as simple as getting confused between similar sounding names

So imove is always ending up as 1, not 5? If you set imove explicitly to 5 does it work as expected? By the way, in your llOwnerSay statements, when you chat out the final value of way, you are actually chatting out count?

The major stumbling blocks I've overlooked are that 1) Only the original poster can edit the post 2) there is a time-limit on how long a post remains editable. So this one has to go in the bin marked "Good idea but unimplementable" We could I suppose petition the forum gods to allow some of us rights to edit other's posts, but, I know I wouldn't be able to resist the odd FIFY and I'm sure there's many here who also