avatar rotation

Hey all...

I need a little advice. I need to rotate an av in a script. Since llPointAt() is deprecated, I tried a few things:

1. Animate the turn and play the animation repeatedly, so that the couple of degrees of rotation add up. This appears to work, until you actually try to change the avatar's position. Only the animation turns; the avatar itself does not. You'll walk sideways.

2. Use llMoveToTarget() and move a small amount, like moving in a small circle. Doesn't work. The avatar will again walk sideways, as llMoveToTarget changes only position and the avatar will not rotate to face the direction of travel like with a forward key press.

3. Attachment rotations are ignored. I tried as well, just to be sure the wiki wasn't wrong.

None of these possibilities panned out. Short of piling pose animations on top of one another, possibly causing a stack overflow (haven't tried this.. don't wanna), has anyone at all thought of any worthwhile solutions?

I shudder to think of how many excellent projects have been canned because of this!

*Sigh*

I have spent my day exploring the same options you have. I have specifically been looking at this option from the point of view of a script inside a HUD. It just seems to be broken.

llLookAt llRotLookAt do nothing.
llSetRot rotates the hud itself.
llMoveToTarget() doesnt affect rotation

I get the feeling it's deliberately disabled. If there are any Lindens reading this, I'm sure we'd appreciate a reason why none of this works. Specifically, I wonder whether the reason is technical or if it broke long ago and was never fixed, or if it was deprecated in favor of a different solution that just never got implemented. (Oh, if any Lindens *are* reading this, contact me and I'll implement it myself if they like.)

I'm going to try piling the animations on and see if I can approximate it. I'll post my results.

Unless I'm misunderstanding what you are trying to do, I think your problem is that all the functions you are describing will work on a prim not an avatar.
And yes although technically an avatar is a load of prims it doesnt quite obey the same rules.

If you sit an avatar on a scripted prim that rotates slowly then the avatar will also rotate, or did last time I played with that kind of functionality.

I think the real issue here is that the Look at functions .. which you would expect to do the trick.. just don't work when invoked from scripts inside attached HUDs.

It is frustrating that the LL scripting environment is not more "canonical". Frankly with $1M a day spent by the community you think LL could start a scripting language 2.0 initative aimed at cleaning up the library. As well perhaps raising the 16k memory limit which has just resulted in prims stuffed with 4 or more scripts all exchanging messages. Oh and gosh there's lag?

If Java can rev as a language why is the LL community stuck with such a hacked up mess that is the current scripting library?

The LL folks should open up the scripting language spec into a community process as a first step!

Perhaps the first step would be for the community to write the spec and deliver it to LL.

~End of Rant~

Burgundy: They intend to go to Mono. I'm taking a look at it a little bit at a time. If you check out libsecondlife.com (yep, them guys) they've got a ton of info up on their site about the server side guts of the scripting. I've been reading...

Newgate: when these functions are called from an attachment, they operate on the avatar, not the prim. To rotate the prim and not the avatar, there are functions specifically for that (and they work.) An avatar is a mesh... and exactly 1 prim: that's why you have to include riders as prims in your vehicle builds

Sitting on something won't do. It's gotta be from an attachment, as the attachment will be controlling a LOT of stuff.

I'm still working on it.

To my knowledge there is no way to rotate a non-sitting avatar. It is unfortunate, and there have been several worthwhile projects that I am aware of canned because of this single missing piece. I mean, really, it is a small but absolutely critical piece in the sense that when you want a rotation absolutely nothing else will do

Bingo. When you need it, you need it. I still have a trick or two to try.

I need this to the point of *I could quit my job* if it worked!

GC Hehe

Ok I guess i know what you are doing tonite

I am not sure 'bout you quiting your job, but if you can post a way to do this .. at very least you earn ULTIMATE bragging rights.

I take it nobody managed to hack this into submission then?

the definitive answer is "it can't be done"

