Darwinbots Forum
Bots and Simulations => Evolution and Internet Sharing Sims => Topic started by: Botsareus on June 08, 2005, 01:35:59 PM
-
I got a FirstBot evolved from scratch that kills I_FLAMMA in F1 mode.
//Now, I need the physics and the Dna code to stay the same for a couple of virsions like maybe 3 weeks, so I wont have to download the new DB and reevolve the robots each time...//
I am so happy it finaly starting to pay off.
YEAAAAAAAA!!!!!!!!
Here it is , DO NOT put to F1 mode , I am not done with it yet.
(Its a tie bot (that does not eat through ties <--- it will , it will))
Bot8g -->
-
Are you using the latest version?
I ask only because the latest version should format DNA code into easier to read lines based on store, inc or dec.
-
I know Num, I was to lazy to copy and paste it.
-
But did any one actualy see it in action yet? Num?
-
I'm too busy working on instabilities in my Euler method for tie force integration.
-
I'm too busy working on instabilities in my Euler method for tie force integration.
What do you need Euler method for? It seems quite complicated compared to the simplistic physics model we have in the other parts of the simulation.
-
:lol:
Euler's is what we use in the other parts of the program.
velocity = velocity + acceleration is Eulers. It has inherant instabilty because you're measuring things in finite steps. After n many steps you're no longer correct.
-
Yup. That's why you can't model a basic orbit program using this kind of math. The forces that should be acting on the moving objects between the start location and the end location are just completely ignored. :rolleyes:
-
I'm working on ties, and I had a bug where after about a thouand cycles any two tied bots would fly off in one direction. I thought it was due to Euler error, but I still had it after implementing a Runge-Kutta method.
Then I figured out its because I update robot 1's position, then I update robot two's distance from robot 1 and apply forces to robot two. That's probably the same problem I reported with ties a while back (remember the triangle bot that started flying across the screen unpredicatably?)
Hooke tie physics is now much cleaner and smoother. Stifftie can be made to work like it should.
-
:redface: I was thinking of the Gauss method of integration...
Anyway, Euler method is good enough for molecular dynamics, so it should be good enough for DB. However, the algorithm to use is
1. Compute forces acting on all particles (including the effect of collisions)
2. Update positions and velocities.
It's not what happens in DB right now and I guess it causes many problems.
-
Geez, where were you when I neede you Sprotiel. I spent a whole day on that problem.
It's very similar to the problem PY had a while back with information transfer through ties. It looks like we really need 3 main loops for the bots. 1st calculates all forces and information passing, 2nd updates the robots' position,, etc. Third handles death and reproduction.
-
What happens when "bots" posts something? Thats Right, It becomes off-topic central.
All I can say is: Yea Thanks Numsgil, PY, (nooobs) for looking on my robot, yea all your comments and qustions were great. ...
funny thing is it lost the complex feeding method on the second next generation, it turns out the simulation has enough randomness in it for worse robots to be selected, fixed it by doing somthing like Contest mode.
This robot was a true random creation it was actualy not a product of slow gradual evolution. It mutated this stuff in one generation and lost it 2 generations later. Thank god I captured it while it lasted.
And what do the online members of Db do? They start talking about how the whole movment and tie system in dn needs a new doover... :pokey:
resently num posted a screen shot , and he says in virsion 2.4 fat robots will be the defult robots. You know why? simple they are using higher resolutions they cant see the robots , so now lets make the robots fater. Gess what: monitors and resolutions and computer speed will always inprove, So what are we going to do? Thats right: make resolutions bigger and bigger and make robots fatter and fatter...
:help: Botsau :help:
-
Thats why I dont post any new suggestions like I used to , no one cares,. they dont even care to look at this freaky tie bot.
-
resently num posted a screen shot , and he says in virsion 2.4 fat robots will be the defult robots. You know why? simple they are using higher resolutions they cant see the robots , so now lets make the robots fater. Gess what: monitors and resolutions and computer speed will always inprove, So what are we going to do? Thats right: make resolutions bigger and bigger and make robots fatter and fatter...
Ah geez bots, you know we can't stay on topic.
resently num posted a screen shot , and he says in virsion 2.4 fat robots will be the defult robots. You know why? simple they are using higher resolutions they cant see the robots , so now lets make the robots fater. Gess what: monitors and resolutions and computer speed will always inprove, So what are we going to do? Thats right: make resolutions bigger and bigger and make robots fatter and fatter...
In the screenshot I posted, the purple robot is the same size as robots are now. It's just zoomed in. It's the vegs that got tiny, because they're reproducing faster than they're building body.
This was already in there, bigger bots increased in size. I just fixed a bug in calculating radius and made more routines use it.
I assure you, you're going to love 2.4. It's going to be awesome.
More on topic, robots learn to tie to things from time to time. It's not a new development, they always have. All they have to do is store to .tie all the time.
The problem is learning to feed through that tie, or use it for anything. The controls are just too complicated for it to learn in a finite period of time. If we had four years to run the simulation maybe...
Feel free to keep evolving a bot in the version of DB you have. THere aren't any rules that say you have to have the latest version. But the next release will have realistic physics. Alot of things are already falling in place just by consequence of the new physics.
Angular momentum, for instance, of tied bots. A few other things too. It's amazing what a system that's designed correctly can do. The old physics were more or less haphazard and spagetti code.
-
Ok , Now I understand. Sounds good to me Num.
But I think this robot uses the fact the physics is spagetti code to beat I_flamma... (will see what happens in the new physics, hope its still as freacky as it is now , or better atleast)
-
Thats why I dont post any new suggestions like I used to , no one cares,. they dont even care to look at this freaky tie bot.
Plz?
:) Bau :) ;)
Ok if you dont want too look dont look , I am not bragging any more.
The best thing you can do is put it in F1 mode agenst I_flamma , really fun too see flamma get in trouble by a mutant.
-
Load it into the program and copy and paste it from the DNA window so it's easier to read. I hate trying to read
cond
start
this
is
really
hard
to
read
and
drives
me
absolutely
crazy
stop
-
'mostly junk dna , but you will see a really waired tie feeding code hidden in here
cond
*.nrg 19874 >
start
add 50 .tieang1 store
.repro store
50 .repro store
50 dec
sub *857 -177 .aim store
rnd
stop
'''''''''Gene 2: Last 'stop' at position 23'''''''''
cond
start
-1084 div add *.up
stop
'''''''''Gene 3: Last 'stop' at position 30'''''''''
cond
start
stop
'''''''''Gene 4: Last 'stop' at position 33'''''''''
cond
start
-1 8
stop
'''''''''Gene 5: Last 'stop' at position 38'''''''''
cond
start
276 add 7 div 289 add inc
*.fdbody 6 276 sub mult *754 18 dec
rnd 210 1 mult add 423 store
*.trefvelmysx store
stop
'''''''''Gene 6: Last 'stop' at position 65'''''''''
cond
start
mult mult
stop
'''''''''Gene 7: Last 'stop' at position 70'''''''''
cond
start
-1 .shoot store
-1 dec
715 rnd store
dec
*.tielen4 6 dec
20 mult -1413 div .up store
20 .up store
stop
'''''''''Gene 8: Last 'stop' at position 94'''''''''
end
-
The only thing I can see that would make a tie is the 715 rnd store (assuming there's some values on the stack).
I think those are the most useful commands. Start doing things at random and you're more likely to do something.
-
... you know if you would actualy see it in F1 mode agenst I_flamma ...
-
Don't despair! I actually started writing a post on-topic a few hours ago but I had to stop before it was finished.
Your bot is interesting for several reasons :
* It reproducibly freezes DB. This is probably due to the anarchic proliferation of ties.
* The numerous conditionless genes hint at the fact that we need a mechanism to insert conditions.
* Analysing the genome should give us some insight on how evolution in DB really works. First, let's take a look at what it actually does. Here's a rewrite of its genome which exactly reproduces everything it does, except for the cost of conditions (each line starting on the first level of indentation is a functional unit):
cond
*.nrg 19874 >
start
add .repro store
50 .tieang1 store
50 .repro store
50 dec
-177 .aim store
sub
*857 rnd
stop
cond
start
-1084 div add *.up -1 mult mult 'This is always(?) zero
715 rnd store
330 inc
*.fdbody -270 mult 'This is always(?) zero
*.trefvelmysx store
.aim dec
*754 rnd 210 add 423 store
-1 .shoot store
-1 dec 'does nothing
6 dec 'does nothing
dec
*.tielen4 20 mult -1413 div .up store
20 .up store
stop
end
If you look at how the instructions are spread in the DNA, you can notice that the functional units are haphazardly intertwined (See the attached file, differing levels of indentation means differing units, I hope it's clear enough!)
My conclusions:
* The actual stuff on which evolution acts isn't DB genes but what I called functional units and these are distributed along DB DNA in a way which is different from genes in real DNA. I'm not sure what this implies, but I think we shouldn't try to model too closely real biological processes because our system is markedly different from biological systems.
* We already have lots of junk DNA. It's made of instructions which are part of units which don't do anything useful. The possibility that it turns into something which has an effect isn't that remote however.
Edit: forgot to attach the stupid file, again!
-
Where did 330 inc come from in your condensed DNA? Man we really need a step by step bot debugger.
-
funny thing is it lost the complex feeding method on the second next generation, it turns out the simulation has enough randomness in it for worse robots to be selected, fixed it by doing somthing like Contest mode.
This is Muller's Ratchet at work. Our population size is small enough that genetic drift is, if not stronger than natural selection, within the same order of magnitude.
-
Ok , I think this robot likes not using conditions that why there is'nt any.
It should not freeze in the 2.37.2 virsion, try it there.
* Analysing the genome should give us some insight on how evolution in DB really works. First, let's take a look at what it actually does. Here's a rewrite of its genome which exactly reproduces everything it does, except for the cost of conditions (each line starting on the first level of indentation is a functional unit):
I did not evolve this robot with reguler db , I wrote my own little patch for Db , its so different that Its going to take me a while to explain and going to take you a while to comprehand.
* The actual stuff on which evolution acts isn't DB genes but what I called functional units and these are distributed along DB DNA in a way which is different from genes in real DNA. I'm not sure what this implies, but I think we shouldn't try to model too closely real biological processes because our system is markedly different from biological systems.
* We already have lots of junk DNA. It's made of instructions which are part of units which don't do anything useful. The possibility that it turns into something which has an effect isn't that remote however.
I think I need to give it more time , it will evolve fearly normal dna in the long run (I hope)
-
thx for looking on my robot guys.
-
That could be a reason that there aren't any conditions. If you change the way the bot mutates...
My new mutations controls should eliminate this kind of favoritism and be strictly random.
-
Where did 330 inc come from in your condensed DNA? Man we really need a step by step bot debugger.
330 comes from
8
276
add
7
div
289
add
It was in the attached file, but I forgot to attach it...
-
I actually checked that part, but my calculator gave me 329.5714286 and in my tired state of mind that didn't equal 330 :P
-
My new mutations controls should eliminate this kind of favoritism and be strictly random.
I hope there is still mutation of mutation rates...
-
If you insist :rolleyes:
-
:P
-
Cool analysis... Anyone wants to look at my Dom ternia in the same way?
:)
-
It turns out the robots were getting extra energy out of junk dna. I cant trace the source of the problem so I wrote a quick simple solution:
Private Sub corpo(n As Integer)
Dim pnt As Integer
rob(n).mem(thisgene) = currgene
For pnt = rob(n).pntr To rob(n).DnaLen
Select Case rob(n).DNA(pnt).tipo
Case 0, 1
instack n, pnt
Case 2
istruzione n, pnt
Case 4
Exit For
End Select
rob(n).nrg = rob(n).nrg - 0.007 'James Bond Fix
Next pnt
...
That fixes the problem, now robots with a lot of junk dna and robots with little dna are in equal ammounts of energy.
Stay tooned for more bugs and/or more mutants, and sry that I deleted 13.txt , its that junk dna feeding robot, :banghead: I should of saved it. But still if you look at the file I posted attached to this thread from before, you will see that it does atleast 5 opps. that are basicaly junk dna. This stuff does not make sense... fix above^.
-
Um, that doesn't really fix the problem, it just covers it up. If bots are getting nrg from somewhere they're not supposed to, you need to find and isolate it. It could just be a symptom of a large problem.
-
c++ for num:
I cant trace the source of the problem so I wrote a quick simple solution:
==
Um, that doesn't really fix the problem, it just covers it up. If bots are getting nrg from somewhere they're not supposed to, you need to find and isolate it. It could just be a symptom of a large problem.
ALL TRUE
-
As long as we understand each other.
-
... This was based on Endys approach to evolve a firstbot ... I abandoned this philosophy because it reminders me of the devil algorithm ...
A cleaner solution is available ... but only to me for now ... God does not play dice, neither do I although I am not in charge ...
-
The day will arrive.