1  |   Order by index

Dec 3, 2003, 2:32pm

I just sent this email to devteam, I think it concerns all bot
developpers, so I post it here (I have no access to the beta ng).

Dear AW development team,

Since the introduction of Global Mode in the bot SDK in version 3.3, a
number of anomalies have been noted and reported, but not fixed. This
includes the empty name fields and citizen number 0 for real citizens,
and the disappearence of avatars which are still present. Note that
although these anomalies have been noted in Global Mode, this does not
imply they do not exist in non-Global Mode.

Yesterday, Chris Mürwald (chrispeg) and myself (XelaG) were doing a
demonstration of interaction between bots and humans in DreamlandPark,
world eLearn (build 56), to representatives of European Union
sponsored institutions. At a certain moment, Chris and myself
realised bots were not receiving my chat, while the browsers were
receiving it. We decided to investigate. We collected the world
logs, and the logs of my xelagot (designed by me) and of chrispeg's
own botty (designed by him): the only code these two bot types share
is the aw.dll.

We seem to have found out what causes this. In short:

All bots were in Global Mode.
I (XelaG) was logged in with session number 45034 from my port 16561
I got disconnected (my winXP showed a 'network cable disconnected'
message for a few seconds)
I reconnected to the world with the same session number, from port
10002
.... at this point, bots still received my chat
My connection from port 16561 timed out, and is closed by the world
server.
.... as from this moment, bots cease to receive my chat, although they
do receive avatar_change and object_click events, and are able to
whisper and send console messages.
After noticing this, I logged off and back in with a different session
number, and the situation went back to normal.

The world logs show this:

Tue 12/02/03 16:44:47 myIP -1 CONNECTED
Tue 12/02/03 16:44:47 eLearn myIP -1 ENTER 45034 37FCDFE9
Tue 12/02/03 16:44:47 eLearn myIP:16561 -1 IDENTIFIED 'XelaG'
2659 2659
Tue 12/02/03 16:44:48 eLearn myIP:16561 2659 EVENT MASK 0x18f
....
Tue 12/02/03 16:47:43 myIP:10002 -1 CONNECTED
Tue 12/02/03 16:47:44 eLearn myIP:10002 -1 ENTER 45034
37FCDFE9
Tue 12/02/03 16:47:44 eLearn myIP:10002 -1 IDENTIFIED 'XelaG'
2659 2659
Tue 12/02/03 16:47:45 eLearn myIP:10002 2659 EVENT MASK 0x18f
....
Tue 12/02/03 16:48:46 eLearn myIP:16561 2659 TIMEOUT
Tue 12/02/03 16:48:46 eLearn myIP:16561 2659 DISCONNECTED

As from this moment the anomaly occurs in the bot SDK (apparently,
browsers are unaffected).

Examining my own bot Delph's log, I noticed that avatar_change events
that had my session number had empty or 0 name, citnum and privs
fields. avatar_delete event (when I finally logged off, it's not the
one in the world log above) had the wrong name.

Moreover: my bot Delph had also experienced the same disconnect but,
had logged off and logged back in, so that it's session number had
changed. When its connection timed out according to the world log, it
disconnected to old ghost session number. Other bots carried on
receiving all events from Delph.


Tue 12/02/03 16:45:18 myIP:16587 -1 CONNECTED
Tue 12/02/03 16:45:18 eLearn myIP:16587 -1 ENTER 45035
37FCDFE9
Tue 12/02/03 16:45:18 eLearn myIP:16587 -1 IDENTIFIED
'[Delph]' 0 2659
Tue 12/02/03 16:45:19 eLearn myIP:16587 2659 EVENT MASK 0x1ff
....
Tue 12/02/03 16:48:20 myIP:10016 -1 CONNECTED
Tue 12/02/03 16:48:20 eLearn myIP:10016 -1 ENTER 45048
37FCDFE9
Tue 12/02/03 16:48:20 eLearn myIP:10016 -1 IDENTIFIED
'[Delph]' 0 2659
Tue 12/02/03 16:48:20 eLearn myIP:10016 2659 EVENT MASK 0x1ff
....
Tue 12/02/03 16:48:47 eLearn myIP:16587 2659 TIMEOUT
Tue 12/02/03 16:48:47 eLearn myIP:16587 2659 DISCONNECTED


Two problems:

1. The world servers do not check to see if a new connection has the
session number of an existing connection, and duplicates connections
with same session numbers. This causes problems, especially when the
ghost connection times out, as an avatar_delete will be sent for that
session number, while there is still a connection open for the same
session number.

