1  2  3  4  5  6  ...  36  |   Order by default

Oct 2, 2000, 7:00pm

What probably happens is you fail to call aw_wait on time. If aw_wait is
not called within I think 60 seconds, the bot gets disconnected. You can
call aw_wait(0) or its VB equivalent as often as you like: the AW browser
calls it for each frame, my bots call it 2x a second. I time this with a
windows timer (VB has them too), setting the timer at 500 milliseconds. In
the timer event, I call aw_wait(0).

XelaG

[View Quote]

Oct 9, 2000, 6:13am

[View Quote] I disagree, Chandler56. The timer should not, as a rule, be disconnected
when bots connect or disconnect (especially if you have a multi-bot
program). aw_wait(0) takes care of the stuff: if there is a disconnection
(waiting for server), calling aw_wait is the only way to re-establish the
connection. If you have more than one bot logged in, you can't stop the
timer anyway if one bot disconnects. There are two problems related to
these disconnections which could justify stopping the timer:

1. aw_wait(0) blocks for 40 seconds at a time when the disconnection is due
to a universe or isp disconnection (not if only the world goes down). This
is caused by the winsock blocking connection, which the AW bot SDK uses:
the AW browser does not use a blocking connection. This blocking will
freeze your UI. This in general is not fatal, but does affect other bots
which are not disconnected, it slows them down a lot.

2. some world servers on NT machines have problems with the AW SDK: this
sems to be a winsock problem in Windows NT in some configurations, I have
never experienced it myself (running world servers on NT4 and now Win 2000).
Linux world servers don't have this problem.

But the benefits of not stopping the timer are bigger than these
disadvantages, in my opinion. It garantees that the bot can be left
unattended, and the AW SDK does its job of reconnecting. A better solution
than stopping the timer, if one really wants to handle oneself these
disconnections, is to remove the bot from the universe (log it off), so as
to allow other bots to function normally.

To detect a disconnection there are 2 methods, using the AW SDK only.

1. you get a aw_world_disconnect, if the world disconnects (stops or is not
reachable). You can simulate this by stopping the world server.

2. the bot's session number changes to 439 (NoConnection) without getting
the world disconnect event: this is the serious case, when aw_wait(0) starts
blocking. You can simulate this case by unplugging your modem.

Reconnections are detected because the bot gets the world attributes: that
means things have normalised. In cases of universe disconnects, the bot will
get first the callback aw_login, then the event aw_universe_attributes,
followed by callback aw_enter and the event aw_world_attributes. These
callbacks, btw, are the result of an aw_login and aw_enter issued by the AW
SDK, not by your bot program: as I said before, the AW SDK takes care of the
situation.

XelaG

>
> SDK.AwWait(0)
>
> --
> - Chandler56
> "Use your free will to the ULTIMATE advantage: Assassinate the
Government!"
[View Quote]

Oct 22, 2000, 7:40pm

[View Quote] Well, I have had this as well in the past: for some reason, the aw.dll seems
to become unstable, as it were, and disconnects the bot for a second or two
from the world (I haven't checked the session number to see if that changes
too). This affected one of my bots last year, running a slide-show script
for the Avvy awards (Avatars 1999): after like 10 slides, every new
slide-change flashed the bot in and out of existance. They had to finish the
slide-show manually. I say it is the sdk and not the world or universe
server, because I tested the bot after it 'got sick', moved it to another
universe and ran the slide show there... from the first slide, the bot kept
disappearing. The bot was only changing objects, and it does that regularly
and well... I never touched that script again!

One thing that *will* cause this behaviour (and that was not the case in my
slide-show script) is if you send strings which are too long (longer that
AW_MAX_ATTRIBUTE_LENGTH = 255).

Alex.


>
> Grrrr..... very irritating !! Better learn C again I think, if I can't
> find out anymore. Gonna go play with aw_object_add and aw_object_delete to
> see what I can discover.
>
> If you managed to sort this, ctc one, I'd be very interest.
>
> Grimble.
>
>
[View Quote]

Oct 9, 2000, 6:17am

Nice script :)

XelaG

[View Quote]
----------------------------------------------------------------------------
----


