Jump to content
Sign in to follow this  
Innula Zenovka

llSetKeyframedAnimation() getting closer

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...