Found a work around for missing attach() …

Found a work around for missing attach() event handler. It is primitive, but using an on_rez() handler instead with a llGetAttached() = ATTACH_RHAND or some such test will at least replace most used of attach(key _towhom) where some action is required at the time of attachment.

The Mantis OpenSim bug contains some sample code.

MoPose 5.0 is now driving Yman Juran’s …

MoPose 5.0 is now driving Yman Juran’s latest trapeze. She and her sisters use a HUD I created that captures the animations available in a given item, in this case the trapeze, and makes them available by just clicking. She has 45 animations loaded currently, the most we could fit vertically on the screen. I used a new AnimAdjustmentFinder script to quickly resolve all the offsets of different animation start positions. I will be adding a HUD to go with it making it even faster to create the animations notecard that goes with the MultiPose script inside the trapeze.

The good news is that all of this should work with OpenSim, which I need to test later. Yman has a big inauguration celebration that she and the sisters are doing although I don’t have a link at the moment.

Why use an AO with a listener? I keep ru …

Why use an AO with a listener? I keep running into them, like the popular Framation ones. Anything that has /ao on and those kinds of commands that listen on channel 0 are just absurd, useless wastes of system resources. Even a small just with buttons that react to touch events is so much better on any sim. It seems SL is doomed to these kinds of things. It just makes me want to discourage even /1 show for poseballs all the more. Perhaps I won’t even enable that as an option in MoPose 5.0. If I do leave it in, it will be with a strong warning about the lag for a largely idle command that goes unused. I already have the simpler scripts for those who don’t want the extra lag.

Beware of llGetObjectDetails() is my les …

Beware of llGetObjectDetails() is my lesson for this week. I ripped it all out of MoPose 5.0 after getting all excited about using that over corrections to buggy sit target values. Turns out you cannot get a reliable capture of the avatars position when it sits–especially if the object being sat upon is moving, as this script also concedes even though it uses other detection methods.

I did leave this function in AnimAdjustmentFinder, which I am still fleshing out and will add a HUD to rather than typed commands soon. This has made getting extremely accurate animations adjustments very easy for items with multiple animations, the bane of multipose animation in general because no two animations start in the same place.

Besides, I don’t think OpenSim yet supports llGetObjectDetails() so this renders MoPose 5.0 much more OpenSim compatible.

How about a save-json? A thread on the O …

How about a save-json? A thread on the OpenSim mailing list again requesting better flattening of complex objects than the current save-xml, save-xml2 and save-oar got me thinking about how JSON might be applied. I happened on osRezFromURL(string url, vector pos, vector vel, rotation rot, integer param) proposed by Jimbo2120 that made me thing of maybe something like osRezFromJSON(string json, vector pos, vector vel, rotation rot, integer param) and/or osRezFromJSONURL(string url, vector pos, vector vel, rotation rot, integer param), which just might be reachable if we pilfered some of the parsing ideas in osParseJSON(string json). The function would likely be mono only, but an OSS/LSL version could be layered on it. It might even inspire similar official LSL functionality in Second Life, nah.

Looks like script performance tools are …

Looks like script performance tools are planned for the viewer. I can only hope they include the ability for any scripters–not just region owners–to assess the impact of the scripts they create on any given sim or the specific sim they are in. I have heard this sentiment echoed many times in different forums by others.

Completed MoPose 5.0 design and project …

Completed MoPose 5.0 design and project plan. Has already helped organized order of feature development and code branching at appropriate points. Here is a class diagram of the scripts, which might still undergo some consolidation and a feature breakdown, which has kept me sane and helped consolidate all the feature requests and ideas over the last year. But keeping each script as focused as possible is part of the plan. Perhaps the best thing so far to come out of going through this road map design step was realizing there are really three core scripts: Pose, MultiPose, and SequPose. I really think this is going to keep the most folks happy and enable the most use on OpenSim as well as Second Life. When complete, this suite of scripts should be available to all for free (BSD) and hopefully displace the pose/animation development kits running for as much as 14k Linden in Second Life. Pose and animation is such a basic, essential requirement for any immersive virtual world experience, this stuff should really be available to all.

More later on that, but after almost all my free time during Christmas vacation working on this, I think I get a few programming blocks, but my other skills have sure suffered for lack of practice this last month.

Add the initial hard stuff in MoPose 5.0 …

Add the initial hard stuff in MoPose 5.0 done, all the positioning and adjustments that are safe with multiple sit targets in a complex object. The rest, even the synchronized animations and emotes timing will be easier. I think I have a quaternion still stuck in my teeth. But oh so filling. Those things are chewy.

Been loving http://imohax.googlecode.com to manage this and all the code going forward. Tagged this milestone as 5.0.0a1.

So jazzed about loooosing sit target …

So jazzed about loooosing sit target from any sit location calculation even for objects such as furniture with multiple sit targets. The best part about using the new (since 1.18) llGetObjectDetails() function to get the exact position of the avatar after it is at the sit target is that you don’t need all those complicated calculations plagued with sit target errors and floating point conversion errors. Now all you need is the offset and rotation difference between the home (sitting) position and any other animations preferred position and you can add that to that current position for an exact adjustment. The part I was struggling with was that (rot / llGetRootRotation()) wasn’t enough to convert the global rotation from llGetObjectDetails(avatar,[OBJECT_ROT]) into a local suitable for passing to llSetLinkPrimitiveParams(avatar_link,[PRIMITIVE_ROT,local_rot]). After you have taken the difference in rotation between the local and root, you also have to adjust that difference again for the objects root rotation. Here’s the final working conversion I eventually figured out:

integer av_link = llGetNumberOfPrims();
list details = llGetObjectDetails(avatar,[OBJECT_POS,OBJECT_ROT]);
pos = llList2Vector(details,0);
rot = llList2Rot(details,1);

vector local_pos = (pos - llGetRootPosition())/llGetRootRotation();
rotation local_rot = (rot / llGetRootRotation()) / llGetRootRotation();
rotation adj_rot = local_rot * adj_av_rot;

llSetLinkPrimitiveParams(av_link,[PRIM_POSITION,adj_pos,PRIM_ROTATION,adj_rot]);

This MoPose is really going to be a good one. Very excited to release. Keeping specific uses isolated to different flavors of script rather than different configurations. MoPose is becoming more of an animator/builders toolkit than just a few poseballs. Goal still is to get it fully compatible and use to benchmark OpenSim script functionality.

Still fighting rotations, bad SL sit tar …

Still fighting rotations, bad SL sit targets (from SL bugs), quaternion conversion problems with precision, and overall lack of clear docs about rotational operands. Managed to really get the Advanced Scripters group scratching their head at the “helper” functions on http://wiki.secondlife.com/wiki/Category:LSL_Link/Get which, by the way, are no where to be found, nor any page like this one on wiki.secondlife.com on lslwiki.net. That meant no updated docs in lsleditor.org, which I use as main source of LSL documentation. It is sad that lslwiki.net is falling that far behind, it has been the main source for documentation for so long and now seems like fewer are actually taking time to support it. I have to wonder what the LSL community is doing instead of supporting that wiki. I hope there isn’t another one out there I have not yet found.

All of this makes me wonder if OpenSim is even attempting to keep up with the new LSL script additions from 1.18 on. At least I will have a lot to test over there when this MoPose 5.0 is finished. Just the LocationHelper and AvLocationHelper I finished today to make sense of what I was seeing are going to be good test scripts for OpenSim.

Anyway, several scripting blocks, nothing but scripting last week or so.