Bot Waypoints?

Yes yes, before yo all indignantly reply, BOLO IS DYNAMIC! just listen ; ).
Having support for waypoints would allow bots to work better, and it would be simple enough to make sure bots wouldn't move to waypoints positioned (after mining) on water, etc. It would be pretty useful, and would definately improve the bot AI.

How hard woud it be to create this invisible layer, and will it happen?

check wrote:

Yes yes, before yo all indignantly reply, BOLO IS DYNAMIC! just listen ; ).
Having support for waypoints would allow bots to work better, and it would be simple enough to make sure bots wouldn't move to waypoints positioned (after mining) on water, etc. It would be pretty useful, and would definately improve the bot AI.

How hard woud it be to create this invisible layer, and will it happen?

umm .. actually .. you could just program these yourself .... in FPS shooter world they are called "nodes" .. what you do is have the AI put "nodes" in places they've seen other players move ... and in alot of fps's thats how they make the bots move around the maps other than having predefined nodes programmed into the bot. The problem with the winbolo bot ai, is its way to hard to get some very simplistic information and that uses up cpu cycles that would be better used for bot logic .. for example .. becuase of how the object list works to find out if an enemy has "picked up" a pill, you'd have to reference when you last saw that pill, and then when you ran near that location again do a check to see if you can "see" it still ... becuase otherwise there is no way to tell if someone has picked up and moved a pill ... there is also no way to tell if enemies are carrying pills ... which is a huge error in my opinion, since if the enemy is carrying, that totally changes the strategy the bot should be trying to use. I was in the process of programming a bot that was more advanced than the current ones, but once I found out these things ... I decided I should just wait for a update to the bot interface ... why don't we just get a array of bases, and a array of pills .... rather than these ultra lame "object" lists ... which are fine for bullets, and probably tanks, and lgms .... but they seem inadequate for allowing proper tracking of pills.

Min

Thanks for the feedback Min. I'll address all the stuff in order.
I could program all the nodes for each map myself, but that would limit the number of maps the bot could be played on to the ones i supported.By simply placing enough nodes in, and chaecking to see if the node is on water/ jungle whater, you could accurately build a path around the map.
You also talked about how working out where stuff last seen would chew up CPU cycles, which would be better on the bot's logic. Most people nowadays have *huge* processors, which can easily handle this. On my (getting old) XP1600+, i can run sixteen copies of bolo in a network game, with the Bascher brain running, with barely a load runnning at all.
Many of these cycles you talked about would be negated anyway. By giving bots an advantage on the main server page, can't they see all pillboxes, etc?

I agree with you on most of your points though. If Bolo just uses object lists, this would be pretty hard. I'm not much of a programmer myself, so i dont know how hard implementing a node system into Bolo would be. It would definately be an advantage for all bots though, if it were implemented well.

check wrote:

Thanks for the feedback Min. I'll address all the stuff in order.
I could program all the nodes for each map myself, but that would limit the number of maps the bot could be played on to the ones i supported.By simply placing enough nodes in, and chaecking to see if the node is on water/ jungle whater, you could accurately build a path around the map.

thats why I said ... have the bot build path/node networks based on where it sees the other players in the game game driving. That way you could have it automatically build its own node network for a map.

check wrote:

You also talked about how working out where stuff last seen would chew up CPU cycles, which would be better on the bot's logic. Most people nowadays have *huge* processors, which can easily handle this. On my (getting old) XP1600+, i can run sixteen copies of bolo in a network game, with the Bascher brain running, with barely a load runnning at all.
Many of these cycles you talked about would be negated anyway.

ok well .. first .. not everyone has a computer that large, second .. if you tie up the winbolo game loop for more than a certain amount of time .. winbolo crashes .... and that amount of time is less than 10 milliseconds last I checked(might be closer to 20 milliseconds). You think you can get all the bot logic you need to process every loop into a 10millisecond timeslice? .... good luck with that.

check wrote:

By giving bots an advantage on the main server page, can't they see all pillboxes, etc?