2. The bot SDK gets confused, as it seems not to keep track of
avatar_add/avatar_delete pairs. It is inconsistent: it allows events
such as avatar_change, avatar_delete to pass through, but not chat
events.

Two solutions:

1. World servers should check for existing connections of a certain
session number. If a connection exists, it should be closed (and the
appropriate avatar_delete event should be issued) BEFORE a new
avatar_add event is sent for that session number.

2. The bot SDK should keep track of paired avatar_add/avatar_delete
events. If two avatar_add events are received from the world server
for the same session number, the SDK should issue an avatar_delete in
between them and remember skip one later. This would not be perfect
but would ensure backward compatibility when the world server code is
fixed.

The effects of this bug:

This bug seems to explain the missing data (names of avatars,
citnums), disappearence of avatars in bot databases: it is completely
consistent with the buggy effects noticed. Although reports have been
done about this for bots in Global Mode, I expect this also happens
with other bots (unless the bot SDK aleady has the fix in these cases
and forgot to implement it in Global Mode).

My hopes:

That this bug will be removed as soon as possible. It has made Global
Mode unfit for projects where reliability is crucial.

Cheers,
Alex

Dec 3, 2003, 5:16pm

I've noticed that bug too, it's really annoying. The rpg's require a bot
in global mode in order to operate, and I've found that quite often in
awrpg the bot suddenly 'forgets' that a player is there and doesn't see
you anymore and you keep having to log out and back in for the bot to
'find' you again.

