edward sumerfield // User Search

edward sumerfield // User Search

1  ...  2  3  4  5  6  7  ...  9  |  

Moving the bots

Nov 30, 1998, 1:54am
I thought we had specked that out? Let me know were you are having problems.

[View Quote] > So i guess this means you haven't figured out how to get my SDK script to
> chase ppl?<g>
>
>
>
[View Quote]

Moving the bots

Dec 1, 1998, 12:05pm
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Are Veleno and Fast the same person or just two interested parties?
<P>So were do you want me to start?
<P>Do you have a C compiler? Which one?
<P>Have you written bots before?
<P>What is your level of C experience?
[View Quote]

Moving the bots

Dec 2, 1998, 3:02am
This is a multi-part message in MIME format.
--------------5F48D06410C8F2FE04DFE96A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Here is a working solution. Most is cut and paste from my C++ AWCPP into this
C program.

It waits for someone to walk within 5 meters of it and then follows them for
60 seconds after which it runs back to its starting position.

To run you will require:

1. Cygnus GNU G++ compiler.
2. The awsdk.lib wrapper that was built to interface with COF's aw.dll.
3. Just type make to create the exe file.

If you do not change anything then to test:

1. Goto Beta and teleport to 99n 99w 0a 45.
This will place you 10 meters away from the bot and facing it.
2. Run the bot using "follower <citizen number> <priv password>"
3. The bot will report your distance as you approach. When you are with 5
meters which
is reported as 500 cm it will switch into follow mode and move to 1 meter
behind you facing
in the same direction as you are.

Good luck.

Edward Sumerfield.

[View Quote] [View Quote] --------------5F48D06410C8F2FE04DFE96A
Content-Type: text/plain; charset=us-ascii;
name="Makefile"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Makefile"

CFLAGS=-g -I. -I${AWSDK}

all: follower.exe

follower.exe: follower.o
g++ $< ${AWSDK}/awsdk.lib -o $ at

--------------5F48D06410C8F2FE04DFE96A
Content-Type: application/x-unknown-content-type-c_auto_file;
name="follower.c"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="follower.c"

