1  2  3  |   Order by default

Nov 21, 1998, 12:06pm

1. BTW, I'm not sure if AW_AVATAR_SESSION refers to the bot or the
avatar, you also have AW_AVATAR_NAME, the login name of the avatar -
my bot is deaf in visual basic.

2. Can anyone clarify this: how do I know for which bot an event is
triggered? Supposing I have bots in different worlds, how do I know in
which world the trapped avatar is? If one can't use threads, one
should be able to identify a relation between event and bot, methinks.

XelaG

Nov 21, 1998, 7:01pm

This solves my dilema. My poor deaf bot doesn't want to know this, he
avoids all dangerous talks with the dll.... Thanks.

About session numbers for bots, although I can't test this yet, seems
illogical they shouln't have one: they would not be able to track
bots, only citizens and tourists... One can also track by name, but
seeing so many BBot0's and BBot1's around, my bot might get
confused...

XelaG

On Sat, 21 Nov 1998 12:29:48 -0500, Canopus <aek2 at ix.netcom.com>
[View Quote] >You can tell which instance an event is for by calling aw_instance.
>
[View Quote]

Nov 21, 1998, 7:29pm

Don't you get an error message in rc = aw_state_change() ?

On Sat, 21 Nov 1998 17:51:38 +0100, "Walter Knupe" <wak at faber.ping.de>
[View Quote] >It never rejected a positon change for me, and i errorneously had tests
>running with 100 changes a second. i guess it discards them or does not
>propagate them to other people, but it does not reject them.
>
>Walter
>
>
>XelaG schrieb in Nachricht <3658c338.2969219 at news.activeworlds.com>...
>

Nov 24, 1998, 7:17pm

MEHEHEHEHE, MEHEHEHEH...

[imabot] [imabot]

[imabot]
[imabot] [imabot]

[imabot]

[imabot]

[imabot]











lol

Nov 24, 1998, 7:30pm

Roland, could you mention from version to version if the bulk of the h
file has changed, besides the buid number, and which changes have been
made? Its a hassle for non-C programmers to check it every time in
case one has to do a new translation of some lost line in the file...
;o)

XelaG.


On Tue, 24 Nov 1998 00:44:36 -0800, "Roland Vilett" <roland at lmi.net>
[View Quote] >Hi everyone,
>
>I have just uploaded Build 10 of the SDK. This build fixes another memory
>leak (hopefully that will be the last of those!) and also fixes a bug where
>the callback AW_CALLBACK_OBJECT_RESULT sent back the wrong return code value
>if an asynchronous building operation failed.
>
>Please upgrade at your earliest convenience.
>
>-Roland
>
>

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, 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, 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 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, 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
>
>
>
>

Dec 20, 1998, 2:40am

On Sat, 19 Dec 1998 21:53:23 -0500, "news.sirus.net"
[View Quote] You should have your dll in the same directory as your programme or in
the path. I have mine in winnt\system32. Btw, where can you get that
dll? . XelaG.

>I downloaded the AwSdkVB.Dll and the sample GreeterBot but my visual basic
>cant find the Dll when I try to run the prog. It might be that i have VB6,
>i'm running Windows NT, or its just plain screwey. Could somebody help me
>with this?
>
[View Quote]

Dec 1, 1998, 2:33pm

I installed AW_CALLBACK_CITIZEN_ATTRIBUTES as:
rc := aw_kallback_set(AW_CALLBACK_CITIZEN_ATTRIBUTES,
at cbkCitizenAttributes);

The callback routine starts so:
procedure cbkCitizenAttributes(rc: Integer);

When I test rc in this routine, I allways get a constant number (it
only varies if I restart the program), never zero. So I can't know
whether there is an error or not. For example: If I ask for, say, the
valid citnum of COF, I get 1, as expected, and rc = 4376872. If I then
ask for the citnum of non-existant HJHJHJHJHJHJHJHJH, I get the
previous values again: COF and 1, and rc = 4376872.

Is this again a Delphi bug, a XelaG lack-of-knowledge, or am I missing
something important?

<whisper> I WON'T PUBLISH ALL MY TESTS HERE THIS TIME.....

