Profaitchikenz Haiku

But the scripts inside it won't be running. ETA - forgot, they'll reset when it's first rezzed or attached, wont they.

Just my tuppernce-worth here, but I think that's a tactical direction and as such it's going to have inherent limitations: you can only do what AWS supports. Single-supplier-dependency leaves you open to several problems, ratchetting up the prices for one. Strategically, a better decision would be to implement on the internet the core services required for the Metaverse in a way that allows a variety of servers to access them. Sort of like the way the opensim is using "standard" servers to cobble together a patchwork hypergrid system. At the moment it's fragmented because of so many competing variants, and they have yet to solve the biggest single issue of a commercial Metaverse: the money. But they have the connectivity, the variety and resilience, the method of taking necessary inventory from grid to grid, and possibly the biggest asset of all, the ability to connect home-based small worlds into a bigger system.

Not quite... the brain works in a different way to the basic on/off/(tristate) method of a chip, but the real difference is in the learning process. That doesn't happen overnight, it takes years. Have a read of people like Susan Greenfield and William H Calvin for how the underlying mechanisms seem to work. Yes, I agree, it could be done, Southampton University began researching protein computing twenty years ago, but as yet, there's nothing on the marketplace. Personally, I feel some anguish at the thought of all those dogs and cats and parrots who are going to be abandoned if the people trying to build carer robots manage to succeed, so I do have a side to take in the biological versus engineered intelligence debate.

What you're sketching out is close to the HTML popup in the Auran Trainz simulator. It displays text with minimal formatting, such as H1 to 6, bold, italic, will put up an OK button or a tick checkbox to close, and will also throw up a single field to allow simple input. Is this what you think is sufficient? If it' limited purely to in-world inventory items (ie HTML must be contained within the script and no external inks are allowed) does that take care of the many reservations about security that others have voiced here?

It works on land (note that it got a null key because it hit terrain). [04:38] emitter: My pos = <19.04506, 125.34560, 22.74044> my Angle = <-102.00000, 0.00000, 90.00000> [04:38] emitter: Raycast got 00000000-0000-0000-0000-000000000000,<19.045060, 130.423000, 21.661200>,1 [04:38] emitter: Hits 1 [04:38] emitter: Found a target at <19.04506, 130.42300, 21.66120> [04:38] emitter: Rezz at <19.04506, 130.42300, 21.66120> distance 5.190856 If your dragon is large enough that the rayCast distance from the emitter to the ground exceeds the length of the raycast vector then you won't get any hits. Also, if you try to breath on water, you won't get any hit (from the surface anyway.). Try increasing the length of the rayCast vector until you get a hit? I simplified the script after posting it because a lot of the diagnostics in it are for my learning about llCastRay, I'd never used it before. Here is a much simpler version. Notice I've set the length of the ray-cast vector to be 12 metres since you (probably) wont be able to get llRezObject to work beyond that, unless the limiting distance is the linkset distance, not the lSetPos 10-metre limit. // Use the region pos and rot of a child prim with // Raycast to determine where the Child's Z axis meets a target // // NOTE Wiki says "Silently fails to rez inventory (to have it's geometric center at pos) if pos is too far from the geometric center of the object trying to rez inventory" // // let us assume that means more than 10 metres away // The child prim must contain an object named rezObject key owner; integer debug = 1; snort() { vector myPos = llGetPos(); rotation myRot = llGetRot(); vector myAngle = llRot2Euler(myRot) * RAD_TO_DEG; vector rezAt; if( debug) llOwnerSay("My pos = " + (string) myPos + " my Angle = " + (string) myAngle); // now determine a possible collision object along the Z-axis of the emitter prim list targets = llCastRay(myPos, myPos + <0.0, 0.0, 12.0> * myRot, [RC_DETECT_PHANTOM, TRUE]); if( debug) llOwnerSay("Raycast got " + llDumpList2String(targets, ",") ); integer iiMax = llGetListLength(targets); integer hits = llList2Integer(targets, iiMax - 1); if( debug) llOwnerSay("Hits " + (string) hits); iiMax -=1; // move back from the result count to the last returned pair integer ii; if( hits > 0) { for( ii = 0; ii < iiMax; ii+=2) { rezAt = llList2Vector(targets, ii+1); if( debug) llOwnerSay("Found a target at " + (string) rezAt ); if( llVecDist(myPos, rezAt) <= 10.0) { if( debug) llOwnerSay("Rezz at " + (string) rezAt + " distance " + (string) llVecDist(myPos, rezAt) ); llRezObject("rezObject", rezAt, ZERO_VECTOR, ZERO_ROTATION, 0); } else // it's too far away to rez at { llOwnerSay("Out of range " + (string) llVecDist(myPos, rezAt) ); } } } } default { state_entry() { owner = llGetOwner(); llWhisper(0, "turn the root prim and touch me"); } touch_start(integer touches) { snort(); } link_message(integer sender, integer num, string msg, key id) { if( msg == "Fire One!") { snort(); llMessageLinked(sender, 0, "Roger Skipper!", NULL_KEY); } } }

