1  |   Order by index

Nov 25, 1998, 8:59am

I finally got my Delphi programme going <thanks, Canopus>, and
something puzzles me"

I have 3 bots, they log in in the following order:

1. [Dealph]
2. [Deaffer]
3. [VBird6]

They trap chat, avatar_add, avatar_change and avatar_delete. They
don't answer to chat/change, they only greet and say goodbye.

I, XelaG, session number 53429, leave and come back as "PPBot1",
session number 53705. The following is said by my bots:

[VBird6]: bye XelaG 53429 hi "PPBot1" 53705
[Deaffer]: bye [Delph] 53429 hi "PPBot1" 53705
[Delph]: bye [Deaffer] 53429 hi "PPBot1" 53705

They al say the correct session numbers, but [Deaffer] and [Delph] get
the names of the departing bots wrong: they name somebody who has said
a chat line recently: [Deaffer] names [Delph], who had said something
before my identity swap, [Delph] names [Deaffer], who just said
something. The last bot, [VBird6], always gets it right.

I now leave as "PPBot1", and instantly come back as XelaG. Same
happens:

[VBird6]: bye "PPBot1" 53705 hi XelaG 53709
[Deaffer]: bye [Delph] 53705 hi XelaG 53709
[Delph]: bye [Deaffer] 53705 hi XelaG 53709

What's up? Here's some of my code, can anyone enlighten me?

XelaG.

=======
Code etc.

My bots are kept in an array of records, botSlot(n).
What bots are to say is kept in a string, per bot, until it gets sent
in the timer-(aw_wait)-loop, once per second.
My event handlers look like this:

{ EVENT HANDLERS }
procedure evtChat;
var BtNr, BtInst, AvSession: Integer; AvName, AvMsg: String;
begin
{
uses AW_AVATAR_NAME ' string
AW_CHAT_MESSAGE ' string
AW_CHAT_TYPE ' long
AW_CHAT_SESSION ' long
}
AvName := String(aw_string(AW_AVATAR_NAME));
AvSession := aw_int(AW_CHAT_SESSION);
AvMsg := String(aw_string(AW_CHAT_MESSAGE));
BtInst := aw_instance;
BtNr := InstanceToBot(BtInst);
if BtNr < 0 then exit;

// I do nothing with this event yet

end;

procedure evtAvatarAdd;
var BtNr, BtInst, AvSession: Integer; AvName: String;
begin
{
uses AW_AVATAR_SESSION ' long
AW_AVATAR_NAME ' string
AW_AVATAR_X ' long
AW_AVATAR_Z ' long
AW_AVATAR_Y ' long
AW_AVATAR_YAW ' long
AW_AVATAR_TYPE ' long
AW_AVATAR_GESTURE ' long
}
AvName := String(aw_string(AW_AVATAR_NAME));
AvSession := aw_int(AW_AVATAR_SESSION);
BtInst := aw_instance;
BtNr := InstanceToBot(BtInst);
if BtNr < 0 then exit;
AddSay(BtNr, 'hi ' + AvName + ' ' + IntToStr(AvSession));
end;

procedure evtAvatarChange;
var BtNr, BtInst, AvSession: Integer; AvName: String;
begin
AvName := String(aw_string(AW_AVATAR_NAME));
AvSession := aw_int(AW_AVATAR_SESSION);
BtInst := aw_instance;
BtNr := InstanceToBot(BtInst);
if BtNr < 0 then exit;
// here also nothing yet
end;

procedure evtAvatarDelete;
var BtNr, BtInst, AvSession: Integer; AvName: String;
begin
AvName := String(aw_string(AW_AVATAR_NAME));
AvSession := aw_int(AW_AVATAR_SESSION);
BtInst := aw_instance;
BtNr := InstanceToBot(BtInst);
if BtNr < 0 then exit;
AddSay(BtNr, 'bye ' + AvName + ' ' + IntToStr(AvSession));
end;



{ }
Function InstanceToBot(i: Integer): Integer;
var b: Integer;
begin
Result := -1;
for b := 0 to MaxBot -1 do begin
if botSlot[b].Instance = i then begin
Result := b; exit;
end;
end;
end;

procedure AddSay(n: Integer; s: String);
var d: String;
begin
d := ' ';
with botSlot[n] do begin
if Say = '' then Say := s else Say := Say + d + s;
end;
end;

Nov 25, 1998, 9:44am

While I was posting, my bots carried on freaking in beta. This time,
trapping one event at a time, they had it right:
[Delph]: hi "Butch" 54010
[VBird6]: hi "Butch" 54010
[Deaffer]: hi "Butch" 54010
[VBird6]: bye "Butch" 54010
[Deaffer]: bye "Butch" 54010
[Delph]: bye "Butch" 54010

