avatar moving problem

Small targets are hard for avatars, avatars move sloppy. Try to make zee higher so the avatar can float in, add half a meter or even less. llApplyImpulse could work better, llPushObject if you want it to work when you are hovering.

Rough and needs to be cleaned up but it gets it to the target range:

integer targetid;
vector startpos;
vector stoppos;
float speed = 2.5;
vector target;
float zee;
default {
	state_entry() {
		startpos = llGetPos();
		stoppos = <10, 10, 0 >;
	}
	touch_start(integer total_number) {
		if (llGetOwner() == llDetectedKey(0)) {
			llSetTimerEvent(15.0);	//safety
			target = startpos + stoppos;
			llOwnerSay((string) target);
//             targetid = llTarget(stoppos, 1.0);
			llMoveToTarget(target, speed);
		}
	}
	at_target(integer number, vector outtarget, vector ourpos) {
		llTargetRemove(number);
		llMoveToTarget(target, 0.3);
		llSetTimerEvent(0.3);

	}
	timer() {
		llStopMoveToTarget();
		stoppos *= -1;
		llSetTimerEvent(0.0);
//         if (target == <21.0, 71.0, zee >) {
//             stoppos = <30.0, 73.0, zee >;
//         }
//         else {
//             stoppos = <21.0, 71.0, zee >;
//         }
	}
}

Thanks, Cerise. Yes, I've noticed the sloppiness. I'm puzzled though by the fact that this script is NOT sloppy if I'm headed in one direction but IS if I'm headed the opposite one. Just to see exactly what progress I'm making, I added a not_at_target event with llOwnerSay((string)llGetPos()) in it. If the target is <21.0,71.0,zee> I approach it nicely and always end up within 0.05m of the target. If the target is <30.0,73.0,zee> I always end up at <29.0, 72.0, zee> +/- 0.05m. That makes no sense to me.

To elaborate on my other question, if I set the range on llTarget to <1.0, the script moves me to something close to <21.0, 71.0, zee> but not close enough to trigger the at_target event, so the script hangs up. That means that it never gets to the llStopMoveToTarget call, never resets stoppos, and won't respond to another touch_start. Again, that makes no sense to me.

I know there are other ways to write the script that will move the avatar between the target points, using llApplyImpulse or whatever, but I'm really curious about how this particular method works, or (really) why it doesn't behave well as I've written it.

I am confused thou after going back and reading the whole thread. Does the OP really understand that she can just tp there instantly using warpPos or even in hops calling llSetPos in a loop, either of which would be much more elegant?

