.:: Bots United ::.

.:: Bots United ::. (http://forums.bots-united.com/index.php)
-   General Bot Coding (http://forums.bots-united.com/forumdisplay.php?f=24)
-   -   Loading other bot wayponts (standard format?) & Standardized directory structure? (http://forums.bots-united.com/showthread.php?t=76)

stefanhendriks 28-12-2003 20:38

Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Perhaps worth considering; while our bots getting united, it would be cool to have them share the same data files. As well using a shared directory structure.

My bot uses:

counter-strike\realbot

as folder. I see pod/pox etc does:

counter-strike\cstrike\podbot

although that is logical, i prefer my structure because this way i centralize and i am able to run multiple mods without changing from 'cstrike' to 'dod', thus having only 1 realbot directory. Makes it easy for me and for users.

within my realbot directory i have:
data\<mod name>

here in theory could be:
data\cstrike
data\dod
data\firearms
data\valve

etc.

And in every mod dir:
cstrike\maps
cstrike\bots
cstrike\exp

i use a dir 'bots' for personalities, and i do this per mod because each mod has different properties. Perhaps its better to have a global bot personality and 'refined' personality info per mod in these directories. This way you don't have so much redundancy as now.

Waypoints/Nodes storage
Perhaps its a good idea to use INI files (as i have), my INI parser is easy to use, but there are many other INI parsers on the web and it is plain-text (thus easy compressable with ZIP and such). Plain-Text formats also allow easy importing, this way we bot authors do not need to share code specific variables which we do not need.

Ie, my code for loading nodes:
Code:

// Load
void cNodeMachine::load()
{
  char dirname[256];
  char filename[256];
  int i, n;

  // Set Directory name
  strcpy(dirname, "data/cstrike/maps/");

  strcat(dirname, STRING(gpGlobals->mapname));
  strcat(dirname, ".rbn"); // nodes file

  // writes whole path into "filename", Linux compatible
  UTIL_BuildFileNameRB(dirname, filename);

  FILE *rbl;
  rbl = fopen(filename, "rb");

  if (rbl != NULL)
  {
    int iVersion=FILE_NODE_VER1;
    fread(&iVersion, sizeof(int), 1, rbl);

    // Version 1.0
    if (iVersion == FILE_NODE_VER1)
    {
        for (i=0; i < MAX_NODES; i++)
        {               
            fread(&Nodes[i].origin, sizeof(Vector), 1, rbl);
            for (n=0; n < MAX_NEIGHBOURS; n++)
            {               
                fread(&Nodes[i].iNeighbour[n], sizeof(int), 1, rbl);       
            }

            // save bit flags
            fread(&Nodes[i].iNodeBits, sizeof(int), 1, rbl);

            if (Nodes[i].origin != Vector(9999,9999,9999))
                iMaxUsedNodes = i;
        }
    }

        // Add nodes to meredians
        for (i=0; i < MAX_NODES; i++)
                if (Nodes[i].origin != Vector(9999,9999,9999))
                {
                        int iX, iY;
                        VectorToMeredian(Nodes[i].origin, &iX, &iY);
                        if (iX > -1 && iY > -1)
                                AddToMeredian(iX, iY, i);
                }

     
        fclose(rbl);
  }
}

as you can see, i do 'read binary'. I use max values so my files do never grow for Nodes. The experience though (vis-table which is calculated by experience, etc) does grow. The above could probably be done in text, we could simply share our piece of code then and all you need to do is change the variable names to get my RBN files loaded in your bot.

Standardized Waypoint format
Perhaps we should agree on a standardized waypoint format. This will be a lot harder though because i use nodes and only use vectors & neighbours. All other stuff is detached because not all info applies on all nodes. Etc. Perhaps we should use files which only contains vectors + bit flags about what kind of 'waypoint' it is. Of course, we have trouble with amounts (i use ~ 2000 nodes, at max 4500).

Anyway, another 'start' about a cool subject. :D 8)

Pierre-Marie Baty 29-12-2003 00:54

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Yes... unfortunately I won't assist you much there, my bots use a navmesh, which is not exactly assimilable to waypoints :)

But great idea indeed, if some of you can hammer out a standard! :)

stefanhendriks 29-12-2003 09:48

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
i bet even you pierre can give me a list of walkable vectors? :) Every 'mesh' center perhaps? You also know if they are connected so you can give a 'neighbour' list as well. In theory my bot can walk using your mesh files. :)