?

Nov 25, 1998, 2:02pm

There's a mysterious (global?) variable, Say, in AddSay: could it be
causing problems?

In akAWAPI. an instance is a pointer to an Integer, not an Integer; but I
don't see how that could be relevant here, since the session#'s are
correct.

In the later example, you say there is 'just one event' trapped? You mean
that here you trapped two events, one event right after the other, and all
bots witnessed both of them?

[View Quote] > I finally got my Delphi programme going <thanks, Canopus>, and
> something puzzles me"
>
> I have 3 bots, they log in in the following order:
>
> 1. [Dealph]
> 2. [Deaffer]
> 3. [VBird6]
>
> They trap chat, avatar_add, avatar_change and avatar_delete. They
> don't answer to chat/change, they only greet and say goodbye.
>
> I, XelaG, session number 53429, leave and come back as "PPBot1",
> session number 53705. The following is said by my bots:
>
> [VBird6]: bye XelaG 53429 hi "PPBot1" 53705
> [Deaffer]: bye [Delph] 53429 hi "PPBot1" 53705
> [Delph]: bye [Deaffer] 53429 hi "PPBot1" 53705
>
> They al say the correct session numbers, but [Deaffer] and [Delph] get
> the names of the departing bots wrong: they name somebody who has said
> a chat line recently: [Deaffer] names [Delph], who had said something
> before my identity swap, [Delph] names [Deaffer], who just said
> something. The last bot, [VBird6], always gets it right.
>
> I now leave as "PPBot1", and instantly come back as XelaG. Same
> happens:
>
> [VBird6]: bye "PPBot1" 53705 hi XelaG 53709
> [Deaffer]: bye [Delph] 53705 hi XelaG 53709
> [Delph]: bye [Deaffer] 53705 hi XelaG 53709
>
> What's up? Here's some of my code, can anyone enlighten me?
>
> XelaG.
>
> =======
> Code etc.
>
> My bots are kept in an array of records, botSlot(n).
> What bots are to say is kept in a string, per bot, until it gets sent
> in the timer-(aw_wait)-loop, once per second.
> My event handlers look like this:
>
> { EVENT HANDLERS }
> procedure evtChat;
> var BtNr, BtInst, AvSession: Integer; AvName, AvMsg: String;
> begin
> {
> uses AW_AVATAR_NAME ' string
> AW_CHAT_MESSAGE ' string
> AW_CHAT_TYPE ' long
> AW_CHAT_SESSION ' long
> }
> AvName := String(aw_string(AW_AVATAR_NAME));
> AvSession := aw_int(AW_CHAT_SESSION);
> AvMsg := String(aw_string(AW_CHAT_MESSAGE));
> BtInst := aw_instance;
> BtNr := InstanceToBot(BtInst);
> if BtNr < 0 then exit;
>
> // I do nothing with this event yet
>
> end;
>
> procedure evtAvatarAdd;
> var BtNr, BtInst, AvSession: Integer; AvName: String;
> begin
> {
> uses AW_AVATAR_SESSION ' long
> AW_AVATAR_NAME ' string
> AW_AVATAR_X ' long
> AW_AVATAR_Z ' long
> AW_AVATAR_Y ' long
> AW_AVATAR_YAW ' long
> AW_AVATAR_TYPE ' long
> AW_AVATAR_GESTURE ' long
> }
> AvName := String(aw_string(AW_AVATAR_NAME));
> AvSession := aw_int(AW_AVATAR_SESSION);
> BtInst := aw_instance;
> BtNr := InstanceToBot(BtInst);
> if BtNr < 0 then exit;
> AddSay(BtNr, 'hi ' + AvName + ' ' + IntToStr(AvSession));
> end;
>
> procedure evtAvatarChange;
> var BtNr, BtInst, AvSession: Integer; AvName: String;
> begin
> AvName := String(aw_string(AW_AVATAR_NAME));
> AvSession := aw_int(AW_AVATAR_SESSION);
> BtInst := aw_instance;
> BtNr := InstanceToBot(BtInst);
> if BtNr < 0 then exit;
> // here also nothing yet
> end;
>
> procedure evtAvatarDelete;
> var BtNr, BtInst, AvSession: Integer; AvName: String;
> begin
> AvName := String(aw_string(AW_AVATAR_NAME));
> AvSession := aw_int(AW_AVATAR_SESSION);
> BtInst := aw_instance;
> BtNr := InstanceToBot(BtInst);
> if BtNr < 0 then exit;
> AddSay(BtNr, 'bye ' + AvName + ' ' + IntToStr(AvSession));
> end;
>
> { }
> Function InstanceToBot(i: Integer): Integer;
> var b: Integer;
> begin
> Result := -1;
> for b := 0 to MaxBot -1 do begin
> if botSlot[b].Instance = i then begin
> Result := b; exit;
> end;
> end;
> end;
>
> procedure AddSay(n: Integer; s: String);
> var d: String;
> begin
> d := ' ';
> with botSlot[n] do begin
> if Say = '' then Say := s else Say := Say + d + s;
> end;
> end;

