Community project (now pretty much defunct)

[Elite]

Thanks for that, I was wondering who that was  :D

I've updated it with all the new info. You are welcome to watch and help with the wiki.

Aren't antbots cool  :)

[PurpleYouko]

seems all the queens end up going 'out of bounds' and then
doing nothing. any idea why that might be?

Could be screen sizes. Ant-Bot 5 is designed to work in size 3 best. If you run a smaller size then the queen may try to leave the screen when she decides where her nest will be.

the nest location is determined randomly with x and y coordinate maxima matching the size 3 dimensions

[Elite]

Go here to participate in the project (+ lots of information about halfway down)

 :help:

Go here to see who's doing what and how the project is organized

 :D

And go here to make suggestions concerning hivebot communication, information gathering and (x, y) location stuff. If you have any ideas then just say, you don't need to know how to program bots to make good suggestions.

 :D

Come on. I need your help!!!  :help:

[Griz]

the nest location is determined randomly with x and y coordinate maxima matching the size 3 dimensions

I figured maybe.
24000 x 18000 is size 3 ...
16000 x 12000 for #2
while size one is 9237 x 6928
where is that set in the code?
 
I find this in gene 2 for new queens:

3 .type store
14000 rnd 100 add .queenx store
10000 rnd 100 add .queeny store

which, if this is it, would work in both size 2 and 3.

if I alter this to  say ... 9000 and 6500 will that do it?

I wonder if the code could be written to sense
what size the field is upon intializing the bots ...
so they could be run in any size?

thanks

[Elite]

Got the same problem with wraithbot

I haven't found a way of sensing field size but it would be a good idea. The problem is that the coordinates cannot exceed 32000.

Suggestion - need some new sysvars:
.fieldx
.fieldy

 :D

[Griz]

Got the same problem with wraithbot

I haven't found a way of sensing field size but it would be a good idea. The problem is that the coordinates cannot exceed 32000.

Suggestion - need some new sysvars:
.fieldx
.fieldy

 :D

that would be slicker.

anyway, altering those values seems to work.
also increased the feeders velocity from 10 to 30 to speed things up
and have to recall how to have a bot turn when it reaches a border
in the non-toridal versions or the feeders just butt their heads.
with just a hint of gravity, and the veggies repopulating only at
the top, they end up as a layer on the bottom with the hives usually
higher and swifter ants cruising down and returning with food.
fun to watch.

[PurpleYouko]

I find this in gene 2 for new queens:

3 .type store
14000 rnd 100 add .queenx store
10000 rnd 100 add .queeny store

which, if this is it, would work in both size 2 and 3.

if I alter this to say ... 9000 and 6500 will that do it?

Yup that's the gene. And you are right. they will work in size 2 also. That alteration will make them work fine in size one.
Seriously though, they are way better in bigger sizes.

Got the same problem with wraithbot

I haven't found a way of sensing field size but it would be a good idea. The problem is that the coordinates cannot exceed 32000.

Suggestion - need some new sysvars:
.fieldx
.fieldy

Yes that would be a pretty good idea. Easy to implement and not using up any resources since it can be set as a fixed value at the birth of the robot. This also gives you the option of screwing with a bot by telling it other values than the real ones. Maybe set ranges that way.

As for not exceeding 32000, I am going to make the variables all "double" soon so that will no longer be an issue with the next version. No plans on when yet. Too darn busy lately.

[PurpleYouko]

and have to recall how to have a bot turn when it reaches a border

*.edge returns 1 when the robot hits a border. Resets every round so the cycle after it will be 0 again.

[Griz]

and have to recall how to have a bot turn when it reaches a border

*.edge returns 1 when the robot hits a border. Resets every round so the cycle after it will be 0 again.

yup. got it.
added it to the ants ...
otherwise in toridial mode, they just bump into a wall ....

'looking for borders
cond
 *.eye5
 -1
  !=
start
314 rnd 157 sub .aimdx *.edge mult store 'rnd turn left or right 45 degrees
stop


and in 2.4, as the body size gets larger/more massive ...
 they go 'outside' the field ... and unless they have some
sort of turning thing, never come back in.  
I still haven't fingered out why Num's enabled that to happen.

I prefer the small field of play and not so many bots ...
otherwise those ants certainly do 'crawl' along.
I set them to 30 vel too, instead of 10.

using version 2.4 now, as I like the physics ...
and it seems pretty stable.

couple questions:

what's the difference between a worker and a warrior?

what is the purpose of fixing a feeder's position if it is not feeding a queen?

