Profaitchikenz Haiku

Each ball is going to have to be a separate face when uploaded, but typically you'd just have a few colours and therefore repeat the faces. If however you want to be clever and have marching colours flowing along the line of lights you might have to accept a higher LI siince each time the faces g upp by a multiple of 8 an extra prim equivalence is added.

I just have to quote the Stott brothers "No you, stop starting you!" (for thhose unfamiiar with the Stotts)

You can't do this with large objects so easily, but with many objects you can use the build tool and rotate the object through 90 degrees on some of the axes to get aligned in different ways. Assuming you are standing facing your garage in the picture earlier, rotating it around the Z axis will get you side and front elevation views, rotating it around it's X-axis will put it into the position of a top-down view. If you really felt the need to replicate the CAD-style three-views you could have four copies of the model and put them in different alignments, however, feel trying to work in the CAD-style is not going to get you the smoothest of experiences here. The Builders-Buddy type aids help with precise positioning, but for a lot of us it's as easy to look at a prim's X,Y,Z positions and dimensions and from that calculate how far along one of those axes a different sized prim must be positioned so that the adjacent faces are coincident. In some of the Third-party viewers is a command-line calculator so that you can type in expressions such as "calc 105.65 + 0.5/2.0 + 0.75/2.0" which will give you a value showing where on the axis in question you place a 0.75 cube so that one face will be up against a face of the 0.5 cube centred on 105.65 on that particular axis. It's much faster than using a calculator.

I was, as usual, just a little bit tongue in cheek there

A really tricky subject, they need to know that ultimately it is their responsibility to take control of themselves, the more you help them evade this realisation the longer it will take them to see the light. Cuddles can sometimes give them the excuse to push uncomfortable truths under the carpet. Time and again, I tell myself, I'm staying clean tonight, But the little green wheels are following Oh no, not again

And give them your IP so they can ban your alts too. ETA colour me tongue in cheek

Two pointers to help you. First, you are starting your b_i counter from 0, instead of 1 as I did. What this means is that the fractions of the bezier offsets P1 to P3 and Q1 to Q3 that should be added incrementally to the starting positions will be zero and the first points you calculate are therefore just your starting points, so no movement will occur 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; } // from nextCoordinates if (b_i == liN || b_i == 0) { b_i = 0; coefisFirst();} iPos = Bez( b_i/liN); // when b_i = 0 iPos = P0 newrot = Vec2Rot(dBez( b_i/liN)); b_i++; So when b_i starts at 0 iPos is just the starting positon. Later on in the routine __llwanderWithinKeyfame, you calculate nex_pos with a call to clipRegion on the result of calling nextCoordinnates, all well and good. I am seeing a value in nex_pos once b_i has incremented from zero that is different to the starting position, but then, what you pass to __loadCordinates to actually do the Keyframed motion are two vectors of identical value, iPos and nex_pos - iPos, so there will be a zero vector result and no keyframed motion target_wander_id = __loadCoordinates(iPos,(nex_pos-iPos),newrot, llFrand(FUDGE)+ (nex_pos.z)/SPEED,target_wander_id); And I think the reason iPos has changed from what it should be, the current position from which you want to move to nex_pos is because although iPos is a global, you have assigned a value to it as the return from a function vector nextCoordinates(integer p_TYPE) { // float driftRange = llFrand(MOVEMENT_RANGE); // float circle_radius = 5.0; // float a = llFrand(TWO_PI); // float b = llFrand(TWO_PI); // float c = llFrand(PI); Debug("nextCoordinates"); // if(TYPE == 2) return <iPos.x + driftRange, iPos.y + llFrand(MOVEMENT_RANGE), iPos.z>; //if(TYPE == 4) return <iPos.x + driftRange * llCos(a), iPos.y + driftRange * llSin(b), iPos.z>; // if(TYPE == 8) return iPos + <driftRange * llCos(a) * llCos(b), driftRange * llCos(a) * llSin(b), driftRange * llSin(a)>; // if(p_TYPE == 9) { if (b_i == liN || b_i == 0) { b_i = 0; coefisFirst();} iPos = Bez( b_i/liN); newrot = Vec2Rot(dBez( b_i/liN)); b_i++; //} llInstantMessage(llGetOwner(),"ipos:"+(string)iPos+", newrot:"+(string)newrot+", TYPE:" +(string)p_TYPE+" b_i:"+(string)b_i); return iPos; } inside that function I think you need to have a local vector variable __localVectorIposSubstitute which gets the return value from bez and that is the return value That assignment is made inside the do loop in _llwanderWithinKeyframe's do loop do { //Debug("_llWanderWithinKeyframe:Process point:"+(string)nex_pos); nex_pos = clipRegion(bot,top,nextCoordinates(llList2Integer(TYPE,TYPE_FLIGHT) )); } while(checkInside2(bot,top,nex_pos) == FALSE && i-- >0); So the only time you will ever get different values between iPos and nex_pos is if the region clip routine changes anything. At all other times, you will be generating KeyframedMotion vector delta values of <0.0,0.0,0.0> and it is no surprise that nothing moves. (To clarify, I believe you need to keep iPos as where the prim is currently, calculate nexPos as where it will be on the bezier curve subject to region clipping, and then the value nex_pos-iPos you pass to the keyframed motion wrapper routine should work. That means the assignment of Bez(b_i/liN) must not go to IPos, but via the function return to nex_pos.. subject to region clipping) Pro-tip: Function return values must be local to the function, to avoid unexpected effects After some fiddling in a sandbox I did manage to get some movement.