Nov 25, 1998, 2:12pm

A Delphi string that is passed to the API can behave badly if you try to reuse
the same string variable after the API returns it again, especially if you
then proceed to add to it.

[View Quote] > There's a mysterious (global?) variable, Say, in AddSay: could it be
> causing problems?
>
> In akAWAPI. an instance is a pointer to an Integer, not an Integer; but I
> don't see how that could be relevant here, since the session#'s are
> correct.
>
> In the later example, you say there is 'just one event' trapped? You mean
> that here you trapped two events, one event right after the other, and all
> bots witnessed both of them?
>
[View Quote]

Nov 25, 1998, 4:44pm

On Wed, 25 Nov 1998 11:02:40 -0500, Canopus <aek2 at ix.netcom.com>
[View Quote] >There's a mysterious (global?) variable, Say, in AddSay: could it be
>causing problems?
'Say' belongs to the record type roBot. I use an array of roBot,
botSlot[] that allows up to 10 bots, I use 3. 'Say' has global scope.
I dont think that's the problem.

type roBot = Record
BotNumber : Integer; (* was Number *)
CitizenNumber : Integer; (* was LoginOwner *)
PrivilegePassword : String;
BotName : String; (* was Caption *)
SavePPW : Boolean;
Instance : Integer;
LoginUniverse: Boolean;
LoginWorld : Boolean;
World : String;
NS : Integer;
WE : Integer;
Altitude : Integer;
Rotation : Integer;
Avatar : Integer;
Gesture : Integer;
GestureTime : Integer;
GestureSay : String;
Say : String;
SendWaiting : Boolean;
MotionType : Integer;
MotionNS : Integer;
MotionWE : Integer;
MotionAltitude : Integer;
MotionRadiusH : Integer;
MotionRadiusV : Integer;
MotionStepH : Integer;
MotionStepV : Integer;
end;

....
var
botSlot: array[0..10] of roBot;
....

>
>In akAWAPI. an instance is a pointer to an Integer, not an Integer; but I
>don't see how that could be relevant here, since the session#'s are
>correct.

I have changed that, instance is now an Integer. I saw no reason to
type it as a pointer, does not refer to a location in memory anyway.
The change I made in akAWAPI.pas is:

type
// AWhInst = Pointer;
AWhInst = Integer;
PAWhInst = ^AWhInst;
AWEventProc = procedure;
AWCallbackProc = procedure(rc : Integer);

I create the bot like this:
c := nil;
rc := aw_create(c, 0, at botSlot[n].Instance);

For selecting the bot:

Function SelectBot(n: Integer): Integer;
begin
Result := aw_instance_set(botSlot[n].Instance);
end;

For reading the instance number (BtInst is Integer):
BtInst := aw_instance;

This seems to work very well. It works both ways, I think, because
Pointer in a generic type, here I think a 32-bit one, and Integer
behaves also as a 32 bit location.

>In the later example, you say there is 'just one event' trapped? You mean
>that here you trapped two events, one event right after the other, and all
>bots witnessed both of them?
When I leave and reappear, there is only a fraction of a second
involved. The timer loop does not have the opportunity to empty 'Say'
before the 2nd event occurst for the same bot: you see that Say
contains the result of 2 events trapped: bye XelaG 53429 hi "PPBot1"
53705.

In the second case, "Butch" is recorded once per line.

It's obviously more complex than that: 3 events are are triggered for
each happening, one for each bot, and they trigger themselves more
events for their neighbours by chatting. So actually when i disappear
and reappear, 2x3 avatar events + at least 2x3 chat events are
triggered.

Yet this was only an example of what happens when more events happen
at the same time. I was testing this in Beta for hours with someone
else and his bot, and the situation was sometimes hilarious, my bots
(except for VBird6) getting totally confused on who was coming,
staying or leaving.
>
[View Quote]

Nov 25, 1998, 4:46pm

I'll have to meditate on this one.

Nov 25, 1998, 10:39pm