no ... they can't ... they wouldn't see any pills that are in tanks, and its debatable what other information they are given, and I'm certainly not going to require people to have giving bots an advantage on to make my bot even function ... you can go that route if you feel like it ... but it will most likely not happen.

check wrote:

I agree with you on most of your points though. If Bolo just uses object lists, this would be pretty hard. I'm not much of a programmer myself, so i dont know how hard implementing a node system into Bolo would be. It would definately be an advantage for all bots though, if it were implemented well.

honestly, due to winbolo's simplicity, a node system is hardly required for an adequate bot to be created .. the problem is that all the people thus far who have actually "released" game bots ... are newbies ... so the bots play like newbies do ... My original plan was to simply release a bot that runs around the map refueling and attacking bases .. ignoring pillbox's other than to avoid their gunfire ... and figured htat would be a decent start, after hitting all the issues with pillbox location, and tracking that sort of thing, I decided it wasn't worth dealing with. Building a bot that would at least defeat "ryan2" without issues would be very very very easy if pillbox's locations were easier to address, as it is, the bot interface doesn't even give you all the information that a normal human player receives.

Min

Yet weirdly enough Indy and aIndy can do it, and they were made 5+ years ago.

ok well .. first .. not everyone has a computer that large, second .. if you tie up the winbolo game loop for more than a certain amount of time .. winbolo crashes .... and that amount of time is less than 10 milliseconds last I checked(might be closer to 20 milliseconds). You think you can get all the bot logic you need to process every loop into a 10millisecond timeslice? .... good luck with that.

Or you could write your own thread to do it in the background to your hearts content.

Elvis wrote:

Yet weirdly enough Indy and aIndy can do it, and they were made 5+ years ago.

was that a slice? ... yep ... your right they can ... but quite honestly ... they do it badly, having played them last time I loaded up my mac, they are not much better than ryan2 .... but from your attitude its obvious you don't give a crap. nice to know

Min

Why teh fuck does ne1 give a crap about bots?

Sorry if you got that impression. I was just pointing out that it is possible to do this with computers that are over 7 years old. You may note that I also suggested an alternative way to get around the problem if the brain can not do its processing within the required time slice. I do think the time to iterate through the item list is negligible.

I do not agree with you in saying that aIndy is on the same level of ryan2 especially with the give brains advantage option turned on.

I know in the past we have had conversations on improvements to the brain interface to provide additional information. I'm sorry if you feel that because I have not changed it yet that I "don't give a crap" about it.

Min wrote:

why don't we just get a array of bases, and a array of pills .... rather than these ultra lame "object" lists ... which are fine for bullets, and probably tanks, and lgms .... but they seem inadequate for allowing proper tracking of pills.

I spent about 5 minutes writing an object list to array function for you. You can download it from: http://www.winbolo.net/brainarray.zip

Its just the brain template source code with an additional function that is called every brain tick to update an array of pillboxes and bases. Feel free to add on tanks, builders or any thing else. It generates a message box if it takes greater then 0 milliseconds to do this. Because the millisecond timer isn't fine enough it will occasionally it will say 1. You may want to try a microsecond timer to see how long it takes.

Admittedly it does take less time to post a complaint that the brain interface doesn't do this for you but only by about 4 minutes :)

Elvis wrote:

I spent about 5 minutes writing an object list to array function for you. You can download it from: http://www.winbolo.net/brainarray.zip

Admittedly it does take less time to post a complaint that the brain interface doesn't do this for you but only by about 4 minutes :)

well, you don't seem to get it elvis. Do you think I'm a total moron? .. with this little tidbit of code you make it seem like it.

