Darwinbots Forum
Code center => Darwinbots Program Source Code => Topic started by: Panda on August 08, 2013, 09:27:38 AM
-
From reading http://forum.darwinbots.com/index.php/topic,3487.50.html (http://forum.darwinbots.com/index.php/topic,3487.50.html), it's just got way too complicated. I've come to it from after a few years and I have NO idea what's going on and how anything is happening.
I've a few questions, anyway:
What's happened to chloroplasts?
Should we rethink it?
Is any help needed? (I've had another 3 years of programming experience (1/3 of which is at University), I might not fuck it up as badly as I did last time.)
P.S. HEY GUYS! :D
-
I am on top of it Panda, I'll like to go with Shvarz logic, he is a Biologist after all.
I had a lot of more minor updates to grind trough and I started work so everything ended up being delayed.
http://forum.darwinbots.com/index.php/topic,3721.0.html
I can send you an excel file of what I was working on (statistically speaking)
(I'll trust that you can program it in, but some concepts you may not like, such as, we need to make chloroplasts as part of the DNA file, We can go step by step and figure it out. TY for your offer to help, I need it right about now :) )
Let me know, I'll upload my most resent updates on the weekend. And If you are not too busy you should be able to knock it out in a week.
There is also http://forum.darwinbots.com/index.php/topic,3816.0.html check out reply #5
This is done so robots do not get free energy with repopulating chloroplasts when they are not supposed to. Once again this is following Shvarz logic. I am getting a lot of heat on this specific topic. (We can discuss further :) )
-
From reading through this, I cannot work out exactly what you want from chloroplasts. I know it would take time but if you could put down in here what you want, in sudo code or in words, it would make it a lot more clear for me.
If not, I'll try to work out what is wanted but it'd take me quite a while.
-
I am at work now, I'll get you my excel file and an explanation on Saturday.
Please tell my you have excel? If no, not a big deal, I'll write up a little vb progy that crunches the data.
-
I don't have excel but I can upload it to google, I'm sure it can show it for me! :D
-
k, will do.
-
I want to go over some pointers before I get into the good stuff. First, you will see me use square and square-root at places. There are two reasons why I do that:
1.) I need to convert from Area (2D) to value (1D)
2.) It just looks and feels better. We may need to play with these further though.
Second, I want to make changes to the Options Form layout as little as possible. In fact, if we go with my system we will not need to touch options form at all.
Finally, this is not what I want to see from chloroplasts, In fact, my views on chloroplasts where completely different. But, after talking to Shvarz, his system is actually pretty good.
Ok, here we go:
Attached is an excel file that shows visually all formulas described herein:
In an ideal world for plants, the amount of light they receive should be a constant. It is not. The two main factors that affect the amount of light a plant gets are
1.) Is it night or day?
2.) How much light is left available in the system?
The first one is easy to code for, we just base it on the current code. We need to start modifying the current code to code for the second.
Let us take a look at feedvegs in vegs.bas. I want to keep that subroutine and modify it. If we do that we can use the existing vegy options (Figure 1) and also we don't have to modify night and day options or even the pond mode options.
1.) We have to reprogram that subroutine so it works on all robots. Any robot can have chloroplasts after all. We still need to keep the veg distinction in the species structure so the system knows what robot to repopulate. I'll talk about that in detail later.
2.) Here is where it gets tricky. We have to start modifying after tok is calculated. The line you are looking for is:
If tok < 0 Then tok = 0
We need to figure out how much light we have available in the system. Acording to shvarz this is done by calculating the ratio of total available space in the current simulation (based on simulation dimensions) to the total area of all robots in the simulation.
Area Inverted = Total robot area / Screen area
Now we figure out the actual area to correct chloroplasts by.
Area correction = ( 1 - Area Inverted) ^ 2 * 4
Now we figure out how much chloroplasts the robot has based on 1 unit. I think 16000 chloroplasts should be equal 1 unit.
Chloroplast correction = Chloroplasts the robot has / 16000
Now we figure out the actual rate the robot is being fed. We multiply by 1.25 to offset the amount of energy lost for sustaining chloroplasts. 'tok' already exists in the subroutine as the feeding rate. We simply use it here.
Add energy rate = Area correction * Chloroplasts correction * tok * 1.25
Now we have to figure out how much energy it costs for sustaining chloroplasts:
Subtract energy rate = (Chloroplasts the robot has / 32000) ^ 2 * tok
Now we figure out the actual feeding rate. Let us cal acttok for simplicity:
acttok = Add energy rate - Subtract energy rate
The rest of the code should now use acttok instead of tok.
And that should be all the changes required for feeding vegys. Let us quicly take a look at mass and robot radios.
Shvarz has recommended to me that we apply chloroplast mass to the robot more gradually we square it here.
Added mass = (Chloroplasts the robot has / 32000) ^ 2 * 31680
We are not going to touch robot radios because there are limits to the distance ties can stretch and ties are calculated from the robots center. I think we should have an indicator for chloroplasts like the indicator for shell or energy. Look into DrawRobPer.
Now let us talk about how the system will keep track of how much chloroplasts a robot has. I don't want a label in robot info to display the chloroplasts. I want an actual value in the DNA. This way we do not need to modify the vegy code to make the system recognize them as vegys. We just put the value on top of the dna, example:
'#chlr: 16000
cond
*.nrg
6000
>
start
50
.repro
store
15
.aimdx
store
stop
end
The value will be displayed in the dna when you click show dna and when you extract dna to file. When you set robots to 'repopulate' (called vegys in version 2.45.01) the system should ask you if you want to reset their chloroplasts to 16000.
The other reason is, there is a good chance some robots do not update their chloroplasts each cycle. I need a way of knowing how much chloroplasts a robot has at all times, this should not be epigenetic.
As far as the command, I think all we need is a simple .chlr variable in the 900s range that differentiates between read and write. Look at how I differentiate for tielen...tieang 1...4 in Update_Ties in Ties.bas. There are three stages:
1.) Input: Only change chloroplasts if flag was triggered (this cycle)
2.) Clear Input: Reset flag (this cycle)
3.) Output: current chloroplast levels stored back into memory (this cycle)
Also, look at the changes in DNAstore in the DNAexecution.bas to get the complete picture of this method.
I don't think we need share chloroplasts or anything like that because according to Shvarz it is not important to change energy when creating or destroying chloroplasts. Also, a baby will have exactly the same amount of chloroplasts as its mama.
Also make sure you add chloroplasts to SaveRobotBody and LoadRobotBody in HDRoutines.bas so that chloroplasts are saved as part of the simulation file if anyone wants to resume a simulation later and for debugging purposes.
Now let us talk about the robot repopulation. I want to keep it the same as it currently is (Figure 2) for the options form. What it does however, will be a little different.
We need to calculate the total amount of chloroplasts across all robots / 16000. Let us call this 'allchlr'
sudo:
If allchlr > Max avg. vegys Then do not let vegys reproduce
If allchlr < Repopulation threshold avg. vegys Then the repopulate vegys using current repopulation rules. (Robots per repopulation event and repopulation cool down period)
(edit: By 'vegys' here, I mean repopulating robots, sorry for the small confusion)
The main change here is that repopulation is no longer a static value. It depends on how much total chloroplast is on the screen. Hopefully, this will lead to robots evolving their own chloroplasts and not being depended on 'repopulating' robots at all because the system only repopulates when non-repopulating robots do not use chloroplasts.
I tried to make my explanation as clear as possible, if you have any further questions let me know. Please, if you decide to code this stuff in, use the revision currently in the trunk in the svn, I submitted all my latest updates this morning.
-
I don?t think we need share chloroplasts or anything like that because according to Shvarz it is not important to change energy when creating or destroying chloroplasts. Also, a baby will have exactly the same amount of chloroplasts as its mama.
Does this mean that a robot can create and destroy chloroplasts without expending or gaining energy and that the only cost of chloroplasts is that of the upkeep? I think this is my only question. :)
-
Pretty much, yea.
The upkeep is a constant based on chloroplasts and tok.
And the actual profit is based on total robot area and tok and chloroplasts.
The cool part about that (in my view) is the fact that we need to add just one more sysvar called .chlr
-
I will do this for now. However, to balance chloroplasts, I think we may need to add another cost on top of the upkeep of them. I can see a few consequences of not doing this. There will be an optimum number of chloroplasts for a robot to have and still move and to gain energy. It may become a tool for non-veggies to get some extra energy. Just a thought.
-
Yes, let's do this for now.
If it is very ugly we can always add rules for getting or losing chloroplasts, and change the mass formula from ^ 2 to ^ 1.5 or something like that.
-
Yeah, it does mean a lot less work. :D
-
If it is very ugly we can always add rules for getting or losing chloroplasts
Wait a minute, following my own logic, this will not work because robots can be loaded in with some chloroplasts.
I have a better idea, if robot has like under 4000 chloroplasts their chloroplasts are not active and does not count to 'allchlr'
-
I don't think that's a fair limit exactly. We can leave it for a while anyway and discuss it after running a few trials. I'm sure we will have to tweak anyway!
-
As far as the command, I think all we need is a simple .chlr variable in the 900s range that differentiates between read and write. Look at how I differentiate for tielen...tieang 1...4 in Update_Ties in Ties.bas. There are three stages:
1.) Input: Only change chloroplasts if flag was triggered (this cycle)
2.) Clear Input: Reset flag (this cycle)
3.) Output: current chloroplast levels stored back into memory (this cycle)
Why is this necessary? If the number of chloroplasts is different then shouldn't it just change the number of chloroplasts or am I missing something, rather than using flags?
Now we have to figure out how much energy it costs for sustaining chloroplasts:
Subtract energy rate = (Chloroplasts the robot has / 32000) ^ 2 * tok
There won't be a cost if it's not daylight because it's written in that way. Unless there's not meant to be a cost overnight?
I believe I have done everything but:
We just put the value on top of the dna, example:
'#chlr: 16000
cond
*.nrg
6000
>
start
50
.repro
store
15
.aimdx
store
stop
end
The value will be displayed in the dna when you click show dna and when you extract dna to file. When you set robots to 'repopulate' (called vegys in version 2.45.01) the system should ask you if you want to reset their chloroplasts to 16000.
-
To be honest, I think it's more hassle than it's worth to add a value to the DNA. Changing the settings really isn't going to be as difficult as reading anything new in. If we're still going to go along with doing it this way, I will need help. XD
-
I've found another problem with not having a cost to create chloroplasts: it's too easy to remove chloroplasts, move and then add chloroplasts.
EDIT: Another problem, when the reproduction gene breaks, the energy feeding rate is high enough for most of them to survive.
-
I am actually taking off work tomorrow to help you out. ttyl
-
To be honest, I think it's more hassle than it's worth to add a value to the DNA. Changing the settings really isn't going to be as difficult as reading anything new in. If we're still going to go along with doing it this way, I will need help. XD
I need this to figure out what robots evolved to use chloroplasts, there is a good chance that they lost there chloroplast gene but still use them. I need this for my system of restarting a simulation with an evolved DNA file. There is a lot of skytsaphernia going around that makes evolved DNA files completely useless and definitally does not prove this software package as a useful tool for representing evolution because the stupid evolved DNA files just don't work. I spend 2 years on this project figuring out a fix for this (2.44.01) and then Eric L released 2.45.01 , I am still ok , minor changes (no problem) then you guys decide to add chloroplasts. Now everything is completely messed up and I had to step in. I spelled skytsaphernia wrong, sorry, it is getting close to 5pm :P
-
I think I understand what you mean but I can see that there are some problems with the system that is being created and I really want to discuss them with you. If you're absolutely determined to do it in your way then you can. I just have encountered a number of problems with it already.
-
Workings of chloroplasts seems way more complicated till you actually know how it works. :wacko:
It really needs some kind of nrg payment to build chloroplasts. Change into a veggie at a whim and changing back might open some loopholes.
-
I've read through the thread. I'm going to take off my admin hat and put on my general user hat, so feel free to completely ignore me. :)
I think I understand where shvarz is coming from. Specifically he doesn't consider conservation of energy to be an important limitation in an ecosystem. For him it's more an issue of energy flow, from producers down the basic trophic levels. The natural predator-prey cycles can produce some wild population swings if the energy coming in to the sim is a function of the number of prey. In a robust ecosystem IRL when one producer's population declines, another producer's population increases to fill the gap. The natural food web is able to ride out population swings in individual species through diversity.
Because Darwinbots doesn't have as many natural niches, we can attempt to dampen the natural fluctuations by keeping the incoming energy in to a sim constant. With that in mind, we have to divide up the incoming energy based on the number of veggies in the sim. It also has the nice property that veggies compete with each other for the available energy, without competing with animals for physical space.
This is pretty close to the energy model that was used when I first joined the project. The primary downside is that it it has no relationship with how things actually work, and is not necessarily intuitive to new users. So I don't think it should be dismissed as a bad idea, but neither should it replace the current system.
There's currently a couple of different methods to feed veggies. One is based on just giving every veggy X nrg per cycle. Another is based on giving every veggy X nrg for every 1000 body points it has. Another is based on giving nrg to veggies based on a quadratic function that rewards bots that are larger (this option is pretty much unused in practice, I think).
It wouldn't be difficult to add another option, orthogonal to the above, that lets users specify if veggies are given energy independently of each other, or are apportioned energy from some large energy pie. That still lets you use the above feeding methods, too. You could divide up the energy pie so that each veggy gets 1 / (total number of veggies) * incoming energy per cycle. Or you can do the per kilobody method and give veggy body / (total amount of body among all veggies) * incoming energy per cycle. Or the kilobody version, with math I don't want to do right now :)
Note that this issue is entirely orthogonal to the issue of chloroplasts. It might be a good idea to do this step first, and release that version for people to play with.
...
On the issue of chloroplasts, I think you can treat it as a new substance very similar to body. You can set the energy conversion rate to/from chloroplasts in code, and then bots can build/unbuild chloroplasts the same way the build/unbuild body. There's no need to reinvent the wheel in terms of interface.
If a bot has the 'veg' flag set, you can replace its body store/feed and body readback memvars with the chloroplast versions. If loading in an old simulation, you can convert all (or maybe 90%?) of the body of bots with the veg flag set in to chloroplasts.
If a bot is spawned with the veg flag set, you can spawn it with all (or maybe 90%) of the usual 1000 body as the equivalent in chloroplasts.
To legacy veggies, there's no difference from the old interface, but new bots can still build chloroplasts and body separately.
In cases where you need a strict is veggy/is not veggy flag, like the per-veggy feeding method I mentioned earlier, you can simply check if they have any chloroplasts. When a bot divides, you split up its chloroplasts just like what happens with body right now.
There's also a UI slider right now for feeding veggies that defaults to giving veggies 90% of the energy as nrg, and 10% of their nrg as the equivalent in body. You'll want to change that to be a slider between nrg and chloroplasts.
I would definitely recommend charging bots for building chloroplasts. If nrg is given to bots based on the number of chloroplasts they have, and especially if the veggies are competing for nrg, you'll want there to be a cost for large numbers of chloroplasts, even if it's just an upfront sunk cost. It also means that the exponential growth of veggies is limited by the the time it takes to save up enough nrg to build more chloroplasts.
Last, I wouldn't recommend trying to add new metadata to the DNA to represent chloroplasts. There are mechanisms in place already for nrg, body, venom, poison, shell, slime, etc., and there's no reason to have chloroplasts follow a different system. If you want to be able to save bots out in DNA form with the body, nrg, etc. set in the DNA, I think that's reasonable, but you should do that for all the substances, and it's an entirely different change from the chloroplasts. No need to conflate multiple features together.
...
Anyway, that's my 2 cents. I probably won't help with coding any of this, so I'll defer the final say to you guys.
-
It wouldn't be difficult to add another option, orthogonal to the above, that lets users specify if veggies are given energy independently of each other, or are apportioned energy from some large energy pie. That still lets you use the above feeding methods, too. You could divide up the energy pie so that each veggy gets 1 / (total number of veggies) * incoming energy per cycle. Or you can do the per kilobody method and give veggy body / (total amount of body among all veggies) * incoming energy per cycle. Or the kilobody version, with math I don't want to do right now :)
I quite like the idea of this. It's a lot more work but it keeps the energy constant and competition up. It's quite a lot of work but I'm willing to do this.
On the issue of chloroplasts, I think you can treat it as a new substance very similar to body. You can set the energy conversion rate to/from chloroplasts in code, and then bots can build/unbuild chloroplasts the same way the build/unbuild body. There's no need to reinvent the wheel in terms of interface.
If a bot has the 'veg' flag set, you can replace its body store/feed and body readback memvars with the chloroplast versions. If loading in an old simulation, you can convert all (or maybe 90%?) of the body of bots with the veg flag set in to chloroplasts.
If a bot is spawned with the veg flag set, you can spawn it with all (or maybe 90%) of the usual 1000 body as the equivalent in chloroplasts.
To legacy veggies, there's no difference from the old interface, but new bots can still build chloroplasts and body separately.
In cases where you need a strict is veggy/is not veggy flag, like the per-veggy feeding method I mentioned earlier, you can simply check if they have any chloroplasts.
Something needs to happen about this but there are many options.
When a bot divides, you split up its chloroplasts just like what happens with body right now.
I agree with this.
I would definitely recommend charging bots for building chloroplasts. If nrg is given to bots based on the number of chloroplasts they have, and especially if the veggies are competing for nrg, you'll want there to be a cost for large numbers of chloroplasts, even if it's just an upfront sunk cost. It also means that the exponential growth of veggies is limited by the the time it takes to save up enough nrg to build more chloroplasts.
This is the biggest thing to fight for.
Last, I wouldn't recommend trying to add new metadata to the DNA to represent chloroplasts. There are mechanisms in place already for nrg, body, venom, poison, shell, slime, etc., and there's no reason to have chloroplasts follow a different system. If you want to be able to save bots out in DNA form with the body, nrg, etc. set in the DNA, I think that's reasonable, but you should do that for all the substances, and it's an entirely different change from the chloroplasts. No need to conflate multiple features together.
I agree.
--------
EDIT: I would add more to this but I'm currently in bed and I just wanted to say what I agreed with. I'm sorry Bots if I seem very harsh about what I've said, though. :/
-
Workings of chloroplasts seems way more complicated till you actually know how it works. :wacko:
It really needs some kind of nrg payment to build chloroplasts. Change into a veggie at a whim and changing back might open some loopholes.
And I've found quite a few of these loopholes already.
-
I would definitely recommend charging bots for building chloroplasts.
I've found another problem with not having a cost to create chloroplasts: it's too easy to remove chloroplasts, move and then add chloroplasts.
I think we should charge energy for ANY change in chloroplasts:
I am thinking energy = energy - abs(old chloroplast value - new chloroplasts value ) / 4
I think we need a new sysvar called 'light' that will give the robot:
light = Total robot area / Screen area * 32000
So it knows when to start using less chloroplasts
Another problem, when the reproduction gene breaks, the energy feeding rate is high enough for most of them to survive.
I need to see this happen enough times before I figure out what to do with it.
There won't be a cost if it's not daylight because it's written in that way. Unless there's not meant to be a cost overnight?
Plants simply go to sleep when its night time, they don't start messing with there chloroplast count, I think it should be ok. Especially if we need to add a cost for changing the amount of chloroplasts.
There's currently a couple of different methods to feed veggies. One is based on just giving every veggy X nrg per cycle. Another is based on giving every veggy X nrg for every 1000 body points it has. Another is based on giving nrg to veggies based on a quadratic function that rewards bots that are larger (this option is pretty much unused in practice, I think).
I am keeping this system and only modifying it.
There's also a UI slider right now for feeding veggies that defaults to giving veggies 90% of the energy as nrg, and 10% of their nrg as the equivalent in body. You'll want to change that to be a slider between nrg and chloroplasts.
What if the robot has no chloroplasts? Now it will not get fed by body?
I also think we should mess with UI as little as possible, this one of the sliders I actually want to leave alone.
It also means that the exponential growth of veggies is limited by the the time it takes to save up enough nrg to build more chloroplasts.
In my system robots do not lose chloroplasts, it is a static value.
I quite like the idea of this. It's a lot more work but it keeps the energy constant and competition up. It's quite a lot of work but I'm willing to do this.
We kinda ran out of control space in the options form :P
We can add another checkbox and do:
1 / (total number of veggies) * incoming energy per cycle.
I don't see a need for:
veggy body / (total amount of body among all veggies) * incoming energy per cycle.
because we have a way of giving every veggy X nrg for every 1000 body points it has, etc.
The only question(s) here is what will be the value for 'incoming energy per cycle' and where do we add a checkbox ?
edit:
On second thought, I am beginning to really dislike this approach, look at my last edit for this post.
When a bot divides, you split up its chloroplasts just like what happens with body right now.
I agree with this.
If chloroplasts are static this should not matter.
Last, I wouldn't recommend trying to add new metadata to the DNA to represent chloroplasts. There are mechanisms in place already for nrg, body, venom, poison, shell, slime, etc., and there's no reason to have chloroplasts follow a different system. If you want to be able to save bots out in DNA form with the body, nrg, etc. set in the DNA, I think that's reasonable, but you should do that for all the substances, and it's an entirely different change from the chloroplasts. No need to conflate multiple features together.
Well, think about F1, now people will start loading in robots with like 32000 energy, slime, venum etc. That is giving the user way more power then they should have.
With chloroplasts it is a little different, I think the user should have control over this, it tells the system if he is designing a plant or not.
I know Numsgil you hate the idea of DNA files containing metadata. I looked on all other options, there is simply no other way to do it.
Oh, and speaking of metadata, a good one to have in the DNA is all epigenetic memory. But I figured out that if you reset it periodically based on accumulated mutations there is no problem.
edit:
In cases where you need a strict is veggy/is not veggy flag, like the per-veggy feeding method I mentioned earlier, you can simply check if they have any chloroplasts.
You just figured out a way for your own idea to fail. What if a robot(s) has very little chloroplasts? Now there is less and less energy avaialble in the system.
I understand your logic Numsgil, but I still think we should hard code the vegy distinction into the MetaData.
I am also envisioning an option box if you want to reset the robots that are veg to spawn with a default 16000 chloroplasts.
I am also envisioning a simulation where you load vegs with 16000 chloroplasts and non-vegs with the same amount and DNA to see if they can evolve to hunt.
Bottom line is,
I envision two tests for this system:
Test 1.) Can non-repopulating plants learn to eat?
Test 2.) Can eating robots become plants and completely replace repopulating robots with there own mutated versions?
Both of the above are very useful to me for evolving eco systems.
I envision a way to evolve the most effective self sustaining eco system and even distributed over internet mode with everyone running there own settings. My approach will involve extracting DNA and restarting the simulation, check out 'Botsareus's vision' on the wiki. Well it is more like a reality now, not just a vision. I just have to re-implement it.
-
Why is the metadata necessarily?
The mechanism that gives 'veggies' free nrg is not affected by the chloroplast system or is it?
-
it is
-
Hey Panda, I am going trough and adding your changes to the main code.
-
I think we should charge energy for ANY change in chloroplasts:
I am thinking energy = energy - abs(old chloroplast value - new chloroplasts value ) / 4
This is fine. :)
I think we need a new sysvar called 'light' that will give the robot:
light = Total robot area / Screen area * 32000
So it knows when to start using less chloroplasts
I still disagree with this approach to it.
Another problem, when the reproduction gene breaks, the energy feeding rate is high enough for most of them to survive.
I need to see this happen enough times before I figure out what to do with it.
Charging for chloroplasts and not having them as part of the DNA file and splitting them like we currently do is, from what I can see, the best way to do it.
There won't be a cost if it's not daylight because it's written in that way. Unless there's not meant to be a cost overnight?
Plants simply go to sleep when its night time, they don't start messing with there chloroplast count, I think it should be ok. Especially if we need to add a cost for changing the amount of chloroplasts.
What I'm saying is, there is no upkeep cost for having chloroplasts during night.
There's also a UI slider right now for feeding veggies that defaults to giving veggies 90% of the energy as nrg, and 10% of their nrg as the equivalent in body. You'll want to change that to be a slider between nrg and chloroplasts.
What if the robot has no chloroplasts? Now it will not get fed by body?
I also think we should mess with UI as little as possible, this one of the sliders I actually want to leave alone.
By shots do you mean? Otherwise they don't get fed by the simulation so of course they're not going to get any free body.
It also means that the exponential growth of veggies is limited by the the time it takes to save up enough nrg to build more chloroplasts.
In my system robots do not lose chloroplasts, it is a static value.
I think he is saying that the cost for each chloroplast should increase so more nrg is needed for each chloroplast. I quite agree with this.
I quite like the idea of this. It's a lot more work but it keeps the energy constant and competition up. It's quite a lot of work but I'm willing to do this.
We kinda ran out of control space in the options form :P
We can add another checkbox and do:
1 / (total number of veggies) * incoming energy per cycle.
I don't see a need for:
veggy body / (total amount of body among all veggies) * incoming energy per cycle.
because we have a way of giving every veggy X nrg for every 1000 body points it has, etc.
The only question(s) here is what will be the value for 'incoming energy per cycle' and where do we add a checkbox ?
edit:
On second thought, I am beginning to really dislike this approach, look at my last edit for this post.
This system is different because it keeps the incoming energy into the system constant (as long as there are veggies).
When a bot divides, you split up its chloroplasts just like what happens with body right now.
I agree with this.
If chloroplasts are static this should not matter.
Why do they have to be static? I don't think this works in practice especially due to probelms already found in the simulation (such as the mass reproducing and surviving)
Last, I wouldn't recommend trying to add new metadata to the DNA to represent chloroplasts. There are mechanisms in place already for nrg, body, venom, poison, shell, slime, etc., and there's no reason to have chloroplasts follow a different system. If you want to be able to save bots out in DNA form with the body, nrg, etc. set in the DNA, I think that's reasonable, but you should do that for all the substances, and it's an entirely different change from the chloroplasts. No need to conflate multiple features together.
Well, think about F1, now people will start loading in robots with like 32000 energy, slime, venum etc. That is giving the user way more power then they should have.
With chloroplasts it is a little different, I think the user should have control over this, it tells the system if he is designing a plant or not.
But couldn't you argue that if you wanted to develop a certain other type of robot then the metadata should be there for you to do that. Why are veggies any more important.
edit:
In cases where you need a strict is veggy/is not veggy flag, like the per-veggy feeding method I mentioned earlier, you can simply check if they have any chloroplasts.
You just figured out a way for your own idea to fail. What if a robot(s) has very little chloroplasts? Now there is less and less energy avaialble in the system.
I understand your logic Numsgil, but I still think we should hard code the vegy distinction into the MetaData.
I am also envisioning an option box if you want to reset the robots that are veg to spawn with a default 16000 chloroplasts.
I am also envisioning a simulation where you load vegs with 16000 chloroplasts and non-vegs with the same amount and DNA to see if they can evolve to hunt.
Bottom line is,
I envision two tests for this system:
Test 1.) Can non-repopulating plants learn to eat?
Test 2.) Can eating robots become plants and completely replace repopulating robots with there own mutated versions?
Both of the above are very useful to me for evolving eco systems.
I envision a way to evolve the most effective self sustaining eco system and even distributed over internet mode with everyone running there own settings. My approach will involve extracting DNA and restarting the simulation, check out 'Botsareus's vision' on the wiki. Well it is more like a reality now, not just a vision. I just have to re-implement it.
I don't know why the old system that we had (with a few modifications to allow for an F1 mode that works) doesn't work like this? I thought it was a perfectly good system (and I knew others agreed with me).
-
I don't know why the old system that we had (with a few modifications to allow for an F1 mode that works) doesn't work like this? I thought it was a perfectly good system (and I knew others agreed with me).
I am just adding what I worked on for a good 2 years, it will be optional.
I need a way to generate DNA files that actually work, I figured out a way.
not having them as part of the DNA file
I have spent 2 years how to make a robots DNA file reflect what the robot is currently doing when extracted from a simulation. I want to include chlroplasts as part of the DNA for two reasons:
1.) It will save exactly what the robot is doing
2.) I can have an entire working eco-system as DNA files.
This is getting stupid, I am acting like Botsareus from 6 years ago where I am just repeating myself and no one is comprehending anything I am saying. Can I just code this stuff in in peace plz?
What I'm saying is, there is no upkeep cost for having chloroplasts during night.
True.
There is also no upkeep cost for pond mode on the bottom of the pond.
This is all by design.
By shots do you mean? Otherwise they don't get fed by the simulation so of course they're not going to get any free body.
I want robots to be able to add to there body from the sun the way they do now artificially. I want to leave that slider alone. Let it be the way it is.
his system is different because it keeps the incoming energy into the system constant (as long as there are veggies).
What will be our constant? How will it work with:
Select Case SimOpts.VegFeedingMethod
Case 0 'per veg
Energy = tok * (1 - SimOpts.VegFeedingToBody)
body = (tok * SimOpts.VegFeedingToBody) / 10
Case 1 'per kilobody
Energy = tok * (1 - SimOpts.VegFeedingToBody) * rob(t).body / 1000
body = (tok * (SimOpts.VegFeedingToBody) * rob(t).body / 1000) / 10
Case 2 'quadratically based on body. Close to type 0 near 1000 body points, but quickly diverges at about 5K body points
tok = tok * ((rob(t).body ^ 2 * Constant) + (1 - Constant * 1000 * 1000))
Energy = tok * (1 - SimOpts.VegFeedingToBody)
body = (tok * SimOpts.VegFeedingToBody) / 10
End Select
rob(t).nrg = rob(t).nrg + Energy
rob(t).body = rob(t).body + body
Why do they have to be static? I don't think this works in practice especially due to probelms already found in the simulation (such as the mass reproducing and surviving)
I have to research further, let me grind trough your code and see what is going on for myself.
But couldn't you argue that if you wanted to develop a certain other type of robot then the metadata should be there for you to do that. Why are veggies any more important.
I think it is not fear for people to be able to set some of these values, it makes the current league unusable and I have no base to test my robots on.
-
I just don't understand why it has to be your system rather than one that other people, who are part of the community, are agreeing on?
EDIT: The amount of energy a bot is used to, the amount of body a bot is used to, ect, isn't known when the bot is extracted by the simulation, why should chloroplasts be any different?
-
Because I want to have an eco system as DNA files
EDIT:
amount of energy a bot is used to, the amount of body a bot is used to
There is an option in global settings to limit body, energy I found not to be an issue.
-
Then why don't you use the system to be able to save and load bots as well as dna files, then? That would be a more accurate way to save them within a DNA file.
-
Because F1 is based on dna files, no organisms
-
So why is the number of chloroplasts in the DNA, then? That surely is part of the organism?
-
Senerio:
A robot evolves to use chloroplasts, it is not feeding at all.
I extract the DNA and start a new simulation (or shove it into F1 even), wow this robot is dead as hell, it is not feeding.
-
Scenario 2: Robot has very little body and lots of energy.
Spawned into new simulation with average energy and quite a bit of body. Dies.
-
With a different system, chloroplasts would be evolved out because they are split how reproduction works with everything else. The problem would be the same as any other bot's problem of a similar type.
-
Scenario 2: Robot has very little body and lots of energy.
Spawned into new simulation with average energy and quite a bit of body. Dies.
True.
I was hacking at it for 2 years to develop an evolutionary work around.
I think the situation is compounded though, if the robot refuses to eat at all.
-
it is
Bit too radical for my taste, backward compatibility issues arise. :(
-
I think the situation is compounded though, if the robot refuses to eat at all.
What do you mean by this?
-
I want to be able to run (lets call it F1 eco) where 15 robots run vs 15 other robots with NO OTHER SOURCE OF FOOD based on DNA FILES.
How will that work in your "different system" ???
I think the situation is compounded though, if the robot refuses to eat at all.
What do you mean by this?
Take a look as scenario 1
it is
Bit too radical for my taste, backward compatibility issues arise. :(
This 'metadata' will be optional defaulting to zero.
If you select a robot as food and 'metadata' is not 16K it will prompt you on selection if you want to reset the chloroplasts to 16K on startup.
-
I think the situation is compounded though, if the robot refuses to eat at all.
What do you mean by this?
Take a look as scenario 1
Then the robot hasn't evolved well.
http://forum.darwinbots.com/index.php/topic,3487.50.html
To be honest I thought this system worked rather well. The only problem with that one is that if all robots decided to use it, free energy for everybody. If we combined it with some of your features it would work.
-
Quote
Quote
Quote
I think the situation is compounded though, if the robot refuses to eat at all.
What do you mean by this?
Take a look as scenario 1
Then the robot hasn't evolved well.
A robot that is dead on startup has evolved well?
I might as well quit right now :P
-
Quote
Quote
Quote
Quote
I think the situation is compounded though, if the robot refuses to eat at all.
What do you mean by this?
Take a look as scenario 1
Then the robot hasn't evolved well.
A robot that is dead on startup has evolved well?
I might as well quit right now :P
What I',m saying is that is that because the chloroplasts are split to the new robot, as the generations go by, they run out of chloroplasts. So the robot would have evolved badly to not eat at all.
-
robot 1:10000 chlr
robot 2:1000
robot 3:100
robot 4:10
robot 5:1
robot 6:0
If they reproduce with 10 .repro store...
-
What I am saying is that is that because the chloroplasts are split to the new robot, as the generations go by, they run out of chloroplasts. So the robot would have evolved badly to not eat at all.
That means there is no evolutionary advantage to use chloroplasts, and my self sustaining eco system based on DNA files is dead anyway.
However, it is even more dead if there is no startup chloroplasts preset in the first place.
-
Why is there no evolutionary advantage to using chloroplasts, then?
-
Why is there no evolutionary advantage to using chloroplasts, then?
What I',m saying is that is that because the chloroplasts are split to the new robot, as the generations go by, they run out of chloroplasts. So the robot would have evolved badly to not eat at all.
yep, it is getting stupid.
Now Panda is starting to write self contradicting posts...
-
Bottom line is,
I want a self sustaining eco system as DNA files.
-
How is that contradictory? If a robot has lost the ability to gain chloroplasts then it should not just keep them, (EDIT:nor should it's child). It gives a percentage to it's child, who also can't build chloroplasts, who gives a percentage to it's child, etc. etc. etc.
-
If chloroplasts just work like any other substance, there should be no problem in the first place. You're making this problem up by making chloroplasts static.
-
I think I get it:
How is that contradictory? If a robot has lost the ability to gain chloroplasts then it should not just keep them.
A robot has to figure out instantly how much chloroplasts it should have and adjust accordingly.
I just think it is a reasonably big jump to figure out and generate chloroplasts on start up for a robot. I am pushing this 'evo system' I am talking about to it's limit already. I don't know how much impact another change like this will make :(
-
Maybe not figure out how much it needs but fdchlr and strchlr. It's only as hard as reproducing sensibly.
-
Ok, tell me this, are we keeping any of Shvarz system?
What will be the cost for chloroplasts and what will be the benefit?
-
Well, we need some way to stop all robots from using this system. I'm not sure what parts we shall keep, I'll look through. I like the respawning system. The cost should be relatively low, it's just to prevent robots from switching between veggie and none veggie. The benefits are getting fed by the system (which I think works well how it does now as well).
-
I say: keep the feeding and respawn how it is at the moment. Add costs for adding them and split them between mother and child.
-
We can then tweek it when we come across problems.
-
Done.
Ok, I am in the process of adding your changes to the main code.
Once I am done reset your local copy and modify further.
I am adding a light sysvar as well.
-
So, you're okay with these changes? I think it makes it much easier to program, it still works how you need it to work and it stays in the style of the rest of DB2.
-
So which part of the code do I modify further, then?
One final problem that I see is that if all robots use chloroplasts then they're all going to get energy, right? Or have I missed something.
-
You will need to change the reproduction codes to split chloroplasts the same as they do energy and body
You will need to modify ManageChlr function to charge energy for adding chloroplasts
One final problem that I see is that if all robots use chloroplasts then they're all going to get energy, right? Or have I missed something.
Only if there is low population density
-
Sorry, I mean, do I use the trunk again? *doesn't often use SVN*
-
Can I just code this stuff in in peace plz?
With great power comes great responsibility. It's important to have a vision of what you want the program to become, but at the same time it serves no one, least of all yourself, if you're unwilling to accept or consider constructive criticism.
I'd say that my primary concerns are:
1. Integrate smoothly and cleanly with the existing infrastructure, so to an end user's perspective there's no seams between new features and old features. The program is pretty hard to grok as it is. We need to follow the principle of least surprise.
2. As best as possible, let old DNA files produce viable bots. We've had some changes in the past that broke all previous bots, and BOY was that a snafu.
3. Don't break or eliminate existing features without carefully considering the implication. Especially around veggy feeding there are dozens of different options in the UI to tweak the settings. At the very least we should have a good idea of how they interact with new features.
4. Keep the changes as small and atomic as possible, to keep the source code in a clean state. Massive systemic changes are dangerous in such a fragile code base. Trying to do even 3 or 4 things simultaneously is a recipe for heartache.
...
Oh, another part of the code that will need changing: -6 and -1 shots steal a certain amount of nrg from the body of the bots they're feeding on. You'll probably want to consider chloroplasts in this as well.
Also, in cases where you need to assign arbitrary constants (such as the nrg cost of building a chloroplast, etc.), you should expose it through the UI. There's a separate UI form for costs and constants, so I don't think it'll cause problems with the widget limit.
-
hmmm....
Just thought of something,
What we will do with existing plants such as Alga_Minimalis that has not chloroplast code in it?
Yes Panda, as soon as I am done, please use the trunk again.
-
A new version can be uploaded with the new version?
-
Good enough, when I give you the project back, figure out the new code.
-
Panda,
When we select a robot to repopulate, we need to ask the user if he wants to add a new chloroplast gene (optionally) to make old plants work correctly. What I mean is, you will need to figure out what that code should be.
We will need a new graph that shows total chloroplasts over all inserted species
We will need to repleace the UI element on the bottom of the screen.
It currently is counting total robots, total vegs, and total objects
We need the one that say total vegs be replaced with Allchlr / 16000
You will need to move AllChlr to global because the Repopulate function will need it as well.
The Repopulate function prevents 'repopulating robots' from repopulating further when a condition is met
'attempt to stop veg overpopulation but will it work?
If rob(n).Veg = True And (totvegsDisplayed > SimOpts.MaxPopulation Or totvegsDisplayed < 0) Then GoTo getout
edit: I think we need this to get robots to start eating.
I am adding your updates to the trunk,
In the future please label any change you make with 'Name Date Details' please keep date in US style format if you can, just easier for me to read :P
-
Panda,
When we select a robot to repopulate, we need to ask the user if he wants to add a new chloroplast gene (optionally) to make old plants work correctly. What I mean is, you will need to figure out what that code should be.
What if they already have a chloroplast gene, already? I think it would be best just to warn the user that the system has changed and that they will need to use chloroplasts for a few versions and then remove that warning?
I'm fine with the rest!
-
Good enough,
I think you should put a new version of Alga_Minimals together. One reason being, I want to play with it ;)
I had trouble figuring out SVN myself. Apparently you have to completely delete your local copy to get the new changes in. Unless, of course, Numsgil has a better solution?
edit: Few, need some coffee (I meant local copy not working copy)
-
Are we going to use .chlr to increase and decrease chloroplasts or are we going to have .mkchlr and .rmchlr?
EDIT: I will write it after we've made all the changes. It should only take a few hours to make the changes, now.
-
Good enough,
I think you should put a new version of Alga_Minimals together. One reason being, I want to play with it ;)
I had trouble figuring out SVN myself. Apparently you have to completely delete your local copy to get the new changes in. Unless, of course, Numsgil has a better solution?
edit: Few, need some coffee (I meant local copy not working copy)
What's the difference between local and working copy?
You should be able to update, if there are conflicts you could force update or revert+update, but you'll lose changes.
Ought to be a way to resolve conflicts or branch and merge if you got conflicting changes, but that depends on what tool you use.
-
The bot will be uploaded to the trunk installer->bots directory and to here as well and then you can do whatever you please with it. :)
-
I may not have made this point very well before:
Currently the system is set up to automatically give veggies body in addition to nrg. This is necessary to prevent legacy veggies (like alga minimalis) from being unable to reproduce once their body falls too low. Also for cases where veggies get fed based on kilobody points.
You can use that system for the new chloroplasts: instead of giving veggies body give them chloroplasts. Then all of our old legacy veggies work basically the same as ever without any changes. You don't have to try and automatically add in chloroplast genes or anything like that.
-
That is a good idea. However, alga_minimalis loses it's function as a robot, really. It's no longer a vegetable robot, it's just an empty shell that can reproduce. The feature of nrg-body is also required for the ones that evolve chloroplasts.
-
That's pretty much what it is right now anyway. I'm mostly saying we should do it like this to provide a bridge transparently for legacy veggies while still allowing new robots that are more sophisticated. There are other ways to provide that sort of bridge, but this is probably the least invasive.
The slider is set at a simulation level right now. So for evo sims you might start the sim with the slider set relatively high, and then slowly wean your evolving bots down to a purely nrg based diet. That would work similarly with chloroplasts.
-
Are you finished making your changes? I couldn't tell if you were.
EDIT:
Are there any other changes that you wish me to make?
At any point, if I see places where the code can be made more efficient(like removing duplicate if statements between methods), should I?]
Oh and permanent waste is given to children. Won't that eventually build up?
Wouldn't it have been easier to update all of the bots memory counts separately to everything else. They all seem to be updated much more than once all the way through it.
-
Oh and permanent waste is given to children. Won't that eventually build up?
It gets split between mother/daughter, yeah. But it gets diluted every time a bot splits, since both halves get only half the amount. The idea is that a reproductive strain has to reproduce often enough to keep its values at a manageable level.
-
Oh and permanent waste is given to children. Won't that eventually build up?
It gets split between mother/daughter, yeah. But it gets diluted every time a bot splits, since both halves get only half the amount. The idea is that a reproductive strain has to reproduce often enough to keep its values at a manageable level.
But the speed at which they have to reproduce would have to continue to increase, wouldn't it?
EDIT: I guess a lot of the issues of inefficient code are going to be faced in DB3? It is a large task to change anything in DB2 because of the number of different areas you have to change, with the same code, just to change one little bit of the code.
-
But the speed at which they have to reproduce would have to continue to increase, wouldn't it?
Assuming it builds up at a constant rate, they can also reproduce at a constant rate and reach a long term steady state level. Like if it takes 10K cycles to go from 100 to 200 waste, and then it reproduces 50/50, it has another 10K cycles before it has to reproduce again. And on like that.
EDIT: I guess a lot of the issues of inefficient code are going to be faced in DB3? It is a large task to change anything in DB2 because of the number of different areas you have to change, with the same code, just to change one little bit of the code.
To a certain extent. But it's also going to be a lot more code. I think I already have approximately as much code as DB2, and I don't have any of the UI or gameplay code really going yet. But it's more strictly architected and tested, which should mean you can change one system without even knowing how the others work.
My experiences in the code base so far have been positive, at least.
-
Botsareus? You know the "light available"? Shouldn't that be the corrected area, because, the more bot area there is, the less light available for them? It currently increases when there are more bots.
-
I thought it was:
1 - total robot area / screen area
So like if robot area is 1000 units and screen area is 1000 units then ...
eh, I see your point
Yes you right "light available" should be corrected area, that day was intense I probably fuged it up. :P
Move stuff out of global and move the proper variable to global.
I'll review stuff this Sunday.
edit:
I need to be a little more clear:
sudo:
That light sysvar should be = ( 1 - robot.area / screen.area ) * 32000
so, at max density it will be zero and at little density it will be close to 32000
Hey btw Panda, you might want to consider adding in a way to share chloroplasts trough ties. (Now that I actually understand your approach that sounds like a good idea)
edit: Also I think we need to add "addchlr" ( or is it mkchlr as in mk47) , "rmchlr" and "chlr" as separate variables
I think "chlr" should be a read only variable
we should charge for addchlr (or is it mkchlr)
we should not give a robot free energy for rmchlr in my opinion.
Wouldn't it have been easier to update all of the bots memory counts separately to everything else. They all seem to be updated much more than once all the way through it.
That is a lot of recoding, and there are later memory depending on earlier memory. But, what specifically did you have in mind?
Numsgil still wants some kind of automated system to help old plants transition into the new system.
Panda, Put together an Alga minimalis that uses the new feeding methods (I still don't know if we are going to use AddChlr or Chlr so I don't have a clue how this robot will look like)
I am seriously considering having a checkbox something like "Add a chloroplast gene" in the settings that automatically inserts the gene into the robot. It must be simple, cost effective, and normalize at 16K Chloroplasts.
edit: I see a few ways of doing this, I can take this part over when it is time
Not so good news:
I really wish I can do more then just give instructions :banghead:,
But, If that was the case I would have start digging into DB3 and trying to figure it out :)
Good news: I am getting an UPS for my laptop this weekend.
-
Why an UPS for your laptop, dead battery?
-
Right, I'm probably dropping off the radar this weekend. I can't really submit my changes as they're mid change. Do you plan on adding anything soon?
-
Why an UPS for your laptop, dead battery?
People strongly recommend not to use your battery when running a laptop 247, something to do with it unchanging and then charging again. Don't know to what extent this is true for a vaio laptop from 5 years ago.
Right, I'm probably dropping off the radar this weekend. I can't really submit my changes as they're mid change. Do you plan on adding anything soon?
Few, Panda, that is a good thing because I am kinda overwhelmed with this project right now, I keep making stupid mistakes in my descriptions.
Leave the lighaval code the way it is, I might have to use it for something else later:
LightAval = TotalRobotArea / ScreenArea 'Panda 8/14/2013 Figure out AreaInverted a.k.a. available light
AreaCorrection = (1 - LightAval) ^ 2 * 4
When you actually tell the robot how much light it has available then we invert it:
rob(n).mem(light) = 32000 - LightAval * 32000
sorry for the confusion :)
I kinda have to wait for you to submit before we can test it.
Oh, we need to add chloroplasts also to 'snapshot' and my three 'custom graphs' for snapshot I already created space for it , it should be the last cstr(0), not sure about custom graphs though.
This is also not a very important change on this stage, I'll take a look at this before we go live with the project.
Also, I would like to have your ideas on this little subroutine:
Public Sub feedveg2(t As Integer) 'gives veg an additional meal based on waste
With rob(t)
If .nrg + (.Waste / 2) < 32000 Then
.nrg = .nrg + (.Waste / 2)
'.Waste = .Waste - (.Waste / 2)
.Waste = 0
End If
End With
End Sub
-
Let's test it! Let's test it!
attached alga and Animal_Minimalis please copy to your 'Robots' folder
I am running two experiments:
Robsbecomevegs target goal is for robots to become plants
Vegsbecomerobts target goal is for plants to become robots
-
noticing something already:
I am not sure if robots mutate the new commands, we need a robot we a bunch of zeros and test copyerror and insertion.
Here is something else I am noticing, it is rather disturbing:
-
I am thinking of this fix, what do you think panda?
Public Function FindRadius(ByVal bodypoints As Single, ByVal chloroplasts As Single) As Single
If bodypoints < 1 Then bodypoints = 1
If chloroplasts > bodypoints Then bodypoints = chloroplasts 'Botsareus 8/31/2013 prevent ultra small robots
If SimOpts.FixedBotRadii Then
FindRadius = half
Else
' EricL 10/20/2007 Added log(bodypoints) to increase the size variation in bots.
FindRadius = (Log(bodypoints) * bodypoints * CubicTwipPerBody * 3 * 0.25 / PI) ^ (1 / 3)
If FindRadius < 1 Then FindRadius = 1
End If
End Function
we need a way to prevent these ultra small robots, the only other way I think is by force killing them...
edit: hmmm... it looks like I solved the problem just by adding costs
-
Yeah, it's either costs that you have to increase or decrease the amount of energy that they get from the simulation.
-
My biggest problem was getting a predator prey system going. Usually I would get a good 5 cycles and then one would die off. I'm not sure how to solve this, either. I'll find an example. Maybe I need to write a better veggie bot.