• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-734
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Andrew Linden
Reporter: Eyana Yohkoh
Votes: 5
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

(Havok4) llMoveToTarget

Created: 29/Sep/07 10:07 AM   Updated: 06/Feb/08 01:31 PM
Return to search
Component/s: Physics, Scripts
Affects Version/s: Havok4 Beta
Fix Version/s: Havok4 Beta

Environment:
CPU: Intel Pentium 4 (Unknown model) (3192 MHz)
Memory: 2048 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 7600 GT/PCI/SSE2
OpenGL Version: 2.1.1
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)
Issue Links:
Relates

Sub-Tasks  All   Open   
 Sub-Task Progress: 
No sub-tasks match this view.

 Description  « Hide
Catchall for the behavior of the llMoveToTarget script function in Havok4.

Non-Attachments:
Initiating llMoveToTarget() behaves as per Havok1 as far as I can tell so far.
Calling llStopMoveToTarget() after an object has "settled in" to it's target position does NOT cause the object to resume physics interactions. The object stays at it's targeted position until something triggers physics again. (Selecting, collision, etc)

On attached script:
When a scripted item is attached and using llMoveToTarget the avatar will not move unless already in motion, be it falling, a movement control, or push. If the avatar is standing still then a llMoveToTarget simply will not work until the avatar starts moving.

Further, when it does work, it appears to "Bounce" or "Rubber band" the posiition. Havok1 Did not exhibit this behaviour.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
WarKirby Magojiro added a comment - 29/Sep/07 10:54 AM
Raising priority because this breaks content.

Ryozu Kojima added a comment - 29/Sep/07 12:57 PM
Adjusted the issue to be a catchall for llMoveToTarget behavioral issues.

Uprgraded to critical, this one is pretty well broken. Havok4 should NOT be released before this is function is fixed.


Lex Neva added a comment - 30/Sep/07 09:50 AM
Why make this issue a catch-all? I think we might better serve LL by keeping separate problems to separate JIRA issues, and using a meta-issue or issue links to tie them together.

Tdub Dowler added a comment - 30/Sep/07 11:09 AM
I have had a similar problem, but when it was attached and i was standing still, it would move very very slowly then go back to my original position.

Ryozu Kojima added a comment - 30/Sep/07 02:37 PM
I understand what you're saying Lex. I'm not really sure what the best way to handle it is. I always saw meta-issues as more "Issues that fall under a subject." Whereas this is about a specific LSL command, not a generalized category.

Thought it could fit into meta issues such as "Scripted Avatar Movement"

I'm actually starting to get the feeling there's a handful of underlying physics issues all acting up at once. One of them being "Objects at rest, stay at rest"


Ryozu Kojima added a comment - 01/Oct/07 05:12 PM
I've made two videos illustrating some of the difference between how llMoveToTarget works in Havok1 vs. Havok4

http://youtube.com/profile_videos?user=n1nj4Ryozu

It seems that
Havok1: Movement is dampened over time, so velocity is a bellcurve
Havok4: Velocity is constant up to the point you reach the target, at which point you kind of overshoot, and are sent back the other way.


Andrew Linden added a comment - 03/Oct/07 08:22 AM
I prefer individual jira items for each problem, even if they all have to do with llTargetOmega().

If a catchall or meta jira item is created, the pieces should be made as sub-tasks.


Andrew Linden added a comment - 03/Oct/07 08:24 AM
Er... I meant llMoveToTarget().

Andrew Linden added a comment - 03/Oct/07 08:38 AM
Ryozu, in the video of the movement overshooting the target position... was that your avatar or a regular object? I couldn't tell in the video.

Andrew Linden added a comment - 03/Oct/07 08:46 AM
If you have a test script, either paste it in the relevant jira item, or send me a copy of the test object in the Havok4 preview world.

Ryozu Kojima added a comment - 03/Oct/07 09:57 AM
Andrew: The video displays both an avatar being moved through an attachment, and an object, side by side. Both cases show contrast in behavior.

Of special note is the behavior of the plain object in Havok4 seeming to.. jump around strangely... I'm not sure if it failed to make it to the target, and required some kind of interaction (My avatar influencing it) or if it was the client failing to accurately show the position until some kind of update was forced.

Here's the relevant code used in each object. I hard coded the positional data so that if I didn't actually make it to the exact position, I wouldn't drift between clicks.

/////////////////
integer On;

default
{
state_entry()

{ llSetColor(<1.0, 1.0, 1.0>, ALL_SIDES); }

touch_end(integer total_number)
{
if (!On)
{ llSetColor(<0.0, 1.0, 0.0>, ALL_SIDES); llMoveToTarget(<175.0, 175.0, 50.0>, 0.05); } else { llSetColor(<1.0, 0.0, 0.0>, ALL_SIDES); llMoveToTarget(<175.0, 175.0, 55.0>, 0.05); }
On = !On;
}
}

//This was placed in two spheres set to a scale of <0.25, 0.25, 0.25>
//One sphere has it's X position in each llMoveToTarget incrased by 1.0
//to avoid collisions with the avatar.
//Each click moves the avatar up or down. Make sure the Z positions are above
//ground and 5.0 meters apart.
////////////////////////////////


CrystalShard Foo added a comment - 22/Oct/07 06:03 AM
llMoveToTarget(llGetPos(), 1); causes the object to sink 0.2 meters below its point of origin rather then stay where it is.

Andrew Linden added a comment - 30/Oct/07 09:52 AM
Ryozu Kojima, the non-critically-damped motion of the avatar is fixed, as far as I can tell.

CrystalShard Foo, the sagging effect of llMoveToTarget(llGetPos(), 1) is expected. The value of 1 at the end means that the motion will be critically damped with a "timescale" of about 1 second --> the object's offset from its target is approximately 1/e of what it was one second ago --> when it is rather close to its target the effect is weak. Unless you also give the object buoyancy it will fight against gravity and will therefore sag a bit from its target position when the "timescale" of the effect is long (1 second). Alternatively, you could give it a smaller timescale (0.1 second for example) and it will try to get there very fast and sag less against gravity.


WarKirby Magojiro added a comment - 22/Dec/07 01:27 PM
This issue has been bulk changed to fix pending.

Andrew Linden added a comment - 06/Feb/08 01:31 PM
Fixed and deployed for weeks now. Or has it been months? It's all a blur.