> [Head]
> Type=Script
> Version=2.2
>
> # Update VRT time sign by Prozak
> # from a script by Alex
> #
> # put this in the action field for a beautiful sign:
> # create sign color=C0C0C0 bcolor=black; name time
> #
> #
> #
> #
> #
>
> [Settings]
> Origin=0.000n 0.000w 0.00a 0.0
> Run
>
> [Script]
>
>
>
>
> OnWorldReconnectEvent Reconnect
>
> #the avatar to use
> var %DefAv, %done
> %DefAv = 3
> Avatar %DefAv
> %done = 0
>
>
> #declare your variables for querying
> var at QueryPos, %IsQuerying, at Seat
> at Seat = 1.230s 0.081e 5.85a 0.0
>
> # declare your variables for the search and modify
> var $BoardName, ~Board, %Board
> var ~Boarda, $BoardDes
> WarpLocal at Seat
> #say starting program
>
> $BoardName = "name time"
> # the bot is not yet querying
> %IsQuerying = 0
> GetLocation at QueryPos
> # install the event handlers for the query
> OnQueryCompleteEvent Complete
> OnWorldReconnectEvent Reconnect
> # start your query
> %IsQuerying = 1
> QueryAt at QueryPos
> # loop until QueryComplete
> Label WaitForQuery
> IfInt %IsQuerying = 1 Goto WaitForQuery
> Label Jump00
> Gosub Update
> # Change the board sign
> Gosub MakeBoard
>
> ~Board = ~Boarda
>
> Goto Jump00
>
> Sub Update
> wait 5
> GetDateTime $a
> concat $b "VRT time is " $a
> $BoardDes = $b
> EndSub
>
>
>
>
> Event Complete
> #say completed
> %IsQuerying = 0
> EndEvent
>
> Event Reconnect
> IfInt %IsQuerying = 1 QueryAt at QueryPos
> EndEvent
>
> # this Sub finds the first instance of your object
> # IfGetResObjectItem ~Board 1
>
> Sub FindBoard
> #say finding board
> FilterClear
> ResClear
> FilterAction $BoardName
> ResFromSurveyFilter
> IfGetResObjectItem ~Board 1 %Board = 1
> Else %Board = 0
> %done = 1
> EndSub
>
> # To modify the description on ~Board and change it to $BoardDes:
>
> Sub MakeBoard
> IfInt %done = 0 Gosub FindBoard
> IfInt %Board = 0 Goto MakeBoardError
> ~Boarda = ~Board
> GetDescription ~Boarda $BoardDes
> ObjectModify ~Board ~Boarda
> EndSub
> Label MakeBoardError
> Say Can't find my VRT Timeboard :(
> EndSub
>
>
>
>
> Event Reconnect
> # reload and run the script after disconnection
> Say Disconnected. System Spiked. Programming Resumed.
> Run
> EndEvent
>

Apr 27, 2000, 4:51pm

Hi Canopus, you can use build 16 bots anywhere, even in an old world build 21...
The newer features will not work in those worlds, but the older features do work
fine. Build 16 fixed the 'same world name in different universes' bug, and the
coming build 17 has more bug fixes, which are a bonus even if you don't have a
3.0 browser or world server.

As far as the version mismatch, I always put the aw.dll in the same folder as the
bot program, and never anywhere on the path known to windows, to avoid
mismatches.

[View Quote] > Version mismatch usually happens when the 'const AW_BUILD = 16' line in your
> akAWAPI Delphi unit doesn't match the Build Number of the aw.dll you are
> using.
>
> Either you keep on using an old build of aw.dll to match your old akAWAPI
> unit
> or you use a new version of akAWAPI (check the 'const AW_BUILD = ' line) to
> match the new version of aw.dll that you have.
>
> I think I usually put the newest aw.dll in the akAWAPI package that I post.
> You
> mention 'three examples': this sounds like you are using the Delphi
> Encapsulation of the SDK. Newer akAWAPI (& the matching aw.dll) should still
> work with the Encapsulation, because mostly methods have been added, not
> subtracted or revised. But probably the Encapsulation section has an old
> akAWAPI
> (& its matching aw.dll) in it: substitute the latest akAWAPI (& matching
> aw.dll), & see if that helps.
>
> It could be that I put the wrong aw.dll in the new akAWAPI package. I'll
> check.
> You can check by comparing their Build/Version numbers.
>
> Also, I'm not sure whether you must have AW 3.0 Beta to use the latest aw.dll
>
> (would that also cause a Version Mismatch?).