Maybe you could eliminate the string-exchanges as a source of the
problem by introducing a second string variable, and not trying to
concatenate to an already-exchanged string (Say1 and Say 2, rather than
Say alone).

Are the two error-prone bots always repeating something they said
previously? over and over? (that would indicate string-exchange
problems)? Or does they just choose a Name (for Say) randomly?

Also try the technique of doing a double cast to get rid of the
C-inserted end-of-string marker (especially if the bots have consistent
errors): String(PChar(Say)).

[View Quote] > I'll have to meditate on this one.

Nov 25, 1998, 11:08pm

On Wed, 25 Nov 1998 19:39:04 -0500, Canopus <aek2 at ix.netcom.com>
[View Quote] >Maybe you could eliminate the string-exchanges as a source of the
>problem by introducing a second string variable, and not trying to
>concatenate to an already-exchanged string (Say1 and Say 2, rather than
>Say alone).
I'll have to check this, but ...

>
>Are the two error-prone bots always repeating something they said
>previously? over and over? (that would indicate string-exchange
>problems)? Or does they just choose a Name (for Say) randomly?
No, they are not. In fact, in the whole 'Say' string, the ONLY error
is in the substring extracted at the event handler for the departing
avatar from AW_AVATAR_NAME: the first part is ok, from a litteral
'bye', then the wrong name, then the right session number extracted in
the same event handler and casted as string. Therefore methinks the
error is either in the dll, or in the process previous to the making
of the final 'Say' string. The 'Say' string has, in my opinion,
nothing to do with the error.

>
>Also try the technique of doing a double cast to get rid of the
>C-inserted end-of-string marker (especially if the bots have consistent
>errors): String(PChar(Say)).
As I said before, I'll have to meditate on this one, in fact, I'll
try this now, but not for poor 'Say' which is taking the blame: I'm
sure the error originates earlier.


hmm. XelaG

Nov 25, 1998, 11:21pm

Pretty convincing reasoning. Same kind of problem (AvName wrong) if you set
it up so that the Delete event is second?

[View Quote] > On Wed, 25 Nov 1998 19:39:04 -0500, Canopus <aek2 at ix.netcom.com>
[View Quote]

Nov 26, 1998, 2:58pm

Canopus, I've tried different combinations of recastings and other
trics, without success. Here is a rather different output of the
browser. The order of loading is still
1. [Delph]
2. [Deaffer]
3. [Deaf]
Within one timer cycle, the same order applies for sending the pending
messages.
Installed event handlers for chat and the 3 avatar (add, change,
delete). Only add and delete actually used, they add or record the
information to a string called botSlot[n].Say , where n=<bot number>.
This string is periodically checked in the timer loop (every 1000
millisecs), and sent to the dll.

