Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nitus

Pages: [1] 2
Suggestions / Suggesting a cost for .fixpos
« on: August 25, 2008, 05:48:26 PM »
I could care less whether whether you accept it or not.  Let me be very clear about something.  The simulator is not intended to be a perfect (or semi-perfect) simualtion of real, macro world physics.   There are hundreds of examples where it is not.    The only reason it even attempts to simulate tangible phyisical world objects and interactions at all (as opposed to purely digital constructs) is to appeal to human intuition and aid humans in identifying interesting evolved or programmed behaviour.   Evolution does not require the model conform to your notion of correctness.   We could in fact do away with all simulated phyiscality and allow bots to reside, interact and evolve in a purely a naitve digital realm divorced from anything our own evolution has prepared us to recognize.   There are good arguments to favor such a model as I have argued in the past.   But even given the current physics model, that something violates your macro-world intuition or personal sense of worth is insufficient reason to change it.  It cetainly is no reason for me to spend my valuable hours doing so.

If you have a well-reasoned, specific suggestion to make, let's hear it.   But spare me your unreasoned value judgements.

There's no need to get hostile. I appreciate your efforts on this fine, free product, as I appreciate that you've taken steps to address concerns that I and others have with this issue.
This isn't about my "notion of correctness" or my "macro-world intuition", whatever that's supposed to mean. Are you suggesting that microorganisms are less beholden to physical laws, somehow? Certainly, you could design any kind of strange model you want to achieve whatever effects you want, though whether the results would say anything meaningful about evolution would be a matter of debate. That's irrelevant to the point: fact is, you chose to go with a model that reflects real world physics. In either case, internal consistency within your model is important - if you're going to have gravity, for example, then it should function properly.
I'm guessing [or hoping] that your friction-based fix will address most of my concerns, including RE gravity. I certainly didn't intend to draw ire with that comment. I'm grateful simply that you've chosen to fix it at all. I've enjoyed darwinbots for years now, and with every release you make it that much more enjoyable. This is work you do on your own time, for little kudos, and it makes my life just a little brighter. If I had the time and the inclination, I'd help out a little instead of just whining about my broken sims ;p.

Suggestions / Suggesting a cost for .fixpos
« on: August 24, 2008, 05:58:13 AM »
I hope that extreme gravity will affect your "suction cup" model. I guess if you're making it strictly fricton-based, it should address my concerns, but for it to be truly in line with the present model there should be at least an morphological cost, such as acceleration vs gravity. I simply can't accept a model that  "fakes it" as saying anything worthwhile. You shouldn't need to make it happen to see it happen.

Suggestions / Suggesting a cost for .fixpos
« on: August 15, 2008, 08:27:43 PM »
You could have a .texture work similar to slime, perhaps, but without the "evaporation" factor - a one time cost as the bot secretes "grease" or lays down "bumps". Have "normal" somewhere between the two extremes of "greasy" and "bumpy" and cost nothing. I could see that general suggestion working - per cycle costs would possibly even be irrelevant from my perspective with that sort of system, because whatever benefits or disadvantages in terms of friction would automatically work within the physics of the sim.

Suggestions / Suggesting a cost for .fixpos
« on: August 14, 2008, 05:34:05 PM »
Quote from: EricL
My $0.02:

I don't really favor a cost for fixing or some limit of fixation duration.

First, I have a dislike for costs of any sort.  I think they are over emphasized as it is.  IMHO, they should play a minimal or non-existant role in applying selection pressure in evo sims because they drive selection towards simplicity rather than complexity.  I prefer to use preditors, shepards and species-species competion (along lines other than cost-effeciency) as selction drivers in my evo sims so as to encourage spiraling co-evolution that selects torwards increasing complexity.   My evo sims generally have no costs.

Second, it's not obvious how it should work.  A cost per cycle?  An initial fixation cost?  A limit on fixation duration?  A consensus could be reached, but it's not immediatly clear to me what it would be.

Personally, I prefer to simply add a global sim option to allow fixing or not.  We already have the options to allow ties and to allow different bot radii.  This would simply be another global sim setting that would provide the human option of disabling fixation in that sim.  If so set, setting .fixpos would do nothing.

A global setting would work, but there could be scenarios where bots might be able to make leigitimate use of .fixpos even if it had some costs assosciated with it - sims with fixed feeders and gravity, for example, where it might profit a bot to fix in clusters near a food source.
My only beef with it is that it breaks the physics model - a bot can anchor itself in space and time regardless of gravity or momentum; even the tiniest bot, when fixed, can stop a massively huge bot dead in its tracks. I have no problem with bots using it, if it's a functional adaption, but it shouldn't circumvent the physics of the sim.

