SVC-1479: damping control of llMoveToTarget

Promoting this issue, which I'd really like to see LL implement. Please give it a look and, if you agree, give it a vote, too!

The original description seems mostly based around projectiles but I think this would make doing any kind of scripted object movement (especially things that follow a path) a lot less complex.


edit: vote here: http://jira.secondlife.com/browse/SVC-1479

This may be infeasible. llMoveToTarget() works by applying a force in the physics engine that is based on the object's current position and velocity relative to the target point. That has to interact with other forces and collisions and such. It's not like a simple position-as-a-function-of-time equation.

Voted, because I want this for the opposite reason you do, I want it to damp more.

I dunno enough about how Havok4 works to say for sure but I'd be a bit surprised if LL couldn't control the acceleration/deceleration behavior.

Fine by me! If you can, adding your use-case to the JIRA would be helpful.

There already is a damping control to llMoveToTarget(), it's the range of llTarget()....

why would you want to add what's already there?? Sorry, no vote here. Besides, wouldnt this break all the scripts out there that use llMoveToTarget()?? Considering all the work I've done with llMoveToTarget(), I don't think you'll be able to get me (or LL for that matter) to change our minds about it.

Perhaps you just need a better understanding of the function (and related functions) to achieve what it is you're trying to do. (Besides the impossible).


http://www.secondscripter.com/

The suggestion isn't to change llMoveToTarget, it's to create a new llFunction, llMove2Target2 or something, that has more control over how the object accelerates and decelerates.

edit: and I'm not sure where the 'impossible' comment comes from. I asked a Linden who works on physics to comment on this bug last week and he seemed to think it was a good idea.

There is a third component to the movement, which seems to be hard coded in, and that is how much the person/object slows down as it nears the target. It's not impossible, and would be useful to have access to this part of the equation.

(Counter argument also posted to JIRA):

Assuming that without the influence of other forces the motion of an object with llMoveToTarget() applied corresponds to a critically damped system, the force applied by the function should be:

F = -(m/T^2) X -(2m/T) V
m = mass of object
T = damping period (second parameter to llMoveToTarget())
X = offset of current position from target position (first parameter to llMoveToTarget())
V = object's velocity (dX/dt)

This results in motion from a starting position and velocity (X=X0, V=V0) that equals:

X = X0 e^(-t/T) + (V0 + X0/T) t e^(-t/T)

which you can check using newton's law F=mA and calculus (V=dX/dt, A=dV/dt) if you like. The thing about this is that you could simply tell the physics engine the force to apply to the object at any point in time given its current position and velocity and the parameters passed to llMoveToTarget(). It would not be possible to similarly create linear motion by applying some kind of (finite) force (assuming that objects obey the laws of newtonian motion).

Are you arguing against the suggestion itself, that people should be able to (easily) create objects that move through a series of waypoints at a constant speed?

Well given that I just want my object to end up where I told it to go without overshooting and rubber banding all over the place, I shouldnt' have to get a degree in physics to do that. There is no valid argument against adding this function. It's only being lazy not to add it.

It's the implementation I think may be faulty. "Being able to move through a series of waypoints at constant speed" is a requirement that might be better met by other solutions, such as a non-physical one or a time-varying rather than fixed target point for a llMoveToTarget() type function (so the object would constantly be drawn toward a time-based position with a relatively short damping period).

I'm not sure I understand the resistance people have to this idea. It seems perfectly reasonable to me.

I don't mean to be rude, Hewee, but I can't tell if that post with the math above is a joke or not. Shirley, you're not suggesting we do that in LSL, are you?

If all you want is to make a ball fly toward a point and not slow down, use llApplyImpulse or llSetForce instead.

Oh..

Will that fire an at_target event when it gets to the destination?

Nope. No joke and no need to implement it in LSL. It is an explanation of the physics that is almost certainly behind the llMoveToTarget() function and its interaction with the physics engine; a little background information for anyone interested, and particularly those who suggest changing/enhancing it. The idea is that llMoveToTarget() adds a force to an object, which is actually a very good way of handling the movement in a way that interacts well with other forces, collisions, etc.

You COULD do it in LSL using something like a simple time-repeated call to:

updateMoveToTargetForce(vector targetPos, float tau)
{
   vector x = targetPos-llGetPos();
   vector v = llGetVel();
   float m = llGetMass();

   llSetForce(-m*(x/tau+2.0*v)/tau, FALSE);
}

but the built-in implementation in the sim/physics engine code is almost certainly going to be a lot more efficient and effective.

If you've set a target using llTarget(), the 'at_target' event should fire no matter HOW the object gets there. You just want to be sure that you don't miss the target using things like llApplyImpulse() and llSetForce(), so you will want to either use a timer or also take advantage of the 'not_at_target' event to update the force/speed.

Actually, I _didn't_ think at_target would fire and was being sarcastic as the official wiki sorta implies that. Apparently I can only be clever OR sarcastic at once.. :\

I still think this JIRA is a good one, even if it can be done in other ways. Similar to what I think you're saying on the last post of the previous page, the sim could do this sort of function a lot easier and more effeciently than we can in LSL. It's like one of my other LSL pet-peeves: lack of switch/case/break. Yeah, we can live without them but wouldn't scripting be nicer with them..

If it's not overly difficult for LL to implement (no idea on this but it doesn't seem like it should be), doesn't cause more stress on the sim (I find it hard to believe it would) and there's use-cases where having it would make life easier for LSL coders, why shouldn't they do it?

Luckily this isn't Hewee Life, it's Second Life. Hewee may not like having options, but most people do. It wouldn't be hard to implement, it uses the same functionality which is already present, but only exposes the falloff which is currently hard coded.

As far as I know llApplyImpulse() or llSetForce() do not automatically stop when the given destination is reached (as they have no destination parameter).

llMoveToTarget() is used on "physical" objects and avatars, the movements of which are constrained by the "physics engine". You propose "simple" solutions that you believe to have trivial implementations, and you reach such a conclusion without an understanding of physics or physical simulation (things which SL obviously utilizes to a great degree for physical objects and avatars). Fine. I suggest though that you think about how a physical object moving with the proposed function will behave when other forces and impulses are applied to it, and what happens when it collides with other objects, avatars, and terrain. Once you've fully fleshed that out in a way that is consistent with other physical movement, you might start to get a picture of just how "simple" the proposed enhancement would be.

Not sure where you're going with this Hewee.. I think the purpose of this thread is to discuss the merits (or lack thereof) of SVC-1479, not how difficult it would be for LL to implement it.

At the end of page 1, you seemed to agree that this kind of movement would be a lot easier and more efficient for the sim to have a 'native' function to do this vs. doing it in LSL.

Are you against this JIRA and if so, why? Because you don't think it's well defined? Because you don't think it's useful? Because you are, in general, against adding features? Something else?? I think the first two are workable, the third is a religious battle and the fourth is something I'll reserve judgement on..

If a physics Linden said, "sure, we can do that easily but get me 50 votes to prove people actually want it" would you vote for it?

edit: or anybody else.. Please comment if you'd like.

Mostly I think it goes too far towards defining an (incorrect) solution. The basic requirement is that people want to move an object to a point with more or less constant speed/time, which is fine. There are solutions other than the one proposed that should be able to meet the requirement adequately while fitting better into either the physical simulation or the general SL model. I would vote for a JIRA issue that stated the requirement if it either left the implementation details up to LL (preferred) or was based on a solid understanding of physical simulation.

Propose away, as far as new features go. However, I hardly think this is a 'major' priority suggestion.

What implementation details?

It looks more to me like functional requirements have been given, which is exactly what I would think LL wants when considering a new feature - they want a clear description of what's being asked for and some examples of what people want to use it for.

edit: and I'm fairly sure Sindy is planning to show up at Andrews office hour tonight and torture him (or try to anyway) about this suggestion. If anybody has strong feelings about this, you might also want to show up. Don't know if she'll make it into the agenda, though.

Leaving the implementation up to LL is not going to work, since they have no idea what people need.

And i have yet to see anything that violates any real or imaginary model which may or may not exist. It' moves an object or avatar from point A to point B, slowing down at a rate specified. It breaks no laws of physics. From the lighest feather to planet can be moved or stopped at any rate, given a force big enough. It doesn't have to be 'realistic' because, this isn't the real world! It's very short sighted to limit things in SL to 'only what is possible in RL'. That's very In-the-box thinking. What I would expect from an engineer I suppose.

How about we do away with the physics engine entirely? SL shouldn't be constrained by the real world, after all.

I've already suggested a requirement that should meet the needs stated without attempting to include implementation details that could easily change it from a possibility to a "will not implement". I'm sorry if it's falling on deaf ears. Don't pout TOO badly if you don't get what you want, especially in light of your unwillingness to participate in a logical and respectful argument. It's been fun, but there's no reason to continue with this "discussion". Good luck with it.