I use two counters, one to track the recordings, one tracks the
sendings. The new data included here are
(a) the recording order, that is, when the event was added to the
existing 'Say' string / the send state i.e. how many messages have
been sent: [rec1/lastsent0], [rec2/lastsent1] etc. Notice one message
can have more than one [rec#/lastsent#] pair. The [/lastsent#]
corresponds exactly to the sending order in (b), same counter.
(b) the sending order: [send1], [send2] etc.
(c) 'hi' or 'bye' indicating the event handler
(d) the name from AW_AVATAR_NAME
(e) the session number from AW_AVATAR_SESSION
(f) the order these messages appeared in my browser
(g) my comments later in {}
For the sake of clarity, I edited the line layout.

Note here that the error ALLWAYS occurs in the delete event,
and its ALLWAYS the 2nd and 3rd bot getting this event that have
the wrong name, and they ALLWAYS have it wrong. The order in which the
browser shows the message doesn't reflect the order in which the
messages were sent to the dll.


- {present: XelaG, amuse, loading Delph}
[Delph]: [send1]
[rec1/lastsent0] hi amuse 51173
[rec2/lastsent0] hi XelaG 52278

- {loading Deaffer}
[Delph]: [send3]
[rec6/lastsent2] hi [Deaffer] 52290
[Deaffer]: [send2]
[rec3/lastsent1] hi amuse 51173
[rec4/lastsent1] hi [Delph] 52283
[rec5/lastsent1] hi XelaG 52278
XelaG: hi

- {loading VBird6}
[Deaffer]: [send6]
[rec11/lastsent4] hi [VBird6] 52300
[VBird6]: [send4]
[rec7/lastsent3] hi amuse 51173
[rec8/lastsent3] hi [Delph] 52283
[rec9/lastsent3] hi [Deaffer] 52290
[rec10/lastsent3] hi XelaG 52278
[Delph]: [send5]
[rec12/lastsent4] hi [VBird6] 52300

- {XelaG 52278 leaves, "TXelaG" 52311 enters}
[Deaffer]: [send8]
[rec15/lastsent6] bye [VBird6] 52278
[rec17/lastsent6] hi "TXelaG" 52311
[Delph]: [send7]
[rec16/lastsent6] bye [VBird6] 52278
[rec18/lastsent6] hi "TXelaG" 52311
[VBird6]: [send9]
[rec13/lastsent6] bye XelaG 52278
[rec14/lastsent6] hi "TXelaG" 52311
- {VBird, the last bot loaded, has XelaG's departure right.
he gets the add and delete events before the other two bots.
Deaffer gets the delete event with the WRONG name,
Delph gets the delete event with the WRONG name,
Deaffer and Delph get the add events correctly.
The messages from the 3 bots get sent to the dll, probably
in one and the same timer cycle, after all events get recorded.}

- {"TXelaG" leaves, XelaG reappears. Similar scenario,
except that VBird6's message gets sent BEFORE Deaffer and Delph
get either event}
[VBird6]: [send10]
[rec19/lastsent9] bye "TXelaG" 52311
[rec20/lastsent9] hi XelaG 52319
[Deaffer]: [send12]
[rec21/lastsent10] bye [VBird6] 52311
[rec23/lastsent10] hi XelaG 52319
[Delph]: [send11]
[rec22/lastsent10] bye [VBird6] 52311
[rec24/lastsent10] hi XelaG 52319
XelaG: changing

- {XelaG leaves, "TXelaG" reappears. Similar to previous}
[Deaffer]: [send15]
[rec28/lastsent13] bye [VBird6] 52319
[rec30/lastsent13] hi "TXelaG" 52330
[VBird6]: [send13]
[rec25/lastsent12] bye XelaG 52319
[rec26/lastsent12] hi "TXelaG" 52330
[Delph]: [send14]
[rec27/lastsent13] bye [VBird6] 52319
[rec29/lastsent13] hi "TXelaG" 52330
"TXelaG": back to citizen

- {"TXelaG" leaves, XelaG comes back. Slight variation:
VBird6 and Delph get the delete event,
again: VBird6 has the name right, Delph has it WRONG.
Then they both get the add event, and send their messages.
Deaffer the gets his add and delete events,
again gets the add name WRONG. He then sends his message.}
[Delph]: [send16]
[rec32/lastsent15] bye [VBird6] 52330
[rec34/lastsent15] hi XelaG 52338
[Deaffer]: [send18]
[rec35/lastsent17] bye [VBird6] 52330
[rec36/lastsent17] hi XelaG 52338
[VBird6]: [send17]
[rec31/lastsent15] bye "TXelaG" 52330
[rec33/lastsent15] hi XelaG 52338

Nov 26, 1998, 4:04pm

Removed all event handlers except for avatar_delete.
a > indicates the 1st bot to catch the event
a & indicates the right name
Bots loaded in the same order as previously:
Delph, Deaffer, VBird6

- {reloded all bots}
[VBird6]: >& [send3] [rec1/lastsent0] bye XelaG 53814
[Deaffer]: [send2] [rec2/lastsent0] bye 53814
[Delph]: [send1] [rec3/lastsent0] bye 53814

[VBird6]: >& [send6] [rec4/lastsent3] bye "TXelaG" 53978
[Deaffer]: [send5] [rec5/lastsent3] bye 53978
[Delph]: [send4] [rec6/lastsent3] bye 53978

[Delph]: [send7] [rec9/lastsent6] bye 53983
[VBird6]: >& [send9] [rec7/lastsent6] bye XelaG 53983
[Deaffer]: [send8] [rec8/lastsent6] bye 53983

[VBird6]: >& [send12] [rec10/lastsent9] bye "TXelaG" 53989
[Deaffer]: [send11] [rec11/lastsent9] bye 53989
[Delph]: [send10] [rec12/lastsent9] bye 53989

- {closed all, reopened and relogged bots}
[Deaffer]: >& [send1] [rec1/lastsent0] bye XelaG 54149
[Delph]: [send2] [rec3/lastsent1] bye 54149
[VBird6]: [send3] [rec2/lastsent1] bye 54149

[Deaffer]: > [send5] [rec5/lastsent3] bye XelaG 54206
[Delph]: [send4] [rec6/lastsent3] bye 54206
[VBird6]: & [send6] [rec4/lastsent3] bye "TXelaG" 54206

[Delph]: [send7] [rec9/lastsent6] bye 54211
[VBird6]: >& [send9] [rec7/lastsent6] bye XelaG 54211
[Deaffer]: & [send8] [rec8/lastsent6] bye XelaG 54211

[VBird6]: >& [send11] [rec10/lastsent9] bye "TXelaG" 54219
[Delph]: [send10] [rec11/lastsent9] bye 54219
[Deaffer]: [send12] [rec12/lastsent11] bye XelaG 54219

Its plain that allmost allways - not allways - the first to get the
event is right,

Some names are empty strings

Some have the wrong name...

When avatar_add event was trapped, no names were left empty

GO FIGURE..................

Nov 26, 1998, 7:27pm

Xelag

I remember Roland explaining that the aw.dll does some caching of names in
order to allways have it available for aw_string(AW_AVATAR_NAME). The server
usually does only give session numbers, and people trying to use
aw_string(AW_AVATAR_NAME) anyway caused the SDK change so that the name is .

which means your code should function right, a similar one in c++ works for
me.

if i remember correctly, the server supplies the name only for the "add"
event. so if you would get the names there right, you could build your own
session<->name mapping for everything else.
that might explain that you don't get the names when you don't even have a
"add" event.

so it might help having an add event, which puts the mapping
sessionid<->avatarname into a list, and all the other function only take the
session id and resolve it to a name using that list.

this should be done internally by aw.dll and its odd that this seems to be
disabled somehow when used by Delphi.

Did i mention this might have been the time for you to look into c++ ? (just
kidding :) )