Oct 16, 2000, 10:07am

This is for people who know how to set up a xelagot server client
connection.

I posted a new xelagot script, used in the Avatars2000 event yesterday (Oct.
15, 2000), that creates a PA system at different locations, worlds or
universes to broadcast messages simultaneously. See the link for PA System
Bot at http://www.imatowns.com/xelagot/xlgasexamplesidx.html.

XelaG

May 25, 2000, 5:24pm

First, let me point out I am not beta testing the RW 3.0 browser because
I am on NT4. But this issue has been pointed out by one of the users of
my bots, in relationship to the new world attributes features.

The new attributes enhance the browser experience, and one would like,
for instance, to be able to change the light settings to match the time
of day, or the fog. That could be done every 5 or 10 minutes, but...
when one sets any of the attributes, they all get reset by the browser.
This includes the home-page, even if it has not changed. Some
home-pages are used functionally: they may have links to other pages,
like to a chat-box. This resetting can be very irritating. This was
probably less noticeable in past times, when only the backdrop and
background colour would be reset four times a day... Could this
behaviour be modified so that one can change an attribute without
reseting the home-page in the browser unless the home-page has actually
changed? Belongs in wish-list, yes, but on the other hand, this is
really a new issue brough up by the 3.0 enhancements :)

XelaG

May 25, 2000, 5:30pm

hmmpff, wrong newsgroup, was meant for beta :)

[View Quote] > First, let me point out I am not beta testing the RW 3.0 browser because
> I am on NT4. But this issue has been pointed out by one of the users of
> my bots, in relationship to the new world attributes features.
>
> The new attributes enhance the browser experience, and one would like,
> for instance, to be able to change the light settings to match the time
> of day, or the fog. That could be done every 5 or 10 minutes, but...
> when one sets any of the attributes, they all get reset by the browser.
> This includes the home-page, even if it has not changed. Some
> home-pages are used functionally: they may have links to other pages,
> like to a chat-box. This resetting can be very irritating. This was
> probably less noticeable in past times, when only the backdrop and
> background colour would be reset four times a day... Could this
> behaviour be modified so that one can change an attribute without
> reseting the home-page in the browser unless the home-page has actually
> changed? Belongs in wish-list, yes, but on the other hand, this is
> really a new issue brough up by the 3.0 enhancements :)
>
> XelaG

Oct 30, 2000, 12:17am

I don't get a reply from JKMT either. Two months ago, he sent me an email
saying he would like to host up to 50 xelagots, could I find a solution for
bot owners to remotely control their bot? He was willing to pay for this...
I replied that I was going away for one month and would contact him... After
the Avatars2000 event, I sent him an email saying I was now working on a
solution, and asked him to contact me about it... I never got a reply.
Well, the solution is freeware now, posted on my xelagot pages, I worked 10
solid days on it. Any bot-hosting instance can now host xelagots (there is
a better version for this than x1, they just need to contact me about it),
and guarantee their customers full access to their bot through xelagot
verbal commands issued with a special User Client.


[View Quote]

Oct 30, 2000, 6:24am

[View Quote] Not that I know of, the AW SDK has not been ported to Linux by AWCOM.

>
> Ox64
>
[View Quote]

Jul 13, 2000, 4:42pm

Dont let it talk or whisper :)

[View Quote] > Hi!
> Does anybody know how to make a visible bot that doesn't display it's
> nametag?
>
> /friendly, Paer

Oct 29, 2000, 8:12pm

A new series of xelagot applications: the stand-alone Xelagot Server (GUI
and NT-service version), and two new client applications: the Xelagot
Administrator Client to remotely manage the server, and the Xelagot User
Client to chat with your bots if they are hosted elsewhere. See the new
xelagot page at:

http://www.imatowns.com/xelagot/index.html

Oct 31, 2000, 12:20pm

The NT-service version (first upload) was maxing the CPU. This bug has now
been fixed.

[View Quote]

Sep 22, 2000, 12:31am

My experience: don't use aw_wait(somethingorother), only aw_wait(0). Time
your bot's heartbeat using something else, like a timer :)


[View Quote]

Nov 1, 2000, 7:36pm

Hello all !