Yes, I was on the Isle of Frogs. I'll try it on the ground and see what happens.

Oh yes, like - mirrored facelights

Agreed, I can think of several good uses for this, interactive fiction for a start. The only complication I see is that if you want to implement fully interactive huds with it, the HTML is going to have to handle image-maps, otherwise there's going to be some messy to-and-fro between the floater and a texture with llDetectedTouchUV If only they'd asked us way back in 2010 if Viewer2 was a good idea I actually feel quite soryy for LL right now, we've banned them from playing with their own toys.

"It's not dead, it's just sleeping"

I wouldn't know for certain, I muted myself years ago.

Your question belongs in the Mesh sub-forum, Bakes on mesh is for textures applied to mesh bodies. Briefly, the log file you have highlighted will be in the viewer directory on your PC and might give you some idea of where the uploader choked on the input. Once this gets moveed to the Mesh sub-forum better minds than mine will hopefully guide you through the process of looking in your build for whatever didn't get accepted.

Let me try to put this problem to rest once and for all: I present Puff, a magic dragon, who came about due to a lone DeHavilland Mosquito straying off course during WW2 and crossing into the City of the Autumn Stars, where it fell in love with a dragon and because most of it was composed of living tissue (plywood), an offspring was produced. Puff is linked with the root prim a path-cut prim, so the root centre is right at the very tip of the tail, at the opposite end to the head. Inside Puff's mouth is a white prim containing a script and a red glowing sphere. The white prim is rotated so that it's up-Z-axis points ahead and down by a few degrees. When Puff's white prim is touched, it ray-casts along it's up-Z-axis and returns a list of targets hit, or else nowt. Just behind the (Sounds like Twit but with an A) in a hat's heels is a red glowing sphere. This was launched by Puff when the white prim was touched with the linkset rotated zero degrees around the (root) Z axis. In front of the (Sounds like Twit but with an A) in a hat is another red glowing prim, slightly to his left, launched by Puff when the white prim was touched after the linkset was rotated 30 degrees around the (root) Z axis. Continuing to rotate Puff around the Z axis and fire would produce a ring of glowing spheres, tilting Puff up or down would move that ring further out or close in. And here is the script do accomplish that. It is very simple, and I hope demonstrates the simplicity of using a rotation times a vector to save any amount of Pythagorean plotting, Euclidiean equations or Trignonemtric trickery. // check the pos and rot of a child prim // Raycast to determine where the Child's Z axis meets a target // // NOTE FOR llRezObject! // "Silently fails to rez inventory (to have it's geometric center at pos) if pos is too far from the geometric center of the object trying to rez inventory" // // let us assume that means more than 10 metres away // The child prim must contain an object named rezObject key owner; integer debug = 1; vector rootPos; rotation rootRot; vector rootAngle; getRootDetails() { rootPos = llGetRootPosition(); rootRot = llGetRootRotation(); rootAngle = llRot2Euler(rootRot)*RAD_TO_DEG; } snort() { vector myPos = llGetPos(); rotation myRot = llGetRot(); vector myAngle = llRot2Euler(myRot) * RAD_TO_DEG; vector rezAt; getRootDetails(); if( debug) llOwnerSay("My pos = " + (string) myPos + " my Angle = " + (string) myAngle + " root pos = " + (string) rootPos + " root angle = " + (string) rootAngle); // now determine a possible collision object along the Z-axis of the emitter prim list targets = llCastRay(myPos, myPos + <0.0, 0.0, 32.0> * myRot, [RC_DETECT_PHANTOM, TRUE]); if( debug) llOwnerSay("Raycast got " + llDumpList2String(targets, ",") ); integer iiMax = llGetListLength(targets); integer hits = llList2Integer(targets, iiMax-1); iiMax -=1; // move back from the result count to the last returned pair integer ii; list targetDetails; if( hits > 0) { for( ii = 0; ii < iiMax; ii+=2) { targetDetails = llGetObjectDetails(llList2Key(targets, ii), [OBJECT_NAME, OBJECT_POS]); string targetName = llList2String(targetDetails, 0); vector targetPos = llList2Vector(targetDetails, 1); rezAt = llList2Vector(targets, ii+1); // See the caveat regarding silently failing at too great a distance if( debug) llOwnerSay("Found " + targetName + " (" + (string) targetPos + ") " + " at " + (string) rezAt ); llRezObject("rezObject", rezAt, ZERO_VECTOR, ZERO_ROTATION, 0); } } else llOwnerSay("Fire at what?"); } default { state_entry() { owner = llGetOwner(); llWhisper(0, "turn the root prim and touch me"); } touch_start(integer touches) { snort(); } link_message(integer sender, integer num, string msg, key id) { if( msg == "Fire One!") { snort(); llMessageLinked(sender, 0, "Roger Skipper!", NULL_KEY); } } } In order to be fully functional for your purposes it does require one little addition: having established a target, use llVecDist to determine if the position is within the limiting distance of llRezObject and hold your fire if it's out of range.

