.:: Bots United ::. - United Bot

.:: Bots United ::. (http://forums.bots-united.com/index.php)

- General Bot Coding (http://forums.bots-united.com/forumdisplay.php?f=24)

- - United Bot (http://forums.bots-united.com/showthread.php?t=519)

logically, you learn, you try something bigger, then you learn again, etc. Endless loop. Cognitive ;)

Anyway, can't wait to see this concept of you guys, because i have no clue of what you are talking about.

I found this discussion in botmans forum archive, I think it's kind of the same idea we're talking about.

Quote:

--------------------------------------------------
Subject: bot+metamod=?
--------------------------------------------------
08/02/03 at 16:01:47 Posted by: LightNinja
--------------------------------------------------
It's just an idea to think about_:
Why not merge the source of metamod into a bot source (or vice versa)?
or, even better: use the source of metamod, modify it, to add plugin-support to your bot. you could have one bot release and several plugins which would change specific things, perhaps some behaviour of the bots. or fit them to the needs of a newer version of the Mod. Or give the user additional commands to control the bots.
It has these advantages:
* Every user could take the modules he wants and add them to his bot you only have to download the plugins you need.
* the size of the bot DLL itself is smaller and you only have to load these during the game and save CPU time and RAM.

* you could give an open source template and documentaions for these plugins to allow other developers to modify your bot without giving away your bot source itself.
* perhaps you could make the bot to load map specific plugin DLLs. In addition to waypoints they propably would get much smarter through this. But the bot should also work if for this map a dll does not exist.
* you do not need metamod to do all this. Okay, its a nice software, but if you do not need to install it, you have not to config it and load it and all this sh**...
[modified on 08/02/03 at 16:01:47]
--------------------------------------------------
08/03/03 at 03:32:59 Reply by: @$3.1415rin
--------------------------------------------------
and why not write a bot as metamod plugin ? that would fit all your needs as well, doesnt it ?
--------------------------------------------------
08/03/03 at 05:26:36 Reply by: LightNinja
--------------------------------------------------
no, absolutely not! because of this:
the bot will not use the plugins itself but needs metamod for it you have to install the whole metamod thing even if you do not want to have any plugins at all
--------------------------------------------------
08/05/03 at 06:15:32 Reply by: PM
--------------------------------------------------
The medication would be worse than the disease, then... each time a new metamod is out, you would have to reflect the changes on the bot's code. And the metamod API sometimes changes *completely*, it already happened twice.
I side with Aspirin :)

--------------------------------------------------
08/05/03 at 23:42:21 Reply by: botmeister
--------------------------------------------------
The whole point about metamod would be defeated if it was transformed into a bot mod.
Perhaps LightNinja was trying to suggest that your bot code should be made to work like the metamod plugin system - where plugins can be added (or removed) to change the behaviour of the bot? Now that I can agree with. For this to work, some kind of interface standard would have to be agreed to, which is not an easy task.

--------------------------------------------------
08/06/03 at 12:36:35 Reply by: LightNinja
--------------------------------------------------
this is exactly what I thought of...
currently I'm busy with other tasks, so in E[POD]bot III there won't be a plugin system like that.
But perhaps in version IV... if I have a good version III out I could focus on adding this plugin support. and then perhaps making some problems, e.g. by removing features from the core bot engine and plugging them in again as a plugin. for example the waypoint editor could be removed, so only ppl who want to make/edit waypoints have to download it.

about the interface standard: I will present it in an documentation. I do not want to establish a system compatible to other bots, such as POX-Bot... but if the developer of another bots wants to adapt the standard and make his bot compatible, this would be great.
but it is also possible that every bot has his own plugin standard.
[modified on 08/06/03 at 12:36:35]
--------------------------------------------------
08/13/03 at 21:38:31 Reply by: botmeister
--------------------------------------------------
You should check this out, I just found it today and have not looked at it closely yet, but it sounds like the same idea we're talking about
http://www.acquerra.com.au/personal/bird/bbm/
--------------------------------------------------
08/14/03 at 05:31:33 Reply by: botman
--------------------------------------------------
This is VERY old, as seen from the changelog...
http://www.acquerra.com.au/personal/.../changelog.txt
It's the same concept, but since nobody really wanted to write an AI plugins for something like this, it never went very far.
botman

I think this whole United Bot thread should be placed into a forum of it's own so it does not get buried away.

Here's some more ideas for a united bot:

1. If we proceed with a bot that can be built up using "plugin" parts, then we'll have to solve some interesting design challenges, which are generic and should apply to bot development outside HL.

2. A united bot will need a common API which should work across game engines. There would be an interchangeable plugin (or driver) for the bot that would be designed to work with each specific game engine - sort of like using a specific device driver that works with a specific video card, yet the software that uses the device driver does not care about which card is in use.

3. A new concept will have to be developed, I'll call it the Data API. Traditionally, an API is used as both for calling functions (FAPI) and for data interchage (DAPI). If you think about a united and generic bot for a while you'll see that the traditional API is not well suited for the task. The DAPI can allow for the generic interference free exchange of data between loosely integrated plugins that are designed to solve a common task.

More details on the DAPI:

Imagine that a plugin is created to replace the default aiming plugin which will perform more realistic aiming. The replacement plugin needs to add extra data fields to the common bot structure. Other plugins may or may not make use of the new data fields, and all existing data fileds must not be removed or interfered with in the process.

The concept of dynamically adding "sharable" data fields to a default structure, is what the DAPI will do. Each plugin can check to see what data fields exist or do not exist, and they can add their own data fields dynamically as the plugin is initialized without interfering with the needs of the other plugins. The DAPI can work for any structure, even for complex waypoint and navigation needs.

I can write volumes on this, so I better stop here for now and let other people chip in their own ideas.

*edit*

I just realized that the FAPI should be extended to make it dynamic, allowing the common interface to be extended as needed by each plugin. The DAPI idea is reasonably well thought out, and I even have something working already, but a dynamic FAPI is just a thought at this point, but I can see at least one method already (sort of).

I think it's not a thread nor a dedicated forum that we need. There are way too much concepts to comment here. We need a working wiki or something.

I'd be willing to write extensively about the API too, by writing a draft document. I don't believe in the DAPI concept but this would be lenghty to elaborate here.

Quote:

Originally Posted by Pierre-Marie Baty

I agree there will be many concepts to discuss and we will need a place to talk about this thing. Is a wiki the right tool for discussions? It may be the right tool for documenting the more or less final design decisions, but I did not think for discussing loose ideas.

For example, where can we talk about the API design if not in a forum? I'd love to hear what you have to say about a DAPI, etc, as we need something that is flexible enough for a multi game & multi plugin bot (if that's even what we decide to work on).

