Bots and Simulations > Evolution and Internet Sharing Sims
Shvartz, can you help me out?
Botsareus:
Yea how about insert a new command with complete numbers with the proper range, the label itself and the store command. ex:
--- Quote ----1 .shoot store 'inserted as a whole
25 .aimdx store 'inserted as a whole
--- End quote ---
I agree with PY on:
--- Quote ---Of course we can still add or delete single points too.
--- End quote ---
And it can change it to out of range if it wants to.
And If you really start to talk about complete numbers with proper range , then insert a new instruction should do range checking as well.
But, If you REALLY want numbers to (almost) always be in range, then good luck , its one bloody long select case to write for each bloody sysvar, I am not doing it :P
PurpleYouko:
--- Quote ---Yea how about insert a new command with complete numbers with the proper range, the label itself and the store command. ex:
--- Quote ---
-1 .shoot store 'inserted as a whole
25 .aimdx store 'inserted as a whole
--- End quote ---
--- End quote ---
It does exactly that now. I wrote the code myself and tested it. Originally it did this but not very efficiently. Now it inserts the entire condition or command with values in the right ballpark for them to work.
--- Quote ---
--- Quote ---Of course we can still add or delete single points too.
--- End quote ---
And it can change it to out of range if it wants to.
--- End quote ---
Yes to a degree it can go out of range, however it is designed to keep the value being mutated, somewhere close to the original value
--- Quote ---And If you really start to talk about complete numbers with proper range , then insert a new instruction should do range checking as well.
--- End quote ---
It does, to a dgree. You can't expect it to be in exactly the right range to work perfectly. For example, the value stored into .aimsx can be in pretty much any range as long is its magniude is less than 32000. However .fixpos (and some others) can only take zero and non-zero as inputs. so if the line...
--- Code: ---187 .aimsx store
--- End code ---
should mutate to
--- Code: ---187 .fixpos store
--- End code ---
You can't expect the code to also change the 187 to something meaningful by searching a massive database of suitable ranges.
If the robot evolves such a crappy line of code then it is just going to fix itself to the spot and die. Tough! That's evolution for you.
--- Quote ---But, If you REALLY want numbers to (almost) always be in range, then good luck , its one bloody long select case to write for each bloody sysvar, I am not doing it
--- End quote ---
You certainly have that right!
But then again I am still waiting to get my hands on a working version of the new code that Num is working on. The stuff he has already given me is so radically different from V2.36.7 that I don't know where to start with debugging it until it is at least mostly working. I would estimate that he is totally re-writing about 10% of the entire code.
Botsareus:
Good Work, Lets release that version and see what happens. Personally I can’t wait to try it out myself:
I came up with an ultra new ultra hyper way to evolve first bot, but guess what? in the current version this ultra new method crashes the simulation. And the error is so deep in the source code, good luck finding it. (its something to do with not finding some kind of dna term and searching beyond the ubound of the dna stack)
Anyway here is exactly what I was doing and plan to try again (hopefully that error will be fixed, if Num or PY care enough to experiment with the following them selves):
I set plants with no mutations, and First bot with mutations about "200!" <--don’t get scared I gave them a good chance to survive because:
After checking and unchecking F1 mode, I set the number of plants to be displayed on the screen at start up to be "400!". The idea is the robot will mutate and reproduce like crazy, then the plants will stabilize back to F1 conditions, and only the best robots from the ~300 on the screen will stabilize to ~60. (If natural selection indeed exists, and there got to be some mutations that ended up better, not worse, then we should get a better resulting robot.)
The problem is when the robot population goes over ~100 the simulation crashes, I also see robots with birth ties / ties, when moved from one side of the screen to the other (on the borders) , the ties stretch out for a second all the way across the screen. I mean just by looking on this entire picture you know something’s gunna crash any second now...
PurpleYouko:
--- Quote ---Good Work, Lets release that version and see what happens. Personally I can’t wait to try it out myself:
--- End quote ---
:blink:
Already did. Ages ago. It was called V2.36.7. I actually modded the mutations code back in 2.36.2 though. <_<
Num may have changed things a little for .7 but I don't think he got that far into it.
The source code is even up there on both servers. Check it for yourself.
Botsareus:
Then why is Shvartz having trouble with my little first bot? :/
Shvartz:
--- Quote ---Consider this: when we program bots we write "a b store". Bots never evolve things like this. They go through complicated scenarios often involving several genes. Numbers are placed on stack, manipulated in many different ways and finally they are stored into memlocs.
--- End quote ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version