I am too. I suggested warpPos way back in the beginning of this thread (post #4), but the OP seems to ignored that and gone off in this direction. Right now, I don't truly care what works best for the OP as much as I did at first. Since I got myself sucked into playing with the OP's script, I'm really curious about why it behaves so strangely. When a script doesn't do what I expect it to, I'd kinda like to know why.

Physical is the only way to go if you can't rez and it looks more cool.

Rollig, I think you got lucky in one direction. llMoveToTarget damps down and fights the avatar near the target. Better results might come with a slow walk to a big target and then a fast leap to a small target at the end.

I see Jesse cheated and took out llTarget and that can work too

Dang! I hate luck. It's too unpredictable. I do like Jesse's workaround, though. I just tested it myself and it does the job. I haven't fiddled with enough scripts like this to feel comfortable yet, so I truly appreciate the help. This is a nice learning exercise.

BTW ..... maybe I'm pressing my luck(?) by asking, but I'm still interested in knowing how to get myself facing toward the target as the script moves me.

I am still playing with it also for the same reason, but maybe not much longer. The combo of Havok 4/MONO just really screwed up target and apply impulse in attachments. I have a Set Elevation script that worked beautifully before then. Set target height and boom you were up at 10,000 meters. It doesn't even work right for little hops of a hundred meters or so anymore. I've been disgusted since then.

This prompted me to go back and take a look at my existing problem with my Elevation Script for a couple of hours last night. I discovered something that may be the root of your problem Rolig.

float height = 4090.0;
integer safetyCnt;
vector target;

default {
	touch_start(integer total_number) {
		target = llGetPos();
		target.z = height;
		llTarget(target, 50);
		safetyCnt = 1;
		llSetTimerEvent(45.0);
	}

	not_at_target() {
		llApplyImpulse(llGetMass() * <0, 0, 20000>, FALSE);
	}

	at_target(integer targetInt, vector targetPos, vector currentPos) {
		llTargetRemove(targetInt);
		llMoveToTarget(targetPos, 0.2);
		safetyCnt = 0;
		llSetTimerEvent(2.0);
	}

	timer() {
		++safetyCnt;
		vector pos = llGetPos();
		if (llVecDist(pos,target)<=.1 || safetyCnt == 2) {
			llStopMoveToTarget();
			llApplyImpulse(-llGetMass() * llGetVel(), FALSE);
			llMoveToTarget(llGetPos(), 0.1);
			llSetBuoyancy(1.0);
			llOwnerSay((string)llGetPos());
			llSetTimerEvent(0.0);
		}
		llOwnerSay((string)safetyCnt);
	}
}

*NOTE* You will have to reset the script when you fly or teleport back to the start position because of llSetBuoyancy.


This works fine if YOU ARE NOT FLYING when you click it. You flail around and it brings you within 1/10th of a meter of target.
[17:50] Object: <83.00000, 20.00000, 4089.94600>
[17:50] Object: 1
BUT if you try the same experiment when you are hovering. More then 50% of the time you have to nudge your av by pushing the Page Up button to start moving and the resulting stop pos is considerably different:
[17:56] Object: 1
[17:56] Object: <82.99980, 19.99759, 4087.62700>
[17:56] Object: 2
As you can see, you never get within the set target range and instead time out on the safetyCnt. So for some reason an av is "stickie" in some states for the Havok 4 engine.
Please note that this was never a problem in the Havok 1 engine and did not matter if the av was flying. I would not doubt that the same applies for traveling sideways, even when walking for some reason. Havok 4 is fighting the script.

You're not wearing Flight Feather are you? You might be having two different llMoveToTargets fighting each other. I added that after Havok4 was introduced because I couldn't use a feedback loop to keep you hovering cleanly any more.

Nope. Flight assist is turned off. I rubber band if I try it with flight assist enabled. As I mentioned, I first noticed the change in behavior back in Aditi when Havok 4 was being tested. Before that point, move to target worked exactly the same for either a vehicle or an attachment. And this is different then the cap on impulse. I bet if someone tested Rolig's script in a physical prim, it would work correctly.

That's the problem.


Haven't had a chance to play with it today. Since it is an attachment, wondering if llLookAt or llRotLookAt will work.

Unfortunately no. You can rotate the attachment to face the way you want but not an avatar itself, including your own. I understand why in the case with someone elses avatar but I think you should be allowed to do this to your own. After all can llPush..(yourself) or llMove..(yourself) anywhere so being able to also face the direction youre pushing/moving yourself would be good also.

Is a JIRA asking for this feature. Dont remember exactly which one though.

https://jira.secondlife.com/browse/SVC-2697 for anyone who wants the flight problem fixed.

Adding to the fun, even with identical sets of attached scripts, I can see the problem with one avatar but not with two others.

Thanks Viktoria. I will vote and comment on it tomorrow. Can't believe no one else had noticed it before then, but then again, I was always too busy (or lazy) to pursue it till now. It was not a bug introduced into any particular server version, but dates back to the changeover in Havok. But it was when jira was first getting off the ground and I just filed an old fashioned bug report.

The avatar rotation problem is due to the way avatar rotation is derived second-hand by looking at what the client is doing. Most of the time your avatar will appear to be facing different directions on different people's screens, unless you have just finished walking directly forward or backwards without turning.

Thank you, all. This has been a great puzzle and a learning experience. I have no idea whether the OP has gained anything from it, but I liked playing with it and appreciate the insights you have offered.