let us examine this little array that you've created. (of which I have somthing very similiar in the bot I was creating)
[code:1:1d990c4bef]
void updateArrays(BrainInfo *info) {
u_short count = 0;
ObjectInfo o;

while (count < info->num_objects) {
o = info->objects[count];
switch (o.object) {
case OBJECT_PILLBOX:
pills[o.idnum].x = o.x;
pills[o.idnum].y = o.y;
pills[o.idnum].armour = o.direction;
pills[o.idnum].owner = o.info;
break;
case OBJECT_REFBASE:
bases[o.idnum].x = o.x;
bases[o.idnum].y = o.y;
bases[o.idnum].armour = o.direction;
bases[o.idnum].owner = o.info;
break;
/* Add other cases for tanks/lgm's etc */
}
count++;
}

}
[/code:1:1d990c4bef]
yeah! thats great we think to ourselfs .... everytime we see a pillbox or base .. it updates its information for us ... handydandy .... wait a sek .... what happens if a enemy comes along .. and picks up one of those pills? .. our handy dandy object list doesn't store pillbox's that are IN tanks ....... so our brain will have this array that .. *gasp* doesn't know were a pill is .. the array reads it as being there ... but its not actually there ... the brain will have no clue were it is until that tank puts it back on the ground. but won't move through that area of ground. What you truely need to write is something that will constantly check that array to make sure that when your within visual range of a pillbox ..... to see if its still were it was lasttime .. and this elvis is what I was refering too .... my point is not that this is hard to do. But first, there is no way to detect if a pillbox is in a tank, second, you must do calculations to determine if a pillbox has moved ... this means, that instantly the borg interface isn't even given what a human player is given with a glance at the counters. so how can a AI even come close to a human player in skill if they aren't even given the same or better information? I'd love for you to actually prove me wrong elvis .. becuase then I'll have a reason to complete the fully automated bot that I have collecting bases. It was quite amusing coding a collision detection/pathing algorithm for it.

Min

Elvis wrote:

I know in the past we have had conversations on improvements to the brain interface to provide additional information. I'm sorry if you feel that because I have not changed it yet that I "don't give a crap" about it.

no, thats not true at all actually. I think you will include the stuff we talked about when it becomes a priority, which it currently isn't. Your attitude in responding to these concerns however ... makes me think you don't give a crap.

Min

Elvis wrote:

You may note that I also suggested an alternative way to get around the problem if the brain can not do its processing within the required time slice.

I had considered using threads for this before, but I think I decided for my own bot I would rather use a method of priority processing or something of that nature. Threads at first glance seem like a good solution, but when in reality you need this information by the time you end the loop so that you can tell the bot how to move/act. Perhaps a working solution can be done using threads, however, I think I'll try it without them.

Min

Elvis wrote:

Admittedly it does take less time to post a complaint that the brain interface doesn't do this for you but only by about 4 minutes :)

uh, I spent 2 months coding (when I could) before I came to the conclusion the bot interface doesn't do it for me .... considerably more time than 4 minutes.

Min