I've always used phsyics-based costs rather than DNA costs in evo sims - DNA costs don't encourage evolution - along with predation and competition, so I would prefer a physics-based fix. There should be some way to make the bot pay for circumventing momentum - in a high g environment, high momentum environment, for example, or when a larger bot slams into it with high "marbleness" set. A movement cost, counter to momentum, or a body-associated cost would be ideal [if harder to implement]. A global .fixpos flag would preclude any legitimate use of a .fixpos strategy [not to mention that fixed veggies seem to use .fixpos behind the scenes; bots that reset .fixpos to zero will unfix veggies]. I suggested a .fixpos DNA costs more as a rough fix that would be easier to implement while not completely disabling .fixpos.
The fact that my zerobots in gravity environments keep selecting for it [particularily with energy-shot fix feeders] is not a problem - it makes sense that they would want to. Inserting a predator bot into the sim makes it a less effective tactic, but I've been rerunning sims in an effort to get the bots to keep their .fixpos strategy while finding a means to defend themselves -  a reef or cluster seems kinds cool if it can be made to function sensibly. It just doesn't make sense for the bots to completely circumvent the physics model.

I'm not sure if it's noteworthy, but I never had this happen until I started using zerobot blanks for my evo sims
. Even then I can only replicate it using an environment where it confers a distinct advantage. Transitioning the sim to a more complex competive environment isn't working well for "reef" bots, but I'm hopeful that they might devise a defensive strategy that allows them to maintain their "reef" behavior. Some of these reefs utilize extensive ties, which is kind of cool. Overall I don't have a problem with this behavior; I'm just picky about the physics ;p.


Bugs and fixes / why do some bots become stationary RESOLVED 2.43.1M
« on: August 14, 2008, 04:54:17 AM »
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.

I started the thread in Newbie. At that point I didn't realize that an evolving zerobot might select to use .fixpos; I just wanted to know why my bots became stationary.
This issue has nothing to do with the waste threshold, although I may have inadvertently reported a bug regarding waste threshold. A higher waste threshold does not prevent bots from storing to .fixpos deliberately.
A .fixpos cost would be a nice fix until the rest comes down the pipeline, but I have to admit that this thread doesn't have much validity by the visible editorial stance on this forum. It's not really a bug that bots can select for .fixpos - it's just that there's no cost preventing them from doing so.

Bugs and fixes / why do some bots become stationary RESOLVED 2.43.1M
« on: August 08, 2008, 02:05:49 AM »
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.

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.
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.

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.

Bugs and fixes / why do some bots become stationary RESOLVED 2.43.1M
« on: August 07, 2008, 06:21:34 PM »
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. :-)

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.

Bugs and fixes / why do some bots become stationary RESOLVED 2.43.1M
« on: August 03, 2008, 03:35:34 AM »
You can have your feeder vegs fire info shots as well that set .fixpos to 0.

Yeah, I'll try that. If the environment is as unfavorable to that strategy as I can make it, and with aging costs set higher, the bots will hopefully discard it. A tender veggie that went around resetting .fixpos might keep them from exploiting stationary feeder veggies with .fixpos and find a different strategy.
Their original toroidal environment, where they free-fell past the feeder veggies, was supposed to favor bots that did things to stay closer to the feeder veggies. It didn't occur to me that a bot could use .fixpos to avoid moving out of feeder range. Some of the others were using ties to latch on to the feeders, and that led to them building clumps of tied-together bots near the feeders, and I don't think they're as quick to fix themselves as 2-8-2f, but they do it to an extent. A veggie that goes around setting .fixpos to zero might be just enough to bump the sim in the right direction.

Bugs and fixes / why do some bots become stationary RESOLVED 2.43.1M
« on: August 02, 2008, 07:51:39 PM »
Is there any way to fix this problem temporarily, perhaps with a dna cost that won't unfairly penalize the kind of evolution I want to see in the sim?
There's no pressure for these bots to ditch the .fixpos command if they can simply wait around without burning energy. In their previous environment, feeder bots were placed at regular inervals, which might had led directly to the inclusion of this gene. Now that they have it, they're stagnating.
Hmm, maybe if I jack up aging costs - I don't want to penalize a class of dna command that might include useful adaptions.
It's too bad that Eric is on siesta, because the ability of a bot to circumvent physics based on a dna command is a serious flaw. I should replicate the initial conditions with fresh zerobots and see if they're likely to do it again - if moving around doesn't do anything for them but expend energy, I can see that they might well develop the same strategy.

Bugs and fixes / why do some bots become stationary RESOLVED 2.43.1M
« on: August 02, 2008, 04:52:02 AM »
Here's a sim that illustrates my problem.

imble.sim -

There's gravity and relatively high morphological costs. All bots except for feeder start at zero cycles [I waited for the feeders to get full before populating the other bots]
The red bots are the ones that exhibit this fixing behavior. Good old 2.8.2f. If you load this sim over and over again, you'll notice that the time it takes for each 2.8.2f to fix itself is more or less random - sometimes they fly around for a long time, sometimes they stop right away. But sooner or later they fix themselves.
The yellow bot is a single mobite - a veggie that's supposed to encourage the zerobots to chase it.
The three green bots are feeders. They're fixed in place and spew energy shots, and in theory they encourage bots to exploit them wherever you place them. In this sim they're just there, but if I put them near the top of the "tank" [with gravity] a bot would have to be going up to explot them [and so on].
The teal bots are fresh zerobots, their zero genome is quite a lot larger than the genome that 2.8.2f evolved from. They're in there to add some spice if you want to run this sim for a few days.