you can rotate a "vehicle" or "prim" that the avatar is seated upon (like on a multi-pose bed.. the poseballs can be rotated, rotating the avatar(s)

you can create an animation that has the avatar turn around. This will not result in the rotation of the agent, but will APPEAR to rotate the avatar ("turn 180" is a good example of this)

The problem really comes in, that the Agent is not the Avatar. It is in fact the "Agent" that is the "one prim added to the linkset" when you sit on an object. The avatar is a ghosted mesh that is phantom, and it merely follows the Agent (and is rentdered in animations, relative to the centerpoint of the agent. Attachments however are attached to the Avatar. (and thank goodness! imagine a 1 prim avatar with 5 255 prim attachments on it.. sitting on a physical object!) You can't control the agent by controlling the avatar. The control can't go upstream.

BTW: The above issue is why most "hug" multi-greeters are glitchy. Because they don't use poseballs.. it's very hard to properly align and animate two avatars, trying to get their agents to align in such a manner to allow the animations run on both avatars to make the two appear to embrace. The "sideways hug" that we see so often is the clearest example that what you're hoping to do.. simply isn't possible (yet).

There are some apparent exceptions to this.. where jetpacks come in.. but they are "taking over controls". it's possible that you could find a way to rotate a free-standing agent/avatar in this manner.. using some kind of torque/push technique to try and forceably apply rotational velocity to the agent. But.. I mean.. REALLY.... At that point you're just WAAAAAY overdoing this project.

From what I can gather.. what you're after is the ability to make your avatar "walk this way" or "dance over here" or "walk in a square". The easiest solution for this is to create an animation in poser or whatever.. where the avatar walks in a square relative to the world axis, then upload that animation. This will result in the avatar appearing to "walk away from it's nametag (the nametag is a particle type effect that is rendered at the screen position of the agent.. not the avatar.. imagine it as "floating text" above the agent prim). The avatar will puppet along in it's animation, and if the animation is properly looped, it will return to it's original position at the agent's location.

My guess is, you're trying to cheat.. by using already existing animations.. to create an animated effect. The sad fact is that nothing can "steer" the freestanding agent. except the user. Rough approximations can be done (using pushes or bumps)... but most of these attempts frankly, are like greifing attacks. (and are usually about as reliable).

My instinct is to ask you to clarify what you're trying to accomplish here. Not in vague, esoteric terminology.. but in simple language and complete concepts. Sure, there's a small amount of risk there.. in terms of "leaking your idea".. but if you want help.. it's possible there's a better, or simpler solution that you simply aren't considering because you're so buried in the work you've already tried. If we knew more about your goals in this project.. we might be able to suggest a radically different approach that would work better for your project?

Sorry, bad form to reply like this, but I'm not awake enough to trust myself with full paragraphs.
Nothing* is impossible. It might require a hacked client to implement without LL, but it's possible. I'm gonna hang onto the slight hope that there's some deep hack in LSL that can do it.

Yup, really hoping I don't have to rely solely on that.

Haven't tried yet, but using in conjunction with llMoveToTarget() might cause some problems since there's some kind of arbitrary pseudo-temporary movement-based rotation going on at the same time.

Nah, the problem is that we're missing basic functions. I'm moving an agent around perfectly happily with a scripted attachment, thanks.

This is where I'm at now, haven't had any luck yet. Know of any example scripts doing this?

Nope, turning the agent is pretty important to lots of things.

Except a) I want to rotate visitor's avatars, I can't pop up a message every time I need the agent facing a new direction asking "could you take a second to rotate yourself to this angle" and b) I'm using the keys in the script, so they'd be unavailable anyway.

But it should be, and possibly once was. There's documented functions for it, they just don't work.

*Not literally nothing, more a turn of phrase.

Edit: I'm at the end of my business day. and the grid is down.. so I'm probably coming off as all kinds of irritable. I'm not trying for that at all. Take the following with a sense of joviality.



MANY* things are IMPOSSIBLE* in LSL. In fact, much of programming in LSL seems to be "working around" things that aren't possible. We all know that it's impossible to create or write to a notecard via script. A wonderful example if "technically impossible" I encountered yesterday, is the inability to replace a single item in a list. I know.. I had to do this. The Workaround involved creating a dynamic one item list, and casting the string to that list, then using ListReplaceList. (obviously a ListReplaceItem would be prefferable.. but such an action is not possible, because such a function does not exist in the current state of LSL.)



Hope in one hand.... <deleted for appropriateness>.. see which one fills up faster.



I won't deny that there are functions not present that we would all like to see. However, one can not say that something is missing simply because it does not exist. Unicorns are not "Missing". I realise it's a point of semantics, but in this case it's an important one. the function "take all of Ansche Chung's Money without asking permission" is not "Missing" from LSL either.. though I am certain there are thousands of people who wish it were present. (the ability to TakeMoney from non-owner is intentionally not provided).

As to successfully moving an agent with a scripted attachment.. I can only assume you're doing this in the same way that the multihuggers "move" the agents together. There is some technology present to move the agent.. I need to apologize for that misstatement. I completely spaced that. it's the same mechanism that lets collar "leashes" keep the collared person from walking further than X from the leash holder. But it's VERY rudimentary.. and as stated before.. it only affects position, not rotation.



