llSetKeyframedAnimation() getting closer

[Innula Zenovka]

A very helpful introduction to llSetKeyframedAnimation, a feature I'm really looking forward to playing with, over in Inara Pey's blog.   Apparently it's likely to be available on parts of Aditi soon.  

[Void Singer]

as proposed on the wiki page it's kinda sloppy.  it need to affect multiple prims at once with different setting for starters in my opinion. the smooth motion portion is nice, and might be a vast improvement for for doors and such, but without link targeting that's all I can really see on first pass unless I'm missing something.

[Rolig Loon]

Very nice indeed.  This is going to make scripting path followers a lot easier all of a sudden.  I haven't paid close attention to the mesh discussions yet, so I may be naive to ask ... Does the PE < 64 restriction mean that this function will really only be useful for carefully-created  mesh objects or very simple prim linksets?

[Innula Zenovka]

I'd far prefer it to work on link targets, too, but I think as it stands it's at least a way of acheiving smooth and not too laggy non-physics movement.   Let's hope it's just the first stage of something bigger.

[Qwalyphi Korpov]

The resident who provided the previous content, if any, has replaced it with this generic statement.

[Void Singer]

as it is it'll be a useful replacement for moveToTarget and rotTarget, providing slightly more accuracy (we hope) and non-physics motion.... but it seems kinda misnamed if that's the point... those are still goo things to have, although if there is a heavy reliance on "energy" then it loses some of it's benefit...

I read it and was expecting something along the line of puppeteer...  hence my comment above.

ETA:
Although looking at what it does, I'm not sure what would be a more appropriate name KeyFramedMotion ? I dunno, animation just bugs me because it implies multiple parts and this really doesn't do that

[Kaluura Boa]

The concept is interesting but the name of the function is misleading. llSetKeyframedMotion() as proposed by Void would be better... or llSetKeyframedTarget() since it's more or less a super llMoveToTarget() for non-physical objects.

I would however add the possibilty to prevent this function from affecting the rotation of the object. Simple interpolated rotations from point to point are a bit restrictive.

I also hope that some new event will be provided so that the script knows when the end of a non-looped list is reached and we don't have to rely on a timer (or worse) to obtain that information.

What I don't understand from the blog post is why the PE system *must* be used. If the object contains no meshes, what's the use of the PE?

[Void Singer]

or even more specifically, isn't the PE of a non-mesh item just the prim count? the wording is a bit odd there =/

 

I agree a callback would be very useful as well. also be nice if it interpreted blanks as zero offset/rotation, making the list more collapsible.

 

think I'll go add those thoughts to the discussion page...

[Qwalyphi Korpov]

The resident who provided the previous content, if any, has replaced it with this generic statement.

[Void Singer]

NMOWSUPEF == ???

[Rolig Loon]

non-mesh object with script using PE functions  = (NMOWSUPEF)   

That one got me too.  :smileytongue:

[Void Singer]

assuming that's the case, then to penetrate the tinfoil it's probably more useful to look as it as:

non-physical items using physical functions.... which still hits the limit of physics items.

[Qwalyphi Korpov]

The resident who provided the previous content, if any, has replaced it with this generic statement.

[Void Singer]

I knew I shoulda parenthesized that last statement....

[arton Rotaru]

The PE (land impact) is always the greatest number of 3 metrics. Download Weight, which is the visible geometry complexity of an object. Physics Weight, which is the collision shapes complexity. And Server Weight, which is the cost for an object when it's scripted or physical.

64 is the max number for the Physics Weight for the use with  llSetKeyframedAnim..... Thus, the Download Weight, or Server Weight can be way higher than that.

Probably the reason why llSetKeyframedAnim.... requires the Mesh accounting system, is to get more and more content under the new accounting system. If LL could, they would love to add that new system to any content inworld. But as we know, they can't, because they would break tons of old content. So they try to force the new accounting to legacy content where ever they can. E.g. linking prims to a mesh, or changing the default physics shape type of a prim. Now they introduce new script functions requiring the new system as well, to force more content to the new system.

[Nalates Urriah]

We have new information... the function is enabled on two regions in ADITI.

Visit: “Sandbox – Bispinor” and “Sandbox – Weapons testing“

http://blog.nalates.net/2011/09/23/second-life-server-update-week-38/

[Falcon Linden]

Void is correct: there is no limit on PE when using this function, the limit is only on physics weight. Why did I tie this to using the PE system at all? No, it was not due to any new LL policy seeking to push all new content into the PE system (there is no such policy to my knowledge). It was simply to limit strain on the physics engine induced by allowing more complex objects to move around the world. Why 64? Honestly, I just picked a number that seemed reasonable. It's more generous than the limit of 32 imposed on making an object physical and the only real way to build a physics shape with a PW >64 is either by using concave prims (eg a torus) which are VERY hard on the physics engine or by just being lazy/sloppy and not using Shape Type None on detail prims. If anyone can show me a quality, efficient build that is limited by this requirement, I will seriously consider altering it.

 

Falcon

[Void Singer]

yay I getz da gold star =)

seriously though, thanks for clearing that up.

My guess was based on the idea that it's essentially a physics function, minus collisions with non-physics items. happy I guessed right for once =D