Pierre-Marie Baty 29-12-2003 09:55

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Yes... but MY bot can't walk using YOURS, you horrible egoistic boy :D

stefanhendriks 29-12-2003 13:47

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
aww, come on pierre you could do better then that! :) I bet you can write some code to check where my nodes are and confirm the meshes they are on that they are 100% connectable. Perhaps your bot does not even need to know anything because it already knows where it can walk and where not (or does it uses some sort of 'remembering what went good/bad' code, like Micheal Boot does with his 'official cs bot'?)

stefanhendriks 10-01-2004 20:16

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
*Bumbed* (?)

I suggest we do agree on a standard format which only provides navigation information. Perhaps not even connection data!

As a suggestion i'd like to propose we have a "WVF" format. This file only contains Vectors which are walkable. THey should represent points (nodes, waypoints, whatever) where you can walk to.

I take 4096 as a max, the format should be simple:

Code:

while (file is not empty)
 fread(file, vector);
 
// and saving the same:
for (every waypoint that is valid, etc)
 fwrite(file, vector of waypoint)

the bot should interpet the information itself. THis means the way I connect nodes will be different then other bots.

Looking at JOE and RACC i think we can agree on such a format. Even RACC can give me the vectors? (You need to know where to move the vBody angle so you NEED to know atleast SOME vectors).

Perhaps pierre can tell me what his max amount of vectors will be?

thoughts? comments?!

botmeister 10-01-2004 22:18

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
I have not worked on my own navigation yet, so I'm not best to comment, however I wonder if it would be best to make the standard file format in text form, rather than binary? Sort of like a high level language for defining the nodes.

Rick 10-01-2004 22:20

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Quote:

Originally Posted by botmeister
I have not worked on my own navigation yet, so I'm not best to comment, however I wonder if it would be best to make the standard file format in text form, rather than binary? Sort of like a high level language for defining the nodes.

That sounds nice. Maybe it would be good if you can specify at the beginning of the file for which game these waypoints so that other bots for other mods can use it to savely to :)

Lazy 10-01-2004 22:31

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Binary format is much easier and smaller than text.
However, if you want to go down that road I suggest using XML...

Code:

 
<?xml version="1.0"?>
<rootnode>
 <waypoint>
  <origin>-64 1055 -231</origin>
  <team>1</team>
 
  <mod_specific game="tfc">
  <class>scout</class>
  </mod_specific>
 </waypoint>
</rootnode>


stefanhendriks 10-01-2004 23:02

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Omg, no XML! I find that sooooooo uber bloatware! ;)

i rather use ini files:

Code:

[NODES]
1=xxxx,yyyy,zzzz
2=xxxx,yyyy,zzzz

A text format is fine with me, i will try to write an 'export' thingy asap. Without even the [NODES] part, so EVERY program can read it. Remember it is only for basic information about the nodes. They only represent walkable dots/points, nothing more, nothing less. Everything else (danger, goals, etc) should be saved in your own waypoint file.

For me, i can do this with the WVF format:

Code:

for (every vector i read in the file && is valid)
{
// create node
// check if any goal is near this, and assign 'goal' to this node
// check any near 'nodes' and connect them (using a special function this also makes sure it happens vice-versa)
// check any special stuff (in water? on ladder? etc)
}

thats all ;) Then i got my RBN file and i can tweak it. When using WVF files we can distribute these files only, especially with our downloads section being under construction we can have 2 sections:

- general World Vector Files
- bot specified files

the general wvf files will do the above, while the bot specific files are 'tweaked' ones (more optimal).

botmeister 10-01-2004 23:29

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
I'd like to have "should we use XML or INI" debated and resolved.

Someone please point out the advantage(s) of using XML over INI.

stefanhendriks 10-01-2004 23:48

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
XML is a sort of HTML kind of thing, with scopes and such. Its nice and all.

INI is a bit different. You do have scopes but yo udon't know them always (unless specificly documented). Its also harder to read when you are 'out of scope' and such.

You can see an XML example at the previous post, but to compare it with an 'ini' scoped thingy i give ya an example:

Code:

[GAME]
 
; common game info:
[COMMON]
name=MyGame
 
; out of scope here
 
[UNITS]
 
