Code center > Bugs and fixes
why do some bots become stationary RESOLVED 2.43.1M
Nitus:
--- Quote from: Testlund ---I've been wondering too why the bots stay fixed all the time. In my sim I have the Friction settings set to the following: Z axis gravity=1, Static Coefficient=0.1 and Kinetic Coefficient=0.05. I have no idea how these work or if they are working at all. I haven't managed to find information about it, other than they would have a gravity pull to the background. With these settings set to very low level and brownian motion set to 10 I would expect bots to float around a little, but all my bots are fixed. The only ones I've seen move on occasion are the tiny ones. Maybe Eric can take a look at the Friction settings some time, to see if it's working as it should. :-)
--- End quote ---
Those settings work, but a bot can simply anchor itself irrespective of physics settings. You could have friction set to zero and gravity maxed out, and bots will still anchor themselves. A massive, full-sized bot could slam at max speed into a pixel-sized anchored bot and stop short, as if it was hitting a brick wall.
I'm not sure what the reasoning is behind momentumless anchoring, but it defies all logic and breaks the evolution part of darwinbots. I find it breaks my zerobot sims over and over and over again - bots that anchor themselves with .fixpos don't spend much energy. There's no way to penalize this without penalizing all kinds of dna commands, something that you don't want to do in a zerobot sim.
In my view a bot should have to spend some kind of energy - not dna costs - in order to defy gravity and/or momentum. Mind you, DB is a work in progress, and free to boot, so I probably shouldn't complain. Hopefully in the future someone adds a toggle to turn that off. Integrating it with the physics model would be better [if real organisms could anchor themselves in space like that, irrespective of any force acting on them, we'd be living in a very different universe] but I could imagine that would take more coding effort.
Whatever they do, I hope they do it eventually - bots that are hand-coded at least a little might not find it advantageous compared to moving and hunting, but my zerobots hit on it every time. It's an interesting - if unrealistic - feature for a user-made bot to apply, but it breaks evolution.
Numsgil:
--- Quote from: Testlund ---I've been wondering too why the bots stay fixed all the time. In my sim I have the Friction settings set to the following: Z axis gravity=1, Static Coefficient=0.1 and Kinetic Coefficient=0.05. I have no idea how these work or if they are working at all. I haven't managed to find information about it, other than they would have a gravity pull to the background. With these settings set to very low level and brownian motion set to 10 I would expect bots to float around a little, but all my bots are fixed. The only ones I've seen move on occasion are the tiny ones. Maybe Eric can take a look at the Friction settings some time, to see if it's working as it should. :-)
--- End quote ---
Z axis gravity and friction will make your bots stay put. Y axis gravity will make them fall to the bottom of the screen. I admit it's not very clear. Just think of your screen as the first quadrant of the cartesian grid (or wait... where is 0,0 exactly? maybe it's the 4 quadrant).
--- Quote from: Nitus ---I'm not sure what the reasoning is behind momentumless anchoring, but it defies all logic and breaks the evolution part of darwinbots. I find it breaks my zerobot sims over and over and over again - bots that anchor themselves with .fixpos don't spend much energy. There's no way to penalize this without penalizing all kinds of dna commands, something that you don't want to do in a zerobot sim.
--- End quote ---
Fixpos is very ancient. Other parts of the program have evolved and become more complex, but fixpos has not. It made sense in the extremely abstract early versions of Darwinbots, way back before I joined. But once the physics system started to make sense and behave realistically, fixpos sort of becase a throwback. I always emant to go back in and have the bots spend energy to strengthen their grip, so when another bot slams into them their grip weakens and they have to repair it. Never happened, though. Other things were more pressing.
--- Quote ---In my view a bot should have to spend some kind of energy - not dna costs - in order to defy gravity and/or momentum. Mind you, DB is a work in progress, and free to boot, so I probably shouldn't complain. Hopefully in the future someone adds a toggle to turn that off. Integrating it with the physics model would be better [if real organisms could anchor themselves in space like that, irrespective of any force acting on them, we'd be living in a very different universe] but I could imagine that would take more coding effort.
--- End quote ---
Think of something like a barnacle. You can pry them off of something, but it takes a lot of effort. The barnacle isn't expending energy constantly to maintain that grip. That's where fixpos came from. The idea that you're looking at an aquarium from the side, and some bots can learn to grip on to the "glass" surface of your monitor.
Nitus:
--- Quote ---is very ancient. Other parts of the program have evolved and become more complex, but fixpos has not. It made sense in the extremely abstract early versions of Darwinbots, way back before I joined. But once the physics system started to make sense and behave realistically, fixpos sort of becase a throwback. I always emant to go back in and have the bots spend energy to strengthen their grip, so when another bot slams into them their grip weakens and they have to repair it. Never happened, though. Other things were more pressing.
--- End quote ---
I guess I can see how something like that could have stayed on the backburner - I have to admit that I'm impressed with how much work has been done over the last few years.
--- Quote ---Think of something like a barnacle. You can pry them off of something, but it takes a lot of effort. The barnacle isn't expending energy constantly to maintain that grip. That's where fixpos came from. The idea that you're looking at an aquarium from the side, and some bots can learn to grip on to the "glass" surface of your monitor.
--- End quote ---
If a pixel-sized barnacle of minimum size and energy clamps onto the "wall" and a max sized barnacle at high speed comes sliding down the "wall" and slams into it, it gets unclamped unless it has one hella clamp. To stay fixed against the tides and currents a barnacle spends energy afixing itself.
I've noticed "body" becoming more and more implemented in recent years - a barnacle spends body points at least, anchoring itself.
I realize that the game is a work in progress, and I don't know what direction is already planned, if any, but a really simple fix would be a ".fixpos cost" under dna costs in the costs menu. That would work until whatever plan comes down the pipeline, and probably wouldn't be too hard.
Testlund:
--- Quote from: Numsgil ---Z axis gravity and friction will make your bots stay put.
--- End quote ---
But with such a low setting of the slider and brownian motion at 10 I don't think they should get glued to the background, unless it's done by fixpos. Hard to know which is which here though. I decided to have z gravity on to see if it would stop the eternal spinning of some bots, like they were in space, not in my petri dish.
Maybe it's too much of a conflict for the program both have a force to push them around (brownian motion) and a force to hold them to the background (Z gravity). Hmm... What if I turn off the Z gravity and keep the coefficients?
Otherwise I'm not opposed to .fixpos. I know how hard it is to scrape off some alga from the glass pane in an aquarium, but maybe it should be a slight cost for the bots to do that. Maybe sacrificing a part of their body, with a timer that cause it to wear off after a set amount of cycles.
EricL:
The waste threshold overflow bug is fixed for the next drop.
I would be happy to add a fixpos per cycle cost or otherwise modify the behaviour of .fixpos, but that is a DCR (Design Change Request) not a bug. If there is not one already, posting a topic specifying the requested change in the Suggestions forum would allow me to track it and not forget about it. Thanks.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version