At long last, two programs that have been used and tested by me and a few
others for almost a year now are made available as freeware for
non-commercial use: the Av99Bot was tested during the 1999 September
Aussiecon event, tested and used in War (these are the bots, but not the
scripts!) and by a few others... and the SrvcXlgBot, an NT Service bot
which runs in the background... both can have more than 3 bots, the limit
being what the AW SDK can handle in one instance of the aw.dll. Depending on
how crowded the places are, you can have 10 to 20 bots running in one
application. These programs are not for beginners, though, and they do not
let you interact with the bot through the user interface. Everything must be
planned beforehand and written in the ini file. They run any xelagot
script, and can log into a xelagot server to communicate among themselves
and with their owners. Go to a link to their page at:

XelaG Quality Bots http://www.imatowns.com/xelagot/

Sep 22, 2000, 12:38am

Put HideSelection to False :)

[View Quote]

Nov 2, 2000, 6:26pm

Hi all,

a few months ago, Billybob wrote a xelagot script for an RPG game. This
script is very well written (at least, for a first go at scripting, it is
excellent), but has some fundamental flaws which were not fixed. He never
finished writing it. People keep sending me this script saying 'I wrote
this but it's not working', or 'can you fix this RPG script?'... I
received this script by email some 5 times in the past month.

My reply to all: no, I can not fix this script. The biggest problem is in
the Sub Battle (the rest I have fixed). This sub will never work the way it
is written, and it is the heart of the game. It is not clear what the author
wanted to achieve here, so I can not make anything out of it: it loops back
and forth, falls through loops and labels... this is the state a script has
when the author has not yet figured out his code and is experimenting.

So, to all: please stop sending me this script to fix :)

Sep 22, 2000, 1:01am

Check my encapsulation of the Bone SDK. The code I use to work with the
RichEdit in Xelagot is reproduced (adapted to the circumstances) in the
Delphi source in this program. http://www.imatowns.com/xelagot/bone/

XelaG

[View Quote]

Sep 27, 2000, 11:09am

reason 444: not initialized

[View Quote]

Oct 2, 2000, 7:00pm

What probably happens is you fail to call aw_wait on time. If aw_wait is
not called within I think 60 seconds, the bot gets disconnected. You can
call aw_wait(0) or its VB equivalent as often as you like: the AW browser
calls it for each frame, my bots call it 2x a second. I time this with a
windows timer (VB has them too), setting the timer at 500 milliseconds. In
the timer event, I call aw_wait(0).

XelaG

[View Quote]

Oct 24, 2000, 7:50pm

Hi andon13,

I have not noticed any difference at all in performance between build 15 and
17. On the contrary, besides adding features, Roland fixed a few bugs:

1. teleporting the bot to a world in a universe with a name also used and
visited by the bot in the last 30 minutes in any of the universes it has
been would cause havoc (world ip:port data remained cached and inmutable so
bot could not go into that world and error messaging was wrong and
confusing). Fixed.

2. a world error (like for instance ejection or world-wfs) would cause the
bot, if teleported by the owner somewhere else, to land at the same spot as
it was in the previous world, to the greatest joy of the abominable sadist
Custom Aids bot. Fixed I think (I had a workaround, and never removed it, so
I haven't tested it)

3. a new error introduced in build 16 was repaired in 17: world ejection
database was not being updated properly by the bot. Fixed.

The World list feature never changed, in my experience. Universe connection
error handeling has always been extremely lousy, so that is not a new
'feature'. I do not see how it ever could go worse from build 15 to 17 !
And until the winsock connection is made non-blocking (as it is in the
browser), or the sdk is made thread safe and client connections are
threaded, we will never have full control on how our users experience our
bots.

XelaG
Antique and Fossilized Programmer
AAGdC (y a mucha honra)

[View Quote]

Nov 4, 2000, 7:36pm

One bot hosting service, two months ago, asked me to add functionality to
the Xelagot bot so that their custommers could remotely interact with their
bots. This hosting service, who also offered to pay me for the job (which I
politely refused, I do this for free), never replied to my emails, so here
goes an announcement for all bot hosting services:

Xelagot bots can be hosted using the Av99Bot or the SrvcXlgBot, two
applications available on my XelaG Quality Bots page:
http://www.imatowns.com/xelagot/ as freeware for non-commercial use (and for
bot hosting instances that provide affordable services). These applications
have most of the xelagot abilities except for those related to the x1 user
interface.