[View Quote] > I just sent this email to devteam, I think it concerns all bot
> developpers, so I post it here (I have no access to the beta ng).
>
> Dear AW development team,
>
> Since the introduction of Global Mode in the bot SDK in version 3.3, a
> number of anomalies have been noted and reported, but not fixed. This
> includes the empty name fields and citizen number 0 for real citizens,
> and the disappearence of avatars which are still present. Note that
> although these anomalies have been noted in Global Mode, this does not
> imply they do not exist in non-Global Mode.
>
> Yesterday, Chris Mürwald (chrispeg) and myself (XelaG) were doing a
> demonstration of interaction between bots and humans in DreamlandPark,
> world eLearn (build 56), to representatives of European Union
> sponsored institutions. At a certain moment, Chris and myself
> realised bots were not receiving my chat, while the browsers were
> receiving it. We decided to investigate. We collected the world
> logs, and the logs of my xelagot (designed by me) and of chrispeg's
> own botty (designed by him): the only code these two bot types share
> is the aw.dll.
>
> We seem to have found out what causes this. In short:
>
> All bots were in Global Mode.
> I (XelaG) was logged in with session number 45034 from my port 16561
> I got disconnected (my winXP showed a 'network cable disconnected'
> message for a few seconds)
> I reconnected to the world with the same session number, from port
> 10002
> ... at this point, bots still received my chat
> My connection from port 16561 timed out, and is closed by the world
> server.
> ... as from this moment, bots cease to receive my chat, although they
> do receive avatar_change and object_click events, and are able to
> whisper and send console messages.
> After noticing this, I logged off and back in with a different session
> number, and the situation went back to normal.
>
> The world logs show this:
>
> Tue 12/02/03 16:44:47 myIP -1 CONNECTED
> Tue 12/02/03 16:44:47 eLearn myIP -1 ENTER 45034 37FCDFE9
> Tue 12/02/03 16:44:47 eLearn myIP:16561 -1 IDENTIFIED 'XelaG'
> 2659 2659
> Tue 12/02/03 16:44:48 eLearn myIP:16561 2659 EVENT MASK 0x18f
> ...
> Tue 12/02/03 16:47:43 myIP:10002 -1 CONNECTED
> Tue 12/02/03 16:47:44 eLearn myIP:10002 -1 ENTER 45034
> 37FCDFE9
> Tue 12/02/03 16:47:44 eLearn myIP:10002 -1 IDENTIFIED 'XelaG'
> 2659 2659
> Tue 12/02/03 16:47:45 eLearn myIP:10002 2659 EVENT MASK 0x18f
> ...
> Tue 12/02/03 16:48:46 eLearn myIP:16561 2659 TIMEOUT
> Tue 12/02/03 16:48:46 eLearn myIP:16561 2659 DISCONNECTED
>
> As from this moment the anomaly occurs in the bot SDK (apparently,
> browsers are unaffected).
>
> Examining my own bot Delph's log, I noticed that avatar_change events
> that had my session number had empty or 0 name, citnum and privs
> fields. avatar_delete event (when I finally logged off, it's not the
> one in the world log above) had the wrong name.
>
> Moreover: my bot Delph had also experienced the same disconnect but,
> had logged off and logged back in, so that it's session number had
> changed. When its connection timed out according to the world log, it
> disconnected to old ghost session number. Other bots carried on
> receiving all events from Delph.
>
> Tue 12/02/03 16:45:18 myIP:16587 -1 CONNECTED
> Tue 12/02/03 16:45:18 eLearn myIP:16587 -1 ENTER 45035
> 37FCDFE9
> Tue 12/02/03 16:45:18 eLearn myIP:16587 -1 IDENTIFIED
> '[Delph]' 0 2659
> Tue 12/02/03 16:45:19 eLearn myIP:16587 2659 EVENT MASK 0x1ff
> ...
> Tue 12/02/03 16:48:20 myIP:10016 -1 CONNECTED
> Tue 12/02/03 16:48:20 eLearn myIP:10016 -1 ENTER 45048
> 37FCDFE9
> Tue 12/02/03 16:48:20 eLearn myIP:10016 -1 IDENTIFIED
> '[Delph]' 0 2659
> Tue 12/02/03 16:48:20 eLearn myIP:10016 2659 EVENT MASK 0x1ff
> ...
> Tue 12/02/03 16:48:47 eLearn myIP:16587 2659 TIMEOUT
> Tue 12/02/03 16:48:47 eLearn myIP:16587 2659 DISCONNECTED
>
> Two problems:
>
> 1. The world servers do not check to see if a new connection has the
> session number of an existing connection, and duplicates connections
> with same session numbers. This causes problems, especially when the
> ghost connection times out, as an avatar_delete will be sent for that
> session number, while there is still a connection open for the same
> session number.
>
> 2. The bot SDK gets confused, as it seems not to keep track of
> avatar_add/avatar_delete pairs. It is inconsistent: it allows events
> such as avatar_change, avatar_delete to pass through, but not chat
> events.
>
> Two solutions:
>
> 1. World servers should check for existing connections of a certain
> session number. If a connection exists, it should be closed (and the
> appropriate avatar_delete event should be issued) BEFORE a new
> avatar_add event is sent for that session number.
>
> 2. The bot SDK should keep track of paired avatar_add/avatar_delete
> events. If two avatar_add events are received from the world server
> for the same session number, the SDK should issue an avatar_delete in
> between them and remember skip one later. This would not be perfect
> but would ensure backward compatibility when the world server code is
> fixed.
>
> The effects of this bug:
>
> This bug seems to explain the missing data (names of avatars,
> citnums), disappearence of avatars in bot databases: it is completely
> consistent with the buggy effects noticed. Although reports have been
> done about this for bots in Global Mode, I expect this also happens
> with other bots (unless the bot SDK aleady has the fix in these cases
> and forgot to implement it in Global Mode).
>
> My hopes:
>
> That this bug will be removed as soon as possible. It has made Global
> Mode unfit for projects where reliability is crucial.
>
> Cheers,
> Alex

Dec 3, 2003, 5:27pm

Although your investigation is correct, and short disconnects cause,
indeed, all sorts of problems, it is not the whole of this problem.

The missing avatar name issue happens as well when a connection had not
timed out either by the universe or the world, and the same is true for
bots changing their avatar type unmotivated.
As for the chat, I had already circumstances in which chat of certain
persons was not received anymore, even when they did not time out - they
simply, after a while, stop reporting to the sdk.

The whole sdk issue appears to require a basic overhaul of the affected
mechanisms, unfortunately, there is none - NONE - response whatsoever to
the reported problems from the side of AW.
The problem is that a good number of sdk applications cannot be trusted
anymore and become simply unuseable for environments that rely on them,
and this is not exactly a "minor" flaw. Furthermore, the constant
ignorance of the existing problems is not satisfactory at all.





[View Quote]

Dec 3, 2003, 6:02pm

Crossposted reply from SDK group

--

Gee.. shouldn't you post this kind of detailed info in the beta group
where the people working on the code are?

[View Quote] Oh.. you're *not* a member of the beta? I'm shocked.

=8O

You should ask for access.. I'm sure they will grant you access.

Why ENZO himself personally asked me if I would like to be on it,
and I've never even released anything to the community.

ENZO? Can Alex have that spot in the beta you offered me?

Pretty please?

>
> Dear AW development team,

<SNIP *extremely detailed feedback that would cost thousands
of dollars to get from professional testers*>

