Darwinbots Forum
Code center => Bugs and fixes => Topic started by: shvarz on May 31, 2005, 11:02:11 AM
-
I tried the 2.37 and the new mutation panel is kinda screwy - try placing 0 in any of the cells, it totally messes up the "Overall 1 in blah-blah" mutation frequency.
Also, the mutations seem to work differently now - not as often as before and "non-mutating" veggie was getting mutated.
Also, the mutation settings are not saved in settings file - I had to re-adjust them again after loading up the saved settings file.
-
The 1 in X mutation probabilities are still a work in progress. THe problem is that not all the mutations are 1 in X per DNA unit. Some are per gene. Some are per condition. You get the idea.
The real value is probably somewhere between chance per unit and chance per bot. (Not a tiny range I know).
None of the actual mutations routines were touched, so the mutations should work like before.
The settings file stuff should be fixed with 2.37.1. I specifically checked it over a bazillion times.
-
About saving mutation rates - just tried it in 2.37.1 and this still does not work. When I load the saved settings file and open the mutation rates panel, all mutation rates are still at values that were there before the save. It is particularly annoying because there are two spots that always have 0 in them: "Delete a data point" and "Insert a new value".
-
Oh this is driving me nuts!
I'll keep working on it.
In the mean time, internet sharing! Internet sharing!
-
shvarz, it looks like it's a graphical bug. Your settings are loading and saving correctly (I think).
-
Nums, I really think mutations got messed up. I just started a sim and my "average mutations" graph shows no mutations at all after 30,000 cycles and 1800 new bots born. Usually I see at least something appearing, but now it is completely empty.
-
Oops, never mind, I see some mutations appearing.
-
Found and fixed the problem. It was a graphical bug. That means what you see when you click okay is being saved to the bot, and the bot to the settings file, but it's just not showing up when you try to find it again.
I'll fix a few more things with internet, then post 2.37.2 to the FTP.
Have you tried out other settings shvarz? Zero Momentum mode perhaps?
-
I like the changes done to the options menu - a lot cleaner now.
About that Zero Momentum mode: Am I missing something, or Zero Momentum is essentially the same as Friction=1 mode? If yes, then it might be better to expand the friction scale to include the value of 1 instead of introducing a whole new option.
-
Not quite. Friction seems to be applied in such a way that at high friction levels you can't move. That is, friction is applied to movement you initiate the same cycle.
Zero Momentum mode just cuts your velocity to 0 at the start of each cycle.
-
OK, I am confused. I thought that friction is applied to current speed, while the "movement factor" applies to acceleration. Then what is the difference between friction and movemement factor?
-
Movement factor is how effective each impulse (acceleration) is. Default is 80%.
Friction is applied to velocity after all accelerations are calculated.
So an impulse from a bot (say, a command to .up) has to go through both movement factor and friction.
-
That is completely messed up! This means that friction and movement factor are essentially the same thing! They should be different, MF should determine how effective your acceleration is and friction should determine how quickly you loose the speed with time. These are not necessarily related things and sometimes can be reversed. Imagine an organism suspended in air with no gravity. Unless it has a propulsion jet, its efforts to gain speed will be largely wasted, because there is very little friction in the air. Once it gained speed, it will loose it very slowly.
So, the order should be like this:
At the beginning of the cycle apply friction to reduce the current speed.
Execute genes.
Apply MF to .up/down acceleration, calculate collisions, brownian motion and such.
Move bots.
Thus, acceleration and deceleration will be separated. Therefore, different combinations of MF and friction thus would allow description of very different environments.
-
I agree that friction is kind of silly in the current system. But it's been that way for a while now (probably since it was first made?) Doesn't mean we can't change it of course, it just means it doesn't appear to have hurt anything in the mean time.
Here's a graph of how it works. Green arrows denote values at the start of the cycle, the others are the order of action. (there's supposed to be a purple arrow between movement factor and velocity)
(http://img91.echo.cx/img91/6840/aaaa6ul.jpg)
Unfortunately, fixing friction is more invlolved because friction works differently in different environments.
On solid surfaces for example you have static and dynamic friction, which are different. In liquid substances, friction again works different.
The main difference between Movement Factor and Friction is that movement factor ONLY applies to accelerations from up, dn, sx, dx, and Movement factor feeds into friction.
-
Well, I don't care about the fancy details, so just separating these two would be fine with me. It did not "hurt" anyone because not too many people tried to create different environments. If you do it my way, then we can have environments like this:
1. Hard to accelerate but slow to loose speed - it is hard to change direction once you get going.
2. Easy to accelerate but fast to loose speed - very precise movement possible, but hard to travel long distances
3. Hard to accelerate and fast to loose speed - sit tight and don't go anywhere.
4. Easy to accelerate and slow to loose speed - current F1 conditions, free for all running and turning.
5. Anything in between 1, 2, 3, and 4.
The way MF and friction work now it is impossible to create these environements. I think everyone will win if these changes are introduced.
-
I'll do some research in this area on how best to implement it. Give me a few days (I'm working on some things at the moment).
-
I already fixed this problem quite a while back <_<
The way it worked after I fixed it was that friction was applied to any velocity from the previous cycle and then the new acceleration vectors were added to the resultant movement rate.
This means that all new accelerations are not effected by friction on the cycle on which they are applied so in sims with infinite friction you can still have movement, just like with the new zero momentum mode.
If this isn't working in the present version then the code must have gootten lost somewhere :(
-
I haven't checked the code yet, I was just quoting from memory. Does so now...
-
Okay, it looks like PY is right. I'll increase the slider to give higher friction environments.
There are two different kinds of 'friction'. If we think of the bots as on dry land, then friction comes in two varieties:
Static and Dynamic. Static determines how hard it is to produce any motion at all. Dynamic is how you slow down once you get moving.
It follows this law:
(http://en.wikipedia.org/math/33b83a8c6eb118f200143e61cfc854a9.png)
where Ff is the end force, Fp is the normal force (in a flat environment, we would call this the objects weight (ie: mass * gravity)) and uf is the coefficient of friction. Dynamic and Static both have sperate coefficients, although usually coefficient of dynamic friction is less than that for static.
In fluids what we think of as 'friction' is in reality air resistance (ie: drag), which obeys an entirely different equation based on current velocity (solid surfaces just apply a constant dynamic friction force).
(http://en.wikipedia.org/math/fd7e004b903217d77e41f86355cbadaa.png)
Here's a page I found on drag (http://en.wikipedia.org/wiki/Drag_equation). It can probably be simplified to some extent for DB, but you see it's an entirely different equation).
Drag is not friction. Drag is a measure of the ability for water/air in the way to get out of the way. (This is one of my pet peeves. Comets do not 'burn up in the atmosphere from friction'. They create a compression wave, which is itself hot because all gases heat as they are compressed. This wave can become so hot that it evaporates the comet. Many comets have been found that are cool to the touch, even icy, after impact. This is precisely because the heating was non direct and fast. Sort of like throwing food into a broiler for a few seconds. The surface may be charred, but the interior can still be ice cold.)
The effects between the two types are somewhat similar, but drag means that your speed drops off faster the faster you get, while friction could care less how fast you're actually moving (but it does care if you're moving or not!)
This all implies some heavy duty slider control.
An interesting note: shape could change how drag works. A sphere and a cube will experience different forces. A triangle can be quite aerodynamic if it's moving right.
-
In the present system initial resistance to movement is determined by the mass (size) of the robot while the existing "friction" is really more like a drag coefficient but doesn't actually follow either rule.
In reality, drag should have a greater effect when the bot is moving faster while friction may actually decrease as the bot moves faster.
It would be nice to make this follow the real laws. Shouldn't be too hard either.
-
Just means we have to set some arbitrary constants, either in the program (the area of a bot exposed along the movement vector) or in the physics panel.
Friction would probably use mass, while drag would use body (the physical size of the bot).
-
Just want to remind of a suggestion I made a while back: allow complex physics controls but hide them from an average user. Instead we can have four "pre-sets" with descriptive names like: "Water, Earth, Side View, Whale" or "Air, Moon, Top View, Bacteria" and these would set physics parameters to suit these presets. I even have a proposed presets and corresponding conditions organized in some Excel file. I can attach it if people like the idea.
-
The options for is getting too large anyway. (It gave me a 'sorry, you have too many controls' error message the other day). I may see if I can have popup windows for advanced options.
Attach the excel file of settings. I'll see if I can set something up.
-
Have you tested out the save and load sim functions? They should be working again, allowing for linger cumulative simulations to be run.
-
Here is the excel file with proposed presets. The user would choose the following:
Organism size: bacteria, eukaryotic cell, dust mites, Insect, Animal
Gravitation: Space, Moon, Earth, Jupiter (not in Excel file, this would simply adjust the absolute amount, the excel file has relative contribution of gravitation to bots movement).
Environment: Space, Air, Water, Earth-Surface (top-down view), Earth-Soil (side view)
See attachment file and ask if you have any questions.