A few months back there seemed to be interest on this mailing list in a formal
way to have custom animation sets for avatars without LSL scripts (Animation
Overriders)
The last I heard there were inquiries on how TPV's were pulling it off (fully
client-controlled isn't the most ideal implementa
Er... Just color the dots based on talk/shout/toofar? ;)
-Adeon
On May 9, 2012, at 9:11 AM, Ricky wrote:
> Correct, but most often a thick horizontal plane centered on your avatar's
> altitude is considered the most critical area. This volume is supposed to be
> indicated by the dots being r
Are the non-AO default animations actually transmitted by the viewer? Or does
each client already know which animation state the avie is in, and animate them
with the correct default animation appropriately?
If the entire AO set was something broadcasted to everyone in advance, it would
cut do
Alright, here's some features that, if missing, *someone* would complain:
-Any given AO needs to be able to have multiple stand, sit, and groundsit
animations. Stands needs a choice of either playing them sequentially,
randomly, or on a set timer. For sits, people want choices of which sit of ma
Alright, here's some features that, if missing, *someone* would complain:
-Any given AO needs to be able to have multiple stand, sit, and groundsit
animations. Stands needs a choice of either playing them sequentially,
randomly, or on a set timer. For sits, people want choices of which sit of ma
Adding entirely new "slots" to AO's (running against a wall, standing on a
ledge, running at various inclines, swimming in system water) is one of the
things you can only do do programmatically. But a base "animation replacer"
client AO to get rid of the official animations is still handy. A scr
Wouldn't a new inventory item type make most sense? That way it could be put in
with any outfit folder or packaged with sold avatars.
On Apr 12, 2012, at 10:42 PM, Tateru Nino wrote:
>
>
> On 13/04/2012 11:30 AM, Argent Stonecutter wrote:
>> The overhead of a conservative scripted AO is prett
Firestorm has a decent writeup on their Wiki on how to use theirs:
http://wiki.phoenixviewer.com/animation_overrider
I don't know the inner workings of how it does what it does, but I do know it
is still merely overriding the default animations, rather than simply replacing
them entirely (as I
I've heard DATA_ONLINE will now only work for "the owner or the creator" of the
script. Shouldn't that be instead "owner or compiler" of the script? Any full
permission script already written could be used and recoded as a status finder,
and I have a feeling this will be what people move to for
I'm pretty sure RLV doesn't modify the shared experience. Any feature of it
that others can see will observe it in the same way as the official viewer.
Perhaps I am interpreting this incorrectly?
This rule will avoid thing like the original double attachments that main
viewer saw incorrectly,
ot;
bones)
-Keyframed rotation and repositioning of attachments (which meshes can weight
to; to use as new child bones :) )
-ClientSide scaling of attachments and default mesh
Just to name a few.
-Adeon Writer
On Jan 16, 2012, at 8:50 PM, Laurent Rathle wrote:
>
> Hello,
>
> Is
For what it's worth, I can also say it works fine for me on all current V3
branches on Vista.
Adeon
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep
llRezObject will rez an object with the center of the to-be-rezzed object's
bounding box at the position specified.
llRezAtRoot will rez the object with it's root prim's center at the position
specified.
You won't see a difference unless the object to be rezzed has a center of
bounding box th
Well, there it is. Maybe it should be called Prop. But whatever works. Name is
an afterthought to function. :)
> Perhaps; although the thing with the mRoot joint is that it never moves in
> relation to the avatar, so it won't actually be positioned on the center of
> their body. (People will u
Perhaps; although the thing with the mRoot joint is that it never moves in
relation to the avatar, so it won't actually be positioned on the center of
their body. (People will use it for worn vehicles, props, dance poles)
But if that's not to confusing, I say go with it.
> For non-technical peo
The official name for the joint is "mRoot" so I suppose "Root" is the most
logical thing to name it.And yes, it should auto-fill in the menus, if "id" and
"pie_slice" have the correct values. I'm not sure how they work. The ones I
provided certainly aren't correct.Additionally, the position and
You get this string when right clicking an object in your inventory, and
choosing "Attach To" the new attachments added to the XML show up at the bottom
of the list (They're actually sorted by ID number, I believe) as
"MissingString(Name)"
There are a few places the new attachments will need to
That's a very common belief, and possibly why the neck attachment has been
missing for so long. But it's not the case: The neck is it's own bone as is the
"root" bone; as anyone who has created an SL animation can tell you. :)Here's a
youtube video to explain my case: It shows the new Neck and
Yes, although the catch here is that there simply isn't a Neck slot or a Root
slot, so the fact that we can attach multiple objects to any given slot is
irrelevant; those two slots have yet to be created. Neck and Root here are
unique locations that aren't simply a duplicate slot of something w
In the interest of seeing how feasible adding "mNeck" and "mRoot" attachment
points to the official LL viewer would be, it turns out that it's as simple as
adding the joint names to the avatar_lad.xml file.
It's been known for a while that modifying the file can give you more
attachment points
20 matches
Mail list logo