the queens often don't reproduce if their feeders
happen to 'buy it' and not get back to them.
there is a gene for them to repro if nrg < than 2000 but I don't see it happen.
they just continue to lose energy until <500 and then have 100 added.
and they eventually die too, not sure how.

seeing as I am using non-toridal and a bit of gravity ...
most of my veggies are near the bottom.
so I want to have the newborns tend to head towards
the bottom to search for food, rather than randomly go in
any direction.
assume this would be .setaim:

' worker selects direction to head after birth
cond
*.robage 10 =
start
1256 rnd .setaim store
stop

1256 covering all angles ....

looks like 0/1256 is to the right ...
314 is up, 628 left, and 942 down ...
so to get a range of 90 degress down ...
45 to -45 degrees from straight down I would need:

314 rnd 785 add .setaim store    yes?

I tried it and it works ...
but might as wll leave this here for others who may
be lurking and know as little as I. ;)

anyway, watching the project and coders ...
and playing with these ants ... who knows ....
I may finger some of this out yet.

so I hope no one minds my asking questions.
would like to have a wiki page for questions like this as well
thinking it is much easier to talk there and not lose where in
some thread someone said what ...
but I don't think many people visit it. yet. ;)
we will see.

[Numsgil]

As to why bots manage to go outa bounds in 2.4:

It's a consequence of how the physics engine works.  Hard constraints are difficult.

In the port I've implemented yet another way in which the engine works which allows me to do both 'hard' constraints (bots CANNOT leave the arena) and softer constraints (bots are pushed into the arena if they leave).  I'm pleased with the results so far, and I think everyone else will be too.

[Griz]

As to why bots manage to go outa bounds in 2.4:

It's a consequence of how the physics engine works.  Hard constraints are difficult.

In the port I've implemented yet another way in which the engine works which allows me to do both 'hard' constraints (bots CANNOT leave the arena) and softer constraints (bots are pushed into the arena if they leave).  I'm pleased with the results so far, and I think everyone else will be too.

cool.
I do enjoy the more realistic physics except for this ...
just seems they go too far ...
I can envision the borders being 'springy' or 'elastic' ...
as long as they get pushed back, or rebound ...
but they do seem to get stuck on the other side and
'out of play' on occasion.
I suppose with hard constraints you would have to
take the bots radius into cosideration, but don't know.
I would think their 'center' would be able to be more
realistically 'reflected', so that no bot, regardless of
size, would every have it's center pass outside the limit.
obviously, you've played with it and would do that if there
was a way to do so. ;)

how's the port coming?

what would be a good compiler to obtain?
I would like to begin to learn C++ ...
and DB is certainly the most interesting program ...
so this would provide good motivation ...
esp with you guys around to sort out problems that
are common to all users.

DB us pretty cool Nums ...
thanks for all the work.
I know you love doing it, so it's not all work for you ...
but I understand it takes a lot of effort and commitment.
so thanks for all you've done.

[Numsgil]

Personally I like MSVC 6.0 (which you can get from the FTP under tools)

Other people swear by Dev-C++ (which is downlaodable outside the FTP.  Google)

Either/or really.

I'm done with everything in the core engine except mutations, shots and ties.  I still need to implement the basic GUI controls (they exist but they don't do anything yet) and debug it like crazy.  I'm also extremely exhausted and sick of looking at the code, so I'm taking some time off at the moment to learn something called Ogre3D.

I'd say there's like another 100-200 man hours of work to get to a beta version.  I'm aiming for the end of February but I'm not 100% certain if I'm going to make it or not.

If you're looking to learn C++ I'd recommend getting a physical book instead of learning it through some online tutorial.  I've purposely tried to keep the source as straightforward and simple as possible, so it shouldn't be too hard for a "newbie" to see what's going on where.

[Welwordion]

Just a thought, but maybe the queen should be a batterybot or more like tieing a veggie reserve to it,
that way the hive could repopulate the world with veggies without having to rely on extern repopulation and it also could try to maintain a better distribution of veggies.

Oh and if we talk about veggie reserve, how about a "bot" reserve? the swarm could try to make "prisoners"
bots that are disabled and forced into some kind of hibernation and if the other species of bots have driven themself to extinction the prisoners would be freed to repopulate the world?

[Henk]

That's a good idea!

Gotta think about that one...

[Elite]

OK, seen as there's interest again

Nice idea Welwordion

How about having the bots hunt at night, so that their prey (and vegs) can be repopulated in the daytime