; common information for unknown units
[COMMON]
name=Unknown

I'd say, don't use them both! ONLY store xxxx,yyyy,zzzz

There is NO NEED for INI or XML in the general waypoint data. Its only needed to include 'neighbouring' data and other stuff (goals, etc). This is imo already to specific. We all know how to code it, hence we could release source code for that.

Quote:

-2321.232 2892.232 1234.0832
2312.322 3215.314 8421.2354
this should be enough! :)

Pierre-Marie Baty 11-01-2004 00:18

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
nah, nah, nah, guys.

How will I store the number of corners of my walkfaces and the vector locations of each of these ?

How will I store the entrypoints (navlinks) to these ?

I have a very different "waypoint" structure than most of you ; if you really want to be generic you must take exotic features in account too. Harder than you thought, I suppose ;)

stefanhendriks 11-01-2004 00:24

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
looking through all bots, i'd say you have to figure that yourself pmb :P We outnumber you with your nav-evilmesh thingy ;)

Is'nt there a way to strip down your data to 'walkable vectors/points' only? If you can do that, there also has to be a way to do that the other way around.

I do admit that it probably will be very hard, or perhaps impossible to convert from 'normal waypoint data' to your navmesh thingy. Nevertheless, there are A LOT of waypointed bots. It would be nice to have one format.

Pierre-Marie Baty 11-01-2004 00:36

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Unfortunately if I "strip down" the data as you say, the navmesh is of no use... and there's strictly no way to get the information back after it would have been "stripped" to vectors.

I suppose I'll have to step out of your project... :(

@$3.1415rin 11-01-2004 10:46

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
about xml and ini files ...

e.g. pierre could put all his data to that file, also providing a middle vector of each walkable node and telling to which of the neighbors it is connected. in xml, it is no problem to load that data not considering the additional data pierre had included because he needs somewhat more data. this may be a bit more complicated with ini files, although solvable.

With xml one would already have a ready-to-use system, just looping thru the tags and comparing them to some keys, no need to bother about any possible differences in the actual data provided ...

dunno, I'd now prefer xml :)

stefanhendriks 11-01-2004 11:12

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
yes, with xml you can possibly make a mid-way for this. So pierre can save additional data for his meshes, and we can simply extract data that we only need. I have read there are already some xml readers available on the net, so there is no need actually to write one from scratch.

botmeister 11-01-2004 18:33

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Just a note about what I mean by "INI" file. I'm not talking about Windows INI files where you use the windows system calls to extract information. I'm talking about a simple text file with tags similar to what is seen in an INI file. With such a file, you can have it do anything you want, including read/write XML formatted text.

For example, PMB's extra info could simply be skipped over if not usable - I don't see a need for XML to do such a simple thing.

I don't really care if XML is used or not, I just don't see what the big deal is about it. Given the lack of advantages, my concern is that if we stick to XML then we are limited to XML.

@$3.1415rin 11-01-2004 20:10

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
an advantage of xml is that normal webbrowsers support their display, allowing to collapse parts etc ...

XML is a well known international standard, so why use an own .ini file format ?!

botmeister 11-01-2004 21:38

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Quote:

Originally Posted by @$3.1415rin
an advantage of xml is that normal webbrowsers support their display, allowing to collapse parts etc ...

XML is a well known international standard, so why use an own .ini file format ?!

One reason we'd use our own ini style of format is if XML cannot do whatever it is that we want it to do. Since we do not yet know exactly what we want done, the fist step should be to decide what it is that we want done, then we decide what is the best means of supporting it. Make any sense? ???:(

stefanhendriks 11-01-2004 22:16

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
I'd say, lets first get to know what information we need to store for PMB, because this is about his extra data. If we don't use that we would not need any luxurious format.

So, PMB, what do you need? If you can give it in a list like:
int numleafs;
vector corners[];
etc...

we know atleast how to get it done, i mean, we could simply do this as a format, and skip this whole XML thingy, which is bloatware imo for this thing:

Code:

; Vector #1, general information for all bots
[VECTOR]
X=
Y=
Z=
 
; Here comes additional information for other bots
[ADDITIONAL]
; Information for RACC-Bot
Numleafs=x
 
[LEAF]
; info of leaf
 
[LEAF]
; info of leaf
 
; Vector introduces another NEW vector, so we begin all over again
; general info:
[VECTOR]
 