I'm not sure I've fully understood you, are you saying "yes, Prof has described what I want to do but I'm struggling to do it because the whole animesh object has to be aligned along the X-axis" ? If so... It doesn't matter about the model or the fact that animesh has to be x-facing, you have an emitter child prim that can do everything needed: it is facing the right way: The line within it "llGetPos() + <vector>*llGetRot()" will always produce a position ahead of the emitter and downwards no matter which way the root is oriented. This is because they are getting WORLD position and rotation values, not CHILD. The script obviously has to be in that child prim and hence addressed by a link message but this won't be affected by animesh or root rotation. All you have to do is establish "vector" which has to have a Z-component which is the distance from the emitter child to the first object or ground along that vector. You could cast a ray and get that Z-length, or.... you could rez a fireball at the emitter which then moves along that direction vector until it collides with something, anything, and erupts into flames. (Actually,this would be a very impressive effect). I'll repeat something I suggested earlier: step away from the dragon and build a small test harness from prims. It has a root prim and it has a child emitter prim. Get the flame particles emitting in the right direction, then play with ray-casts, then get the fireball working, so you can understand the particular problem without getting distracted by animesh, it's just adding to the confusion and making you look in the wrong areas.

Ruth2V4 /Roth2V4 are mesh head, body and hands combined, the feet are separate.

Would not llGetPos(),llGetPos() + <0.0, 0.0, 10.0>*llGetRot() also work for the CastRay vectors to scan for 10 metres along the line of the particles? I'm thinking that since the goal is to rez something at a position calculated by that combination it would make sense to scan using that as well? (I'm not sure what the maximum range of a dragon's blast is but I suspect anything over 10 metres is going to be outlawed by some sort of Geneva Convention)

I'm not quite sure why you're suggesting that? The fire emitter is* aligned such that the Z-axis is perfectly aligned for the direction the ray needs to take to find what is going to be ignited. (Unless the build has since changed, but I doubt it, because particles can only be fired out along the Z axis)

This is an area I have recently started to try and actively improve upon, I've used Nanao Watanabe's Mesh generator for years now and initially played with the import-default but found I had to go to quite high levels at the middle two distances to stop degeneration at anything over 5 metres. I've recently started adopting the method Chin has shown and tried making own intermediate LoD models. I'm still getting to grips with that. Texture mapping is where right from the beginning I would make a single texture with sub-details on and map those onto different faces of the prims, and Mesh Generator works well with that approach. The one gotcha is if you decide to have some faces transparent in the finished model you mustn't do so in the assembly otherwise mesh generator optimises such faces away. Strangely, I've not yet had to do any texturing on a sphere as you have described. In general I agree with everything you say, I think users should be encouraged to use in-world building tools again, but as many have pointed out, it's possible to make bad mesh with such tools with remarkable ease. (Like Blender users never ever ever make such howlers, though