Obviously you would be a great asset for any company to test their
stuff. That assumes of course that they are interested in finding bugs,
and fixing them too. You've led them right to the exact problem, and
provided enough information that surely they can squash this bug
completely without the costly process of actually reproducing it and
capturing the kind of intformation you have there.

Hopefully the oversight with your name not getting pulled out of the
'beta' hat will be corrected. Hopefully you and the half dozen or so
other people who make things everyone relies on in here every day
have the appropriate access to the AWI developers.

This issue will be a good chance for all of us to see how AWI deals
with outside developers and content producers who provide all of the
added value, which is an issue of particular interest to me.

I would also be interested in knowing how they deal with people
trying to make commercial ventures based around AW technology.
As you clearly point out, this issue is a bit of a roadblock. I would
expect to see quick action to resolve this.

Please.. keep us all informed how this situation plays out.

Dec 3, 2003, 7:55pm

I asked for access to the beta ng, and was denied, because it was for
alpha testers only. This bug was reported a few times directly to
members of the dev team. I reporterd it personally a few weeks after
the 3.3 version was made public. This now is the first time I had
world logs to base my analysis on. I got a reply from Bill Hoover
just now saying:

---
Thank you for this detailed information. We will see what we can do to
resolve this issue.
---

I would suggest that reports about this bug (and others related to it)
would be sent to devteam at activeworlds.com as well as being posted to
the newgroups. Maybe in this way we can help AW realise how seriously
'external' developpers are being hindered in producing applications
that can enhance the AW experience if these bugs do not get a priority
treatment.

And I do agree with the one who said that you not always need to be
able to reproduce a bug to fix it. In some cases (that's my own
experience), re-examining your code and using good logic can help you
find the bug, and fix it. A lot is a matter of what priorities you
have.

Alex

[View Quote] >Crossposted reply from SDK group
>
>--
>
>Gee.. shouldn't you post this kind of detailed info in the beta group
>where the people working on the code are?
>
[View Quote]

Dec 3, 2003, 8:16pm

PS - I hope they also invite you and a few of the other main third party
developers to participate in the 'alphas' too.

The more time you have to prepare for new things, and the more AW's
coders get to hear your feedback and insight, the better their product
will be as well as yours, and the more it will have to offer people who
have money they want to spend on VR toys.

Alpha, beta .. whatever it is labelled... I hope the top external developers
are asked to be involved :-)

[View Quote]

Dec 3, 2003, 8:23pm

[View Quote] We are talking about AWI here. Did you see who they picked for beta
testers a couple of times..?

--
--Bowen--
http://bowen.homelinux.com
Give me ideas.

Dec 3, 2003, 9:22pm

[View Quote]
> We are talking about AWI here. Did you see who they picked for beta
> testers a couple of times..?
>

Yeah - I see your name in the beta group posting :)

--
Andras
"It's MY computer" (tm Steve Gibson)

Dec 3, 2003, 9:31pm

I'm not against including anyone in betas including idiots. Idiots
should in fact be included in any kind of beta test since they will
quickly try all the stupid things that normal people would never try
to do and thus reveal where the programmer never thought they
needed to put code.

But regardless of what people are chosen to test new features
whether alpha or beta, I certainly think that the people who have
created 'add ons' for your product should be there without regard
for whatever other considerations you apply.

[View Quote]

Dec 4, 2003, 12:44am

I know they picked me 0_0 :-)

Go figure.

j/k iv reported a cpl errors already :-)
[View Quote]

Dec 4, 2003, 5:20am

[View Quote] Mhmm.. I seem to remember posting numerous amounts of bug reports in
comparison to present company. The small bugs are just as buggy as the
larger ones.

Oh wait, wasn't that me who helped Roland with one of the major bugs
that caused random crashes in 3.2, wait it was. I thought you
researched the things you talked about? You always tell us. Unless you
were joked, in which case I concede.

--
--Bowen--
http://bowen.homelinux.com
Give me ideas.

Dec 4, 2003, 5:21am

[View Quote] > I'm not against including anyone in betas including idiots. Idiots
> should in fact be included in any kind of beta test since they will
> quickly try all the stupid things that normal people would never try
> to do and thus reveal where the programmer never thought they
> needed to put code.
>
> But regardless of what people are chosen to test new features
> whether alpha or beta, I certainly think that the people who have
> created 'add ons' for your product should be there without regard
> for whatever other considerations you apply.

Not the idiots, just the really... retarded people.

--
--Bowen--
http://bowen.homelinux.com
Give me ideas.

1  |   Order by index