I2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8bWF0
aC5oPg0KI2luY2x1ZGUgPGF3Lmg+DQoNCiNkZWZpbmUgVFJVRSAxDQojZGVmaW5lIEZBTFNF
IDANCg0KI2RlZmluZSBQSSAzLjE0MTU5MjY1NA0KI2RlZmluZSBDSVJDTEVfUkFESUFOUyAg
KDIqUEkpDQojZGVmaW5lIENJUkNMRV9ERUdSRUVTICAoMzYwKQ0KI2RlZmluZSBDSVJDTEVf
QVcgICAgICAgKDM2MDApDQoNCiNkZWZpbmUgTUlOX1hfQ09PUkQgICAtMzI3NjcwMA0KI2Rl
ZmluZSBNQVhfWF9DT09SRCAgIDMyNzY3MDANCiNkZWZpbmUgTUlOX1pfQ09PUkQgICAtMzI3
NjcwMA0KI2RlZmluZSBNQVhfWl9DT09SRCAgIDMyNzY3MDANCiNkZWZpbmUgTUlOX0FMVElU
VURFICAtMzI3NjcwMA0KI2RlZmluZSBNQVhfQUxUSVRVREUgIDMyNzY3MDANCiNkZWZpbmUg
TUlOX1lBVyAgICAgICAwDQojZGVmaW5lIE1BWF9ZQVcgICAgICAgMzYwDQojZGVmaW5lIE1J
Tl9QSVRDSCAgICAgMA0KI2RlZmluZSBNQVhfUElUQ0ggICAgIDM2MA0KDQp0eXBlZGVmIGVu
dW0gew0KICBJTlZBTElEID0gMCwNCiAgV0FJVElORywNCiAgRk9MTE9XSU5HDQp9IFNUQVRF
Ow0KDQovKiBTdGF0aWMgdmFyaWFibGVzIHNoYXJlZCBiZXR3ZWVuIHRoZSBtYWluIGxvb3Ag
YW5kIHRoZSBjYWxsYmFjayBmdW5jdGlvbnMuICovDQoNClNUQVRFIHJvYm90X3N0YXRlID0g
SU5WQUxJRDsNCg0KZmxvYXQgZm9sbG93X3ggPSAwOw0KZmxvYXQgZm9sbG93X3ogPSAwOw0K
ZmxvYXQgZm9sbG93X2FsdGl0dWRlID0gMDsNCmZsb2F0IGZvbGxvd195YXcgPSAwOw0KDQpp
bnQgYXZhdGFyX3Nlc3Npb24gPSAtMTsNCmludCBhdmF0YXJfeCA9IDA7DQppbnQgYXZhdGFy
X3ogPSAwOw0KaW50IGF2YXRhcl9hbHRpdHVkZSA9IDA7DQppbnQgYXZhdGFyX3lhdyA9IDA7
DQoNCmludCByZXNldF94ID0gMTAwMDAwOw0KaW50IHJlc2V0X3ogPSAxMDAwMDA7DQoNCmlu
dCB0aW1lciA9IDA7DQppbnQgZm9sbG93X3RpbWUgPSA2MDsNCg0KLyoqIGRpc3RhbmNlDQog
KiAgQ2FsY3VsYXRlIHRoZSBkaXN0YW5jZSBiZXR3ZWVuIHR3byB4LCB5LCB6IGNvb3JpbmF0
ZXMuDQogKi8NCmludA0KZGlzdGFuY2UoKSB7DQoNCiAgaW50IGF2YXRhcl94ID0gYXdfaW50
KEFXX0FWQVRBUl9YKTsgDQogIGludCBhdmF0YXJfeiA9IGF3X2ludChBV19BVkFUQVJfWik7
IA0KICBpbnQgYXZhdGFyX2FsdGl0dWRlID0gYXdfaW50KEFXX0FWQVRBUl9ZKTsgDQoNCiAg
aW50IG15X3ggPSBhd19pbnQoQVdfTVlfWCk7IA0KICBpbnQgbXlfeiA9IGF3X2ludChBV19N
WV9aKTsgDQogIGludCBteV9hbHRpdHVkZSA9IGF3X2ludChBV19NWV9ZKTsgDQoNCiAgZmxv
YXQgZGVsdGFfeCA9IChmbG9hdCkobXlfeCAtIGF2YXRhcl94KTsNCiAgZmxvYXQgZGVsdGFf
eiA9IChmbG9hdCkobXlfeiAtIGF2YXRhcl96KTsNCiAgZmxvYXQgZGVsdGFfeSA9IChmbG9h
dCkobXlfYWx0aXR1ZGUgLSBhdmF0YXJfYWx0aXR1ZGUpOw0KDQogIC8vIFdvcmsgb3V0IHRo
ZSBob3Jpem9udGFsIGh5cG90ZW51c2UgdXNpbmcgUHl0aGFnYXJvdXMgdGhlb3JlbS4gDQog
IC8vIA0KICAvLyBoeXBvdGVudXNlIHNxdWFyZWQgPSBvcHBvc2l0ZSBzcXVhcmVkICsgYWRq
YWNlbnQgc3F1YXJlZDsgDQoNCiAgZmxvYXQgaG9yX2ggPSBzcXJ0KCgoZGVsdGFfeCAqIGRl
bHRhX3gpICsgKGRlbHRhX3ogKiBkZWx0YV96KSkpOyANCg0KICAvLyBUaGUgdmVydGljYWwg
aHlwb3RlbnVzZSBpcyB0aGUgdGhlIGFjdHVhbCBkaXN0YW5jZSBiZXR3ZWVuIHRoZSANCiAg
Ly8gdGhlIGF2YXRhcnMuIA0KDQogIGZsb2F0IGRpc3RhbmNlX2Zyb21fYXZhdGFyID0gc3Fy
dCgoKGhvcl9oICogaG9yX2gpICsgKGRlbHRhX3kgKiBkZWx0YV95KSkpOyANCg0KICByZXR1
cm4gKGludClkaXN0YW5jZV9mcm9tX2F2YXRhcjsNCn0NCg0Kdm9pZA0KbW9kX2Zsb2F0KGZs
b2F0ICpudW1iZXIsIGludCBtb2R1bHVzKSB7DQoNCiAgd2hpbGUgKCpudW1iZXIgPiBtb2R1
bHVzKSB7DQoNCiAgICAqbnVtYmVyIC09IG1vZHVsdXM7DQogIH0NCiAgcmV0dXJuOw0KfQ0K
DQp2b2lkDQpmb2xsb3coZmxvYXQgKm15X3gsIGZsb2F0ICpteV96LCBmbG9hdCAqbXlfYWx0
aXR1ZGUsIGZsb2F0ICpteV95YXcsDQogICAgICAgZmxvYXQgYXZhdGFyX3gsIGZsb2F0IGF2
YXRhcl96LCBmbG9hdCBhdmF0YXJfYWx0aXR1ZGUsIGZsb2F0IGF2YXRhcl95YXcpIHsNCg0K
ICBpbnQgZGlzdGFuY2UgPSAxMDA7ICAvLyAxIG1ldGVyDQogIGZsb2F0IHlhd19yYWRpYW5z
Ow0KICBmbG9hdCBkZWx0YV94X2Nvb3JkOw0KICBmbG9hdCBkZWx0YV96X2Nvb3JkOw0KDQog
IC8vIFNldCBteSB5YXcgdG8gdGhlIHNhbWUgZGlyZWN0aW9uIHRoYXQgdGhlIGF2YXRhciBp
cyBmYWNpbmcuIFdlIG11c3QgDQogIC8vIGRvIHRoaXMgbm93IGJlY2F1c2Ugd2UgYXJlIGdv
aW5nIHRvIHR1cm4gdGhlIGF2YXRhciB5YXcgYXJvdW5kIGZvciB0aGUgDQogIC8vIGRpcmVj
dGlvbiBjYWxjdWxhdGlvbi4gDQoNCiAgKm15X3lhdyA9IGF2YXRhcl95YXc7IA0KDQogIC8v
IEJlY2F1c2Ugd2Ugd2lsbCBiZSBmYWNpbmcgdGhlIGF2YXRhciBmcm9tIGJlaGluZCB3ZSBj
YW4gc2V0IG91ciANCiAgLy8geWF3IHRvIHRoZSBzYW1lIGFzIHRoZSBhdmF0YXJzLiBIb3dl
dmVyLCB0aGUgbmV3IHBvc2l0aW9uIGlzIA0KICAvLyBjYWxjdWxhdGVkIGFzIHNvbWUgZGlz
dGFuY2UgaW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiBmcm9tIHdoZXJlIA0KICAvLyB0aGUg
YXZhdGFyIGlzIGZhY2luZyBzbyB3ZSBtdXN0IGFkZCAxODAgZGVncmVlcyBmb3IgdGhlIHRy
aWcgDQogIC8vIGVxdWF0aW9uLiANCg0KICBhdmF0YXJfeWF3ICs9IChDSVJDTEVfQVcgLyAy
KTsgICAgLy8gVGhpcyBpcyAzNjAwLzIgDQogIG1vZF9mbG9hdCgmYXZhdGFyX3lhdywgQ0lS
Q0xFX0FXKTsNCg0KICAvLyBDb252ZXJ0IHRoZSBBVyBkZWdyZWVzIHRvIHJhZGlhbnMgZm9y
IHVzZSB3aXRoIHRoZSBjb3MgYW5kIA0KICAvLyBzaW4gZnVuY3Rpb25zLg0KDQogIHlhd19y
YWRpYW5zID0gKGF2YXRhcl95YXcgLyAxMCkgKiAoQ0lSQ0xFX1JBRElBTlMgLyBDSVJDTEVf
REVHUkVFUyk7DQoNCiAgLy8gQ2FsY3VsYXRlIHRoZSBkZWx0YSBjaGFuZ2VzIGluIHBvc2l0
aW9uIGZvciBlYWNoIG9mIHRoZSANCiAgLy8geCwgeSBhbmQgeiBheGVzLiANCg0KICBkZWx0
YV94X2Nvb3JkID0gZGlzdGFuY2UgKiBzaW4oeWF3X3JhZGlhbnMpOyANCiAgZGVsdGFfel9j
b29yZCA9IGRpc3RhbmNlICogY29zKHlhd19yYWRpYW5zKTsgDQoNCiAgLy8gQXBwbHkgdGhl
IGRlbHRhIGNoYW5nZXMgdG8gdGhlIGV4aXN0aW5nIHBvc2l0aW9uLg0KICAvLyBDaGVja2lu
ZyBmb3IgdGhlIHdvcmxkIGJvdW5kYXJpZXMuIA0KDQogICpteV94ID0gYXZhdGFyX3ggKyBk
ZWx0YV94X2Nvb3JkOyANCiAgaWYgKCpteV94ID4gTUFYX1hfQ09PUkQpIHsgDQoNCiAgICAq
bXlfeCA9IE1BWF9YX0NPT1JEOyANCiAgfSANCiAgZWxzZSBpZiAoKm15X3ggPCBNSU5fWF9D
T09SRCkgeyANCg0KICAgICpteV94ID0gTUlOX1hfQ09PUkQ7IA0KICB9IA0KDQogICpteV96
ID0gYXZhdGFyX3ogKyBkZWx0YV96X2Nvb3JkOyANCiAgaWYgKCpteV96ID4gTUFYX1pfQ09P
UkQpIHsgDQoNCiAgICAqbXlfeiA9IE1BWF9aX0NPT1JEOyANCiAgfSANCiAgZWxzZSBpZiAo
Km15X3ogPCBNSU5fWl9DT09SRCkgeyANCg0KICAgICpteV96ID0gTUlOX1pfQ09PUkQ7IA0K
ICB9IA0KDQogIC8vIEFsdGl0dWRlIHN0YXlzIHRoZSBzYW1lLiANCg0KICAqbXlfYWx0aXR1
ZGUgPSBhdmF0YXJfYWx0aXR1ZGU7IA0KfQ0KDQp2b2lkDQphdmF0YXJfY2hhbmdlKCkgeyAg
ICAgICAgICAgIC8vIENhbGxlZCB3aGVuIGF2YXRhciBtb3Zlcy4gDQoNCiAgaW50IHNlc3Np
b247DQogIGludCBkaXN0Ow0KDQogIHN3aXRjaChyb2JvdF9zdGF0ZSkgew0KICBjYXNlKFdB
SVRJTkcpOg0KDQogICAgLy8gY2FsY3VsYXRlIGRpc3RhbmNlIHVzaW5nIGRpc3RhbmNlIGNh
bGN1bGF0aW9uIGFib3ZlLiANCg0KICAgIGRpc3QgPSBkaXN0YW5jZSgpOw0KDQogICAgcHJp
bnRmKCJEaXN0YW5jZSAlZC5cbiIsIGRpc3QpOw0KDQogICAgaWYgKGRpc3QgPCA1MDApIHsg
Ly8gNSBtZXRlcnMuDQoNCiAgICAgIHJvYm90X3N0YXRlID0gRk9MTE9XSU5HOyANCg0KICAg
ICAgLy8gUmVwcmVzZW50cyA2MCBsb29wcyBhcm91bmQgdGhlIDEgc2Vjb25kIGxvb3AuIEZv
bGxvdyBmb3IgYSBtaW51dGUuDQoNCiAgICAgIHRpbWVyID0gZm9sbG93X3RpbWU7DQogICAg
ICBhdmF0YXJfc2Vzc2lvbiA9IGF3X2ludChBV19BVkFUQVJfU0VTU0lPTik7IA0KICAgICAg
YXZhdGFyX3ggPSBhd19pbnQoQVdfQVZBVEFSX1gpOyANCiAgICAgIGF2YXRhcl96ID0gYXdf
aW50KEFXX0FWQVRBUl9aKTsgDQogICAgICBhdmF0YXJfYWx0aXR1ZGUgPSBhd19pbnQoQVdf
QVZBVEFSX1kpOyANCiAgICAgIGF2YXRhcl95YXcgPSBhd19pbnQoQVdfQVZBVEFSX1lBVyk7
IA0KICAgIH0NCiAgICBicmVhazsNCg0KICBjYXNlKEZPTExPV0lORyk6DQoNCiAgICBwcmlu
dGYoIkZvbGxvd2luZ1xuIik7DQoNCiAgICAvLyBJZiB0aGUgYXZhdGFyIHdlIGFyZSBmb2xs
b3dpbmcgaGFzIG1vdmVkIHRoZW4gZ2V0IGl0cyBuZXcgcG9zaXRpb24uDQoNCiAgICBzZXNz
aW9uID0gYXdfaW50KEFXX0FWQVRBUl9TRVNTSU9OKTsNCiAgICBpZiAoc2Vzc2lvbiA9PSBh
dmF0YXJfc2Vzc2lvbikgew0KDQogICAgICBhdmF0YXJfeCA9IGF3X2ludChBV19BVkFUQVJf
WCk7IA0KICAgICAgYXZhdGFyX3ogPSBhd19pbnQoQVdfQVZBVEFSX1opOyANCiAgICAgIGF2
YXRhcl9hbHRpdHVkZSA9IGF3X2ludChBV19BVkFUQVJfWSk7IA0KICAgICAgYXZhdGFyX3lh
dyA9IGF3X2ludChBV19BVkFUQVJfWUFXKTsgDQogICAgfQ0KICB9DQp9IA0KDQp2b2lkDQpt
b3ZlKGludCB4LCBpbnQgeiwgaW50IGFsdGl0dWRlLCBpbnQgeWF3KSB7DQoNCiAgaW50IHJj
Ow0KDQogIGF3X2ludF9zZXQgKEFXX01ZX1gsIHgpOw0KICBhd19pbnRfc2V0IChBV19NWV9a
LCB6KTsNCiAgYXdfaW50X3NldCAoQVdfTVlfWSwgYWx0aXR1ZGUpOw0KICBhd19pbnRfc2V0
IChBV19NWV9ZQVcsIHlhdyk7DQogIGlmIChyYyA9IGF3X3N0YXRlX2NoYW5nZSAoKSkgew0K
ICAgIHByaW50ZiAoIlVuYWJsZSB0byBjaGFuZ2Ugc3RhdGUgKHJlYXNvbiAlZClcbiIsIHJj
KTsNCiAgICBleGl0ICgxKTsNCiAgfQ0KfQ0KDQptYWluIChpbnQgYXJnYywgY2hhciAqYXJn
dltdKSB7DQoNCiAgaW50IGluc3RhbmNlID0gMDsNCiAgaW50IHJjOw0KICBpbnQgZmluaXNo
ZWQ7DQoNCiAgcHJpbnRmKCJGb2xsb3dlclxuIik7DQoNCiAgLyogY2hlY2sgY29tbWFuZCBs
aW5lICovDQogIGlmIChhcmdjIDwgMykgew0KICAgIHByaW50ZiAoIlVzYWdlOiAlcyBudW1i
ZXIgcGFzc3dvcmRcbiIsIGFyZ3ZbMF0pOw0KICAgIGV4aXQgKDEpOw0KICB9DQoNCiAgLyog
aW5pdGlhbGl6ZSBBY3RpdmUgV29ybGRzIEFQSSAqLw0KICBpZiAocmMgPSBhd19pbml0IChB
V19CVUlMRCkpIHsNCiAgICBwcmludGYgKCJVbmFibGUgdG8gaW5pdGlhbGl6ZSBBUEkgKHJl
YXNvbiAlZClcbiIsIHJjKTsNCiAgICBleGl0ICgxKTsNCiAgfQ0KDQogIC8qIGluc3RhbGwg
aGFuZGxlciBmb3IgYXZhdGFyX2FkZCBldmVudCAqLw0KICBhd19ldmVudF9zZXQgKEFXX0VW
RU5UX0FWQVRBUl9DSEFOR0UsIGF2YXRhcl9jaGFuZ2UpOw0KDQogIC8qIGNyZWF0ZSBib3Qg
aW5zdGFuY2UgKi8NCiAgaWYgKHJjID0gYXdfY3JlYXRlICgwLCAwLCAwKSkgew0KICAgIHBy
aW50ZiAoIlVuYWJsZSB0byBjcmVhdGUgYm90IGluc3RhbmNlIChyZWFzb24gJWQpXG4iLCBy
Yyk7DQogICAgZXhpdCAoMSk7DQogIH0NCg0KICAvKiBsb2cgYm90IGludG8gdGhlIHVuaXZl
cnNlICovDQogIGF3X2ludF9zZXQgKEFXX0xPR0lOX09XTkVSLCBhdG9pIChhcmd2WzFdKSk7
DQogIGF3X3N0cmluZ19zZXQgKEFXX0xPR0lOX1BSSVZJTEVHRV9QQVNTV09SRCwgYXJndlsy
XSk7DQogIGF3X3N0cmluZ19zZXQgKEFXX0xPR0lOX0FQUExJQ0FUSU9OLCAiU0RLIFNhbXBs
ZSBBcHBsaWNhdGlvbiAjMSIpOw0KICBhd19zdHJpbmdfc2V0IChBV19MT0dJTl9OQU1FLCAi
R3JlZXRlckJvdCIpOw0KICBpZiAocmMgPSBhd19sb2dpbiAoKSkgew0KICAgIHByaW50ZiAo
IlVuYWJsZSB0byBsb2dpbiAocmVhc29uICVkKVxuIiwgcmMpOw0KICAgIGV4aXQgKDEpOw0K
ICB9DQoNCiAgLyogbG9nIGJvdCBpbnRvIHRoZSB3b3JsZCBjYWxsZWQgImJldGEiICovDQog
IGlmIChyYyA9IGF3X2VudGVyICgiQmV0YSIsIDApKSB7DQogICAgcHJpbnRmICgiVW5hYmxl
IHRvIGVudGVyIHdvcmxkIChyZWFzb24gJWQpXG4iLCByYyk7DQogICAgZXhpdCAoMSk7DQog
IH0NCg0KICAvKiBhbm5vdW5jZSBvdXIgcG9zaXRpb24gaW4gdGhlIHdvcmxkICovDQogIG1v
dmUocmVzZXRfeCwgcmVzZXRfeiwgMCwgMTgwMCk7DQoNCiAgZm9sbG93X3ggPSAoZmxvYXQp
cmVzZXRfeDsNCiAgZm9sbG93X3ogPSAoZmxvYXQpcmVzZXRfejsNCiAgZm9sbG93X2FsdGl0
dWRlID0gMDsNCiAgZm9sbG93X3lhdyA9IDE4MDA7DQoNCiAgLyogbWFpbiBldmVudCBsb29w
ICovDQogIHRpbWVyID0gMDsgDQogIGF2YXRhcl9zZXNzaW9uID0gLTE7IA0KICByb2JvdF9z
dGF0ZSA9IFdBSVRJTkc7DQogIGZpbmlzaGVkID0gRkFMU0U7DQogIHdoaWxlICghZmluaXNo
ZWQpIHsgDQoNCiAgICByYyA9IGF3X3dhaXQoMTAwMCk7DQogICAgaWYgKHJvYm90X3N0YXRl
ID09IEZPTExPV0lORykgeyANCiAgICANCiAgICAgIHByaW50ZigiRm9sbG93XG4iKTsNCg0K
ICAgICAgLy8gTW92ZSByb2JvdCBwb3NpdGlvbiB1c2luZyBmb2xsb3dpbmcgZnVuY3Rpb24g
YWJvdmUuIA0KDQogICAgICBmb2xsb3coJmZvbGxvd194LCAmZm9sbG93X3osICZmb2xsb3df
YWx0aXR1ZGUsICZmb2xsb3dfeWF3LA0KCSAgICAgKGZsb2F0KWF2YXRhcl94LCAoZmxvYXQp
YXZhdGFyX3osDQoJICAgICAoZmxvYXQpYXZhdGFyX2FsdGl0dWRlLCAoZmxvYXQpYXZhdGFy
X3lhdyk7DQoNCiAgICAgIG1vdmUoKGludClmb2xsb3dfeCwgKGludClmb2xsb3dfeiwNCgkg
ICAoaW50KWZvbGxvd19hbHRpdHVkZSwgKGludClmb2xsb3dfeWF3KTsNCg0KICAgICAgcHJp
bnRmKCJNb3ZlZCB0byAlLjJmeCUuMmYrJS4yZi5cbiIsDQoJICAgICBmb2xsb3dfeCwgZm9s
bG93X3osIGZvbGxvd19hbHRpdHVkZSk7DQoNCiAgICAgIHRpbWVyLS07IA0KICAgICAgaWYg
KHRpbWVyIDw9IDApIHsgDQoNCglyb2JvdF9zdGF0ZSA9IFdBSVRJTkc7IA0KCWF2YXRhcl9z
ZXNzaW9uID0gLTE7IA0KDQoJLy8gcmVzZXQgcG9zaXRpb24NCgltb3ZlKHJlc2V0X3gsIHJl
c2V0X3osIDAsIDE4MDApOw0KCWZvbGxvd194ID0gKGZsb2F0KXJlc2V0X3g7DQoJZm9sbG93
X3ogPSAoZmxvYXQpcmVzZXRfejsNCglmb2xsb3dfYWx0aXR1ZGUgPSAwOw0KCWZvbGxvd195
YXcgPSAxODAwOw0KICAgICAgfSANCiAgICB9IA0KICB9IA0KDQogIC8qIGNsb3NlIGV2ZXJ5
dGhpbmcgZG93biAqLw0KICBhd19kZXN0cm95ICgpOw0KICBhd190ZXJtICgpOw0KICByZXR1
cm4gMDsNCn0NCg==
--------------5F48D06410C8F2FE04DFE96A--