The bots can connect to a Xelagot Server (also on my page, freeware). This
server can be remotely managed by the hosting service using the Xelagot
Administrator Client (freeware). Their custommers can connect to the same
server using the Xelagot User Client (freeware), and chat with and command
their bots remotely. The server administrator has full control on who may
log in and for what.

New in the latest version of the bots (1.65): the hosting service can
drastically restrict file access by the bots. Properly written scripts will
still run impecably, but file access by script statements is restricted to
the folder where the script lives. Abusive use of file access commands are
negated by the new applications. The bots, it is true, could still fill
your partition with trash files: it is then up to you to check who is
abusing (easily done, files remain in one folder, even trash files) and
punish the offender.

Needless to say: the regular Xelagot (x1.exe) should not be used by hosting
services.

XelaG

Nov 6, 2000, 12:39am

Hi,

the hearing zone is a square LOL, about 400m wide, with you in the middle.
The maximum number of ppl and bots you can hear is 50 even in that zone,
depending on your settings (I'm not sure about browsers, but this holds for
bots). To be sure not to hear someone, you must be at least 200m N, S W or
E away from them (20 aw coordinates, 400 building clicks).

XelaG

[View Quote]

Dec 27, 2000, 5:49pm

I think you need to change the drive and directory first to the world's
directory (using a shell command) and then issue a shell to start the world
server, or maybe you can specify it directly in the shell command to start
the world. If you look at the Properties of a windows link to any program,
you will see that mechanism too, in the tab 'Shortcut', item 'Start in'.

XelaG

[View Quote]

Feb 11, 2001, 9:51am

Here go a few things I learned using the new 3.1 sdk, I hope this helps
someone.

How the CellIterator works.

The cell iterator is a 32 bit integer (4 bytes), which consists of two
parts. The most significant 16 bits (or hi word) is the x coordinate of the
cell (West is positive, South is negative), in decametres, the low word is
the z coordinate (North is positive, South negative). These are signed 16
bit integers (2 bytes) which in Delphi Pascal is called a Smallint.

When you put it to 0, and call aw_cell_next, a whole process is triggered.
(I assume the callback AW_CELL_RESULT has been installed).

In Pascal:
aw_instance_set(Instance);
aw_int_set(AW_CELL_ITERATOR, CellIterator);
aw_cell_next;
where Instance is the instance number of the bot and CellIterator is what I
mentioned above (normally, you start with a 0 value).

What happens next? These events:

AW_CELL_BEGIN, where you can collect the same information as when you query
a zone,
AW_CELL_OBJECT, (none ore more, depending on how many objects are in the
cell). Here you collect your objects,
AW_CELL_END.

All this is followed by the callback AW_CELL_RESULT. This callback returns
a new CellIterator when you call aw_int(AW_CELL_ITERATOR). Depending on the
value of rc:
rc = 0 : the CellIterator collected here will give you a new cell coordinate
which you can use to get the next cell contents, by repeating the previous
calls: you can omit the call to
aw_int_set(AW_CELL_ITERATOR, CellIterator) in this case;
rc <> 0 : the new CellIterator has no practical value (remains unaltered in
my experience).

By starting off the CellIterator at 0 (equivalent to 0n 0w), you can get
the contents or all the valid cells in the world, and must stop when in the
callback AW_CELL_RESULT the value of rc becomes <> 0.

But there is more to all this: the CellIterator can be set to a specific
cell coordinate, to retrieve the contents of that cell. By setting the upper
word of the CellIterator to the x value of the cell, and the lower word to
the z value, you can issue your aw_cell_next for just that cell. This means
that there is a new way to query... And the beautiful part of this is that
it does not interfere with a live update or a query, if you follow certain
rules.

Both a zone query and a cell iteration use the same event handlers:
AW_CELL_BEGIN, AW_CELL_OBJECT and AW_CELL_END. If a query has finished and
live update has started, you can use the iteration method safely. You must,
of course, handle the situation differently in these three event handlers,
so you may want to set a flag or something before you call aw_query and
aw_cell_next so as to distinguish these cases in the event handlers.

In an ongoing query (before the AW_QUERY_COMPLETE returns true) you can also
issue the iteration order: just make sure you do that after receiving the
callback AW_CALLBACK_QUERY: instead of issing a new aw_query, you issue your
aw_cell_next, wait for the callback AW_CELL_RESULT, and then resume your
query with aw_query.