NB: kallback is spelled so on purpose. I use Canopus' akAWAPI.

XelaG

Dec 3, 1998, 3:28am

For collectors of AW SDK Delphi paraphernalia, here's a cut-and-paste
list of ascii characters ;o)


const RC_SUCCESS = 0;
const RC_CITIZENSHIP_EXPIRED = 1;
const RC_NO_SUCH_CITIZEN = 3;
const RC_MESSAGE_LENGTH_BAD = 4;
const RC_LICENSE_PASSWORD_CONTAINS_SPACE = 5;
const RC_LICENSE_PASSWORD_TOO_LONG = 6;
const RC_LICENSE_PASSWORD_TOO_SHORT = 7;
const RC_LICENSE_RANGE_TOO_LARGE = 8;
const RC_LICENSE_RANGE_TOO_SMALL = 9;
const RC_LICENSE_USERS_TOO_LARGE = 10;
const RC_LICENSE_USERS_TOO_SMALL = 11;
const RC_LICENSE_WORLD_CONTAINS_SPACE = 12;
const RC_INVALID_PASSWORD = 13;
const RC_UNABLE_TO_MAIL_BACK_NUMBER = 14;
const RC_LICENSE_WORLD_TOO_SHORT = 15;
const RC_LICENSE_WORLD_TOO_LONG = 16;
const RC_SERVER_OUT_OF_MEMORY = 17;
const RC_WORLD_NOT_RUNNING = 27;
const RC_NOT_LOGGED_IN = 31;
const RC_UNAUTHORIZED = 32;
const RC_ALREADY_LICENSED = 33;
const RC_NO_SUCH_LICENSE = 34;
const RC_IDENTITY_ALREADY_IN_USE = 39;
const RC_UNABLE_TO_REPORT_LOCATION = 40;
const RC_INVALID_EMAIL = 41;
const RC_NO_SUCH_ACTING_CITIZEN = 42;
const RC_ACTING_PASSWORD_INVALID = 43;
const RC_MUST_UPGRADE = 58;
const RC_BOT_LIMIT_EXCEEDED = 59;
const RC_EMAIL_CONTAINS_INVALID_CHAR = 100;
const RC_EMAIL_ENDS_WITH_BLANK = 101;
const RC_EMAIL_MISSING_DOT = 102;
const RC_EMAIL_MISSING_AT = 103;
const RC_EMAIL_STARTS_WITH_BLANK = 104;
const RC_EMAIL_TOO_LONG = 105;
const RC_EMAIL_TOO_SHORT = 106;
const RC_NAME_ALREADY_USED = 107;
const RC_NAME_CONTAINS_INVALID_CHAR = 108;
const RC_NAME_CONTAINS_INVALID_BLANK = 109;
const RC_NAME_DOESNT_EXIST = 110;
const RC_NAME_ENDS_WITH_BLANK = 111;
const RC_NAME_TOO_LONG = 112;
const RC_NAME_TOO_SHORT = 113;
const RC_NAME_UNUSED = 114;
const RC_PASSWORD_TOO_LONG = 115;
const RC_PASSWORD_TOO_SHORT = 116;
const RC_PASSWORD_IS_WRONG = 117;
const RC_PRIVILEGE_PASSWORD_IS_TOO_SHORT = 128;
const RC_NOT_CHANGE_OWNER = 203;
const RC_CANT_FIND_OLD_ELEMENT = 204;
const RC_CANT_CHANGE_OWNER = 211;
const RC_CANT_BUILD_HERE = 216;
const RC_ENCROACHES = 300;
const RC_NO_SUCH_OBJECT = 301;
const RC_NOT_DELETE_OWNER = 302;
const RC_TOO_MANY_BYTES = 303;
const RC_UNREGISTERED_OBJECT = 306;
const RC_ELEMENT_ALREADY_EXISTS = 308;
const RC_NO_BUILD_RIGHTS = 310;
const RC_OUT_OF_BOUNDS = 311;
const RC_RESTRICTED_OBJECT = 313;
const RC_RESTRICTED_AREA = 314;
const RC_OUT_OF_MEMORY = 400;
const RC_NOT_YET = 401;
const RC_TIMEOUT = 402;
const RC_NULL_POINTER = 403;
const RC_UNABLE_TO_CONTACT_UNIVERSE = 404;
const RC_UNABLE_TO_CONTACT_WORLD = 405;
const RC_INVALID_WORLD_NAME = 406;
const RC_SEND_FAILED = 415;
const RC_RECEIVE_FAILED = 416;
const RC_STREAM_EMPTY = 421;
const RC_STREAM_MESSAGE_TOO_LONG = 422;
const RC_WORLD_NAME_TOO_LONG = 423;
const RC_MESSAGE_TOO_LONG = 426;
const RC_UNABLE_TO_CONNECT = 429;
const RC_NO_CONNECTION = 439;
const RC_UNABLE_TO_INITIALIZE_NETWORK = 442;
const RC_INCORRECT_MESSAGE_LENGTH = 443;
const RC_NOT_INITIALIZED = 444;
const RC_NO_INSTANCE = 445;
const RC_OUT_BUFFER_FULL = 446;
const RC_INVALID_CALLBACK = 447;
const RC_INVALID_ATTRIBUTE = 448;
const RC_TYPE_MISMATCH = 449;
const RC_STRING_TOO_LONG = 450;
const RC_READ_ONLY = 451;
const RC_INVALID_INSTANCE = 453;
const RC_VERSION_MISMATCH = 454;
const RC_IN_BUFFER_FULL = 461;
const RC_PROTOCOL_ERROR = 463;
const RC_QUERY_IN_PROGRESS = 464;
const RC_EJECTED = 466;
const RC_NOT_WELCOME = 467;