Moving the bots

Dec 3, 1998, 2:07am
I don't understand. A renderware extension? Like .rwx?

The c file has the extension of ".c" and the Makefile has no extension. Makefile is the
standard name that the command make looks for when you run it. You can of coarse call
your makefile anything you like but you would have to add the "-f <file name>"
parameter to tell the make command which file to use.

o Copy both files into one diretory
o cd to that directory
o export AWSDK=<path were you installed aw.h>
o make sure that the aw.dll is in a directory in your PATH
o make
o follower <number> <priv>

Edward Sumerfield.

[View Quote] > why is the makefile in a renderware extension? How can it work?
>
[View Quote]

Moving the bots

Dec 3, 1998, 12:03pm
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
I'm glad it worked for you.
<P>What did you mean by "converted to standard GNU format"?
[View Quote]

Moving the bots

Dec 4, 1998, 1:54am
--------------F23D54E14A43430991BB801A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I see what you mean now. I agree, that was how we started the GNU development
process. However, since then we have worked out some simpler ways of
interacting with the dll.

What you are doing in your code is loading the DLL, and retrieving the
addresses of all the functions from within it so that they can be called. It
seems there are some standard tools for dynamically generating this "wrapper"
code so that you don't have to bother with all that extra coding.

With VC++ there is implib, Borland's C++ there is impdef and we discovered the
following slightly clugy solution for the GNU gcc compiler.

