.:: Bots United ::.  
filebase forums irc server wiki web
cubebot epodbot fritzbot gravebot grogbot hpbbot ivpbot jkbotti joebot
meanmod podbotmm racc rcbot realbot sandbot shrikebot soulfathermaps waypoints yapb

Go Back   .:: Bots United ::. > Cyborg Factory > United Bot
United Bot The ultimate beast is being given birth right here! Half-Life 2

Closed Thread
 
Thread Tools
Unreal driver discussion summary
Old
  (#1)
botmeister
Ex-Council Member
 
botmeister's Avatar
 
Status: Offline
Posts: 1,090
Join Date: Nov 2003
Location: Canada
Default Unreal driver discussion summary - 06-04-2004

[Edited by a moderator: this thread has been closed as it contains a summary of the discussion that has been held about the best way to communicate with the Unreal engine, for further reference. This discussion is now followed up in the "Unreal engine driver communication" thread.]
-------------------


Crazy idea #1

Create an interface between game engine and the external C++ driver using a shared file. This may be slow, but it could work provided the game engine provides the means to write code that allows files to be read/written to.


Maker of the (mEAn) Bot.Admin Manager

"In theory, there is no difference between theory and practice. But, in practice, there is." - Jan L.A. van de Snepscheut

Last edited by Pierre-Marie Baty; 08-04-2004 at 15:22..
   
Re: United Bot philosophy and roadmap.
Old
  (#2)
Pierre-Marie Baty
Roi de France
 
Pierre-Marie Baty's Avatar
 
Status: Offline
Posts: 5,049
Join Date: Nov 2003
Location: 4643'60N 043'0W 0.187A
Default Re: United Bot philosophy and roadmap. - 06-04-2004

Quote:
Originally Posted by botmeister
Crazy idea #1

Create an interface between game engine and the external C++ driver using a shared file. This may be slow, but it could work provided the game engine provides the means to write code that allows files to be read/written to.
Are you nuts ??? 8o
Disk I/O access times absolutely prohibit this method.

although..... Extension to Crazy idea #1: what about setting up a tiny RAM drive just for this ?

*edit* sounds barbaric, though... the system will still need to allocate/deallocate millions of file descriptors per second... O joy...

@botman and botmeister: I agree, we should take this to a dedicated forum. Already 2 Council members agreeing here. One more and the idea is validated.



RACC home - Bots-United: beer, babies & bots (especially the latter)
"Learn to think by yourself, else others will do it for you."

Last edited by Pierre-Marie Baty; 06-04-2004 at 21:48..
   
Re: United Bot philosophy and roadmap.
Old
  (#3)
Lazy
Member
 
Lazy's Avatar
 
Status: Offline
Posts: 236
Join Date: Jan 2004
Location: Toronto, Ontario, Canada
Default Re: United Bot philosophy and roadmap. - 06-04-2004

What's with the disk I/O?
Just use ReadProcessMemory and WriteProcessMemory on an address you allocate inside the game.

Just use file i/o once to define where the memory is located.

Actually, I'm not sure now. I really need to get more sleep.
   
Re: United Bot philosophy and roadmap.
Old
  (#4)
botmeister
Ex-Council Member
 
botmeister's Avatar
 
Status: Offline
Posts: 1,090
Join Date: Nov 2003
Location: Canada
Default Re: United Bot philosophy and roadmap. - 07-04-2004

Quote:
Are you nuts ???
Absolutely! Next question please.

Quote:
Disk I/O access times absolutely prohibit this method.although..... Extension to Crazy idea #1: what about setting up a tiny RAM drive just for this ?
edit* sounds barbaric, though... the system will still need to allocate/deallocate millions of file descriptors per second... O joy...
RAM disk? This is great, some more lunacy!

Perhaps such a thing is too OS dependant and complex for people to set up. The large amount of RAM allocated for disk caching these days probably makes it redundant anyway.

Yes, using disk I/O is *very* inefficient, but who cares so long as it is fast enough for what we need it to do. The current method we use to make our plugins is also silly and ineffiecient, but it still works.

Quote:
What's with the disk I/O?
Just use ReadProcessMemory and WriteProcessMemory on an address you allocate inside the game.

Just use file i/o once to define where the memory is located.
You are right and I did think of this, but the problem is that most of the game scripts probably cannot allocate memory and return an address for us to pass on. I'm not 100% sure about what a typical game scripting language is capable of, but someone like botman may be able to answer this one for us.

More ideas ...


Maker of the (mEAn) Bot.Admin Manager

"In theory, there is no difference between theory and practice. But, in practice, there is." - Jan L.A. van de Snepscheut

Last edited by botmeister; 07-04-2004 at 06:40..
   
Re: United Bot philosophy and roadmap.
Old
  (#5)
Pierre-Marie Baty
Roi de France
 
Pierre-Marie Baty's Avatar
 
Status: Offline
Posts: 5,049
Join Date: Nov 2003
Location: 4643'60N 043'0W 0.187A
Default Re: United Bot philosophy and roadmap. - 07-04-2004

I think not. I've read a little bit about UnrealScript and arbitrarily allocating memory isn't in the list of features.

If you REALLY want to go with the disk I/O method then I urge you to consider that the expense in solving portability issues with a RAM disk (which is THE fastest way to do disk I/O) will become a mandatory step anyway, as soon as you'll figure out that no matter how fast your hard drive spins, it will still be extraordinarily slow for a process who wants to make 200 engine calls and more per second and communicate them through a file access.



RACC home - Bots-United: beer, babies & bots (especially the latter)
"Learn to think by yourself, else others will do it for you."
   
Re: United Bot philosophy and roadmap.
Old
  (#6)
@$3.1415rin
Council Member, Author of JoeBOT
 
@$3.1415rin's Avatar
 
Status: Offline
Posts: 1,381
Join Date: Nov 2003
Location: Germany
Default Re: United Bot philosophy and roadmap. - 07-04-2004

this disk I/O stuff was a joke, wasn't it ? OK, for this scripting crippled engines, it's ok, but that can then maybe be a disk io plugin. arent there more engines with a nicer interface to talk about than Unreal ?

but we should really get some structure to thsi topic soon. if you are not reading especially this thread every day, it's pretty hard to keep track first we need some general idea to be able to create some structure, but then we should say good bye to such threads

just my 2 cents


   
Re: United Bot philosophy and roadmap.
Old
  (#7)
botmeister
Ex-Council Member
 
botmeister's Avatar
 
Status: Offline
Posts: 1,090
Join Date: Nov 2003
Location: Canada
Default Re: United Bot philosophy and roadmap. - 08-04-2004

No I was not entirely joking about the disk I/O communications idea.

On a relatively slow 850 Mhz machine running Win2K I can read from a text file 649,520 bytes in .02 seconds,and I can write the same amount to a text file in about 0.14 seconds.

You have to remember that the reaction times of a bot are in the 1/100 (0.01) of a second at best, which is *very* slow for a modern day desktop computer. We can probably get away with many reaction functions in 1/10 of a second range, or even longer. Only a few tasks, such as aiming and firing weapons will require the lowest reaction times.

How much data needs to be transfered per frame at 100 farmes per second is the big question, from there we can calculate if the concept is feasible or not. If it is, then we'll have a relatively universal communications method between the game and the bot. Of course enough games must allow efficient disk I/O from their scripting language. If basic disk I/O is not available then it is hard to imagine that scripting languages will provide us with anything that is more sophisticated.

edit:

We may also be able to perfom compression/decompression on the data that is exchanged to further reduce disk I/O times.

edit again:

Also, how fast (or slow) is communications through TCP/IP over 100 MB LAN? I can tell you it is a lot slower than local disk I/O.


Maker of the (mEAn) Bot.Admin Manager

"In theory, there is no difference between theory and practice. But, in practice, there is." - Jan L.A. van de Snepscheut

Last edited by botmeister; 08-04-2004 at 06:15..
   
Re: United Bot philosophy and roadmap.
Old
  (#8)
FrostyCoolSlug
Member
 
FrostyCoolSlug's Avatar
 
Status: Offline
Posts: 318
Join Date: Mar 2004
Default Re: United Bot philosophy and roadmap. - 08-04-2004

Quote:
You have to remember that the reaction times of a bot are in the 1/100 (0.01) of a second at best, which is *very* slow for a modern day desktop computer. We can probably get away with reaction times in 1/10 of a second range.
Ok, this might sound a bit stupid, but surely we want bots to be as fast as possible, i understand that using I/O may be the only solution, but maybe we should find a way to let a plugin decide what the best way to do it is..

The engine would have all the avaliable options avalaible, then the plugin decide which one to use? Making it more 'game specific'. and unless you want to hinder bot performance over all games, this is the only solution that i can think of which will happily work for all.
   
Re: United Bot philosophy and roadmap.
Old
  (#9)
botmeister
Ex-Council Member
 
botmeister's Avatar
 
Status: Offline
Posts: 1,090
Join Date: Nov 2003
Location: Canada
Default Re: United Bot philosophy and roadmap. - 08-04-2004

Quote:
Originally Posted by FrostyCoolSlug
Ok, this might sound a bit stupid, but surely we want bots to be as fast as possible, i understand that using I/O may be the only solution, but maybe we should find a way to let a plugin decide what the best way to do it is..
Agreed, but it would not be the plugin to decide, it would be the driver that sits between the UB and the game engine that decides what method to use (normally the best method that is available).

"faster than necessary" is not only unnecessary but may create redundant overhead which translates into more lag. You have to realize what I mean by "reaction times" vs processing time. These are two separate things. You will want the lowest possible processing time in most situations, but reaction times need only be as fast as required to get a bot to perform adequately against human players.

Quote:
The engine would have all the avaliable options avalaible, then the plugin decide which one to use? Making it more 'game specific'. and unless you want to hinder bot performance over all games, this is the only solution that i can think of which will happily work for all.
The disk I/O concept would be the lowest common denomonator across game engines assuming it can even work, and assuming no one can come up with anything better. For example, games that use the HL engine will have far better options due to the availablity of the SDK.


Maker of the (mEAn) Bot.Admin Manager

"In theory, there is no difference between theory and practice. But, in practice, there is." - Jan L.A. van de Snepscheut
   
Closed Thread


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
vBulletin Skin developed by: vBStyles.com