Walter

Nov 26, 1998, 11:10pm

Thanks, Walter.

Yes, you did try to recruit me earlier on ;o)

In all but the last test, I did have the add event enabled. A few
hours ago, in desperation, I decided to ignore all AW_AVATAR_NAMEs
except for the ones provided by the avatar_add event. For each bot I
built a database mapping <session number> -- <avatar name> at the add
event, and removed the item after the delete event. When I
teleport/loggin to a world, I restarted the database. It works. I wish
this had been made clearer from the start, I wasted 2 f***ing days!
There's no need for the dll to cache names anyway if it won't work
(that's why I don't use my provider's proxy, it stinks).

Just curious, but: what about the chat event? Any known restrictions
for multiple instances? I'm starting on that trail soon, don't want to
waste time.

BTW, when you tested this
>this should be done internally by aw.dll and its odd that this seems to be
>disabled somehow when used by Delphi.
were you using multiple bot instances? I don't think it's a Delphi
problem, but I can't be sure. The fact is that ONE of the bots seems
to allways have it right with the name in the delete event, but WHICH
is not predictable: it's ususally, but not allways, the one getting
the delete event first, as far as my tests are reliable. Anyway, I'm
tired of this, I've filled this ng with 1% of my tests, and it's still
unclear. For me, a non-feature of the dll that has not been properly
tested or documented for multiple instances. I've seen worse (what
about JBuilder2, paid $$$ for it, crashes all the time?).

Thanks for the patience you all had to excercise.

On Thu, 26 Nov 1998 22:27:57 +0100, "Walter Knupe" <wak at faber.ping.de>
[View Quote] >Xelag
>
>I remember Roland explaining that the aw.dll does some caching of names in
>order to allways have it available for aw_string(AW_AVATAR_NAME). The server
>usually does only give session numbers, and people trying to use
>aw_string(AW_AVATAR_NAME) anyway caused the SDK change so that the name is .
>
>which means your code should function right, a similar one in c++ works for
>me.
>
>if i remember correctly, the server supplies the name only for the "add"
>event. so if you would get the names there right, you could build your own
>session<->name mapping for everything else.
>that might explain that you don't get the names when you don't even have a
>"add" event.
>
>so it might help having an add event, which puts the mapping
>sessionid<->avatarname into a list, and all the other function only take the
>session id and resolve it to a name using that list.
>
>this should be done internally by aw.dll and its odd that this seems to be
>disabled somehow when used by Delphi.
>
>Did i mention this might have been the time for you to look into c++ ? (just
>kidding :) )
>
>Walter
>
>
>
>

Nov 27, 1998, 3:01pm

XelaG schrieb in Nachricht <365df383.41411146 at news.activeworlds.com>...
>Thanks, Walter.
>
>Yes, you did try to recruit me earlier on ;o)
>
>There's no need for the dll to cache names anyway if it won't work
>(that's why I don't use my provider's proxy, it stinks).

Well, the dll name cache does work for everyone else, so it is usefull (at
least for me :) )
I wonder when the aw.dll decides to purge its name cache. it seems that
Delphi triggers that somehow.