All it is doing is creating a .lib file that contains all the code for loading
the dll and working out the function addresses. So all you have to do is link
with this new lib and you are set. This method drastically reduces your code
maintenance problem and removes the need to add all the GetProcAddress stuff.

The following is copied from a thread above titled "Cygwin" started by Josh.

==============================================

There is a utility called "impdef" (apparently the same name as a similar
Borland
tool) that lists the methods in a dll file. You can find it at

http://www.geocities.com/Tokyo/Towers/6162/gcc-extra.html

Once you have this you must run it from a DOS prompt. Doesn't
work from a bash shell.

impdef aw.dll > awsdk.def

This generates an awsdk.def file which is just a text file that lists the
functions
in the dll file. Now you can use the Cygwin utility dlltool to read this def
file
and the dll file and create a new Cygwin compatible lib file.

dlltool --def awsdk.def --dllname aw.dll --output-lib awsdk.lib

==============================================

Edward Sumerfield.

[View Quote] > The way you have your AWCPP written, you need the lib file to make it
> work, and the makefile. The normal way of running the sdk through the
> GNU is bypassing the aw.lib through the aw.dll defining the methods
> manually. I've been using this system for a while, so I feel comfortable
> with the layout.
> I assume you've seen the source of GNU sdk bots that have done that.
> (ie, "aw_int" is "(AWInt)").
> There's an example source in a higher thread...
>
[View Quote] --------------F23D54E14A43430991BB801A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I see what you mean now. I agree, that was how we started the GNU development
process. However, since then we have worked out some simpler ways of interacting
with the dll.
<p>What you are doing in your code is loading the DLL, and retrieving the
addresses of all the functions from within it so that they can be called.
It seems there are some standard tools for dynamically generating this
"wrapper" code so that you don't have to bother with all that extra coding.
<p>With VC++ there is implib, Borland's C++ there is impdef and we discovered
the following slightly clugy solution for the GNU gcc compiler.
<p>All it is doing is creating a .lib file that contains all the code for
loading the dll and working out the function addresses. So all you have
to do is link with this new lib and you are set. This method drastically
reduces your code maintenance problem and removes the need to add all the
GetProcAddress stuff.
<p>The following is copied from a thread above titled "Cygwin" started
by Josh.
<center>
<p>==============================================</center>

