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

[stefanhendriks]

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:

; 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]

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.

; 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]

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]

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?

; 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]

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
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]

yes,its nice you can read it with a browser, but whats the use of that?

[Killaruna]

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]

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]

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]

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.

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]