Fenix Eldritch

Hi folks! While working on a project, I discovered the need for more control over texture animating (without having to resort to repeated llSetLinkPrimitiveParamsFast() calls. I drafted up a JIRA request and was hoping to get some feedback on it. The gist of it is a new function which looks nearly identical to llSetLinkedTextureAnim() but replaces the start and length parameters with a list. That list would contain integers (indexs of the animation frames). https://jira.secondlife.com/browse/SCR-399 After digesting it for a day, one concern comes to mind, would the overhead of sending a potentially large list to the viewer to store and locally animate be more costly than repeated set prim params?

Doh... you are correct. Looks like that feature was added in version 2.50

Here's something that works for me... In blender, go the the Scene options region. There should be a set of buttons allowing you to choose what units you want to use. I have always set them to use metric and they appear to be honored through the export to dae and uploading into SL.

Here is the SL wiki article explaining why this kind of "animation" is bad: http://wiki.secondlife.com/wiki/Why_UUID_Flipping_is_Bad

Chosen Few wrote: ...wisdom... Ah, thanks for keeping me honest, Chosen!

I was curious about this as well, so I did some searching. Wikipedia said: Interlacing (also known as interleaving) is a method of encoding a bitmap image such that a person who has partially received it sees a degraded copy of the entire image. PNG uses the Adam7 algorithm, which interlaces in both the vertical and horizontal direction. So... non-interlaced: as the image loads, you see parts of it that are perfectly clear. interlaced: you see the entire image. It starts fuzzy and then gets more clear as the image loads. Typically one would interlace large files and/or when dealing with VERY slow connections. Now.. all that being said, Second Life uses an internal picture format of JPEG-2000. No matter what file type you upload, SL converts it to JPEG-2000. And as we all know from experience, images in SL start out fuzzy and gradually become clear (meaning JPEG-2000 itself uses interlacing as well). Bottom line, don't bother setting interlacing for pngs you plan to upload into SL.

I haven't coded with it yet, but by looking at the wiki page of LSL functions for it, here are my suggestions: For changing color when moving, generally, you have to code your own logic to determine when you want your object to start following/chasing/evading. When you do, you can add the commands to change color For the other two, there is a new event path_update [http://wiki.secondlife.com/wiki/Path_update] which has a number of useful status constants that you can use for this very effect. PU_SLOWDOWN_DISTANCE_REACHED could be use to tell if the object is near the goal (player) but I don't think you can specify the distance criteria. PU_GOAL_REACHED, PU_FAILURE_UNREACHABLE, PU_FAILURE_TARGET_GONE could be used to tell if the object has stopped moving (though if it has the wander behavior, this may not occur.)

I just checked the JIRA about this, and I may have been wrong... according to this record, the issue was fixed...but it doesn't really clarify what was done. https://jira.secondlife.com/browse/SVC-34 Additionally, a comment in the jira proposed a small workaround to counter this: Have the pilot wear an invisible attachment that is larger than the vehicle. that way, anyone trying to right-click it will instead pickup your attachment.

STATUS_BLOCK_GRAB_OBJECT only prevents left-click-dragging on physical objects. Anyone can still right-click-edit an object to halt its physical movement. Sadly, there is no way to counter that. And in the grand scheme of things, it's probably better that way, since it provides a defense against players being griefed by physical objects. Innocent vehicles being affected by this is in unfortunate side effect Edit: Wait, when was that fixed?? Kaluura, can you provide a link to any info on that?

While stumbling through creating a mesh object today, I discovered I had a number of overlapping edges that did not form any faces. It was difficult to select the correct edge for deleting... But after a bit of experimentation, I found a quick way to isolate them. In blender, go to edit mode and enable Face Select mode.Select all faces with "A"Hide all faces with "H"enable Edge Select modeSelect all again... hopefully you will see any orphaned edges highlighted.

I always seem to miss it, but not this year! Today is my Rez-Day! Holy cow, seven years in SL! Here's to seven (any many) more!

It's rare that you will find a script already created to suite your exact needs. If you want to commission someone to make the script for you, check out the Commerce/Wanted forums. If you want to try building the script yourself, this is the place to come for advice. That said, using a Collision_start event would be a good idea to detect when an avatar/object collides with the inner surface of your tube. A global variable can be used to store the number of impacts, incrementing it each time the collision start event is triggered. You can use llSetColor or llSetLinkColor to change the color of the inner "face" when the collision_start event triggers. Using the llCollisionSound function will allow you to set a sound to play when something does impact the tube That should be enough to get you started!

duLuna, your original idea is correct, but is just missing one component. Every time you rez a prim/object, it gets a new UUID (or key). So you need a mechanism to discover the new key of the target prim and relay that to the particle emitter script - which would update the particle system's parameters with the new target key every time you rez the object. I forget, when you are wearing an object and drop it, does that count as rezzing a new copy (while simultaneously deleting the object from your inventory) ?

Quite the opposite for me on the first point. I'm a newbie to ownling land and only have one 1024 sq. meter plot on the mainland. I actually want to expand into a neighboring plot if the owners decide to close up shop. I purchased my land not long before Mesh Beta started gathering steam, so I've always had it in the back of my mind when building on the plot. At the moment I'm working to replace my main structure with a mesh version (hopefully for significatly less land impacts with more detail than the prim version). When I get enough experience, I hope to deck out my plot with as much detail as I can while still leaving enough prims free for my projects.

That looks like the Lindens updating various fields in the Jira. Not all updates are comments. JIRAs contain important information developers use to keep track of bugs, problems, diagnoses and overall status of the bug/fix. In this particular example, Vir Linden updated the "Fix Versions" field to be "Sprint 33" .

It's annoying, but at least LL knows about this issue. I opened SVC-7462 and Maestro Linden is able to reproduce it.

Here is a thought regarding the sails... There is a way to hack a limited animation into mesh objects by using multiple materials. The trick is to have your mesh have a unique material for each sail position. When uploaded, triangles in a mesh that have different materials will be counted as "faces" as we know them on prims. (we can have up to 8 on a single mesh object). When done correctly, you can use a script to cycle the alpha levels of each "face" effectively making the sail using a particular material slot visible or invisible. So, create you mast and boom normally. Then create your sail on the mesh for it blowing on one side - but be sure to assign it a unique material slot. On the same mesh, add the sail modeled as if it were blowing on the other side an give it a new material slot as well. When you upload that mesh to SL, you will see both sails - but you can now select them as if they were faces on a prim and make the desired one invisible.

I don't often poke my nose out of the content creation forums... so .... wow ... that's messed up. Void, I am forever grateful for your dedication to helping us to better understand LSL. Thank you! Like everyone else, I'm sad to see you go. I wish you well, and hope our paths cross again some day.

Thanks for your response Dora! I spent all day playing with your code. While trying to understand how the llAxes2Rot worked, I stumbled across your wiki page further explaining it: llAxes2Rot right and wrong and the example function calls you had Vec2RotHor() really helped me understand! From that I was able to cobble this new routuine together: vector targetOffset = llVecNorm( llDetectedPos(0) - llGetPos() ); //normalized direction to target from turret primvector UP = llVecNorm(llRot2Up(llGetRootRotation())); //normalized direction of "Up" for the entire shipvector LEFT = llVecNorm(UP % targetOffset); //calculate left direction by taking cross product of up and fwd directionstargetOffset = llVecNorm(LEFT % UP); //recalculate fwd to confine it to the horizontal plane (relative to the ship)rotation targetRot = llAxes2Rot(targetOffset, LEFT, UP) / llGetRootRotation(); //calculate final rotation using fwd,left,up...llSetLinkPrimitiveParamsFast( LINK_THIS, [PRIM_ROT_LOCAL, targetRot] ); And it works! No mater the orientation of the ship, the turret child prim will accurately swivel to track a target while staying confined to its local z axis. Thank you! I just have one more question.... why must we divide the rotation by the root prim's rotation? I don't quite understand why that makes it work...

I'm building a model ship to have rotating turrets. The idea is that when directed to "fire" on a target, the (child prim) turret would swivel around its z-axis only to face the target. Since the model will be physical and thus moving around, I need to ensure only the local z axis of the child prim changes... I've almost got it, but one last thing is tripping me up. I could use an extra set of eyes for any suggestions... sensor(integer num_detected) { //cause the child prim's forward (+X) axis to face target vector targetOffset = llDetectedPos(0) - llGetPos(); //target_pos - child_global_pos targetOffset.z = 0.0; //don't care about z coordinates here rotation targetRot = (llRotBetween( <1.0,0.0,0.0>, llVecNorm(targetOffset) ) )*llGetRootRotation(); llSetLinkPrimitiveParamsFast( LINK_THIS, [PRIM_ROT_LOCAL, targetRot] ); } I think the problem is that last part of the calculation of targetRot.... if I don't multiply by the root rotation of the object, the child prim won't track the target accurately... it seems as the root's z rotation gets close to 180, the resulting rotation of the child turret becomes inverted.... but it still stays "upright" relative to the base. Now if I DO multiply by the root rotation, the turret correctly tracks the target... but it no longer stays "locked" to only swiveling about its local z axis. The child prim will now always stay "upright" relative to the global frame. (I hope I'm getting the terms right)

Thank you all for helping me! I'm just so used to the concept of working with prims where I can always zero out the rotation of an object perfectly in relation to the world. When I accidentally applied a rotation to my mesh, I lost that "zero reference point" for the "world" ... if that makes any sense. But using these methods helped a great deal!

My apologies for the confusion... I should have mentioned that when in object mode, the object reports having a zero rotation - yet the thing is still not aligned. I think I did the equivalent of Apply Rotation when I shouldn't have... So now I want to re-align it and then apply that rotation again.... what I'm trying to figure out is if it's possible to rotate the mesh such that two arbitrarily selected points would be on the same plane (for example, having the same x, y, or z global coordinate).

Newbie question... Somehow I've managed to mess up my object's rotation. Is there a way to re-align the object based on an arbitrary triangle? In other words, if I have a triangle within the mesh that I know "should" point up along a specific axis, can I rotate the whole object to match that?

Back in 2007 I made this vehicle which was just over the 31 physical limit. I tried as much as possible to reduce the prim count but I just couldn't get it to below the cutoff point. I really wasn't content to use the workaround where you wear the high-prim "vehicle" and ride a low prim invisible counterpart, but at the time I saw no other way. Sculpts were a possibility, but I wasn't very good at them either. Ultimately I just kept working on the prim build to get it to look nice. Final prim count was around the mid 40's Flash forward to yesterday when I pulled the vehicle out again to make some updates (still 100% legacy prims). I noticed that the physics cost for the 40+ prim object was around 18. Out of curiosity I switched the object to use the new resource accounting method. The Land impact added a few extra prims (now in the mid 50's) but the physics cost was still 18. I could now turn this object physical! I thought it would be nice to hear how the new accounting system actually helped an old prim build.

I agree on some points - LL providing extensions to the build tools like modifiers that could help edit existing prims in different ways (or automate difficult manual tasks) would be welcome. But some things just aren't realistic. For example, an inworld mesh editor is just not feasible with the current implementation... Of both mesh and SL itself. SL was designed to work with prims, so adding mesh capability even as static objects has been a monumental effort. A lot of the limitations on mesh as they are now are resultant from that. As an example, originally mesh objects could have their UUIDs changed to those of different meshes - like sculpts. But that turned out to cause too much chaos on the servers, so the mesh asset was hidden internally. Maelstrom Janus wrote: What about being able to taper and slice prims along ALL axes.... What about a menu which relays the sizes of a triangular prims sides ?? Is the ability to slice a prim between two points or curve a square edge prim beyond the bounds of acievability... Actually, yes the ability to do those specific things are pretty much beyond the bounds of achievability. Or at the very least, beyond the bounds of practicality. I asked a similar question focusing on slices being applied to arbitrary axes... I got some really informative answerers. Check 'em out, it's an interesting read. http://forums-archive.secondlife.com/8/c6/357545/1.html