Dec 3, 1998, 4:35am

Here's the Delphi Pascal file of the aw error codes: AwReasons. Put
it, just as you do akAWAPI, in your uses clause if you wish to use
these constants.

Dec 3, 1998, 4:35am

begin 644 AWReasons.pas
M=6YI="!!5U)E87-O;G,[#0H-"FEN=&5R9F%C90T*>R!!5RYD;&P at 17)R;W( at
M8V]D97-]#0H-"F-O;G-T(%)#7U-50T-%4U, at /2`P.PT*8V]N<W0 at 4D-?0TE4
M25I%3E-(25!?15A025)%1"`](#$[#0IC;VYS="!20U].3U]354-(7T-)5$E:
M14X at /2`S.PT*8V]N<W0 at 4D-?34534T%'15],14Y'5$A?0D%$(#T at -#L-"F-O
M;G-T(%)#7TQ)0T5.4T5?4$%34U=/4D1?0T].5$%)3E-?4U!!0T4 at /2`U.PT*
M8V]N<W0 at 4D-?3$E#14Y315]005-35T]21%]43T]?3$].1R`](#8[#0IC;VYS
M="!20U],24-%3E-%7U!!4U-73U)$7U1/3U]32$]25"`](#<[#0IC;VYS="!2
M0U],24-%3E-%7U)!3D=%7U1/3U],05)'12`](# at [#0IC;VYS="!20U],24-%
M3E-%7U)!3D=%7U1/3U]334%,3"`](#D[#0IC;VYS="!20U],24-%3E-%7U53
M15)37U1/3U],05)'12`](#$P.PT*8V]N<W0 at 4D-?3$E#14Y315]54T524U]4
M3T]?4TU!3$P at /2`Q,3L-"F-O;G-T(%)#7TQ)0T5.4T5?5T]23$1?0T].5$%)
M3E-?4U!!0T4 at /2`Q,CL-"F-O;G-T(%)#7TE.5D%,241?4$%34U=/4D0 at /2`Q
M,SL-"F-O;G-T(%)#7U5.04),15]43U]-04E,7T)!0TM?3E5-0D52(#T at ,30[
M#0IC;VYS="!20U],24-%3E-%7U=/4DQ$7U1/3U]32$]25"`](#$U.PT*8V]N
M<W0 at 4D-?3$E#14Y315]73U),1%]43T]?3$].1R`](#$V.PT*8V]N<W0 at 4D-?
M4T525D527T]55%]/1E]-14U/4ED at /2`Q-SL-"F-O;G-T(%)#7U=/4DQ$7TY/
M5%]254Y.24Y'(#T at ,C<[#0IC;VYS="!20U].3U1?3$]'1T5$7TE.(#T at ,S$[
M#0IC;VYS="!20U]53D%55$A/4DE:140 at /2`S,CL-"F-O;G-T(%)#7T%,4D5!
M1%E?3$E#14Y3140 at /2`S,SL-"F-O;G-T(%)#7TY/7U-50TA?3$E#14Y312`]
M(#,T.PT*8V]N<W0 at 4D-?241%3E1)5%E?04Q214%$65])3E]54T4 at /2`S.3L-
M"F-O;G-T(%)#7U5.04),15]43U]215!/4E1?3$]#051)3TX at /2`T,#L-"F-O
M;G-T(%)#7TE.5D%,241?14U!24P at /2`T,3L-"F-O;G-T(%)#7TY/7U-50TA?
M04-424Y'7T-)5$E:14X at /2`T,CL-"F-O;G-T(%)#7T%#5$E.1U]005-35T]2
M1%])3E9!3$E$(#T at -#,[#0IC;VYS="!20U]-55-47U501U)!1$4 at /2`U.#L-
M"F-O;G-T(%)#7T)/5%],24U)5%]%6$-%141%1"`](#4Y.PT*8V]N<W0 at 4D-?
M14U!24Q?0T].5$%)3E-?24Y604Q)1%]#2$%2(#T at ,3`P.PT*8V]N<W0 at 4D-?
M14U!24Q?14Y$4U]7251(7T),04Y+(#T at ,3`Q.PT*8V]N<W0 at 4D-?14U!24Q?
M34E34TE.1U]$3U0 at /2`Q,#([#0IC;VYS="!20U]%34%)3%]-25-324Y'7T%4
M(#T at ,3`S.PT*8V]N<W0 at 4D-?14U!24Q?4U1!4E137U=)5$A?0DQ!3DL at /2`Q
M,#0[#0IC;VYS="!20U]%34%)3%]43T]?3$].1R`](#$P-3L-"F-O;G-T(%)#
M7T5-04E,7U1/3U]32$]25"`](#$P-CL-"F-O;G-T(%)#7TY!345?04Q214%$
M65]54T5$(#T at ,3`W.PT*8V]N<W0 at 4D-?3D%-15]#3TY404E.4U])3E9!3$E$
M7T-(05( at /2`Q,# at [#0IC;VYS="!20U].04U%7T-/3E1!24Y37TE.5D%,241?
M0DQ!3DL at /2`Q,#D[#0IC;VYS="!20U].04U%7T1/15-.5%]%6$E35"`](#$Q
M,#L-"F-O;G-T(%)#7TY!345?14Y$4U]7251(7T),04Y+(#T at ,3$Q.PT*8V]N
M<W0 at 4D-?3D%-15]43T]?3$].1R`](#$Q,CL-"F-O;G-T(%)#7TY!345?5$]/
M7U-(3U)4(#T at ,3$S.PT*8V]N<W0 at 4D-?3D%-15]53E53140 at /2`Q,30[#0IC
M;VYS="!20U]005-35T]21%]43T]?3$].1R`](#$Q-3L-"F-O;G-T(%)#7U!!
M4U-73U)$7U1/3U]32$]25"`](#$Q-CL-"F-O;G-T(%)#7U!!4U-73U)$7TE3
M7U=23TY'(#T at ,3$W.PT*8V]N<W0 at 4D-?4%))5DE,14=%7U!!4U-73U)$7TE3
M7U1/3U]32$]25"`](#$R.#L-"F-O;G-T(%)#7TY/5%]#2$%.1T5?3U=.15( at
M/2`R,#,[#0IC;VYS="!20U]#04Y47T9)3D1?3TQ$7T5,14U%3E0 at /2`R,#0[
M#0IC;VYS="!20U]#04Y47T-(04Y'15]/5TY%4B`](#(Q,3L-"F-O;G-T(%)#
M7T-!3E1?0E5)3$1?2$5212`](#(Q-CL-"F-O;G-T(%)#7T5.0U)/04-(15, at
M/2`S,#`[#0IC;VYS="!20U].3U]354-(7T]"2D5#5"`](#,P,3L-"F-O;G-T
M(%)#7TY/5%]$14Q%5$5?3U=.15( at /2`S,#([#0IC;VYS="!20U]43T]?34%.
M65]"651%4R`](#,P,SL-"F-O;G-T(%)#7U5.4D5'25-415)%1%]/0DI%0U0 at
M/2`S,#8[#0IC;VYS="!20U]%3$5-14Y47T%,4D5!1%E?15A)4U13(#T at ,S`X
M.PT*8V]N<W0 at 4D-?3D]?0E5)3$1?4DE'2%13(#T at ,S$P.PT*8V]N<W0 at 4D-?
M3U547T]&7T)/54Y$4R`](#,Q,3L-"F-O;G-T(%)#7U)%4U1224-4141?3T)*
M14-4(#T at ,S$S.PT*8V]N<W0 at 4D-?4D535%))0U1%1%]!4D5!(#T at ,S$T.PT*
M8V]N<W0 at 4D-?3U547T]&7TU%34]262`](#0P,#L-"F-O;G-T(%)#7TY/5%]9
M150 at /2`T,#$[#0IC;VYS="!20U]424U%3U54(#T at -#`R.PT*8V]N<W0 at 4D-?
M3E5,3%]03TE.5$52(#T at -#`S.PT*8V]N<W0 at 4D-?54Y!0DQ%7U1/7T-/3E1!
M0U1?54Y)5D524T4 at /2`T,#0[#0IC;VYS="!20U]53D%"3$5?5$]?0T].5$%#
M5%]73U),1"`](#0P-3L-"F-O;G-T(%)#7TE.5D%,241?5T]23$1?3D%-12`]
M(#0P-CL-"F-O;G-T(%)#7U-%3D1?1D%)3$5$(#T at -#$U.PT*8V]N<W0 at 4D-?
M4D5#14E615]&04E,140 at /2`T,38[#0IC;VYS="!20U]35%)%04U?14U05%D at
M/2`T,C$[#0IC;VYS="!20U]35%)%04U?34534T%'15]43T]?3$].1R`](#0R
M,CL-"F-O;G-T(%)#7U=/4DQ$7TY!345?5$]/7TQ/3D< at /2`T,C,[#0IC;VYS
M="!20U]-15-304=%7U1/3U],3TY'(#T at -#(V.PT*8V]N<W0 at 4D-?54Y!0DQ%
M7U1/7T-/3DY%0U0 at /2`T,CD[#0IC;VYS="!20U].3U]#3TY.14-424].(#T at
M-#,Y.PT*8V]N<W0 at 4D-?54Y!0DQ%7U1/7TE.251)04Q)6D5?3D545T]22R`]
M(#0T,CL-"F-O;G-T(%)#7TE.0T]24D5#5%]-15-304=%7TQ%3D=42"`](#0T
M,SL-"F-O;G-T(%)#7TY/5%])3DE424%,25I%1"`](#0T-#L-"F-O;G-T(%)#
M7TY/7TE.4U1!3D-%(#T at -#0U.PT*8V]N<W0 at 4D-?3U547T)51D9%4E]&54Q,
M(#T at -#0V.PT*8V]N<W0 at 4D-?24Y604Q)1%]#04Q,0D%#2R`](#0T-SL-"F-O
M;G-T(%)#7TE.5D%,241?05144DE"551%(#T at -#0X.PT*8V]N<W0 at 4D-?5%E0
M15]-25--051#2"`](#0T.3L-"F-O;G-T(%)#7U-44DE.1U]43T]?3$].1R`]
M(#0U,#L-"F-O;G-T(%)#7U)%041?3TY,62`](#0U,3L-"F-O;G-T(%)#7TE.
M5D%,241?24Y35$%.0T4 at /2`T-3,[#0IC;VYS="!20U]615)324].7TU)4TU!
M5$-((#T at -#4T.PT*8V]N<W0 at 4D-?24Y?0E5&1D527T953$P at /2`T-C$[#0IC
M;VYS="!20U]04D]43T-/3%]%4E)/4B`](#0V,SL-"F-O;G-T(%)#7U%515)9
M7TE.7U!23T=215-3(#T at -#8T.PT*8V]N<W0 at 4D-?14I%0U1%1"`](#0V-CL-
M"F-O;G-T(%)#7TY/5%]714Q#3TU%(#T at -#8W.PT*#0II;7!L96UE;G1A=&EO
+; at T*#0IE;F0N#0I/
`
end

Dec 7, 1998, 11:38pm

Sure. If you install the event handler for AW_EVENT_AVATAR_ADD whith
aw_event_set(...), then, in the event handler,
aw_string(AW_AVATAR_NAME) gives you the name of the avatar when it is
detected by the bot. You can then ask for the citizen number of the
avatar using rc = aw_citizen_attributes_by_name(<name of avatar>).
This will return either:

(i) inmediately, then if rc = 0 you find the citizen number using
aw_int(AW_CITIZEN_NUMBER), if rc <> 0 then its not a citizen and the
values of aw_int and aw_string are worthless.

(ii) using a callback function. If you use callbacks, then make sure
you ask again for the citizen name with aw_string(AW_CITIZEN_NAME), to
make sure its the same name you sent. The advantage of the callback is
you dont have to wait for aw_citizen_attributes_by_name to return.

[View Quote] >Ok, I'm back...
>I have my bot stationed at a specific place in my own world. What he's
>SUPPOSED to do, is check the person's citizen number when they walk too
>close, and if it matches one of the numbers on the right's list, then it
>lets em pass, otherwise... ejection. My only problem is getting the bot
>to find the person's citizen number... anything i've tried so far has
>just resulted in a core dump of the program every time someone got too
>close...
>I need a way to get the bot to recognize citizen number of the avatar on
>approach. Not from the chat line, which is my problem. Anybody got a
>solution? or something close to it that would serve the same purpose is
>plenty well fine....

Dec 8, 1998, 3:12am

You dont get the avatar number (whats that?) from anywhere, Veleno.

You can retreive the Name and Session number directly from 3 places:
avatar_add,
avatar_change,
avatar_delete.

What you do with this information, which is volatile, is entirely up
to you. You can store it or use it immediately, as you wish. Its not
less volatile that the chatline, btw.

To get the citizen number, you need the Name of the avatar, obtained
from one of the 3 above mentioned places (or from the chatline). Those
3 places only 'exist' if you know how to install an event handler.
Then you have to ask the universe server for the citizen number
yourself, by sending the Name through an aw api call. There is no
other way.

The Session number is not a citizen number: it changes, for instance,
when the server is temporarily disconnected, or if an avatar relogs.

I hope this helps, good luck.

[View Quote] >I know about that already. My problem is not in getting it to recognize
>them... it's in getting their avatar number from the avatar_change(). Getting
>the number from the avatar_add() won't do me much good since it doesn't keep
>it. I have the ability to get the information out of the rights list about
>the citnums. and have gotten that to work successfully... (asking if the
>number is a PS or not, but from the chatline) what I need is for the bot to
>be able to do the same function, but not voiced by a third party. Anybody
>understand what I'm trying to say?
>
[View Quote]

Dec 9, 1998, 5:39am

Well, if i get it right this time, you could proceed as i pointed out
in my first answer for AW_EVENT_AVATAR_ADD: get
aw_string(AW_AVATAR_NAME) from AW_EVENT_AVATAR_CHANGE. That IS the
name of the avatar that caused the event by changing position or
something else. All 3 events mentioned in my 2nd posting, i.e.
avatar_add,
avatar_change,
avatar_delete.
give you access to the SAME TYPE of information, only on different
occasions:

(language: Delphi Pascal)
AvName := aw_string(AW_AVATAR_NAME); // <-- NAME.
AvSession := aw_int(AW_AVATAR_SESSION); // For which bot.
AvNS := aw_int(AW_AVATAR_Z); // Coords of
AvWE := aw_int(AW_AVATAR_X); // avatar.
AvAltitude := aw_int(AW_AVATAR_Y);
AvRotation := aw_int(AW_AVATAR_YAW);
AvAvatar := aw_int(AW_AVATAR_TYPE); // Appearence.
AvGesture := aw_int(AW_AVATAR_GESTURE); // Gesture.

The API reference is unclear, states these attributes only for
avatar_add. Took me a while to figure out.

Hope this helps. XelaG.

[View Quote] >Sorry if I was a bit confusing XelaG. I am well aware the properties of the
>session number. what I meant by the 'avatar number' was the citizen's number. It
>wouldn't do me much good to just have the value of their citizen number stored in
>a variable from the avatar_add event. What I really need is to get the
>avatar_change to see the avatar's name and then I can call the event to get the
>number, already.
>
[View Quote]

Dec 9, 1998, 5:50am

Rectification:

BtInst := aw_instance; // For which bot
AvSession := aw_int(AW_AVATAR_SESSION); // Session number of avatar

Sorry for the confusion ;o)

Dec 14, 1998, 5:49pm

Not quite, Ima Genius. Some 2.0 worlds have no problems whatsoever
welcoming SDK bots. Try Jurasico, for instance, or the trial worlds.
Other 2.0 worlds require caretaker privileges, others (the majority, I
think) can't accept SDKs at all. I might be wrong about this last bit,
though, maybe you need caretaker privileges in those worlds too. It's
a mystery to me, there doesn't seem to be a logic behind it. Rumors
say that 2.0 worlds built from scratch - not upgraded - don't have
problems with SDK. I wish someone could explain this, it's very
frustrating building bots that go nowhere.

XelaG.


On 13 Dec 1998 13:33:46 -0800, "Ima Genius" <webmaster at imatowns.com>
[View Quote] >Because SDK bots require 2.1 universes which aren't released yet. There's
>only two 2.1 universes, one being AW.
> - Ima
>
>dean <challagar at hotmail.com> wrote in article
><367427E0.9D5CB199 at hotmail.com>...
>maker
>to
>design
>or
>project and

Dec 16, 1998, 1:01am

Hi Roland,

On Mon, 14 Dec 1998 12:28:02 -0800, "Roland Vilett" <roland at lmi.net>
[View Quote] >Xela,
>
>Ima was referring to the universe server, not the world server. SDK
>applications can function inside 2.0 world servers as you say, because SDK
>apps just look like normal users to 2.0 servers. One exception is the
>aw_whisper() call, which will work only in 2.1 worlds, since 2.0 worlds
>don't know how to implement whisper.
>
>I don't understand what you are saying about some 2.0 worlds not accepting
>SDK apps. SDK apps work in all 2.0 worlds, unless the access permissions of
>a particular world have been set to block out the owner of the bot. That's
>all the logic there is to it. Whether a world was built from scratch or
>upgraded from 1.3 has nothing to do with it.

I'll give you an example. I have permission and are welcome to try my
bots in Amigos and Amigos2. Although I get into those worlds myself,
my bots don't, neither do Hambots in SDK mode, unless I bring them in
with caretaker rights: as plain citizen XelaG, they get rejected with
reason 467 RC_NOT_WELCOME. We have been looking for a solution with
AMD and other amigos ppl, but have not found one. Most other worlds
I've tried in the COF universe (I suppose that is where they are if
they are on the browser's list) refuse my and Hamfon's SDK bots,
although they don't refuse me.

>
>The same does not go for universe servers. There were very substantial
>changes made to the universe server to support the SDK. None of these
>changes are present in the 2.0 universe servers, so SDK apps will not work
>there. The SDK will work in all universes once the 2.1 universe server is
>released.

Excuse my ignorance in these matters, Roland, it talk of my experience
and the explanations I've heard. If I follow your reasoning correctly,
it means that
(i) the COF universe has a 2.1 server, whereas others don't. And:
(ii) 2.0 worlds in 2.1 universe servers should accept all bots,
including SDK ones, unless the owner of the bot is refused entry.
(iii) the worlds on my browsers list are all in the COF universe.

If this is so, then I have been attempting to bring in SDK bots to
places where they should not get rejected with reason 467, but they
do. Right?

That's my experience in these matters. Welcome back to ng, btw !

XelaG

>
>-Roland
>
>
[View Quote]

Dec 16, 1998, 11:05am

Thank you very much, Roland, for your explanation. I will forward this
information to the Amigos group.

On Wed, 16 Dec 1998 00:13:54 -0800, "Roland Vilett" <roland at lmi.net>
[View Quote] >Hi Xela,
>
>The reason you are getting RC_NOT_WELCOME from some worlds is that those
>worlds are running the 2.1 world server. All COF worlds are running 2.1, as
>well has all worlds hosted by TCSN. I believe the Amigos worlds are hosted
>by TCSN.
>
>2.1 worlds can disallow bots, and in fact by default they disallow all bots
>until set otherwise. If you need to get bots into a world hosted by TCSN,
>have the world owner contact Bill Hoover(bill at activeworlds.com) and ask him
>to enable bots in that world.
>
>From the outside, it's not easy to tell the difference between a 2.0 world
>server and a 2.1 world server, at least without a 2.1 browser. However, if
>you are getting RC_NOT_WELCOME back from the SDK in a world that you
>yourself can enter without difficulty, then it is definitely a 2.1 world
>server set to not allow in any bots.
>
>-Roland
>
[View Quote]

Dec 16, 1998, 8:18pm

I'd be delighted, mailto:decastro at cable.a2000.nl

;o} XelaG.

On 16 Dec 1998 11:52:27 -0800, "Ima Genius" <webmaster at imatowns.com>
[View Quote] >If you want I can write a quick bot that lets you set the bot_rights. :)
> - Ima

Dec 16, 1998, 5:47am

On Tue, 15 Dec 1998 20:12:00 -0800, Canopus <aek2 at ix.netcom.com>
[View Quote] >Attached is the Delphi (Object Pascal) version of Build 11 of the AWAPI.
>If you're new to the SDK, go back to the 10/1/98 Delphi thread, where
>there are general instructions for using the Delphi AWAPI.
And in the dec.3rd XelaG thread you'll find the error codes.... ;o)

Dec 23, 1998, 1:41am

In my experience, setting the altitude in Hambots and SDK bots is a
buggy business. Moving up doesn't seem to cause problems, moving down
does. I'm referring to changing *only* the altitude. In many but not
all cases, the browser does not apply the change in altitude, until a
horizontal coordinated is changed. You can wait half an hour for the
bot to descend, but just change the x or z coordinate 1 cm and down it
zooms. Which makes me think that the problem might not be at the
server end or in the dll, but in the browser, maybe something
connected with gravity?

It's there, it could be anything, but don't say it's Delphi's fault...


[View Quote] >doesn't seem to wkr and I am calling aw_state_change but all other
>zeroes in other functuins work just fine.

Dec 20, 1998, 2:33am

I would like to know in what units is AW_WORLD_RESTRICTED_RADIUS? Is
it in decametres or metres (cm doesnt seem plausible)?

Also, is it a real radius, or a +/- NS/WE distance from 0n 0w?

Thanks.

Dec 20, 1998, 3:14am

Another related question: does the radius-restriction apply to all SDK
bots, or are right-holders exempted. If so, which?

I plan to include an automatic check of bot coords in my progs, to
avoid a very unpleasant situation that arose today: not only my bot
was ejected frow AW, so was I. Simply because of a bug that sent the
bot within the restricted area. This situation can be easily avoided
with this check, I hope.

This automatic check should only take place if the bot in question
does not have the right to be within the restricted zone.

XelaG.

[View Quote] >I would like to know in what units is AW_WORLD_RESTRICTED_RADIUS? Is
>it in decametres or metres (cm doesnt seem plausible)?
>
>Also, is it a real radius, or a +/- NS/WE distance from 0n 0w?
>
>Thanks.

1  2  3  |   Order by default