I got bored and had a play with faking parabolas using piece-wise linear curves for KFM. I have to say constant velocity doesn't look natural, but feel free to have a play for yourselves. // fake a parabolic trajectory and calculate KFM values for a traversal // uses standard forumula for an ellipse with range as minor axis and altitude as major axis key owner; integer debug = 0; // user-input start and end, altitude // ASSUMES land.y == launch.y and land.z == launch.z vector launch; // llGetPos() vector land; // float altitude = 15.0; // maximum hieght above the launch required float range = 8.0; // this is land.y - launch.y list points = []; // calculated set of X,Y,Z delta values to be used for each KFM translation integer thisPoint; integer maxPoints; vector destination; integer inFlight; // stops touch processing if in motion calculatePoints() { float x; float z; float theta; float increment = PI / 20.0; // require 20 segments of arc float halfRange = range * 0.5; points = []; for( theta = increment; theta <= PI + increment; theta += increment ) // ignore 0.0 as that gives a wasted zero vector { x = (range - halfRange) - ((range - halfRange) * llCos(theta)); // ugh, I know z = altitude * llSin(theta); points += [<x, 0.0, z>]; // y unchanged in flight if( debug) llOwnerSay("X = " + (string) x + ", Y = 0.0, Z = " + (string) z); } maxPoints = llGetListLength(points); } nextMove() { vector nextVals = llList2Vector(points, thisPoint); vector here = llGetPos(); vector delta = launch + nextVals - here; destination = here + delta; float dist = llVecDist(here, destination); // now calculate speed as a function of distance to get constant velocity // longer distances move faster float speed = dist * 0.5; if( debug) llOwnerSay("At " + (string) llGetPos() + " adding " + (string) delta + " destination " + (string) destination + " distance " + (string) dist + " speed " + (string) speed ); llSetKeyframedMotion([delta, speed],[KFM_DATA, KFM_TRANSLATION]); } default { state_entry() { owner = llGetOwner(); launch = llGetPos(); land = launch - <range, 0.0, 0.0>; calculatePoints(); llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]); llSetKeyframedMotion([], []); inFlight = 0; thisPoint = 0; if( maxPoints > 0) llOwnerSay("Touch me to begin"); else llOwnerSay("I am bereft of data"); } touch_start(integer touches) { key toucher = llDetectedKey(touches - 1); if( toucher == owner) { if( inFlight == 0) { if(thisPoint <= 0) { thisPoint = 0; inFlight = 1; nextMove(); } else { thisPoint = 0; llSetRegionPos(launch); llOwnerSay("Touch me to begin again"); } } } } moving_end() { thisPoint += inFlight; if( thisPoint < maxPoints) nextMove(); else { llSetKeyframedMotion([], []); // the uggle has landed if( llGetPos() != destination) llSetPos(destination); // but just in case... inFlight = 0; llOwnerSay("Touch me to go back again"); } } }

I would ask that there is a preferences or debug setting to allow the end-user to specify where on the screen the floater should open. It can be very annoying when you have the viewer laid out so you can see your radar, chat history, mini map and camera controls and then suddenly one of them gets occluded by a popup telling you that somebody has come online, or you have entered private property and are going to be ejected within 10 seconds (and when such a popup obscures your inventory with the landmarks where you would wish to quickly click-and-flee it's doubly annoying).

I also react badly to sudden noises such as things falling, I don't know of any remedy other than to let the initial flash just go through you and curb any instinctive reactions. On a positive note, it could be a life-prolonger: one of my brothers is now a retired fire-fighter and related the following to me. It was observed quite a few years back that there was an unusually high number of heat-attacks amongst such retirees in their first few months, possibly due to the lack of adrenalin episodes they had previously been accustomed to, and the way round this was for people to phone up the retiree at unexpected moments just to perk them up a little. Treat your anger episodes as similar awakeners.

Madeleine's right then, sinusoidal motion would be a good approximation of a bounce. I remember there was a circus cannon that would fire a sitter quite a distance. Or there's the catapult (flashback to the scene in Jabberwocky). Either way, I suspect the actual path is going to be a series of straight lines for KFM, pre-calculated. Each point is in a list giving a starting vector and rotation, KFM then goes between two vectors and two rotations at a speed you would need to set according to llVecDist to meet your constant-velocity constraint.

You say high-school maths, but this is actually rocket-science The flight path is probably parabolic, but the velocities in the two axes (x and z) vary according to the point on the parabola. A close approximation would be half of an ellipse with the major axis vertical. Most ballistic projectiles conform to parabolas, with variations in the major and minor axes depending on the initial launch angle and velocity, and initial thrust (if a projectile) or motor thrust controlling the maximum altitude. Constant velocity is unusual, though, initial launch or ascent-thrust together with drag tend to cause velocity to rise from a minimum to a peak (at impact). But since you can only put linear interpolation into KFM I suggest the closest approximation would be a series of straight lines (what we used to know as a piecewise linear curve). The KFM time would be directly related to vector distance. If you're simulating a rocket I'd suggest making the powered portion of the ascent a straight line anyway, and only bother with the effects of drag and gravity on the flight path after the rocket impulse has ended.

Try this: Use the selection tool : select by colour, and click into the white area. Copy this and paste into a new image. It will give you an outline mask. Use that and fill the transparent areas with the colour of your choice, then erase or recolour the white surround. Or use the outline mask and invert it to layer over a swathe of colour of your choice. Or, even simpler. (Just read Wulfie's response) Use the select by colour tool, click into a black line, then with the colour picker as Wulfie has described, recolour the selected areas.

I've jut realised the significance of this: Most of the explanatory articles about using quarternions do follow the pitch-roll-yaw model, so I too have always done so, but I now see from both your comment and reading through another article that SL inverted the way quarternions generally worked. Is it only when trying to convert between the two formats that this becomes significant?

Ah my bad indeed, I do apologise most profusely to Quistessa for my incorrect attribution