the wikki is working, only access controll does not (see my pm). so if you want it public, here you go :

http://server.bots-united.com/wiki/index.php

to be able to edit use your pop/imap username and password.
this is to keep nonsense away, i can change that on request to allow for editing w/o password.
(the login is in the lower right corner)

cheers

p.s. i love wikki wkki working, i now hereby declare www
a) beeing usefull again and
b) standing for wikki wkki working

I clicked on the wiki link but got this

The XML page cannot be displayed

Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later. Cannot have a DOCTYPE declaration outside of a prolog. Error processing resource 'http://server.bots-united.com/wikki/index.php/DeveloperWikki'. Line 4, Position 11

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"----------^

/edit
*rofl*

i changed the link to the start page, for IE users :-)

klick on DeveloperWikki to go to some prepared documents

edit/

/edit2
when loging in you will get some minor php errors, they should be harmless, just fyi.

edit2/

I still have the same error as botmeister.... and there are a lot of warnings too, especially at login :|

This is what I now get

lib/Theme.php (In template 'navbar') (In template 'top') (In template 'body') (In template 'html'):634: Warning[2]: dir(themes/default/buttons): failed to open dir: Permission denied

Fatal error: Call to a member function on a non-object in /home/bots-united.com/server/wikki/lib/Theme.php on line 635