1  |   Order by index

Apr 7, 2001, 11:45pm

Hi there people, I have something that I would probably have posted to the
Beta NG if I could have done, so I'm going to try my luck here.

I have two identical areas setup in a world ... right next to each other.
They each have an "anchor point" which I use for some calculations. I also
have a bot tracking a single avatar (me ... the only one in the world),
maintaining its location through the usual AW_AVATAR_CHANGE events.

On clicking an object (when the avatar is stationary and has been for a good
few seconds), the bot takes the avatar's X, Y and Z offsets from that area's
anchor point and teleports the it to the same X, Y and Z offsets from the
other area's anchor point (positioned in exactly the same relative position
within the area). The Yaw is retained ... that's no problem.

Sounds straight forward right? Pah!

The first time I do the teleport (as the avatar), after using the browser to
move the avatar into the first area, the avatar is teleported to a position
slightly further along the line of last movement. The ONLY way I am updating
the avatar's position within the bot is through the AW_AVATAR_CHANGE events.

I know its not my code, because if I teleport back and forward between the
areas afterwards (without moving the avatar in the browser), it gets EXACTLY
the right position. So I can only see that the browser is sending at least
one more avatar movement notification to the server without carrying it out
itself properly. I'm sure the world server wouldn't be trying to trick me by
inventing movements (perhaps I'm just not paranoid enough yet).

This is in v3.0 (build 354). I'm going to try it on v3.1 (Build 370) later
on to see if this is still apparent, but in the meantime if anyone has any
comments on this I'd be grateful (preferably like someone noticed it before
and its fixed in Build 370). It may sound trivial, but I am relying on these
messages to be correct and, if anything, I would expect the SDK to be behind
the movement if it was going to be incorrect at all .... not ahead of it.
I'm using is Build 19 of the SDK.

I hope I managed to explain myself clearly enough. If anyone thinks its
appropriate, please post this on to the Beta NG for me.

Thanks,

Grims.

Apr 7, 2001, 11:53pm

bots are just like that i guess. when i log bots in it doesnt go at exactly 0n
0w... normally up to .5 offset of where it should be... not sure how to fix this

[View Quote] > Hi there people, I have something that I would probably have posted to the
> Beta NG if I could have done, so I'm going to try my luck here.
>
> I have two identical areas setup in a world ... right next to each other.
> They each have an "anchor point" which I use for some calculations. I also
> have a bot tracking a single avatar (me ... the only one in the world),
> maintaining its location through the usual AW_AVATAR_CHANGE events.
>
> On clicking an object (when the avatar is stationary and has been for a good
> few seconds), the bot takes the avatar's X, Y and Z offsets from that area's
> anchor point and teleports the it to the same X, Y and Z offsets from the
> other area's anchor point (positioned in exactly the same relative position
> within the area). The Yaw is retained ... that's no problem.
>
> Sounds straight forward right? Pah!
>
> The first time I do the teleport (as the avatar), after using the browser to
> move the avatar into the first area, the avatar is teleported to a position
> slightly further along the line of last movement. The ONLY way I am updating
> the avatar's position within the bot is through the AW_AVATAR_CHANGE events.
>
> I know its not my code, because if I teleport back and forward between the
> areas afterwards (without moving the avatar in the browser), it gets EXACTLY
> the right position. So I can only see that the browser is sending at least
> one more avatar movement notification to the server without carrying it out
> itself properly. I'm sure the world server wouldn't be trying to trick me by
> inventing movements (perhaps I'm just not paranoid enough yet).
>
> This is in v3.0 (build 354). I'm going to try it on v3.1 (Build 370) later
> on to see if this is still apparent, but in the meantime if anyone has any
> comments on this I'd be grateful (preferably like someone noticed it before
> and its fixed in Build 370). It may sound trivial, but I am relying on these
> messages to be correct and, if anything, I would expect the SDK to be behind
> the movement if it was going to be incorrect at all .... not ahead of it.
> I'm using is Build 19 of the SDK.
>
> I hope I managed to explain myself clearly enough. If anyone thinks its
> appropriate, please post this on to the Beta NG for me.
>
> Thanks,
>
> Grims.

Apr 8, 2001, 12:22am

What you see in the browser is not what you get :)

Try this: give your bot 2 commands, one after the other: warp to x y z, seed
object where you are.

You will see the bot moving towards its destination, and if that is like say
20m away, while the bot is still half way on the road the object will appear
at destination. This is a normal consequence of the browser's need to show
fluid movement...

The position of an avatar in the browser is calculated by the browser, not
by the world server. The world server, in my experience, sends the correct
coordinate, but the browser sometimes fails. A notorious example in the past
(which is now apparently solved) was the zero altitude bug. If you
teleported from any altitude to zero altitude, without changing other
coordinates, the browser would not show the change... this was easy to
verify, all browsers watching the avatar would suffer from this illusion,
you just needed to move your bot (or your own avatar if you were the one who
had moved to 0a) one centimeter forward, and it would also descend/ ascend
to 0a in all renderers.

I mentioned a similar bug when 2.x appeared: in some occasions, my bot would
move towards me, but the browser would fail to register... but if I changed
from 1st to 3rd person view, suddenly my bot would adopt the correct
position.

Possibly related to these bugs is the still occuring 'sunken' avatars,
especially noticeable with old avatars which have the 0 0 0 coord at eye
level.

And the 3.0 browser introduced an even more noticeable bug, especially
noticeable when bots are involved: if an avatar moves in a straight line
exactly from north to south, the avatar keeps twitching back to face north.
The first time I noticed this was when making a script for a ship bot... the
enormous Galleon was acting spastic when going from north to south, and only
when it was moving exactly to a southern coordinate without changing the
western one. I don't know if this bug is still there.

There seems to be a permanent problem with the last step of the avatar in
the browser... the routine for that should really be checked.

XelaG

[View Quote]

Apr 8, 2001, 12:33am

Thanks Xelag,

Have to agree with you there. Shame it screws me 7 way from Sunday though!.

Grims.


[View Quote] There seems to be a permanent problem with the last step of the avatar in
the browser... the routine for that should really be checked.

Apr 8, 2001, 2:22am

Done a little more playing on this, tracing the messages against where the
browser says it is in the title bar (in a very high-tech fashion ....
gradually stepping over a cell boundary and watching the messages) and the
messages to the bot are actually very consistent with the position reported
by the browser. The problem comes (still from the browser unfortunately)
with what it does with the teleport.

Although the teleport specifies the position in centimeters (as the web-help
says it supports that precision), the AW_AVATAR_CHANGE message comes back to
the bot with pretty much a 1 meter precision. For example, the Z-coordinate
before the teleport was 3250 (centimeters) and was notified after the
teleport as 2900 when it was actually set to 3250 - 400 = 2850.

So I played some more ... 2909 + 800 = 3700, 3700 - 800 = 2900 (yay!!!), and
3030 + 800 = 3799. Its the same with the Z-coordinate AND the Y-coordinate
.... 1 meter precisions.

So what gives?? This doesn't look like a complicated calculation problem
anymore (although I guess we can blame rounding issues for the 99's ... they
had to get in there somewhere with so much going on ... but that's close to
irrelevant).

Going to try 3.1 now ... its (potentially) such a small thing that it may
have been fixed.

Grims

Apr 8, 2001, 3:37am

Grimble, can we talk about this thru email, I cant follow you full ?
xelag at 3dee.nl

[View Quote]

Apr 8, 2001, 9:43am

ok

[View Quote]

Apr 8, 2001, 11:18am

And another thing ... how come you don't get an AW_EVENT_OBJECT_CLICK if the
object has an activate action command on it? Maybe its a technical reason,
maybe its an oversight, but either way its a pain in the butt LOL.

Grims.

Apr 8, 2001, 7:06pm

Do you mean: your bot clicks on the object, and it should get an
aw_event_object_click? I'm not sure what you mean LOL :)

XelaG

[View Quote]

1  |   Order by index