p.s. Here is a snippet of my code. it of course turns ugly when pasted into a message ... but you get the idea.
[code:1:55bebebf96]
// Function to check the objects list and update the bases array
// ObjectInfo tPillboxs[15];
void PillArrayUpdate()
{
int objs;

for (objs = 0; objs < info->num_objects; objs++)
{
if(info->objects[objs].object == OBJECT_PILLBOX)
{
tPillboxs[info->objects[objs].idnum] = info->objects[objs];
}
}

fout<<"Pill1 id "<< tPillboxs[0].idnum << " " << tPillboxs[0].x << " " << tPillboxs[0].y << " " << tPillboxs[0].direction << " " << tPillboxs[0].info << endl;
fout<<"Pill2 id "<< tPillboxs[1].idnum << " " << tPillboxs[1].x << " " << tPillboxs[1].y << " " << tPillboxs[1].direction << " " << tPillboxs[1].info << endl;
fout<<"pill3 id "<< tPillboxs[2].idnum << " " << tPillboxs[2].x << " " << tPillboxs[2].y << " " << tPillboxs[2].direction << " " << tPillboxs[2].info << endl;
fout<<"pill4 id "<< tPillboxs[3].idnum << " " << tPillboxs[3].x << " " << tPillboxs[3].y << " " << tPillboxs[3].direction << " " << tPillboxs[3].info << endl;
fout<<"pill5 id "<< tPillboxs[4].idnum << " " << tPillboxs[4].x << " " << tPillboxs[4].y << " " << tPillboxs[4].direction << " " << tPillboxs[4].info << endl;
fout<<"pill6 id "<< tPillboxs[5].idnum << " " << tPillboxs[5].x << " " << tPillboxs[5].y << " " << tPillboxs[5].direction << " " << tPillboxs[5].info << endl;
fout<<"pill7 id "<< tPillboxs[6].idnum << " " << tPillboxs[6].x << " " << tPillboxs[6].y << " " << tPillboxs[6].direction << " " << tPillboxs[6].info << endl;
fout<<"pill8 id "<< tPillboxs[7].idnum << " " << tPillboxs[7].x << " " << tPillboxs[7].y << " " << tPillboxs[7].direction << " " << tPillboxs[7].info << endl;
fout<<"pill9 id "<< tPillboxs[8].idnum << " " << tPillboxs[8].x << " " << tPillboxs[8].y << " " << tPillboxs[8].direction << " " << tPillboxs[8].info << endl;
fout<<"pill10 id "<< tPillboxs[9].idnum << " " << tPillboxs[9].x << " " << tPillboxs[9].y << " " << tPillboxs[9].direction << " " << tPillboxs[9].info << endl;
fout<<"pill11 id "<< tPillboxs[10].idnum << " " << tPillboxs[10].x << " " << tPillboxs[10].y << " " << tPillboxs[10].direction << " " << tPillboxs[10].info << endl;
fout<<"pill12 id "<< tPillboxs[11].idnum << " " << tPillboxs[11].x << " " << tPillboxs[11].y << " " << tPillboxs[11].direction << " " << tPillboxs[11].info << endl;
fout<<"pill13 id "<< tPillboxs[12].idnum << " " << tPillboxs[12].x << " " << tPillboxs[12].y << " " << tPillboxs[12].direction << " " << tPillboxs[12].info << endl;
fout<<"pill14 id "<< tPillboxs[13].idnum << " " << tPillboxs[13].x << " " << tPillboxs[13].y << " " << tPillboxs[13].direction << " " << tPillboxs[13].info << endl;
fout<<"pill15 id "<< tPillboxs[14].idnum << " " << tPillboxs[14].x << " " << tPillboxs[14].y << " " << tPillboxs[14].direction << " " << tPillboxs[14].info << endl;
fout<<"pill16 id "<< tPillboxs[15].idnum << " " << tPillboxs[15].x << " " << tPillboxs[15].y << " " << tPillboxs[15].direction << " " << tPillboxs[15].info << endl;


return;
}
[/code:1:55bebebf96]

Elvis wrote:

I do not agree with you in saying that aIndy is on the same level of ryan2 especially with the give brains advantage option turned on.

well your entitled to that opinion, however when I fired up my mac, and loaded it up ....... if it is better than ryan2 .. its not much .. you plant a pill by one of your bases and ... its screwed ... then you just run around taking its bases .... really tough .... load up 2 of them, they don't work together, they just do what they were doing seperating ... dunno maybe the processing power on my performa just isn't enough to give them all they need to show me who's boss..

Min

p.s. I guess your right though ... they don't drive into the water nearly as much as ryan2 ...... but I feel we could do way way better than that... with a few minor improvements to the interface.

Elvis wrote:

Sorry if you got that impression. I was just pointing out that it is possible to do this with computers that are over 7 years old. You may note that I also suggested an alternative way to get around the problem if the brain can not do its processing within the required time slice.

I'd like for you to point out to me ... using the borg interface .. or the one from macbolo .... how you detect that pills are in a tank .... like when the counter shows "little" pills ... indicating someone is carrying .... explain how they did this on computers 7 years ago .... or on computers now for that matter.....

Min

Min wrote:

yeah! thats great we think to ourselfs .... everytime we see a pillbox or base .. it updates its information for us ... handydandy .... wait a sek .... what happens if a enemy comes along .. and picks up one of those pills? ..

Your absolutely right. It was answering your complaint that:

Min wrote:

why don't we just get a array of bases, and a array of pills .... rather than these ultra lame "object" lists ... which are fine for bullets, and probably tanks, and lgms .... but they seem inadequate for allowing proper tracking of pills.

It did nothing else.

Min wrote:

I'd like for you to point out to me ... using the borg interface .. or the one from macbolo .... how you detect that pills are in a tank .... like when the counter shows "little" pills ... indicating someone is carrying .... explain how they did this on computers 7 years ago .... or on computers now for that matter.....

Min

I don't know. Show me where it says this is done in the borg interface specification released with Bolo. Perhaps they received the newswires which is undocumented. They only received player messages in WinBolo.

Min wrote:

load up 2 of them, they don't work together, they just do what they were doing seperating ...

They communicate with each other about information they see using the BBMPL. Reference: http://www.lgm.com/bolo/guides/brains.html

Text: "BBMPL 0.8 (65Kb, Nov 93) is the source code archive of the BBMPL (Bolo Brain Message Parsing Library) version 0.8. Potentially a good way to get started implementing a messaging system in your brain or borg. aIndy and Ladmo use this code, modified as needed..."

Infact even Indy, the predecesor to aIndy did this. From the Indy documentation:
"Indy will tell all the other Indy's that are allied with you about pillboxes and bases that you see."

Heh, I think you 2 should team up for the next version of bolo. Elvis could work on the upgrades he's planned, and Min could fix bugs and code up some sweet bots and brains. :D

Elvis wrote:

Min wrote:

yeah! thats great we think to ourselfs .... everytime we see a pillbox or base .. it updates its information for us ... handydandy .... wait a sek .... what happens if a enemy comes along .. and picks up one of those pills? ..

Your absolutely right. It was answering your complaint that:

Min wrote:

why don't we just get a array of bases, and a array of pills .... rather than these ultra lame "object" lists ... which are fine for bullets, and probably tanks, and lgms .... but they seem inadequate for allowing proper tracking of pills.

It did nothing else.

then unfortunatly you misunderstood my complaint. Making my own array is simple, but I want to know when pills are picked up by an enemy tank, I want to know when a pillbox is in a tank .. weither its in an ally tank, or in a enemy tank ... perhaps this could be done by changing the position for the info or something to a prespecified amout while its in a tank. If I know when a pill has been picked up, I can properly update the position in my array so that the bot no longer thinks the pill in on the ground....

I got to the point in my bot where I would want to properly avoid pillbox positions, so I started writing an array to update pill positions, this is when it came to my attention that doesn't tell you when a pill is in a tank. so if a tank comes along and takes one of the pills in his pillbox line, the bot won't know that .. and will act as if there is still a pillbox in that position. not very effective.

Min

Elvis wrote:

I don't know. Show me where it says this is done in the borg interface specification released with Bolo. Perhaps they received the newswires which is undocumented. They only received player messages in WinBolo.

it doesn't, thats what I'm saying ... nowere in the winbolo interface, or in the macbolo interface is this information given. Which is what I'm asking ... maybe it is and I'm just a moron and missing it? .... show me were it is so I can shut up and go back to programming the bot I've put alot of time, effort and thought into.

Min

Elvis wrote:

Min wrote:

load up 2 of them, they don't work together, they just do what they were doing seperating ...

They communicate with each other about information they see using the BBMPL. Reference: http://www.lgm.com/bolo/guides/brains.html

Text: "BBMPL 0.8 (65Kb, Nov 93) is the source code archive of the BBMPL (Bolo Brain Message Parsing Library) version 0.8. Potentially a good way to get started implementing a messaging system in your brain or borg. aIndy and Ladmo use this code, modified as needed..."

Infact even Indy, the predecesor to aIndy did this. From the Indy documentation:
"Indy will tell all the other Indy's that are allied with you about pillboxes and bases that you see."

ya, thats what it says .... but I didn't experiance this behavior myself ... perhaps I had them configured incorrectly? .... or perhaps my performa didn't have enough cpu power to power 2 aIndy's and my local copy of bolo. Dunno, they seemed bad to me ..... and after examining the indy code (dunno what version) I honestly don't see anything that would make me think that their gamebot logic was anything more than a simple statemachine with 4-5 states ..... aIndy may be better but I didn't experience that when I was playing it.

Min

Lol. Argumints.

I prefer spearmint over argumint.

Also, there is a