<p>There is a utility called "impdef" (apparently the same name as a similar
Borland
<br>tool) that lists the methods in a dll file. You can find it at
<p>&nbsp;&nbsp;&nbsp; <A HREF="http://www.geocities.com/Tokyo/Towers/6162/gcc-extra.html">http://www.geocities.com/Tokyo/Towers/6162/gcc-extra.html</A>
<p>Once you have this you must run it from a DOS prompt. Doesn't
<br>work from a bash shell.
<p>&nbsp;&nbsp;&nbsp; impdef aw.dll > awsdk.def
<p>This generates an awsdk.def file which is just a text file that lists
the functions
<br>in the dll file. Now you can use the Cygwin utility dlltool to read
this def file
<br>and the dll file and create a new Cygwin compatible lib file.
<p>&nbsp;&nbsp;&nbsp; dlltool --def awsdk.def --dllname aw.dll --output-lib
awsdk.lib
<center>
<p>==============================================</center>

<p>Edward Sumerfield.
[View Quote] --------------F23D54E14A43430991BB801A--

can someone test this for me... - 37kb

Nov 22, 1998, 2:10pm
Excellent work. How did you do that?

I downloaded your lib and put it in an empty directory with the same bot.C we had
earlier, it compiled fine and ran with no DLL errors.