>
>Just curious, but: what about the chat event? Any known restrictions
>for multiple instances? I'm starting on that trail soon, don't want to
>waste time.

Not that i know of. In your place i just would assume that AW_AVATAR_NAME
does not work there as well.

>
>BTW, when you tested this
>were you using multiple bot instances? I don't think it's a Delphi
>problem, but I can't be sure. The fact is that ONE of the bots seems
>to allways have it right with the name in the delete event, but WHICH
>is not predictable: it's ususally, but not allways, the one getting
>the delete event first, as far as my tests are reliable. Anyway, I'm
>tired of this, I've filled this ng with 1% of my tests, and it's still
>unclear. For me, a non-feature of the dll that has not been properly
>tested or documented for multiple instances. I've seen worse (what
>about JBuilder2, paid $$$ for it, crashes all the time?).

Yes i did it with multiple bots. I never observed a problem so therefore i
didn't test it into that detail as you did. maybe there is some kind of
problem, you never know...

Nov 28, 1998, 9:46pm

In the early thread on AW_EVENT_CHAT (9/16/98), Roland says that, after Build 5,
AW_AVATAR_NAME should be defined for AW_EVENT_AVATAR_ADD, AW_EVENT_AVATAR_CHANGE,
AW_EVENT_AVATAR_DELETE, and AW_EVENT_CHAT. The reference to caching all strings
is possibly the one in the Dialog Based Bot (10/14/98) where Roland says the SDK
always makes its own copies of everything, including strings. This is the only
known case where a Delphi event handler seemingly isn't receiving strings from
the API correctly, and your tests are surely exhaustive (as well as exhausting).

[View Quote] > Thanks, Walter.
>
> Yes, you did try to recruit me earlier on ;o)
>
> In all but the last test, I did have the add event enabled. A few
> hours ago, in desperation, I decided to ignore all AW_AVATAR_NAMEs
> except for the ones provided by the avatar_add event. For each bot I
> built a database mapping <session number> -- <avatar name> at the add
> event, and removed the item after the delete event. When I
> teleport/loggin to a world, I restarted the database. It works. I wish
> this had been made clearer from the start, I wasted 2 f***ing days!
> There's no need for the dll to cache names anyway if it won't work
> (that's why I don't use my provider's proxy, it stinks).
>
> Just curious, but: what about the chat event? Any known restrictions
> for multiple instances? I'm starting on that trail soon, don't want to
> waste time.
>
> BTW, when you tested this
> were you using multiple bot instances? I don't think it's a Delphi
> problem, but I can't be sure. The fact is that ONE of the bots seems
> to allways have it right with the name in the delete event, but WHICH
> is not predictable: it's ususally, but not allways, the one getting
> the delete event first, as far as my tests are reliable. Anyway, I'm
> tired of this, I've filled this ng with 1% of my tests, and it's still
> unclear. For me, a non-feature of the dll that has not been properly
> tested or documented for multiple instances. I've seen worse (what
> about JBuilder2, paid $$$ for it, crashes all the time?).
>
> Thanks for the patience you all had to excercise.
>
> On Thu, 26 Nov 1998 22:27:57 +0100, "Walter Knupe" <wak at faber.ping.de>
[View Quote]

Nov 28, 1998, 10:02pm

And in all cases at least one bot gets the correct string (in one case,
two bots do). Is the dll responding too quickly to the first DELETE
event (and calling for its copy of the string to be erased before it
should)?

