Is this a bug?

[PurpleYouko]

Which exact version are you using?
I recently fixed a problem with acceleration and friction but I don't remember if it made it into the "official" version on the DarwinBots.com server.
I definitely uploaded it to the old FTP site. If you are not running that version then I suggest you change over to it. Might fix your problem and if it doesn't then at least we have identified an area to look at.

[shvarz]

OK, that fixed the problem! I don't see the slow buggers anymore!

One suggestion though is to change the version number even if you fixed something small.  First, that let's everyone know that this is a new version with another bug fixed.  Second, if you fixed something and broke something at the same time, then we can easily roll back to previous, more stable, version.  You and Nums being the only two programmers - any version that comes out can be called "official" :)

Here is another mistery for you:  Take those settings and the Alga grexa that are attached to my first post in this thread and remove all the hunters (just add alga minimalis as a hunter).  Now you can just look at what happens with veggies.  Start the sim and this is what you should see: The first generation of Alga grexa are actually spending more energy then they are getting, so they die within 100 cycles or so.  The program reseeds and they die again.  But after a couple of reseeds there appears an Alga that actually spends less than it gets and that one flourishes and starts dividing and such.  So what's the deal with that?  Mutations are disabled, so it's not a mutant.  

My guess is that it has something to do with how much bots are charged for movement.  First bots are running very fast and are charged a lot.  Then through some chance there appears a bot that accumulated enough body to slow it down.  Since it is slowed down by body, it will be charged less - therefore, it will survive.  All it's children will get a portion of its body, so they are also not running as fast.

If this is true, then I think that costs of movement should be adjusted.

[Numsgil]

I couldbe wrong, but I think movement cost is equal to:

actual movement * mass

so I don't think that's the problem.

[shvarz]

Yes, but if the "actual movement" is a function of mass, then that may lead to the weirdness I described.

Example.  Two bots, one is light and the other is heavy:
mass1=1,000
mass2=5,000
.up=10
cost1 (in whatever units)=1,000x10=10,000
cost2= 5,000x10=50,000

Your adjusted case:
mass1=1,000
mass2=5,000
.up=10
Adjusted .up1=10
Adjusted .up2=2
cost1=1,000x10=10,000
cost2=5,000x2=10,000

[shvarz]

I think we should consider .up to be the force applied by the bot and charge based on that force alone.

Consider this scenario:  you have 1000-pound rock and two people try to move it in turn.  First one pushes it very slightly, the second one makes an honest effort.  Neither of them moves the rock, yet the energy they spend is very different.  Same with bots, we should not charge by end result, we should charge by the effort.  

If I remember correctly, the KE mode was very-very harsh before you changed it to "charge for effect".  I was glad at first, but now I think it is a bad idea.  So, maybe we should go back to "charge for effort".  To make it less harsh, maybe we can charge less for that effort than before.

[PurpleYouko]

I think we should consider .up to be the force applied by the bot and charge based on that force alone.

That is exactly how it works now.

The net acceleration change (from up dn sx dx) in the direction the robot is facing is first calculated.
This is the value that is charged for.

Additions of other accelerations (such as those caused by collisions) are added after costs are calculated, then adjustments to acceleration due to mass considerations are applied at the end.

This means that a fat robot with a mass of 2 storing 10 into .up will be charged 10 but will only acrue 5 extra speed.
A really skinny bot with a mass of 1/2 storing 10 into .up will be charged 10 but will acrue 20 extra speed

I have no idea where this strange behaviour of your robots is coming from. I will see if I can check it out as soon as my present F2 league run finishes.
I am currently up to 37 rounds in a battle between a new Hunter species and Light's Icarus. Hunter is up by 21 to 15 but that is still a statistical draw. A typical round lasts about 10,000 cycles so it is likely to take a while.  :(

[Shen]

Just wondering how maxvel figures into this? If I just write a gene that is constantly on with 50 .up store, will the bot get charged for the 50 or will it be decreased because of the velocity cap?

[shvarz]

This means that a fat robot with a mass of 2 storing 10 into .up will be charged 10 but will only acrue 5 extra speed.
A really skinny bot with a mass of 1/2 storing 10 into .up will be charged 10 but will acrue 20 extra speed

Well... see, I seem to remember that Numsgil changed that at some point.  

Shen's question is good too.  Because Alga grexa almost constantly stores 16 (or 17) in .up  Will that bring it to high velocity and then allow it to stay there at little cost?

[Numsgil]

Here's how it works:

Calculate how fast the robot wants to go.

cost = Sqr((Newaccelx / .mass) ^ 2 + (Newaccely / .mass) ^ 2)

Normalize speed so the bot isn't going too fast.  Ie:

If tvel > Maxspeed Then       'limits speed to maxspeed
        Reduce = tvel / Maxspeed
        .ax = .ax / Reduce
        'Newaccelx = Newaccelx / Reduce
        .ay = .ay / Reduce
        'Newaccely = Newaccely / Reduce
        tvel = Maxspeed
      End If

Does that answer any questions?  My brain is tired right now

 :D  :D

[PurpleYouko]

cost = Sqr((Newaccelx / .mass) ^ 2 + (Newaccely / .mass) ^ 2)

The two Newaccel variables represent the x and y vectors of the acceleration applied only by up, dn, sx and dx

This is done before we calculate the actual change in velocity

Well... see, I seem to remember that Numsgil changed that at some point.

He changed some of the code in that part of the program but this is the way the code is right now in th ecurrent version. I just checked. And the bits that Num just posted are directly out of 2 different parts of the source code.

[PurpleYouko]

Just wondering how maxvel figures into this? If I just write a gene that is constantly on with 50 .up store, will the bot get charged for the 50 or will it be decreased because of the velocity cap?

Only the velocity will be decreased by the cap
The cost will be exactly which acceleration you asked for, up to a maximum value of 100.

This is not true of KE mode however. In that mode you get charged for exactly what you receive. (unless that is different now. Num changed something in there too)
The KEs (1/2MV^2) for before and after the acceleration are calculated and you are charged for the difference.

[shvarz]

And I am running KE mode!
That's what I was talking about!  Yay!

This needs to be fixed, really.  It should work just like in regular mode.  As I said, it used to be very touch, but we can compensate for that by charging less in the first place.