If you do a "strings awsdk.lib | grep dll" it shows that there is a string in the
lib "aw.dll". If you do it on my lib it returns "F:/etc...".

With no path in the lib I must be using my PATH environment variable to find the
aw.dll.

So how did you make the dlltool create a lib with no path on the dll.

Edward Sumerfield.

[View Quote] > Ok I did as edward said and now I wanna see if I can get this .lib to
> compile on others comps and not come up saying they need the same dir I
> had my dll in so if you have Cygwin32 download this and link it to your
> bot and compile and send me the results when you run the bot.
>
> ------------------------------------------------------------------------------
> Name: awsdk.lib
> awsdk.lib Type: unspecified type (application/octet-stream)
> Encoding: base64

can someone test this for me... - 37kb

Nov 23, 1998, 1:59am
It worked wonderfully, thanks. I will have to migrate my AWSDK.C class over to using
this method. It will be much easier to maintain.

[View Quote] > when I did -dllname I put -dllname aw.dll and not -dllname e:/bytebot/aw.dll
> that way it would look for aw.dll and not e:/bytebot/aw.dll
>
[View Quote]

How can I execute "aworld.exe" in other program?

Nov 23, 1998, 9:39am
There is a standard C library call system("command") that will start a program
for you. I seem to remember it is a blocking call, not sure if this is what
you want.

Edward Sumerfield

[View Quote] > How can I execute "aworld.exe" in other program?
> I try to execute in my program with ::CreateProcess() API.
> But, I can see Just Welcome Dialog Box.
> Never enter Active World.
> I don't understand why can't.

Multiple Instances

Nov 25, 1998, 11:59am
Ahh, a Java object model. Can I get a look?

More comments below.

Edward Sumerfield

[View Quote] > [snip]

> For further reference, I *could* put in multiple instance support into
> Java so that the C SDK only saw one handler for each event, but the
> Java side would build up a database of handlers and sort through them
> as necessary.

The word database seems overkill. All you need is an array of { instance,
object } that the single installed callback function looks in to work out which
object to callback.

I wrote a class call Callback and an interface called CallbackAvatarIF. The
Callback class has a static method that it tells the SDK to call when an event
is generated. It also has a setEvent(instance, CallbackAvatarIF *) methods
that allows a robot to install its object as a called back object. Sample using
Java syntax (if I remember it right)

class Bot implements CallbackAvatarIF {
Bot() {
Callback::setEvent(instance, this); /* Note that this must be a
static class. */
}
void avatar_add() {
/* Callback function. Called from Callback class */
}
void avatar_change() {
/* Callback function. Called from Callback class */
}
void avatar_delete() {
/* Callback function. Called from Callback class */
}
}

I think this is a very pretty way of routing events to the appropriate object
and it is essential for any OO SDK to implement such a strategy. If you do not
implement it then the programmer will have to implement their own anyway for
every multi-instance bot they create.

Think back to the first event model in Java. the "handle_events" method that
was called for every object that generated an event from a frame. The case
statement that resulted from that was really ugly.

My current implementation in the AWCPP is wrong because I didn't make the
Callback class static. This will be fixed for the AWCPP 0.4 release.

> But, this seems pretty ugly to me. Are there any plans
> to make handlers instance dependent?

Can't be done in c. so I expect this will take a long time.

> [snip]
>
> glen
> --
> glen e. p. ropella =><= Hail Eris!
> the swarm corporation W:(505) 995-0818
> <gepr at swarm.com> H:(505) 424-0448

Multiple Instances

Nov 29, 1998, 1:31pm
[View Quote] > Edward,
>
> Edward Sumerfield schrieb in Nachricht <365C0D30.17FF6C0F at poboxes.com>...
>
> Did you manage to accidently pass a non static C++ member function as the
> call back function and a) the compiler did not complain and b) it worked
> somehow ?

No. I use the extern "C" {} method to prevent the callback functions from
getting name mangled. So this static/global C function is what is called by
the sdk then it manages the searching of the static array of objects by
instance number to calls the appropriate method to effect the callback. See
the code in Callback.C

> Just curious.... I just remember my early attempts on passing a
> pointer-to-member as function pointers, which were all blocked by the
> compiler at first sight. coming from a c background took me a while to
> figure why it doesn't make sense to even try :)

You are right the GNU compiler traps this as well. It not conceptually
possible once you understand the difference between object instances and
static functions.

> Walter

Format of TimeStamp field

Dec 1, 1998, 7:05pm
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
What timestamp field?
<P>If you are referring to the standard C time_t which is actually just
an int then take a look at the localtime function. It returns you the following
structure.
<P>struct tm
<BR>{
<BR>&nbsp; int tm_sec;
<BR>&nbsp; int tm_min;
<BR>&nbsp; int tm_hour;
<BR>&nbsp; int tm_mday;
<BR>&nbsp; int tm_mon;
<BR>&nbsp; int tm_year;
<BR>&nbsp; int tm_wday;
<BR>&nbsp; int tm_yday;
<BR>&nbsp; int tm_isdst;
<BR>};
<P>Edward Sumerfield.
[View Quote]