Supposing you use the iteration method to search for lost property... in a
huge world like AlphaWorld.... this will take days. You may need to
disconnect and reconnect, or you may get disconnected from the world etc...
no panic. Keep the last value of the CellIterator, and resume the iteration
using this value instead of starting from zero.

For Pascal freaks, below are some usefull chunks of code. The zSplit series
splits the 32 bits into two chunks, the zUnite series joins two signed
values into a 32 bit thingmebob :) Note: this code will not work with
Delphi3, because of the use of overload and because Delphi 3 has a 31 bit
Cardinal (or was it Delphi 2?).

Have fun, XelaG.

in the interface declare:

procedure zSplit(a: Integer; var H, L: Integer); overload;
procedure zSplit(a: Cardinal; var H, L: Integer); overload;
procedure zSplit(a: Integer; var H, L: Cardinal); overload;
procedure zSplit(a: Cardinal; var H, L: Cardinal); overload;
procedure zSplit(a: Cardinal; var H, L: Word); overload;
function zUnite(H, L: Integer): Cardinal; overload;
function zUnite(H, L: word): Cardinal; overload;
function CardToInt(a: Cardinal): Integer;
function IntToCard(a: Integer): Cardinal;


in the implementation declare:

procedure zSplit(a: Integer; var H, L: Integer);
type
PCar = ^Cardinal;
PWor = ^Word;
var
p: Pointer;
pc: PCar;
pw: PWor;
c: Cardinal;
HW, LW: Word;
SH, SL: Smallint;
begin
p := at a;
pc := PCar(p);
c := pc^;
zSplit(c, HW, LW); // calls the Word version
p := at HW;
pw := PWor(p);
SH := pw^;
H := SH;
p := at LW;
pw := PWor(p);
SL := pw^;
L := SL;
end;

procedure zSplit(a: Cardinal; var H, L: Integer);
type
PWor = ^Word;
var
p: Pointer;
pw: PWor;
HW, LW: Word;
SH, SL: Smallint;
begin
zSplit(a, HW, LW); // calls the Word version
p := at HW;
pw := PWor(p);
SH := pw^;
H := SH;
p := at LW;
pw := PWor(p);
SL := pw^;
L := SL;
end;

procedure zSplit(a: Integer; var H, L: Cardinal);
type
PCar = ^Cardinal;
PWor = ^Word;
var
p: Pointer;
pc: PCar;
c: Cardinal;
HW, LW: Word;
begin
p := at a;
pc := PCar(p);
c := pc^;
zSplit(c, HW, LW); // calls the Word version
H := HW;
L := LW;
end;

procedure zSplit(a: Cardinal; var H, L: Cardinal);
var
HW, LW: Word;
begin
zSplit(a, HW, LW); // calls the Word version
H := HW;
L := LW;
end;

procedure zSplit(a: Cardinal; var H, L: Word); // this is the Word version
type
Pwor = ^Word;
var
b: Cardinal;
p: Pointer;
pw: Pwor;
begin
p := at a;
pw := PWor(p);
L := pw^;
b := (a shr 16);
p := at b;
pw := PWor(p);
H := pw^;
end;

function zUnite(H, L: Integer): Cardinal;
type
PWor = ^Word;
var
p: Pointer;
pw: PWor;
SH, SL: Smallint;
WH, WL: Word;
begin
try
SH := H;
SL := L;
p := at SH;
pw := PWor(p);
WH := pw^;
p := at SL;
pw := PWor(p);
WL := pw^;
Result := zUnite(WH, WL); // calls the Word version
except
raise;
end;
end;

function zUnite(H, L: Integer): Cardinal;
type
PWor = ^Word;
var
p: Pointer;
pw: PWor;
SH, SL: Smallint;
WH, WL: Word;
begin
try
SH := H;
SL := L;
p := at SH;
pw := PWor(p);
WH := pw^;
p := at SL;
pw := PWor(p);
WL := pw^;
Result := zUnite(WH, WL); // calls the Word version
except
raise;
end;
end;

function zUnite(H, L: word): Cardinal; // this is the Word version
var
CH: Cardinal;
begin
CH := H;
Result := ((CH shl 16) and $FFFF0000) or L;
end;