; And again additional info
[ADDITIONAL]
;...

It is not hard to code at all,in fact i have an ini parser ready to use.

Pierre-Marie Baty 12-01-2004 02:55

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
I also have an ini parser ready to use, anyway:
I use 2 sorts of nav files.
.map files which hold the world data, that is, the global navmesh, that all bots know.

.nav files, which are the LINKS to different nodes of this navmesh, along with particular info about them, which are specific for each bot. The more a bot discovers links between nodes, the more it knows the map, and the better it navigates.

I propose not to worry about this separation, and in order to simplify things I'll sacrify the per-bot autonomy (only in this project, not in my bot code). I can also rebuild the topology hashtable myself out of the walkfaces pool, so it's OK if I drop it.

The file will need to have the following information, a minima. Arranged or not like this, anyway this one is the format I use - I can't simplify it more.

Quote:

; walkable faces, with all their corners.
; this is the global navmesh, the one that all bot knows. It describes
; exactly which surfaces are walkable on the map and which are not.
[walkfaces]
number_of_walkfaces = nnn

walkface0000.number_of_corners = nnn
walkface0000.corner0_location = {X, Y, Z}
walkface0000.corner1_location = {X, Y, Z}
walkface0000.corner(...)_location = {X, Y, Z}

walkface0001.number_of_corners = nnn
walkface0001.corner0_location = {X, Y, Z}
walkface0001.corner1_location = {X, Y, Z}
walkface0001.corner(...)_location = {X, Y, Z}

(...)

walkface(...).number_of_corners = nnn
walkface(...).corner0_location = {X, Y, Z}
walkface(...).corner1_location = {X, Y, Z}
walkface(...).corner(...)_location = {X, Y, Z}


; navigation links between each walkable faces (i.e, "waypoints").
; normally navlinks are between NAVNODES and not walkfaces. Doing them
; at the walkface level will make all my bots share the same nav brain.
[navlinks]
number_of_navlinks = nnn

navlink0000.index_of_walkface_it_is_for = nnn
navlink0000.location = {X, Y, Z} ;<--- HERE'S your waypoint, guys ;)
navlink0000.reachability = nnnn

navlink0001.index_of_walkface_it_is_for = nnn
navlink0001.location = {X, Y, Z}
navlink0001.reachability = nnnn

(...)

navlink(...).index_of_walkface_it_is_for = nnn
navlink(...).location = {X, Y, Z}
navlink(...).reachability = nnnn


; "likelevels", that is, how much bots like or dislike a particular
; reachability. Reachabilities stand for the description on how to move
; from here to there. It may be a ladder, a train, a longjump, a fall, etc.
[likelevels]
likelevel_ladder = nnnn
likelevel_falledge = nnnn
likelevel_elevator = nnnn
likelevel_platform = nnnn
likelevel_conveyor = nnnn
likelevel_train = nnnn
likelevel_longjump = nnnn
likelevel_swim = nnnn
likelevel_teleporter = nnnn
See, Stefan, it's completely different. Incompatible, I would say.

botmeister 12-01-2004 05:21

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Quote:

I propose not to worry about this separation, and in order to simplify things I'll sacrify the per-bot autonomy
If it is not a big deal, I suggest that you allow your bots to function either with bot dependant navimesh's, or through a bot independant global navmesh.

Possible?

stefanhendriks 12-01-2004 13:55

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
I think RACC would eventually not even need nav data from us, as his bots are capable of learning maps more quickly then bots plotting nodes. Actually, RACC should know what surfaces are walkable already, it just needs some confirmation for that. That would mean, only 1 round to play and you already have data to play with.

I see why it is difficult to port navmesh to nodes and vice-versa, so i think we should focus on this standard format? Do we agree on the following format?

Code:

; A walkable vector
[VECTOR]
x=xxxx.xxxx
y=yyyy.yyyy
z=zzzz.zzzz
; flags , if needed, to tell if its ladder, water, air, etc
; seperated with each 'flag word' so we do not use
; comma seperated stuff (yuk!)
flag=AIR
flag=LADDER
 
; new vector..
[VECTOR]
...


Killaruna 12-01-2004 17:51

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Quote:

Originally Posted by botmeister
One reason we'd use our own ini style of format is if XML cannot do whatever it is that we want it to do. Since we do not yet know exactly what we want done, the fist step should be to decide what it is that we want done, then we decide what is the best means of supporting it. Make any sense? ???:(