Not SIMPLY by script. You can rez "bullets" that will slam into the avatar in a physical manner, and try to turn the avatar. Bullets with offset shapes.. that slap the avatar and then got into a spin, and take the avatar with it. (think "L" shaped bullets). Like I said.. we're into "way overthinking" territory here.. since your controlled avatar will be assaulted my a maelstrom of impact sparks.. and their sheilds (if any) will be going into overtime to mitigate "the attack". We're talking extremely inelegant (and that's a huge understatement!)



I really can't think of more than a couple. If your goal is to "provide a tour" of your sim.. then a scripted "tour vehicle" is the way to go. Frankly, I wonder why this is so important to exert control over someone else's avatar.



a... WHY? Isn't there some way you could rez a vehicle in front of them that says "hop on and I'll take you there"??? (I've seen this done.. in some really cool ways). Plus, there's a whole particle system you could use, to draw a dotted line between the visitor and where they should go. You could also animate little footprints on the ground, or say "follow the red line" and paint different coloured lines on the ground like they do in hospitals. Why must you "FORCE" or "SHOVE" an avatar that doesn't belong to you, someplace? Why not just put up a sign that says "free puppies this way". Give your visitors the option to go where they like.. or give them a vehicle/teleporter that assures their arrival at the proper destination.



Show me the documented functions... I'm certainly not aware of anything like this existing in the last 9 months. I admit.. I'm no expert.. if it's there.. and depricated, I'd like to see it. But everything I've seen indicates that this has never been possible. and while it may be occassionally desireable, I haven't seen anything indicating that such a function is planned.

*Many.. more than a few. Generally more than some, less than most or all.
*Impossible... meaning not possible; given the current, recent, or projected state of the tools at our disposal in LSL.

llPointAt

http://www.lslwiki.net/lslwiki/wakka.php?wakka=llPointAt

Documented, and broken. A long long time ago, but it was there as well as llStopPointAt.

Not to seem argumentative, but you might want to re-examine the bulk of your above posts; your main thrust really depends entirely on the presumption that AJ is idly wishing for something that never was and never can be, with lots of well-thought-out arguments to support its utter impossibility - but in fact it's right there and it reportedly worked at one time, and was removed and not replaced for reasons unknown to us.

So while this whole thing may currently be an exercise in futility, it's not at all unreasonable to think that situation may yet change at some point, or there may be some workaround hidden away in the dark recesses of libsl, or something. I'm not going to look for it, but it's fine with me if others do, and if someone finds it that enterprising soul deserves to get rich off working huggers alone

Ah, but you still achieved the desired effect, no matter how inelegantly...

Before I carry on, I just want to state that I approach SL as a platform in the fullest sense. I don't see this world that people build things in (well, I do, but not when talking about tech stuff) but as a server-client framework for presenting realtime 3D. I see very little of the default SL interface as a necessity for presenting content to the end user, including the standard navigation controls. Just so we don't get confused.

Besides the fact they've been documented (see later) rotating the avatar is an essential part of the platform. The functions are present to take complete control of the avatar in every way apart from this, if that's not indicative of a missing feature I don't know what is.

It doesn't seem much more rudimentary than the built in movement control to be honest. I reckon you could get just as good fidelity, if not better, though scripted control.

Ugh. I might give this a try (along with using a cage) but I can't see it being a happy solution. Oh well.

It's really about presenting the end-user with the experience you intend, rather than simply dropping them in an environment and letting them wander about with little or no direction. I could list a myriad of things it'd be needed for, but I think my test project illustrates it well: allowing the user to move the avatar relative to the camera (i.e. press up - avatar walks into the screen, press left - avatar walks toward the left of the screen).

I think I've addressed all this, let me know if I missed anything and I'll happily go over it.

Just noticed, it's mentioned in the OP: llPointAt.

EDIT:Always try to. Hope you'll take mine in the same way, I have trouble telling how people will react to what I 'say' sometimes (and not being able to add inflections just makes things worse) and it's been known for people to flame me because they didn't realise I wasn't taking things seriously.

I've created a JIRA issue on this since it's bugging me. Any votes or implementation suggestions are appreciated.

https://jira.secondlife.com/browse/SVC-56

Hey all..

I'm not quite sure if this will be of any real usage towards this specific discussion as I haven't tried implementing it in this fashion.. However.. there is a way to rotate an avi if the avi is considered "linked" to a prim (i.e. sitting on it).

I figured out a way to to do it with my Photo Studio, where a child prim in a link set can have a sit target, have an avatar sit on it, and rotate the avatar, without rotating the child prim (since it won't work anyways). Take a look at a fairly new function llSetLinkPrimitiveParams().

Basically what I did was take the child prim that had the sit target, made it the last prim in the link set, and incremented by 1 from llGetLinkNumber() to get the Link Number of the avatar and told it to rotate. Works nicely

Might be something worth attempting if possible in this scenario.

The trouble with that method is that you then have to implement your own movement control as well; which is incredibly hard, if not impossible, to get as good as the standard movement control.