I still make things inworld, for some things I then use a tool to mesh or sculpt sub-assemblies of prims rather than go out to Sketchup, but I suppose this means I am a builder, not a creator? whatever, I'm happy doing it that way, I like a wide open space around me when I'm building, I like to see how things fit with other things, the most I could wish for is for LL to release their own inworld prim-to-mesh/sculpt method.

If you know where it's going wrong you're 90% of the way to fixing it! My suggestion, which may or may not be taken seriously, is to simplify this, Abandon all the wander-within, keyframed motion, constrain within parcel and simply write a small routine that generates a series of points. Make the cube move to each point. When you are happy that the cube is moving to each point, add keyframed motion and glide from each point using the delta values for positions and rotations. When you are happy that it i working, add in the constrain to region/parcel limits After that, add in flight types, etc. I started to see if I could make sense of the script but it is far too complicated to debug by just reading, and produces faar too much chatter to see anything in the stream of messages. Mullah Nasrudin was discovered crawling around on his hands and knees in the road outside his house. Onlookers asked him "What are you doing?" He replied "I lost my keys". They got down on their hands and knees to help him, and one of them asked "Where were you when you dropped them?" He replied "I was indoors" The same one asked him "Then why are you looking for them out here?" He replied "It's too dark to see anything inside"

I see that you are not using ownerSay for your diagnostics but llInstantMessage in several places. This might cause you a few problems: From the wiki llInstantMessage This function causes the script to sleep for 2.0 seconds. If the specified user is logged in, message will appear in the chat window and will not logged by the InstantMessage logging facility. If messages are sent to the same user by the same object within about 65 seconds, they will be bundled together in a single email Messages longer than 1175 bytes will be truncated to 1175 bytes Using llOwnerSay is going to be far quicker

