Board ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
edward sumerfield // User Search
edward sumerfield // User SearchMoving the botsNov 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 botsDec 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 botsDec 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 botsDec 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 botsDec 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 botsDec 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> <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> 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> 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... - 37kbNov 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... - 37kbNov 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 InstancesNov 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 InstancesNov 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 fieldDec 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> int tm_sec; <BR> int tm_min; <BR> int tm_hour; <BR> int tm_mday; <BR> int tm_mon; <BR> int tm_year; <BR> int tm_wday; <BR> int tm_yday; <BR> int tm_isdst; <BR>}; <P>Edward Sumerfield. [View Quote] Format of TimeStamp fieldDec 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 fieldDec 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. 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. 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. 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 gamesDec 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 gamesDec 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 gamesDec 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 gamesDec 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 gamesDec 11, 1998, 5:52pm
chess gamesDec 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> MonopolyBotDec 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 problemsDec 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 problemsDec 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> aw_int_set (AW_MY_GESTURE, 5); <br> if (rc = aw_state_change ()) { [View Quote] Gesture problemsDec 14, 1998, 5:01pm
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html> Cool. So If I do <p> aw_int_set(AW_MY_GESTURE, 0); <br> aw_state_change(); <br> aw_int_set(AW_MY_GESTURE, 5); <br> aw_state_change(); <p>It will work every time? [View Quote] Gesture problemsDec 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> |
