Darwinbots Forum
Code center => Darwinbots Program Source Code => Topic started by: Griz on October 21, 2005, 02:22:02 PM
-
playing with both 2.36.5 and 2.36.7 ...
finally figuring out how to get leagues to work.
how-some-ever ...
is there some way to limit the number of cycles in a round?
if I have two bots of similar 'skill' ... this contest can go on forever.
now that wouldn't be too bad ... to wait it out but ...
if it goes on too long I will eventually get a runtime error ...
maybe too many bots generated ... who knows?
and then the whole thing crashes in the middle of my league run!
so all my work is lost!!! read: waste of time.
I don't know how any leagues ever got run ...
when bots with similar skills are involved.
I know folks are busy spending time playing with 2.45.b.213.acv.4x ...
but just wanted to know about 2.36 as that's the only one I am
interested in investing time in at this point.
if no one wants to play with it ...
then at least can we eentually have control over the number of cycles
in a round of league play in version 2.4xxxxxxx
~griz~
-
question:
what do I need to be able to program DB in VB?
besides skill that is. ;)
I have VB6 ... and can download the DB sources ...
what else is required?
is there compiling involved?
I mean if I can get a handle on how it sorta, kinda goes ...
maybe at some point I'll be able to help debug some of the older versions ...
as I'm sure you'll all be roaring off in c++ by then. ;)
what do I need?
~griz~
-
You need the MSDN help library. Thats about all. Good Luck.
-
question:
what do I need to be able to program DB in VB?
besides skill that is. ;)
I have VB6 ... and can download the DB sources ...
what else is required?
is there compiling involved?
I mean if I can get a handle on how it sorta, kinda goes ...
maybe at some point I'll be able to help debug some of the older versions ...
as I'm sure you'll all be roaring off in c++ by then. ;)
what do I need?
~griz~
Just Visual Basic IDE and the code. That is one nice thing about VB.
You don't even have to have the MSDN, (I don't) but it would sure come in handy.
-
IDE means somthing like: "Programing Invirment" witch is the softwear you already have.
-
Yes, IDE = Integrated Development Environment which is the thing that's generally called "Visual Basic". It's what you code the code in.
-
One more thing: You need to place your source code files in your v 2.1 main install folder so all the "robots" and "defult.set" and sutch... are happy.
-
Well, you don't have to (I don't) but it helps. Otherwise you're constantly being asked "where the heck is sysvars2.21.txt".
-
You don't even have to have the MSDN, (I don't) but it would sure come in handy.
well if these are the help files, programming guides, etc ... yes ... they would be handy. ;)
I may have some old docs from when I had an early version of VB ...
like from around 1996 ... you remember back that far? ;)
so even if I can find them ... don't know how good they will be.
probable some basics tho ... haven't done and vb since 2000 or so.
ok. then we will see ...
I'll install the vb and play around this next week or two ...
and see if I can learn enough to ask questions. ;)
~griz~
-
Griz, It says "c 1992 - 1998 Microsoft Corporation" on the back of my msdn disk. I was 10 when I got it but I remember. ;)
-
now what about my original post ... for this topic ...
can you point me towards the code where one might find a way to
enable the user to limit the number of cycles in a round in the league play?
I mean it is obvious you intened to 'go there' at some point as the form
is there ... just won't accept input.
ver 2.36.5 [I guess the newer versions will be the same]
~griz~
-
I had the idea of doing it, but I never implemented it. At onec point I added like 20 new fields to options form that were all things I wanted to add. And I added maybe 16 of those.
If you want to implement it yourself, I'd put the code in the Sec_timer or whatever in Form1. Have it check to see if SimOpts.TotRunCycle or SimOpts>TotRunTime (depending on which you want) is less than or equal to some user preset value.
If it isn't then restart the round, or give one bot the win, or whatever.
-
Well, 2.37 has a "max time in round" option. As far as making your own ristrictions you have to make a "catchy" for it in the timer executed parts of the program. I would go to "Form1 > cyccaption" to write the actual code. But my code will "effect" what is happening at "F1Mode > Countpop".
lol Num beat me to the post ONLY because I am looking to my second time attachment of my damed placement control. god dam it every time I attach it I cant find it.
-
Well, 2.37 has a "max time in round" option
well the box is there ... but last I knew it wouldn't accept input.
but I copied both Num's and your suggestions ...
and will file them away until I can get into the prog and see if I can
find my way about.
thanks
~griz~
-
If it isn't then restart the round, or give one bot the win, or whatever.
yes. also ... when I did that manually with two bots that were too evenly matched to end it on their own ... it would still go into extra rounds if one was not statistically ahead ...
so it would also be nice to say ... STOP after 5 or whatever is selected. period.
ok.
I should have it fixed by 2008. ;)
~griz~
-
lol Num beat me to the post ONLY because I am looking to my second time attachment of my damed placement control
that's something I'm interested in as well ...
and I noticed that when the algae are repopulated ...
they ignore my placement instructions.
is that part of what you are addressing?
see ... I have been doing gravity sims trying to confine the veggies to the
upper portion of the window ... developing bots that have to be able to
find a way to reach them. works fine until a repopulation event ...
and then they show up everywhere and the whole sim falls apart.
I'm also wondering if we might just post the relevent forms or whatever
moduals we alter somewhere ... rather than upload the entire program rev.
then other's who are messing with the programming could grab those and
run them in their own sim ... check 'em out.
once they are known to work and address what people want changed ...
then they could be incorporated into a new beta version.
just throwing out ideas ...
twywaltr
~griz~
-
I found it: http://forum.darwinbots.com/index.php?show...dpost&p=1107061 (http://forum.darwinbots.com/index.php?showtopic=825&view=findpost&p=1107061)
As you can see, I did not even touch the actual placement routines, forget about modifing them. Ok I will implement this stuff and what you are suggesting but It will be useless once we got the egrid because the placement for repopulation will be determind by the conditions on the grid.
-
I'm just stashing stuff away for now ...
will install vb later this week and begin to see if any of this makes sense.
this was for ver 2.4, yes?
~griz~
-
I'm also wondering if we might just post the relevent forms or whatever
moduals we alter somewhere ... rather than upload the entire program rev.
then other's who are messing with the programming could grab those and
run them in their own sim ... check 'em out.
once they are known to work and address what people want changed ...
then they could be incorporated into a new beta version.
That's the idea. All the code used to be pretty much in one form, (Form1). Several monmths ago I took that apart and posted them to seperate modules.
Anyway, yeah, just zip up and attach modified forms. It's easy enough for me to run windiff and see what's different.
-
Bots' robot placement code was really just a proof of concept about how the controls could work in the options form. He left the actual grunt work of figuring out what the current code is doing and modifying that to the other programmers.
-
Bots' robot placement code was really just a proof of concept about how the controls could work in the options form. He left the actual grunt work of figuring out what the current code is doing and modifying that to the other programmers.
ah ... another 'idea' man, eh? ;)
~griz~
-
ok ok , I added the control myself, and will upload everything (including somebug fixes) to the darwinbots email adress. (Good Luck with that bots doing off yahoo on a 56k...)
-
Off topic:
Griz Posted on Oct 21 2005, 08:51 PM
... I have been doing gravity sims trying to confine the veggies to the
upper portion of the window ... developing bots that have to be able to
find a way to reach them. works fine until a repopulation event ...
and then they show up everywhere and the whole sim falls apart.
I did something similar for an ecological sim. The plants were modified to turn skywards and then accelerate. They typically wound up in the left top corner as an oddball consequence(I think sunwards(*.sun) is very slightly to the left of dead center, not sure). The plants eventually die from energy exhaustion and can leave corpses to fall down for lower bots to eat.
This should give you the results you want. An alternative option is to have them use buoyancy instead to provide the acceleration.
-
I did something similar for an ecological sim. The plants were modified to turn skywards and then accelerate. They typically wound up in the left top corner as an oddball consequence(I think sunwards(*.sun) is very slightly to the left of dead center, not sure). The plants eventually die from energy exhaustion and can leave corpses to fall down for lower bots to eat.
slick! of course I've not yet explored corpses and who can/can not eat them ...
trying to keep as few variables as possible ... to see what changes/mutations in bots evolves to work in a restricted environment that "I" have control of.
btw ... do you have that plant posted here? is it the floating veggie one I saw?
if not ... do you have it stashed or can you tell me how you modified it to do so?
tanks.
This should give you the results you want. An alternative option is to have them use buoyancy instead to provide the acceleration.
yes ... I enabled bouyancy to help my bots get up there ...
and then tweaked gravity to get a nice balance.
I believe that was perhaps in 2.21 or something ... as the placement worked there.
trying it in the newer versions ... it doesn't keep them there.
not sure bouyancy is a feature in the 2.4 series ... perhaps it is renamed somewhere.
I'm still trying to just get it to run ... nowhere close to being able to experiment.
~griz~
-
Bouyancy is in 2.4, but not so directly.
Boyancy in 2.4 is a function of the density of the liquid around a bot and how much if it he is displacing. Later on I was going to add a way to build "float sacs" that increase volume without increasing density all that much.
-
Bouyancy is in 2.4, but not so directly.
Boyancy in 2.4 is a function of the density of the liquid around a bot and how much if it he is displacing. Later on I was going to add a way to build "float sacs" that increase volume without increasing density all that much.
ah ... I like it ...
having been a submariner at one time.
are you also thinking of having density vary with 'pond depth'?
and as a function of the 'fluid' ... thick or thin?
interesting.
but why build 'float sacs'?
simply allow a bot to alter it's own density.
perhaps you were going to already have a bot density ...
and perhaps have it change along with body size ... I don't know.
anyway ...
always a good rule ...
to whenever possible ...
simplify, simplify, simplify.
that ...
and troubleshooting by altering only one variable at a time.
things are complicated enough on their own. ;)
~griz~
-
Well, bots currently have a radius and a mass. Density is easy enough to construct from that (mass / (4/3 PI radius ^ 3)).
Currently, body is the only substance that effects bot volume and thus radius. Shell and body are the only things that effect mass.
So presently a bot can increase it's density by building lots of shell, but there really isn't a way to decrease it's density along the same lines.
That's what I invisioned float sacs for. float sacs would be massless bubbles that increase volume without increasing mass.
Also, in physics, all forces operate on added mass, which is a property I can only find alluded to in several places, so I may be off with it.
Basically added mass means that for an object in a liquid to move, it must accelerate itself and an equivelant volume of liquid it's displacing (that it must displace to move forwards and replace behind it as it leaves).
As far as I know, isn't liquid incompressible? Gasses are compressible, so density changes with depth, but I think things like water have a constant density at all depths.
So Maybe you could set wether the big blue field is a fluid or solid, and if it's a fluid wether it's a liquid or a gas?
Pressure, on the other hand, does indeed vary with depth. Should we make an "implosion/explosion" threshold that bots explode/implode at if the pressure differential becomes too great?
Though I'm not so sure that's applicable since theoretically the bots' membranes are premeable to the fluid they're in.
-
You all know what I am waiting for...
-
Num, I think its better to release a new virsion of 2.37, because you may or may not have changed some of the code I wrote bug fixes for...
-
I can't worry about more than one version at once. If someone wants to debug 2.37, more power to them, but I don't have the time or mental ability to keep track of two seperate versions...
-
Just release my program to the ftp , thats all I am really asking right now. the way it is.
-
Well, bots currently have a radius and a mass. Density is easy enough to construct from that (mass / (4/3 PI radius ^ 3)).
Currently, body is the only substance that effects bot volume and thus radius. Shell and body are the only things that effect mass.
So presently a bot can increase it's density by building lots of shell, but there really isn't a way to decrease it's density along the same lines.
That's what I invisioned float sacs for. float sacs would be massless bubbles that increase volume without increasing mass.
Also, in physics, all forces operate on added mass, which is a property I can only find alluded to in several places, so I may be off with it.
Basically added mass means that for an object in a liquid to move, it must accelerate itself and an equivelant volume of liquid it's displacing (that it must displace to move forwards and replace behind it as it leaves).
As far as I know, isn't liquid incompressible? Gasses are compressible, so density changes with depth, but I think things like water have a constant density at all depths.
So Maybe you could set wether the big blue field is a fluid or solid, and if it's a fluid wether it's a liquid or a gas?
Pressure, on the other hand, does indeed vary with depth. Should we make an "implosion/explosion" threshold that bots explode/implode at if the pressure differential becomes too great?
Though I'm not so sure that's applicable since theoretically the bots' membranes are premeable to the fluid they're in.
I just think you are overcomplicating things ...
getting distracted by the details.
and that this has little if anything to do with simulating evolution.
yes ...
it would be nice to have it follow physical laws as much as possible ...
but that should be secondary ...
a lower prority than actually simulating how entities and their
environment evolve in a symbiotic relationship.
that's where the focus should be, imo.
we should get the basics of that working ... as they should ...
and provide a working platform from which others can continue
to explore and experiment.
and to simplify whenever possible, not complicate.
that's my opinion.
-
I tend to spend more time working on other things than the physics... That was more recent.
You see, one time I wanted to make a squid bot that moved by jet propulsion. Turned out the physics engine at the time wasn't capable of doing that. Which made me really frusterated.
So I tirelessly work to make the physics engine robust enough to program the sorts of bots I wanted to all those months ago.
-
yeah ... I can relate ...
and seeing as you are the one doing the work ...
I guess you will do whatever you need to realize your vision.
but that then will result in a 'physics' simulation ...
which I could get off on too ...
but it isn't an evolution simulator ...
which is my primary interest.
I will say I am impressed by how much work you have done
since hooking up with DB.
but you know (or maybe not) ;)...
it's just kinda frustrating for many of us ...
to not have in place something that is finished and works
as advertised. ;)
so ...
I guess that's motivation to quit sniveling and whining ...
and figure out how to do it for ourselves. ;)
sorta like life.
-
Most versions fix the bugs from before them. Then introduce their own new ones. I suppose that doesn't really make things easier for the end users, does it.
I'll release a 2.4 version later tonight with error.sim re-instated, so I can let you guys wreck the program and send me the error reports.
-
Num, mind telling me how error.sim works because as far as I know once you get an error in vb you cannot save anything including simulations...
-
At the start of the main loop, I do:
On Error goto somelabel.
Then at the end of the code I have:
somelabel:
Savesim "error.sim"
MessgaeBox "oops"
exit sub
(Not exact code, I'm paraphrasing).
-
I see B)