function CardToInt(a: Cardinal): Integer;
{ changes a Cardinal (32 bit unsigned) to Integer (32 bit signed) }
type
Pint = ^Integer;
var
p: Pointer;
pin: PInt;
begin
p := at a;
pin := PInt(p);
Result := pin^;
end;

function IntToCard(a: Integer): Cardinal;
{ changes an Integer (32 bit signed) to a Cardinal (32 bit unsigned) }
type
PCar = ^Cardinal;
var
p: Pointer;
pc: PCar;
begin
p := at a;
pc := PCar(p);
Result := pc^;
end;

Feb 12, 2001, 11:13am

A word of caution about using the cell iterator for collecting the contents
of one cell. I just got this email from Roland:



Maybe you could add the cell iterator's secret to the docs: high word
(signed) = x, low word (signed) = z (x and z in decametres). Took me a while
to figure it out...

I'd actually prefer to keep this undocumented for the moment...I mean,
I expected people would probably notice that, but by keeping it
undocumented I have the right to change the significance of the
cell iterator value in the future. :) aw_cell_next() isn't
intended as a mechanism for querying the value of specific cells.

But oh no! I hear Alex cry...that will break my bots! Never fear...
I am planning (was planning for 3.1 in fact but ran out of time) to
add a new SDK method, something like aw_cell_get (int x, int z) which
simply queries the entire contents of any cell. This makes it nice
and clean and formalized with no (x << 16) + z or other funny
business like that. :)

-Roland

Nov 7, 2000, 2:02pm

(applies to X1.exe 2.9999950 and Av99Bot/SrvcXlgBot 1.66, which will be
available soon)

Dear xelagot script makers (and users),

The next version of xelagot applies strict rules to scripts, enforcing many
of the currently legal syntax laws. Some illegal constructions, which work
up to now, will cause the script to abort. This enforcement is needed to be
able to catch and stop recursive and circular calls (which can cause a stack
overflow killing the application), and loops which do not return control to
the application (causing it to freeze). The new syntax control checks Main,
Event, Sub and Text boundaries

The most common error is a Goto pointing to a label outside its own Sub,
Event or Main. In the following example, the statement Goto OneA in Sub One
is legal, but the same statement in Sub Two is not legal (but worked).

Sub One
... code
IfInt %r > 1 Goto OneA
... code
EndSub
Label OneA
... code
EndSub

Sub Two
... code
IfInt %r > 1 Goto OneA
... code
EndSub

Another less common error is a ResetTo pointing to a label outside the Main
part of the script.

If you think your scripts may be defective, when you upgrade install the new
X1.exe in a COPY of the bot's current directory (so that the settings are
preserved) and test and eventually fix your scripts first.

Notice that X1.exe will produce error messages on screen, so this
facilitates debugging your script. Some errors are trapped during script
initialisation, others (like Goto errors) at runtime.

For more details, see http://www.imatowns.com/xelagot/xlgaserrors.html

Feb 21, 2001, 4:42pm

When you query a zone, in aw_cell_object you can get ALL the data of the
object, including the number you are looking for: keep those in a database.
When you get a click on an object, the number and cell coordinates are also
given to you. So go back to your database and look for it.

BTW, it would be fantastic if AWCOM finished the API documentation job by
including the callbacks.

XelaG

[View Quote]

Nov 9, 2000, 8:05pm

[View Quote] XelaG

Mar 3, 2001, 3:39pm

dont use quickstart, use sdk.AwCreate, sdk.AWLogin and sdk.AwEnter

Function sdk.AwCreate(domain As String, port As Long) As Long
then set the necessary attributes:
(long) sdk.AwLoginOwner,
(string) sdk.AwPrivilegePassword,
(string) sdk.AwLoginName
then call
Function sdk.AwLogin() As Long
Function sdk.AwEnter(World As String, Avatars As Long) As Long
set the coords and yaw:
sdk.AwMyX, sdk.AwMyY, sdk.AwMyZ, sdk.AwMyYaw
and finally call
Function sd.AwStateChange() As Long

I hope I did not make a mistake LOL, I', not an VeeBee-er :)

Check MrGrimm's help pages at http://aw.grimmsoft.com/sdk/awsdkocxhelp.htm

XelaG

[View Quote]

1  2  3  4  5  6  ...  36  |   Order by default