Topics

31

RANT / Sick of people posting only on Thursdays

« on: January 23, 2008, 12:52:15 PM »

I don't know why it bothers me, but people who show up thursday mornings, post a bunch of nonsense then dissappear for the rest of the week really bother me!  Why does he do it?  WHY? WHY? WHY?  Perhaps he's in jail and thursday is library day...

Tomorrow's thursday.  It's going ot happen again!  Make him stop!

32

Suggestions / .sexrepro reimplemented in 2.43.1

« on: January 21, 2008, 04:29:51 PM »

.sexrepro has been (re)implemented for the next buddy drop (2.43.1).

DNA may now be decorated with a new command "cross" which is subject to mutation, etc. like all DNA.  This command does nothing other than to define crossover points for when DNA is combined during sexual reproduction.

Currently, the only way to sexually reproduce is for both parents to be near each other at the same time.  Down the road, other methods may be defined where fertilization by one or both parents can be time shifted (e.g. egg laying, shot-based fertilization, etc.).

Currently, there are number of requirements to sexually reproduce:

1) The two bots must be looking at each other with their focus eyes.  That is, each bot's refvars must represent the other.
2) They must both store a positive value (that is not a multiple of 100) into .sexrepro during that cycle (as with .repro, the value gets MODed down the line to determine the percentage of resources to give to the offspring).

There is no requirement that the two bots be of the same species.  Species recogninition and mate selection are and should be a function of the morph and are totally outside the scope and jurisdiction of the simulator code.

The bot with the higher .sexrepro value (before the MOD) is designated the female, the other the male (if they both have the same value, one is chosen as the female randomly).  There are ramifications of this, the most important being that all the nrg and other resources for the offspring are provided exclusivly by the female according to her value in .sexrepro.  The male pays no nrg or other resources for reproducing sexually.  The idea here is that as in nature, reproducing sexually is expensive for females and cheap for males.  Perhaps one day this may lead to male-male competition and sexual selection.

The bot designated as female also plays an important role in many other ways akin to asexual reproduction including:

1) She must have .body > 2
2) There must be space for the offspring to materialize in front of her.
3) The offspring is born with a birth tie to the mother and inherits her velocity.
4) Genetic memory is inherited from the mother only.
5) Custom defined sysvars (e.g. user-defined memory location labels) are inherited from the mother only.
6) Mutation history is mother's side only.
7) "species" level info such as disabled visioin, disabled mutations, etc. are mother side only.
offspring inherit their mother's color.

Veggies may reproduce sexually but veggy reproduction limits are respected (and reproduction may be prevented) when the female is a veggy.  Note that veggy males may reproduce sexually with non veggies independent of veggy population limits.  The mother must be a veggy for the offspring to be a veggy.

Crossover is performed by taking alternating sections of DNA from each parent deliniated by cross commands, first one parents DNA and then the other's.  Switching between parent genomes is performed whenever a "cross" is encounterred at that bp location in either parent's DNA.  Which parent the process begins with is chosen at random.  If one parent's DNA is longer than the others, the offspring may or may not inherit the DNA from the longer genome (that DNA which extends beyond the length of the shorter genome) depending upon whether or not the longer parent is providing DNA at the time the end of the shorter is encounterred.  Crossover does not respect gene boundaries.  Crossover points may occur mid gene and/or in non-coding areas.

2.43.1 should be out in a day or two.

33

Internet Mode Commentary / Its a bot-eat-bot world out there...

« on: January 13, 2008, 12:43:09 PM »

I think it's curious that CostX in my IM sims has been zero for quite a long time.  I don't know whether it's the difficulty in catching veggies such as shrinking violet or the effectiveness of macro preditors such as Lionfish 7, but the populations have been self regulating without costs for days and days...

34

Suggestions / Better Seeing

« on: January 09, 2008, 08:56:43 PM »

In addition to the forthcoming change which modifies the distance an eye can see as a function of it's width, I've been thinking about how to do a better job w.r.t. being able to get refvar level info on multiple objects per cycle, both those in sight and those being "rememberred".  Here's a couple ideas:

1) Changing .focuseye would instantly change all the refvars.  Thus a bot could do things like:

-4 .focuseye store
*.myeye *.refeye !=
 -140 .aimshoot store
-3 .focuseye store
*.myeye *.refeye !=
 -105 .aimshoot store
-2 .focuseye store
*.myeye *.refeye !=
 -70 .aimshoot store
.
.
.
and so on...


2) Add the sysvars .refid, .focusid and .focustype.  .refid is a refvar that would return an ID of the object being viewed.  If .reftype is 0, this is a bot.  If .reftype is 1, a shape and so on.  Setting .focusid and .focustype would change the refvars to reflect the properties of the object with that ID and type if it exists.  With this, bots could do things like keep track of objects they've seen recently without needing to look at them.  Conspecs could stay in formation with one another or know when and where a sibling died.  Preditors could shoot at things they once glimpsed but are now beyond their vision range.  An ant queen could read the .outNs of scout bots at distance...  Lots of possibilities.

35

Bugs and fixes / GeneEnd() bugged in 2.43y RESOLVED (2.43z)

« on: January 08, 2008, 02:19:16 PM »

The GeneEnd() routine still uses the old definition of gene boundary in calculating the ending BP of a specific gene g and may returns a location eariler in the genome than is correct, effectivly breaking .delgene.  

Fixed in 2.43z

36

Bugs and fixes / Shot leak RESOLVED 2.43z

« on: December 30, 2007, 07:59:03 PM »

version 2.43y.

I'm pretty sure if a bot makes another virus before a previous virus is fired, we leak a shot.  This is just to track that so I don't loose the bug.

37

DNA - General / Virus / gene feedback requested

« on: December 27, 2007, 08:13:07 PM »

I'm curious how people like the new definition of a gene in 2.43x.  It impacts .mkvirus and .thisgene, so probably breaks many viruses and virus spawning bots.

I'm also curious as to what people think of the new DNA tokinzation logic for bot DNA in the bot properties dialog.  I put some time in and made this a lot more useful.  Makes it easier to see what is coding and non-coding in evolved bots as well as debug bot code that is gene number sensitive.  As far as I know, it's pretty bug free and accurate, including the gene activations dialog.

38

Suggestions / Varying sight distance as a function of eye width

« on: December 26, 2007, 03:48:30 PM »

In playing around with building a bot that can catch Shrinking Violets, its apparent that having the sight distance the same for all species makes sneaking up and "surprising" a species rather difficult, particularily when everyone is using omnieye vision.

I'm still planning on adding .camo at some point, but what do people think about the idea of making an eye's sight distance a function of it's width?  The wider the eye, the shorter the distance it can see.  If we assume the sight distance for the default PI/18 eye width is 1, then I might scale this such that the sight distance S for a specific eye width W as a function of W

S = 1 - log(W)/2 where W is the eyewidth as a mutplie of standard Pi/18 eye widths.

Thus, when the .eyewidth is 0 and thus the eye has the standard width, W=1 and thus S=1.

For a 360 degree omnieye, W=36.  S ~ 0.22.

For an eye half the normal width, W = 0.5, S~1.15.

For the narrowest eye possible, W=1/35, S~2.54.

So, omnieye bots can only see about 1/4th as far as bots with the standard eye wdith.  Bots using a long distance eagle eye can potentially see 2.5 times as far as standard bots, but with an incredibly narrow field.

This change might actually improve performance, particularly over sims with omnieye bots.

What think?

39

Suggestions / Using .shootval for virus targeting

« on: December 23, 2007, 09:33:49 PM »

Now that virus insertion is random as opposed to always being the last gene, I have had a request to allow the virus (or virus shooter) to optionally control where virus insertion occurs in the infected organism.  Unless there are objections, I plan to use the value of .shootval on the cycle .vshoot successfully shoots to indicate the gene number in the target organism before which the virus would like to be inserted.  The value will be MODed by the number of genes (plus 1) in the target organism at virus infection time.  A .shootval of 0 will indicate random insertion.

I view this as a temporary targeting mechanism which will suffice until we move to a sequence based targetting paradym.

40

Simulation Emporium / The Enterprise is in deep trouble...

« on: December 23, 2007, 04:30:45 PM »

Remember that episode of the original Star Trek where the alien ships are weaving a web around the helpless Enterprise?

Well, if nothing else, this sim demonstrates that shape visiblity is now complete.

Requires 2.43w or later to work correctly.

41

Suggestions / The shape pit of death

« on: December 21, 2007, 02:47:09 PM »

Shapes can be more than simple walls that keep bots out of their insides.  Now that we have the infrastructure for bots to see shapes and find out things about them (via refvars) we can use the shape paradym to add environmental complexity.  For example, we can have shapes that do the following things:

Hill shapes.  The repulsion force is small at the edges, but becomes progressivly stronger towards the center.
Pit shapes.  The repulsion force works in reverse of hill shapes.
Nrg sources.  Bots on the shape get free nrg.  Could scale this as a function of distance from shape center.
Cost Free Zones / Cost multiplier zones.  Bots on the shape expereince no costs or dramatically increased costs.
Shapes where ties don't work.
Shapes where shots don't work.
Shapes where nrg shots are everlasting.
Shapes where eyes or poison or venom or viruses don't work.

The possibilities are endless.

Of course, shapes can reside on top of other shapes, so one can imagine combining these things - a hill with a smaller nrg source on the top, high cost shapes in which where nrg shots last forever.  The nrg shot remains of corpses bouncing around inside may justify venturing into the higher cost zone and so on.

I'm thinking the first one I will do is the shape "pit of death".  Think of it as a hole in the field into which bots can fall to their death.  Bots die instantly if they cross the shape edge.   .refkills will get updated, allowing bots to detect these pit of death shapes and avoid them.

42

Suggestions / vision - distance discrimination

« on: December 19, 2007, 06:11:50 PM »

I've got the rest of shape visibility implemented now for 2.43w.  There were two cases missing in pre 2.43w drops:

1) The case where a bot is off the corner of a shape and the eye spans the shape corner.  In this case, the bot eye value registered the shorter of the distances of the interestion points of the two eye edges with the shape sides, not the distance to the corner as it should.  In cases of wide eyes where the eye edges don't even intersect the shape, the eye didn't see it the shape at all!   Now the eye value correctly registers the corner as the closest part of the shape in view and it works for any and all eye widths.

2) The bot is off the side of the shape and the eye spans the closest point of the shape (the point of interestection of the shape edge and line drawn perpendicular to the shape edge through the bot center).  Simialr to above, in cases of wide eyes, the bot may not even see the shape in current drops.  Now the closest point is registerred and everything works for all eye widths.

I have several issues for comment.  Let me try to be breif and precise.

Q1) Are bot eyes located at the bot center or at the edge of the bot (I.e. at it's radius)?  Particularly for bots of large size, this has bearing on absolute eye values, distance discrimination and whether bots can and should see things inside themselves (such as when a vastly smaller bot penetrates it).  Currently, the eye value equation factors in the viewing bot's radius, but in sort or a strange way.   Imagine 2 bots, A and B, each exactly the same distance away from a third bot C.   If A is considerably larger than B, it's eye value when looking at C will be somewhat higher than when B looks at C, soley because it is larger.  The purpose of this (I assume) is to sort of locate eyes on the bot's edge.  But A can still see things within itself and the ultimate highest possible value of one of A's eyes (occurs when it is centerred right on the thing it is viewing) will be larger than B's ultimate highest eye value.   Bascially, being larger conveys slighty better distance discrimination capabilites.  

Q2) Should we increase the range of eye values for better eyesight distance discrimination?  This subject has been discussed before.  Currently we are using only a fraction of the range of values for eyesight, which seems to me like a waste.  If we want to allow for pricision burrowing in shapes or detection of shape imperfections due to previous burrowing or the identification of a small hidden bot moored against the side of a shape using distance alone or precision ambush tactics such as hiding around shape corners or precise dodging of visible shots, we are going to need better eyesight resolution.  I can still make it non-linear, as it is today, but doing so over a larger range of values would open the door I think to more precisie behaviour and interaction with the environment.  I would implement this via a toggle of some sort for backward compatability, either a per-bot settable sysvar or a DNA file flag.   Bots could choose to use the higher range or not.

43

Veggies / Shrinking Violet (veg) (1G) EricL - 12.16.2007

« on: December 16, 2007, 03:07:03 PM »

Runs from everything.
Stays small to avoid shots and viruses.
Uses omnieye targetting.
Kills itself if dnalen changes to avoid virus propogation or serious mutations.
Hard to catch.  Has profound impacts up the food chain.


start
1221 .eye5width store
50 .repro store
0 .fixpos store
*.eye5 0 >
*.refxpos *.refypos angle .setaim store
200 .dn store
*.eye5 30 > *.nrg 100 > and
-1 .shoot store
*.eye5 0 =
1 .fixpos store
*.body 5 <
1 .strbody store
*.body 10 >
100 .fdbody store
*.numties 0 >
*.tiepres .deltie store
*.dnalen 66 !=
32000 .shootval store
-2 .shoot store
stop
end

44

Bugs and fixes / Wide eyes can't see shapes RESOLVED 2.43w

« on: December 16, 2007, 02:03:09 PM »

Bot's can't see shapes when neither of the edges of the eye intersect the shape.

45

Suggestions / Seeing world's end

« on: December 15, 2007, 08:56:14 PM »

I'll probably make the field edges visible in 2.43w.  They will only be visible in non torridal sims, making them visible will be optional and controlable via a human setting, if they are visible, .reftype will be 2 when the closest thing in the focus eye is a world edge.

Note that a forthcoming enhancement is for the refpos sysvars to reflect the actual positon of the portion of the viewed object, be it a shape or the world edge, rather than the viewed object's orgin (for shapes, the upper left corner).   This way, bots can remember where the corners of shapes are for example or in the future, where their burrow is.