Bugs and fixes / why do some bots become stationary RESOLVED 2.43.1M
« on: August 02, 2008, 03:21:01 AM »
How can I manage or disable this effect in physics/settings? I assumed those settings were "off" since I started with no settings file.

These bots are the product of zerobots. If they can select for fixing themselves against the force of gravity without spending any movement energy, magically, then I can see why they would have selected for that in their previous environment. Right now they need to be falling if they're not moving.

I'll play around with waste settings while I wait for a reply.

EDIT I jacked waste threshold to 20000 and BAM, bots started doing things.
Any advice as to how best to eliminate this problem in the future? What's the maximum value for waste threshold? I tried 32000 and it crashed. Feature request: waste on/off toggle.

EDIT 2 This doesn't work on all the bots in the stable. Some of them just stop and remain fixed, and it happens a lot sooner than waste as I understand it could be responsible. Could these zerobot-spawn have a .fixpos in their genome somewhere?

If a bot can thwart the sim physics and evade morphological costs just by enacting some command in its DNA, that's a major flaw. A bot should not be able to defy gravity without expending energy, and I should not have to penalize other aspects of its dna that don't expend the same amount of energy. I think I understand the idea behind "alzheimers", but it shouldn't defy the laws of physics. If a bot is not doing anything to prevent itself from falling, and the "immobile" flag is unchecked, then it should fall.
Moreover, when a bot hits one of the frozen bots, even if it's a much larger bot, it's like hitting a brick wall. How can anything the bot is doing prevent it from being banged around like the sim physics dictate?

Bugs and fixes / why do some bots become stationary RESOLVED 2.43.1M
« on: August 02, 2008, 12:54:07 AM »
Despite having zero friction and having 0.2 gravity, I notce bots becoming immobile. They're moving around, then suddenly they stop and stay fixed in place.
They're not doing anything to remain immobile, so gravity should be making them at least fall. But they are expending no energy and remaining fixed in place. What could be causing this?

Newbie / question about costs / evo
« on: July 29, 2008, 03:11:19 AM »
Quote from: Numsgil
They let you specify different costs for different sorts of DNA commands.  A *number is something in the DNA that looks like *.this  Basic commands are things like add, sub, mult and div.  Advanced commands are things like pyth, sqrt, etc.

The original thinking was to allow more complex commands, like pyth and sqrt, to cost more than more basic commands, to favor things like add that people are good at figuring out what it does.  Anymore I think the whole thing is overly complex, so it's safe to ignore it if you want to

Oh, ok. Well, I'm sure it'll someday be on the wiki.
I have to admit I'm impressed with the work that's been done since the last time I updated. I was skeptical at first, because in the earlier releases [at least as far as plebs or "end users" go] made me feel that some of the intent behind darwinbots had been lost in the eagerness to facilitate someone's bot-writing. But I can see already that I should have checked in earlier and updated, because it's clear now that much of what I thought was being lost was simply in utero, waiting to be implemented.
Since the last time I checked in, you guys have taken my doubts and turned them into admiration - kudos to whoever it is that works on this thing.

Newbie / question about costs / evo
« on: July 28, 2008, 03:13:54 PM »
If your bots are autotrophs, maybe you're giving them too much energy/cycle?

I do have veggie energy/cycle set to 1, but this is happening wih animals; my veggies don't do much but get eaten.

What happens when you change something in that form, close it, close the options panel, and reopen it and that form again?  Are the numbers you entered still there?

Yes, they're still there. They just aren't having any effect.
I started with no default settings file - is there perhaps some value somehwere that acts as a multiplier to costs, that I might have left blank?
Edit Ah, heh, such as "Cost Multiplier". It was set to zero. ;p
Soo . . . what's "number" "*number" and "logic" - and what's the difference between basic, advanced, bitwise, and etc?

Newbie / question about costs / evo
« on: July 27, 2008, 07:57:07 PM »
Ok, I registered msstdfmt.dll and made it to the menu, but the changes I make there don't seem to be taking.
As a test, I jacked up the cost for rotation and toggled "zero momentum" mode, and the bots aren't expending energy despite rotating and changing direction of rotation. The changes I make to the cost settings don't seem to have any effect on gameplay, for whatever reason. I'm using XP pro, if this is realted to the "regional" issue or whatever..

I do have a few questions about some of the controls. What is "number" and "*number" and "logic" and what are the differences between the various commands?
edit The regional settings aren't the problem, now I've read the "installation issues" page on the wiki. I've disabled "brownian motion. The bots just simply aren't expending energy, despite the cost settings.

Pages: [1] 2