Hi!

[Sprotiel]

Hi all! I've actually discovered DB a long time ago (Autumn 2003) but I played with it only for a few weeks and then I shelved it. I'd like to help with the code. I've already had a look at it and, frankly, it's a mess! The physics model is quite weird and, IMHO, should be brought more in line with reality.

So, may I meddle with the code and if yes, how can I submit changes to the code and where do I start?

[shvarz]

Just want to say "Welcome!".  As for changes - talk to PY and Numsgil, they will simply incorporate the code and make an "official" new version release.  What kind of changes are you talking about?

[PurpleYouko]

Hi Sprotiel

Welcome to DB.

Please feel free to play with the code all you like. If you make some changes that make the program work better than it does now then just let Numsgil and Myself know so that we can evaluate your changes then incorporate them into the next release.

What exactly do you see wrong in the physics?

I know a lot of the code could be improved on but I think we are mostly there.
Also which version of the source are you looking at. There are a number of different versions out there. I think the last posted version was for the first release of V2.36.5. Anumber of small fixes have been made since then but the source has not been updated.

[Sprotiel]

Sorry, my first post sounds much more critical than I intended. The thing is, I'm mostly interested in evolution sims and I was a bit disappointed to see that this part of the program didn't seem much improved. What I'd like to see would be vegetables that can evolve without predators (I.e. that can compete between themselves for something else than space), viable evolution for multibots, etc.

Anyway, the actual changes I'd like to make would mostly be to make the code read better, so that the logic becomes more apparent. Separate clearly what happens inside the robots from what happens outside, find a way to not use robots to make corpses and walls, etc.

Concerning the physics, the most obvious incoherence is that we have solid friction even though bots are supposed to live in water. Fluid friction (I.e. proportional to velocity) would make more sense. I haven't yet understood all the code, but it's written in such a way as to make me feel there must be mistakes. Perhaps there aren't, but rewriting it would make it is possible to understand and modify it.

PS: the version I have is 2.36.5, from the FTP server.

[shvarz]

Evolving veggies is what we need!  Bring it on!

More realistic friction would be awesome too.  Just remember that DBs is very open system and does not necessarily represent things moving through water.  It can be air, it can be ground and it can be open space and everything in between.  Also, even fluid friction behaves very strangely when you go down to the levels of microorganisms, see this thread for details: http://s9.invisionfree.com/DarwinBots_Foru...p?showtopic=186

[Sprotiel]

Interesting! Physics at low Reynolds number is definitely weird. This might be an interesting option, though I don't really know how to program it.

However, I know that the environment could be anything but fluid friction has the advantage that there is a physical maximum velocity (well, depending on the force created by the bot...) To me, this feels better than having an artificial cap.

[PurpleYouko]

There is no artificial cap on velocity any more.

Velocity is interdependant on the mass of the robot, moving factor, friction and a few other things. That is why we have the sysvar *.maxvel. This is different for every bot rather than a fixed value of about 40 like it used to be.

Agreed that we need some serious improvement in evolution. There have been some fairly major changes in the last year or so but you just can't see them at first glance.

The ultimate aim is to blur the line between veggies and animals so that it will be possible to have aspects of both. Read some of the threads on enzymes in the suggestions forum for an idea of where we are trying to go.

[Sprotiel]

Well... the artificial cap is on momentum, not velocity. It's not fundamentally different.
I'll try to make concrete suggestions when I understand the code better.

A question: how can I get the latest version of the code?

[PurpleYouko]

Well momentum is just mass times velocity so the only cap possible is due to the physical constraints of mass getting too big.
The main problem is that we currently use single variables for robot memory locations which limits all values that are read directly to the sysvars, to about 32000.

[Numsgil]

The almost current code should be on the FTP as 2.36.5.  The changes that PY and I have made since are incredibly minor, so much so that it hasn't even warrented a release.

So whatever you can figure out in the 2.36.5 code should hold true for everyone.

[Carlo]

There is no artificial cap on velocity any more.

Are you still able to calculate collisions without errors? The artificial cap was exactly the half of the robot's size, so that two robots, moving in opposite directions at max vel, always collided instead of passing through each other.

[PurpleYouko]

The collisions are actually much simpler now.
The "repel" routine has been ditched in favor of a system which uses conservation of momentum. This make more sense as bots are different masses now.
Runs faster too.

I haven't seen any problem with bots passing through each other.

Effective absolute max speed is about 60 now though I have never known a bot to get there yet. It is necessary for it to have a mass of 1/2 to acheive this. That means no shell and a body of 20. Robots that small are pretty sickly really. They can't shoot worth a shit.

Minimum bot size is 120 so they shouldn't be able to go through each other at max speed.

The way it all works now is that when a collision is detected, the robots are first moved back along the path they came in on until they are just touching (variable with physical size). Then the difference in their momentum is calculated (in x and y vectors) and re-assigned such that both robots move away from the collision point. NO ACCELERATIONs are applied to either.
It is now possible for a fat slow bot to plow through a gang of little skinny bots without slowing down much while the "skinnies" are knocked all over the place.

[Sprotiel]

The collisions are actually much simpler now.
The "repel" routine has been ditched in favor of a system which uses conservation of momentum. This make more sense as bots are different masses now.
Runs faster too.

Great! Though I wish you'd told me this before I decided to rewrite repel.

It is necessary for it to have a mass of 1/2 to acheive this. That means no shell and a body of 20.

Code: [Select]

.mass = 1 + (.body / 10000) + (.Shell / 200)Or has it changed as well ?

So whatever you can figure out in the 2.36.5 code should hold true for everyone.

Well... mostly I figured that the code is more readable when unused procedures and commented out bits of code are deleted and that every time you fix something, you create a new source of crashes.

[PurpleYouko]

Code: [Select]

 
.mass = 1 + (.body / 10000) + (.Shell / 200)
Or has it changed as well ?

OK you caught me out here. Mass/2 has a minimum of 1/2 therefore mass cannot be lower than 1.
That's what I get quoting from memory instead of checking the code.

Well... mostly I figured that the code is more readable when unused procedures and commented out bits of code are deleted and that every time you fix something, you create a new source of crashes.

Yup. We all figure that one out pretty quickly.
That's the reason so much old code is left in there and commented out. You never know when you might need it back again to fix something that you inadvertently screwed up elsewhere.
V2.35 was an example of that. Something in the ties got screwed right up (phantom ties to nothing and weird long ties going across the whole screen)
We spent hours trying to figure out what was wrong and eventually just imported the whole routine back from the last known working version. Fixed it but we still have no idea how.  :blink:

[Sprotiel]

V2.35 was an example of that. Something in the ties got screwed right up (phantom ties to nothing and weird long ties going across the whole screen)

I've seen something like this when trying to modify the collision routines. Switching all private variables to Single seems to have cured it.