Format of TimeStamp field

Dec 2, 1998, 3:05am
The standard C time is also an int, typedef'ed to time_t, that is a number of
seconds since some base date. Is that not 1970 aswell? I seem to remember that
1970 was the unix base time.

Edward Sumerfield

[View Quote] > Thats in seconds since 1970 :)
> - Ima
>
> Lucio Pascarelli <lucio at pascarelli.com> wrote in article
> <36646015.0 at homer>...
> sorry, I was unclear.
>
> I am referring to the AW_OBJECT_BUILD_TIMESTAMP attribute returned by the
> AW_QUERY. It is a long integer which I am trying to decode into a Time
> field for a database :)
>
> Luco
[View Quote]

Format of TimeStamp field

Dec 2, 1998, 3:09am
Try and find out on which line the program crashes. Either by adding printf
statements until you narrow it down or by using the debugger and stepping
through until it crashes.

You describe a problem that may have nothing to do with a time function.

[View Quote] > I have a recent question on something of this. In a thread farther up I
> was asking about the time(). I got the example given to run, but when I
> tried to get the bot to timestamp the console window when someone came
> in, everytime someone entered, it would just crash with a core dump. I
> can post the contents of the dump if it's necissary... any reason why
> this doesn't work?
>
[View Quote]

Bots and FTP?

Dec 4, 1998, 11:44am
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
When you say "log to a file" I assume you mean write to it? FTP allows
you to move entire files between machines. It doesn't supply a file read/write
interface.
<p>If you want to log to a local file then move it to another machine that
would be possible. I know that MFC has an FTP class that should allow you
to do this. Though you should wait for Walter to give you the details.
<p>If you are in a Windows environment you can also do this by logging
to a local file and then copying the file into a shared directory. This
allows a fairly fast logging mechanism and a simple file move. If your
server is Lynx then Samba is a product that allows disk sharing with windows
using the NFS protocols.
<p>If you really want to write to a file on a remote machine then I would
suggest one of the following:
<p>1.&nbsp;&nbsp;&nbsp; Again, in a windows environment, a simple solution
would be to share the remote directory onto the logging machine. It would
not be too much of an overhead to log to a file on the remote disk. Keep
in mind that these write operations will be blocking operations and that
a write to a network drive will be much slower than a write to a local
file. The delay added to you logger will depend on how much you want to
write to the file.
<p>2.&nbsp;&nbsp;&nbsp; Another solution would be to write a little logging
server that listens on some socket, receives connections and writes anything
that is sent to it to a local file. Then your logger would just have to
connect to the log server at startup and write log messages to it. Less
overhead than a network disk but still some overhead.
<p>3.&nbsp;&nbsp;&nbsp; The most efficient central logging design involves
a proxy log server that runs on the local machine. This proxy logger would
receive log messages from from processes on the same machine. It would
be responsible for forwarding them to a remote, central logging server.
This design decouples the time critical logger application from the non
time critical logging of messages operation. Ideally some shared memory
message exchange should be devised between the logger and the proxy log
server for optimum speed.
<p>I feel that I have said too much.
<p>Edward Sumerfield.
[View Quote]

Bots and FTP?

Dec 5, 1998, 1:24pm
If you want to, go for it.

A simple solution to the ftp problem would be to use a bat file with the
appropriate ftp command in it. Then use the C system("command.bat") to run it.

The standard windows ftp client will do this for you.


[View Quote] > What about having the program download the log off the FPT server than
> writing to it an when you complete a session it uploads the log to the
> server?
>
[View Quote]

Bots and FTP?

Dec 5, 1998, 3:28pm
I don't quite understand the architecture you are proposing.

Bot -> web server -> cgi -> log file or html file.

If you want to write a cgi as a remote logging server that would be fine. Your bot
would have to be a socket client, connect to the web server, talk HTTP to it passing
the text to be written encoded as some kind of form field or get parameter. Then the
cgi would parse the HTTP input fields and write to the log file.

Some things to watch out for. A CGI program is started for every interaction with the
web server so it is possible to have two bots connecting to the server at the same
time which would mean some kind of file locking error if you are lucky or just a
corrupted log file.

The CGI standard is still extensively on the net these days but there are a number of
newer standards that might make your life easier.

Microsoft's ASP files allow you to write script to manage the requests to a web
server, its easy to write and saves you all the hassles of parsing the HTTP protocol
messages.

Java Servlets supply a nice standard way of plugging in functionality to a web
server.

However, there are a number of free C based CGI libraries floating around that would
help a great deal.

Its up to you. Good luck.

[View Quote] > k, I was also thinking of getting a cgi that wrote to a html file on the net, and
> when the program was started it would send info tot he cgi which would than write
> the log...
>
[View Quote]

Bots and FTP?

Dec 11, 1998, 5:00pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I think I'll take that as a compliment Walter. Thank you.
<p>You see the thing is, I am a high paid computer consultant whose current
assignment is printing a sorting some reports. While totally frustrating
and mind numbing, it does leave me with a fare amount of time on my hands.
<p>Here's wishing for an interesting job one of these days.
<p>Edward Sumerfield.
[View Quote]

SDK on VB??

Dec 7, 1998, 12:58pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I hope you made the VB SDK party on Sat night at 2am VRT. Though I am not
sure which night/morning that was.
<p>Yes there is a great deal of VB bot stuff floating around. Check the
old threads.
<p>Edward Sumerfield.
[View Quote]

chess games

Dec 7, 1998, 12:55pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
It could definitely be done.
<p>You wouldn't have to label the pieces. The program could keep track
of all the pieces and move them as directed by the players.
<p>Your biggest design issue is the interface between the players and the
program. The pieces could be moved just by pushing them around the board
or you could enter kb4->qp1 in the chat line. There are a few board addressing
schemes to choose from.
<p>Go for it Dean.
<p>Edward Sumerfield.
[View Quote]

