1  |   Order by index

Dec 7, 2003, 5:02pm

copied from worldbuilders:



[View Quote]

Dec 11, 2003, 12:33pm

kf,

reading your post again, I think you are refering to a forced avatar
change on the bot by anorther CT bot. What you should do is this:

your bot receives an avatar_change event. The session number received
aw_int(AW_AVATAR_SESSION) has to be compared to the session of the
bot aw_session. If both are equal then this is a forced avatar
change and the only valid fields are aw_int(AW_AVATAR_TYPE) and
aw_int(AW_AVATAR_GESTURE). You must now explicitely keep the values
of the avatar and gesture in whatever variables the bot uses to set
them and later send them to the SDK. If you forget to do this, next
time the bot moves, it will be sending the old values of avatar and
gesture back to the SDK and world server.

If this is what you were refering to, the problem is in your bot and
can be solved easily. It is not well explained in the AW pages, it
took me a while to understand how this works.

Alex


PS: I emailed this to you I think earlier today. I add here this:

I think this could be considered a bug in the SDK, as the SDK should
itself check the session number and adjust the internal parameters of
the bot (avatar and gesture) in the case of a forced change of avatar
and gesture, without requiring that the programmer does that
him/herself explicitely. In any case, if not a bug, it is a
non-feature :)

[View Quote] >copied from worldbuilders:
>
>
>
[View Quote]

Dec 11, 2003, 5:56pm

Yes, I agree, this is a bug - unless a bot is, by the developers,
supposed to keep the avatar with which he logged into the universe.

Even with the workaround, which I use also, I see the avatar switching
back and forth between the type the server sets and the type I force him
back into - and this happens although I issue the command right away:

Result = sdk.aw_state_change
Result = sdk.aw_int_set(AW_AVATAR_TYPE, mytype)
Result = sdk.aw_int_set(AW_AVATAR_GESTURE, 0)
Result = sdk.aw_avatar_set(mysession)

In this regard, even when the programmer provides type and gesture on
each state_change (which is, btw, a huge unnecessary server load, eg.
when multiple bots are moving) - it will not work correctly, so this
cannot be a non-feature, but only a bug.

Actually, when you set another gesture than 0, the gesture will start
again and not continue - this might look quite funny in certain
circumstances <g>.



[View Quote]

Dec 11, 2003, 6:21pm

The problem is, you are issuing aw_state_change BEFORE setting the
avatar type and gesture. aw_state_change must be the LAST command.

Alex

[View Quote] >Yes, I agree, this is a bug - unless a bot is, by the developers,
>supposed to keep the avatar with which he logged into the universe.
>
>Even with the workaround, which I use also, I see the avatar switching
>back and forth between the type the server sets and the type I force him
>back into - and this happens although I issue the command right away:
>
>Result = sdk.aw_state_change
>Result = sdk.aw_int_set(AW_AVATAR_TYPE, mytype)
>Result = sdk.aw_int_set(AW_AVATAR_GESTURE, 0)
>Result = sdk.aw_avatar_set(mysession)
>
>In this regard, even when the programmer provides type and gesture on
>each state_change (which is, btw, a huge unnecessary server load, eg.
>when multiple bots are moving) - it will not work correctly, so this
>cannot be a non-feature, but only a bug.
>
>Actually, when you set another gesture than 0, the gesture will start
>again and not continue - this might look quite funny in certain
>circumstances <g>.
>
>
>
[View Quote]

Dec 11, 2003, 7:13pm

No, this is not correct, because the state_change is the command that
causes the server to turn the avatar back to the log-in avatar type.

So, when you set the avatar type BEFORE, then it will turn the avatar
type, but the state_change immediately changes it back.

When you set it before, btw, you do not need to issue avatar_set to make
it work, but nevertheless, in every circumstance, state_change switches
it back.


[View Quote]

Dec 11, 2003, 8:17pm

Sorry, KF. You are using the SDK commands in a way they are NOT
supposed to be used. The correct order is FIRST to set the values to
be sent to the world server by the SDK, an then, and ONLY then, to
send them to the server with aw_state_change. You are doing the
opposite. And by doing so, you can never produce a correct
bug-report.

Alex

[View Quote] >No, this is not correct, because the state_change is the command that
>causes the server to turn the avatar back to the log-in avatar type.
>
>So, when you set the avatar type BEFORE, then it will turn the avatar
>type, but the state_change immediately changes it back.
>
>When you set it before, btw, you do not need to issue avatar_set to make
>it work, but nevertheless, in every circumstance, state_change switches
>it back.
>
>
[View Quote]

Dec 12, 2003, 7:36am

Meanwhile I have solved the problem. In order to work, this command
sequence must be followed:

1) avatar_set to avatar type desired
....move to another position
2) state_change
3) avatar_set to avatar type desired

Any other combination or order of commands will not work. In fact, these
3 commands are the only ones used in the subroutine, and in the whole
program is no other state_change used - so there is no possible error
margin.

This is most likely not the "intended" behaviour, especially due its
redundancy, not to speak about the significant additional traffic that
is caused by this on every move.

When you skip step 1, then the avatar will rapidly switch between the
intended avatar type and the avatar type that was used when the bot
FIRST entered THIS world server.

When you skip the (normally not needed) step 3, the state_change event
will set the avatar back until the next state_change, and this is
particular odd since it would mean that any state_change, even when
issued by another sdk (eg. the browser) to the server, might affect the
bot avatar type as well.

Another explanation could be that calling aw_wait(0) without a callback
happens too fast to let the application/server execute internally the
change event or that the state_change somehow is executed faster (do the
sdk messages have a priority value?). But then again, when I double step
1 (eg. 1-1-2), the result is the same as when I used (1-2) only.

But anyway, the above described is the definite workaround when using
the VB wrapper.

Dec 12, 2003, 8:07am

Things can be so easy sometimes and there is not even a workaround
needed:

When you simply do NOT use the avatar_set command and switch the avatar
type instead ONLY with the state_change command (using my_type and
my_gesture), everything works fine.

So please skip my previous posting, there is no workaround needed, just
do not use avatar_set on your OWN avatar.

I have been mislead by the assumption that avatar_set can *also* be used
to switch your own avatar, but in thise case the sdk sentence "Set a
***users*** avatar and gesture" has to be taken literally - although it
also works with the own one, but then only using the lengthy workaround
I have described earlier.

Resumee: Lots of excitement for nothing, my apologies!

KF

1  |   Order by index