[View Quote] > Removed all event handlers except for avatar_delete.
> a > indicates the 1st bot to catch the event
> a & indicates the right name
> Bots loaded in the same order as previously:
> Delph, Deaffer, VBird6
>
> - {reloded all bots}
> [VBird6]: >& [send3] [rec1/lastsent0] bye XelaG 53814
> [Deaffer]: [send2] [rec2/lastsent0] bye 53814
> [Delph]: [send1] [rec3/lastsent0] bye 53814
>
> [VBird6]: >& [send6] [rec4/lastsent3] bye "TXelaG" 53978
> [Deaffer]: [send5] [rec5/lastsent3] bye 53978
> [Delph]: [send4] [rec6/lastsent3] bye 53978
>
> [Delph]: [send7] [rec9/lastsent6] bye 53983
> [VBird6]: >& [send9] [rec7/lastsent6] bye XelaG 53983
> [Deaffer]: [send8] [rec8/lastsent6] bye 53983
>
> [VBird6]: >& [send12] [rec10/lastsent9] bye "TXelaG" 53989
> [Deaffer]: [send11] [rec11/lastsent9] bye 53989
> [Delph]: [send10] [rec12/lastsent9] bye 53989
>
> - {closed all, reopened and relogged bots}
> [Deaffer]: >& [send1] [rec1/lastsent0] bye XelaG 54149
> [Delph]: [send2] [rec3/lastsent1] bye 54149
> [VBird6]: [send3] [rec2/lastsent1] bye 54149
>
> [Deaffer]: > [send5] [rec5/lastsent3] bye XelaG 54206
> [Delph]: [send4] [rec6/lastsent3] bye 54206
> [VBird6]: & [send6] [rec4/lastsent3] bye "TXelaG" 54206
>
> [Delph]: [send7] [rec9/lastsent6] bye 54211
> [VBird6]: >& [send9] [rec7/lastsent6] bye XelaG 54211
> [Deaffer]: & [send8] [rec8/lastsent6] bye XelaG 54211
>
> [VBird6]: >& [send11] [rec10/lastsent9] bye "TXelaG" 54219
> [Delph]: [send10] [rec11/lastsent9] bye 54219
> [Deaffer]: [send12] [rec12/lastsent11] bye XelaG 54219
>
> Its plain that allmost allways - not allways - the first to get the
> event is right,
>
> Some names are empty strings
>
> Some have the wrong name...
>
> When avatar_add event was trapped, no names were left empty
>
> GO FIGURE..................

Nov 30, 1998, 3:45am

The behavior of AW_EVENT_AVATAR_DELETE is suspicious. I did a program
that had 3 bots, with nothing but a DELETE handler, and the same thing
happened: the handler would get the bot instance and the session number
correctly, but the AVATAR_NAME was lost after the first (or occasionally
the second) event. Then I added AW_EVENT_AVATAR_CHANGE, and all went
smoothly (with some timely advice from XelaG): the 3 bots all used the
correct AVATAR_NAME. In fact, once I did a CHANGE before a DELETE, the
problem with AVATAR_NAME subsequently vanished; but if I started over,
with DELETE first, there was the same weird loss of AVATAR_NAME again,
until the first CHANGE event.What could that mean?

[View Quote] > Removed all event handlers except for avatar_delete.
> a > indicates the 1st bot to catch the event
> a & indicates the right name
> Bots loaded in the same order as previously:
> Delph, Deaffer, VBird6
>
> - {reloded all bots}
> [VBird6]: >& [send3] [rec1/lastsent0] bye XelaG 53814
> [Deaffer]: [send2] [rec2/lastsent0] bye 53814
> [Delph]: [send1] [rec3/lastsent0] bye 53814
>
> [VBird6]: >& [send6] [rec4/lastsent3] bye "TXelaG" 53978
> [Deaffer]: [send5] [rec5/lastsent3] bye 53978
> [Delph]: [send4] [rec6/lastsent3] bye 53978
>
> [Delph]: [send7] [rec9/lastsent6] bye 53983
> [VBird6]: >& [send9] [rec7/lastsent6] bye XelaG 53983
> [Deaffer]: [send8] [rec8/lastsent6] bye 53983
>
> [VBird6]: >& [send12] [rec10/lastsent9] bye "TXelaG" 53989
> [Deaffer]: [send11] [rec11/lastsent9] bye 53989
> [Delph]: [send10] [rec12/lastsent9] bye 53989
>
> - {closed all, reopened and relogged bots}
> [Deaffer]: >& [send1] [rec1/lastsent0] bye XelaG 54149
> [Delph]: [send2] [rec3/lastsent1] bye 54149
> [VBird6]: [send3] [rec2/lastsent1] bye 54149
>
> [Deaffer]: > [send5] [rec5/lastsent3] bye XelaG 54206
> [Delph]: [send4] [rec6/lastsent3] bye 54206
> [VBird6]: & [send6] [rec4/lastsent3] bye "TXelaG" 54206
>
> [Delph]: [send7] [rec9/lastsent6] bye 54211
> [VBird6]: >& [send9] [rec7/lastsent6] bye XelaG 54211
> [Deaffer]: & [send8] [rec8/lastsent6] bye XelaG 54211
>
> [VBird6]: >& [send11] [rec10/lastsent9] bye "TXelaG" 54219
> [Delph]: [send10] [rec11/lastsent9] bye 54219
> [Deaffer]: [send12] [rec12/lastsent11] bye XelaG 54219
>
> Its plain that allmost allways - not allways - the first to get the
> event is right,
>
> Some names are empty strings
>
> Some have the wrong name...
>
> When avatar_add event was trapped, no names were left empty
>
> GO FIGURE..................

1  |   Order by index