chess games

Dec 7, 1998, 5:51pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
If you can code pascal then you will pick up C in no time.
<p>I checked Thierry's web site and found GNU Chess with source code and
everything. It doesn't look too hard to change the InputCommand function
over to one that reads the chat line in a browser.
[View Quote]

chess games

Dec 8, 1998, 1:33am
And a cool idea it was. I have downloaded the GNU Chess already. Give me a month or
two and you never know what might happen.

[View Quote] > I will just ask ImaGenius or ByteMe. I do not have fond memories of
> programming and do not want to mess with it. I posted in hopes that i could
> perhaps give somebody a good idea to work on, because games are in demand and I
> would like to see them done.
>
[View Quote]

chess games

Dec 11, 1998, 5:06pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
So, Daniel is an avatar that moves chess pieces around? I like the idea
visually but its an extension of the chat solution isn't it? Just with
a visual component.
<p>Well, personally, I want to complete AWCPP 0.4 first and release a herd
of deer. That will complete the avatar management portion of the AWCPP.
Then I can get into object manipulation stuff and chess may be a good entry
app in that field.
[View Quote]

chess games

Dec 11, 1998, 5:52pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
[View Quote]

chess games

Dec 11, 1998, 7:03pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
I hope we don't have to get to entire worlds just for one game. I would
think it would be better for a world like AWGames to run tournaments and
start and stop the games bots as appropriate. Its not like chess is going
to take up much land.
[View Quote] </body>
</html>

MonopolyBot

Dec 11, 1998, 6:56pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Make the board vertical so that people don't have to fly and look down.
You could also curve it so that an auditorium could be built at a focal
point. Using this plan you could make any bot games dynamically build a
board around an auditorium when they are started.
[View Quote]

Gesture problems

Dec 14, 1998, 2:11am
The following source is supposed to initiate a gesture every time it hears
some chat message. However, it only does it once after the program starts and
never again. What am I doing wrong?

#include <stdio.h>
#include <stdlib.h>
#include <aw.h>

void avatar_chat() {
int rc;
printf("chatting\n");
aw_int_set (AW_MY_GESTURE, 5);
if (rc = aw_state_change ()) {
printf ("Unable to change state (reason %d)\n", rc);
exit (1);
}
}

main (int argc, char *argv[]) {

int instance = 0;
int rc;
int finished;

printf("Gesture\n");

/* check command line */
if (argc < 3) {
printf ("Usage: %s number password\n", argv[0]);
exit (1);
}

/* initialize Active Worlds API */
if (rc = aw_init (AW_BUILD)) {
printf ("Unable to initialize API (reason %d)\n", rc);
exit (1);
}

/* install handler for avatar_add event */
aw_event_set (AW_EVENT_CHAT, avatar_chat);

/* create bot instance */
if (rc = aw_create (0, 0, 0)) {
printf ("Unable to create bot instance (reason %d)\n", rc);
exit (1);
}

/* log bot into the universe */
aw_int_set (AW_LOGIN_OWNER, atoi (argv[1]));
aw_string_set (AW_LOGIN_PRIVILEGE_PASSWORD, argv[2]);
aw_string_set (AW_LOGIN_APPLICATION, "SDK Sample Application #1");
aw_string_set (AW_LOGIN_NAME, "GreeterBot");
if (rc = aw_login ()) {
printf ("Unable to login (reason %d)\n", rc);
exit (1);
}

/* log bot into the world called "beta" */
if (rc = aw_enter ("Beta", 0)) {
printf ("Unable to enter world (reason %d)\n", rc);
exit (1);
}

/* announce our position in the world */
aw_int_set (AW_MY_TYPE, 12); // choose Aaron
aw_int_set (AW_MY_X, 100000);
aw_int_set (AW_MY_Z, 100000);
aw_int_set (AW_MY_Y, 0);
aw_int_set (AW_MY_YAW, 1800);
if (rc = aw_state_change ()) {
printf ("Unable to change state (reason %d)\n", rc);
exit (1);
}

aw_wait(-1);

/* close everything down */
aw_destroy ();
aw_term ();
return 0;
}

Edward Sumerfield

Gesture problems

Dec 14, 1998, 11:31am
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Its in the avatar_chat function. Specifically, the following two lines.
<p>&nbsp;&nbsp; aw_int_set (AW_MY_GESTURE, 5);
<br>&nbsp;&nbsp; if (rc = aw_state_change ()) {
[View Quote]

Gesture problems

Dec 14, 1998, 5:01pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Cool. So If I do
<p>&nbsp;&nbsp;&nbsp; aw_int_set(AW_MY_GESTURE, 0);
<br>&nbsp;&nbsp;&nbsp; aw_state_change();
<br>&nbsp;&nbsp;&nbsp; aw_int_set(AW_MY_GESTURE, 5);
<br>&nbsp;&nbsp;&nbsp; aw_state_change();
<p>It will work every time?
[View Quote]

Gesture problems

Dec 14, 1998, 6:35pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
I see. Its a perspective change from me. I keep making the mistake of see
actions as changes in the server but really they are changes in other browsers
propagated by a 1 second polling server.
<p>You know this means I am going to have to rethink my class library infrastructure
again. Doh.
<p>A performance question for you. You say that the server updates the
browsers every second. Is there any kind of propagation delay noticed as
the number of browsers increases or does the max logins per world keep
this to a minimum.
<p>You recommend resetting the gesture after 5 seconds. A gesture sequence
takes a certain amount of time to run in a browser. If I set to gesture
to 5 and reset to 0 in two seconds will it stop the currently running sequence?
<p>Is there some timing advantage to noting long gesture sequence compared
to short sequences and varying the reset time interval appropriately?
[View Quote] </body>
</html>

1  ...  2  3  4  5  6  7  ...  9  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2022. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn