SVC-1479: damping control of llMoveToTarget

You two should get partnered!

I still don't see implementation details in this JIRA, Hewee. Throw me a bone here please and point them out to me.

At last we agree on something! Being able to turn off gravity would be great, I think it's been suggested a few times. Or making prims and avatars bounce around like rubber balls.

just 2c...

I tried to build some remakes of some old arcade-games (like pacman and breakout) but always failed because the movement of the objects (the pacman or the ball in breakout) don't need to follow physical rules... being able to turn this off would be great!

Making those two games using physics in SL is not very feasible, though.

It can be done pretty well without physics, though.

I tried using llSetPos() in a loop... doesn't look good...

Hey, neat, a thread on my proposal. Yeah, seriously, I know there are ways to do this in LSL. I wrote such a hack to constantly update llMoveToTarget with new values to produce a smoother movement over a given time, however it's a big script for what should only require a parameter to say, "I want to slow down over x (milli)seconds." There's no programmatic reason why this can't be done, knowing other physics engines as I do (Bullet and Newton specifically). If free alternatives can do this, Havok (which up until last month didn't feature a free version) should be capable of it as well.

Doing away with the physics engine entirely is unfortunately something we can't do. Disabling physics through the estate controls (effectively removing the physics engine) will freeze everyone's movement within a sim. On top of that, cars, planes, avatar catapults, and everything else we enjoy physically would cease to work. If I recall, even sitting is controlled by the physics engine. Imagine not being able to use pose balls anymore. >O
I'm all for changing how physics works though, negating gravity or inverting it on a whim, or specifying gravitational points within a sim to allow for unique builds (for instance, the 2001: A Space Odyssey scene where one of the characters is running around the inside of the space ship's ring. Or remaking particular areas of Super Mario Galaxy). This, however, seems like something bordering on the impossible. Unlikely is a better term, as I'm sure in time a way could be devised to accomplish that, but it's one of those things very few people would understand and even less would use.

Just got back from Andrews office hour. Simon was also there for the discussion. Sidewinder was too but you know management - he showed up late.

It was a pretty interesting conversation and I'd _strongly_ encourage people who are interested in this sorta stuff to go to Andrew's office hours. Some really cool stuff gets talked about.

Find tonights transcript here: http://wiki.secondlife.com/wiki/User:Andrew_Linden/Office_Hours/2008_06_05

(and my group title tonight, which is discussed briefly but not given in the transcript, was "Will script 4 shoes"

I can only ever remember one Linden's office hours, Qarl's and it's on Friday. But when I remember it's usually just wrapping up. >D

Just read the transcript though, interesting stuff. I'll have to send Andrew a notecard with some of my thoughts about that keyframing thing he was talking about. I'd like it to extend to a number of other systems too, and it'd be awesome to maybe work it into a new animation system for NPCs.

Oddly though, he didn't really seem to notice the suggestion at hand. I get the impression he was too fascinated by the idea of a keyframe movement system to hear about llMoveToTarget additions or changes. >3

Could definitely find a use or two for keyframing and it might exceed the criteria of the jira entry. As mentioned once, this could go hand in hand with puppeteering. Puppeteering is some mostly finished, just slightly buggy code that was just released to the dev community to see if they could do something useful with it. At the moment it is client side only.

I also noticed that but didn't really read too much into it. Once he said that it was something he'd thought of too, I was happy. My only real goal was to make sure they understood what was being asked for and, bonus, get opinions on what they thought of it. That it was something Andrew had already been thinking about was enough for me - I think he acknowledged that then just moved on to a tangent on what other kinds of things might happen down the SL physics road.


I'm not sure they got my reference to the puppeteering but it may not be fresh in their minds from reading about it today. Dunno how much, if any, of the UI work could be shared between Andrews ideas and the puppet stuff but there seems to be some similar concepts there.

Yeah, and I told you back then the solution to the problem, yet you refuse to use it, and look for long ways around, or now, propose functionality that's not really needed. You should simply use a realistic range in your llTarget(), or use llApplyImpulse(), and no, an at_target event isn't raised if using llApplyImpulse(), but certainly an if statement can drop you out of the loop, and you're done. Personally, I'd use llMoveToTarget() and a reasonable range, (as a matter of fact, I have already), and it WORKS, and raises the at_target() event that you seem to not be able to do without... so I just don't really see the need for a function that does what can easily be done already.


http://www.secondscripter.com/

Because aside from solutions regarding llMoveToTarget() any of the others are subject to script lag, causing very unexpected and possibly unwanted results (rubber banding, gravitational influences, etc.). It's also subject to obstruction based screw ups, having objects go flying all over the place if anything happens to be in the way thanks to ricochet. The resulting script to correct for these things is large, far larger and more confusing than a single llMoveToTarget() call. This isn't new functionality, it's a trivial thing to add by copying and pasting code and altering it slightly to allow users to change the start and end acceleration and deceleration. It could be done over someone's lunch break.

I suppose the question here is why are you so opposed to a code change that makes code less obfuscated, use less memory, suffers less from lag, and is less prone to error (either at the fault of the programmer or due to environmental interference)?

Yeah, it is, the event only cares if the prim gets into the target range, any movement physical or not will do. I actually use that pair of functions in a silly toy that drags me to the camera position.

If you were around before LL had implemented llVecDist and llVecNorm and such, would you have objected to them being added, too?

No, but llTarget() and llMoveToTarget() already exist, which is my point.

Yes, I think you've made that clear.

The points that others have tried to make is that it doesn't really do everything we want it to. Yes, these behaviors can be faked in LSL but doing that adds a bunch of script code, eating into the limited memory we can use, and will want to run a lot more often to adjust the force/target/etc, which adds to the script load on the sim.

Just because there's a way to do something in LSL doesn't mean that LL shouldn't provide a llFunction to do the same thing. The llVecDist function is a good example of exactly such a thing - the math to get the distance between two vectors is well known and we could all just add a function in every script that wants to know the distance but LL added a function for it anyway..

One thing I don't understand, is why is anyone worried about realism with llMoveToTarget? Real world objects don't leap into action spontaneously and decide that they're going to reach a spot in a certain amount of time with no means of propulsion, well they don't do that in my neighborhood. What's wrong with a little variability in the damping?

Just a reminder that people who are interested in getting this should vote for it..

(shameless bump for votes)

Who's the bozo who put this in scripting tips? Should be in feature suggestions.

/me sends a PM to Strife.

/me waits patiently high up in a tree for the thread to come into range. Spotting the thread, slowly raising the rifle then pulling the trigger the dart springs fort, flying straight and true it hits it's mark. The thread jumps and tries to run off but stumbles and falls, the drugs take hold. After giving the thread a thorough examination, checking it's teeth and claws, and giving it a few shots, caries it over to the truck, loads it in the back and drives it to the Features Suggestion forum where it will live out it's days.

Now freed from the circling predators, the thread was able to grow in peaceful coexistence with it's fellow jira entries.





Voted for

TY, Jesse.

(zomg, was that a shameless bump or what??)