Just playing with this in a sandbox, just before the call to llSetKeyframedMotion I chatted out the list lCoordinate which you are passing to llSetKeyframedmotion and it consists of a Zero Vector, a Zero rotation, and a time of 0.3 seconds, so no movement is going to occur. You need to debug what you are feeding into the list lCoordinate. Here is my suggestion: Remove all diagnostic output except the immediate feed to the keyframedMotion, lCoordinate. If you see Zero vector and zero rotation., move the diagnostic output backwards in the sequence of statements to check what you are passing into that routine. Examine the positions and rotations , which should be non-zero if any movement is to occur. Keep doing this until you reach the point where you are outputting actual changes to position and rotation, then go forwards again to see where they are being lost. You have several possible causes such as the routine that tries to clip the generated values to keep them inside a region boundary. If that is too hard to contemplate, then go in the other direction: Start where you generate your next position and look to see why this different position then gets changed back to zero vector Either way should gradually lead you to where you are losing the calculated values. (I also think that with keyframedmotion you might be better off using moving_end rather than at_target? I've never used targets with KFM< only with llMoveto and RotLookat)

As wulfie has pointed out, getting the two lists in the right arrangement for tthe one to be searched in and the one to produce the search items will affect performance. It also can affect what would otherwise be a paradoxical situation: Consider you have to create two lists: List A is all men who shave themselves. List B is all men who are shaved by the village Barber Preparing list A first then list B allows you to escape Russel's paradox, since the answer to the question "does the village barber shave himself" can be answered immediately by list A, whereas in preparing list B you would be working from a list of the Village Barber's customers and so would exclude him. No real surprise anyway, I have always found my ultimate reaction to many of the paradoxes is "it's a joke you idiot" The trouble with many patterns of human thinking is that it is excessively polarised. "You're either for me or against me". No room there for "Couldn't Give a ****"

This isn't unique to SL, in the Auran trainz community a class of people were nicknamed "Gimme Pigs" for loudly demanding that the suppliers of payware also make freebie items.

Funny you should say that: I was asked yesterday to examine a looprezz-derived script that was apparently failing to work for the owner. I rezzed the object on my parcel and proved it rezzed 16 items in an ellipse, but then got an immediate burst of moving_end errors from the funicular, which has been running error-free for over two months now. I repeated the test several times but couldn't get any further errors to occur, it seems that the initial shock to the region was a one-off, but it's left me puzzled. There are plenty of prims free so that's not the cause, and the rezzed items were just flexible path prims, unscripted, so it wasn't a hit on the region script resources either. Regarding the suggestion of a suite of benchmark tests to examine region performance issues, I think we need to include things like keyframed motion, texture changes on display boards, object-rezzing, rather than just a looped counter seeing if 11000 iterations of a routine takes more or less time than anticipated,

An interesting scenario, but you are only talking of scripts sending data to scripts: I tested llRegionSay, llSout, llSay, llChat and link_msssages in two parcels over a 2 week period and not one message failed to be received, let along score a delay of any measurable amount. These activities are relatively light but equally vital for things like Huds, and so it's good to know they don't seem to show degradation, despite what the stats might show. But in that same period I was recording instances where moving_start or moving_end failed to be raised with a 30-second timeout period beyond the point at which they ought to have occurred. In all the cases where moving_start had not been raised the object had indeed failed to move, but more puzzling was that in the moving_end failures, the object had got to within half a metre of the destination, just decided to do a Zeno's paradox demonstration and not quite make it. My thoughts are that scripts on their own are not subject to problems, it's when they are trying to cause movement in world that degradation of performance is becoming noticeable.

welcome back, they're possibly all shrieking about the metebetteverse

On and off. Sometimes I'll log in and in local chat I'll see the tail end of conversations from a few years back. No idea what triggers it and it's too infrequent to pin down.

Sorry if I stubbed your toes, but I'm under doctor's orders to ruffle somebody's feathers once a day to keep my blood-pressure down

Yes, I agree, but from my own experiences I found that running scripts on their own to just count messages sent from other inworld objects showed no signs of any issues. It is when events requiring server and client communication are involved that the problems do start to become apparent. Things like Hud comunications don't seem to be affected, scripted attachments all seem to function normally, it is objects moving inworld that seem most affected by whatever is at the heart of this issue.

Those of us who noticed something strange a few months back already had scripts that used keyframed motion or prim puppeteering to move transport objects to and fro, and observed these movements were becoming jerky and erratic, and the times for the journeys were longer than had originally been programmed for, These changes coincided with a dropping in the contentious figure. The only problem, as I have discussed with Coffee previously, is that helivators, railways, busses, wandering pets are too complicated to form the basis for a jira. I on't think we need new scripts, just simpler test cases derived from them.

I ought to bring to everybody's attention that Monty said "some are just wrong". Some != all.

As n old-school programmer* I have to say give absolute priority to getting the code to work properly, documentation can be given to less able people during quiet spells. * Those who can do, do, Those who can't do but know, teach. Those who can't do and don't know, go into QA

I think what Monty was trying to say is that although you might have a lowish scripts run % figure, you might not actually be suffering any performance as a result of it. As I said above, using a scripted object that should perform to a known schedule is probably the only way to really evaluate the performance of scripts in your region. If the object behaves acceptably, doesn't jitter when moving, and keeps reasonable time, then the value you're seeing for your % scripts run indicates an adequate level. If the object takes much longer to complete the movement and is noticeably jitter then your scripts are not performing adequately. I am coming to the conclusion that many of the metrics we have in the Ctrl-Shift-1 floater are quite old diagnostics dating from when SL was in it's infancy and haven't been updated for some time, but are left there because trying to remove them from the code could a) break something because parts of the code involved may have other purposes b) cause all the TPVs a real headache in having to revise all their code in line with the Lab's sweeping changes So they're there, and because they don't actually have relevance today no attempt has been made to document them.

Add an on_Rez event and inside it either call close() or llResetScript() default { on_rez(integer n) { close(); } state_etry.... } Oh, and you don't need the two return statements in the touch event, the event isn't called as a function so they do nothing.

It's a bit like building a sandcastle, it's great fun and totally absorbing while you'e doing it. And then somebody comes along and kicks it everywhere...