Umm, sorry to get back to the XML/Ini discussion, but there's nothing you can't do with XML :D
It may be harder to read (for a human, that is) and it surely is bulky, but what universal applicability concerns, it is hard to beat. It's a world standard and you can use techniques like DTD to let your webbrowser verify the files - VERY convenient. You might have guessed it, but I would go with XML...

stefanhendriks 12-01-2004 17:57

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
yes,its nice you can read it with a browser, but whats the use of that?

Killaruna 12-01-2004 18:38

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Not only read, but verify. If (for whatever reason) one coordinate is missing in your Ini-file, your reader will go havoc. If you load an XML-file with a missing coordinate in your browser, it will print out something like "Error in line xxx" - at least if you are using DTDs.

Pierre-Marie Baty 13-01-2004 00:33

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Why would the readed go havoc ? If it's correctly written it should check for such cases...
I understand your concern for XML but elitism is no good for me, and I'd never sacrify the readability of the data to some obscure universal standard, however these are only my cent and a half.

botmeister 13-01-2004 01:38

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
It appears that PMB's method of navigation should in theory be better than all the others. If this is so, then why not adopt his method as the standard? I suppose one problem will be that the method assumes a certain type of map structure is to be parsed, so it may not be universally applied - I may be wrong about this however. What do you guys think about this one?

As for using XML or not, it really boils down to knowing if using it will provide more advantages than disadvantages over other potential formats.

XML is an accepted standard format, and web browsers can read it and look for syntax errors. While this is true, many errors cannot be detected by a generic XML reader because the generic reader cannot do anything with XML other than verfiy that the XML syntax looks ok. The XML tags are all customizable and a special interpreter is needed to make sense out of the supplied XML code.

Is there a BIG advantage that XML will give us?

If I understood coorectly what XML is all about, it is clear the idea is potentially a good one because the basic infrastructure for defining new mark up languages is agreed on universally as a standard. However, any new markup language that is created out of XML remains useless unless a special reader is developed for it. For example the MathML(tm) specification won't help anyone unless a special reader is aquired and installed for your browser. If it is not installed, you won't get any thing usefull from it.

Essentially XML is about as much of a standard to web browsers as ascii/unicode is to text processors. The world has only agreed that a certain format is to be used, but what the content represents is up to the individual application.

So, no matter if XML is used or not, the only advantages we'll see is that a web browser can read it, and if a special interpreter is installed for the browser, the browser may be able to do something more with it.

Is having a web browser read and interpret the XML data something we want, or need?

Killaruna 13-01-2004 15:09

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Quote:

Originally Posted by Pierre-Marie Baty
I understand your concern for XML but elitism is no good for me

There's nothing elite about using common standards, it's just a matter of being on the safe side.

Quote:

Originally Posted by botmeister
It appears that PMB's method of navigation should in theory be better than all the others. If this is so, then why not adopt his method as the standard? I suppose one problem will be that the method assumes a certain type of map structure is to be parsed, so it may not be universally applied - I may be wrong about this however. What do you guys think about this one?

I wouldn't say it is better, it is a different approach. You can't setup visibility tables with navmeshes AFAIK, with waypoints that is no problem. In a general waypoint file structure, you would include both systems, like:

[NAVMESH_INFO]
...
[/NAVMESH_INFO]

[WAYPOINT_INFO]
...
[WAYPOINT_INFO]

Pierre-Marie Baty 13-01-2004 16:45

Re: Loading other bot wayponts (standard format?) & Standardized directory structure?
 
Quote:

Originally Posted by Killaruna
You can't setup visibility tables with navmeshes AFAIK

Actually you still can setup something which resembles vaguely a visibility table, provided the navmesh nodes don't move around once they have been plotted, and provided you don't rely too much on it, especially if you want to figure out ALL the visible nodes from a certain point - since this state will exist only when all the walkfaces will have been "discovered" by the bots.

Quote:

Originally Posted by botmeister
I suppose one problem will be that the method assumes a certain type of map structure is to be parsed

Yes, so far my navmesh is based out BSP polygons. But give me a way to get the list of world polygons that a particular engine is supposed to display and I'll build you a navmesh out of anything, basically.


All times are GMT +2. The time now is 10:46.

Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.