Topics

46

Suggestions / xpos, ypos, angle and dist

« on: December 15, 2007, 06:16:50 PM »

I think most everyone knows that xpos and ypos don't work for larger fields with dimensions >32000 (they get capped in current versions at 32000).  Similarly for refxpos, refypos, trefxpos and trefypos.

What people may not know is that angle and dist are also similarly broken.

There are valid arguments both for and against making global information such as exact position available to bots.  Personally, I am more inclined to provide only local, bot-relative information and let bots operate exclusivly from what they can "see" around them, but I hesitate to take action which would break backward compatability without some discussion and consensus.

There are two possible choices I see.  The first is to do away with xpos and ypos completly and make the related refvars and trefvars as well as the semantics of angle and dist bot-relative.  They would return or take relative coordinates.

The refvars would return the position of the viewed or tied bot relative to the viewing or tying bot.
'angle' and 'dist' would similary take relative positions instead of absolute positions as they do today.  This has the effect of bascially making dist equivalent to pyth.

The second chocie is to retain xpos and ypos and the refvars and institute a grid system, where the field is made up of 32000 X 32000 grids.  xpos and ypos would be mod 32000, thus indicating a bot's absolute position on a particular grid.  Angle and dist would work as today, but using the absolute coordinates of the particular grid the bot was on and would work as long as the position the bot was using to dertermine an angle or distance was on the same grid.  The result of a dist or angle would be nonsensical when the position was from another grid, say when using the xpos ypos or refvars of a bot across a grid boundary.  Adding the sysvars .gridx and .gridy (along with refgridx, refgridy, trefgridx, trefgridy) would help a bot to know when this was the case.  Unfortunatly I don't see a clean way to avoid bots having to deal with grid boundaries without moving to a bot-relative scheme and thus breaking backward compatability.

As above, I prefer the first option even though it breaks backward compatability.  It's local rather than global, removes the need for bots to deal with grid boundaries and handles any field size.  Bots will be able to do things such as

.refxpos, .refypos angle .setaim store

and have it work on any size field.

The downside is backward compatability and the fact that ant bots and such will need to find some other means of global positioning coordination.

Comments appreceiated.

47

Suggestions / veggy feeding should nrg -> body at 32000?

« on: December 14, 2007, 09:49:58 PM »

Should sun nrg go to body if a veggy has 32000 nrg?

Should a veggy die when it's nrg and body both hit 32000?

48

Suggestions / Internet Mode Restrictions

« on: December 07, 2007, 03:08:47 PM »

When you join internet mode, you necessarily give up some control of your sim inorder to become part of the larger mega-sim.  Yes, of course we want the environments of each connected sim to be able to differ soemwhat, to be unique and configurable, but what we don't want is to allow the ability to so dramatically change the rules from sim to sim that its not a level playing field.  We want certain assumptions such as "size matters" or "ties work" to hold everywhere.

I favor putting the following restrictions in place when connected in internet mode:

All bots are virus susceptable (already the case as of 2.43u)
The Fix Bot Radii option is ignored.  Bot radii always vary acording to body, mass, etc.
The Disable Ties option is ignored.  Ties always work.


Down the road, we will be the abiltiy to have additional internet modes with specific restrictions.  If people want an intenet mode where ties are disabled or its pond mode only or every sim has uses planet eaters or uses fixed bot radii only, etc. then we will (someday) have an authoring mechanism for enforcing this.  But for now, with the one and only IM.... well, I kinda think we want some restrictions that allow for maximum phenotypic varation.  

On a related topic, I also favor the following but for different reasons discussed here.

Veggy repopulation is disabled.  Veggy reproduction would be the exclusive veggy propogation method.


Comments welcome of course.

49

Suggestions / Genetic Distance

« on: December 06, 2007, 10:45:51 AM »

Every bot has a guarenteed unique ID (guarenteed unique in a single sim.  Not necessarily guarenteed uinique in teleporter connected multi-sims like internet mode.  Not yet that is.  I'll work on it.).

For every extant bot I now maintain an orderred ancestor list of unique IDs for the last 100 ancestors and the number of mutations each ancestor had at the time it spawned the next descendent in the line leading to the extant bot.

I have implemented some routines internally that can find the most recent common ancestor of any two extant bots and determine the gentic distance between them.  (Well, okay.  Not actually genetic distance per se.  I'm not actually comparing the genomes and determining how they differ.   Rather, by distance here I mean the number of mutations that seperate them on both lines of descent.  I walk up one side of the phylogeny and down the other and add up number of mutations at each generation.  I have no way to know if those mutations impacted expression or not, were in coding regions or not, were large or small, etc.)  Also, viruses complicate things as does non-asexual reproduction, but lets put those aside for a momnet.

I'm soliciting suggestions as to what to do with this information now that I have it.  What do people want to know or what features do people want to see that leverages this?

Fair warning, some things may be computationally expensive.  I had thought of a graph that showed for each species the maximum genetic distance within the species.  This number climbing from a mean might indicate a speciation event.  But this graph would involve m(n^2) genetic distance compares (I think) where m is the number of speceis and n is the number of individuals/species for every data point.  I'm working on ideas to short cut this, but stiil, yuck.

Another thing I'm working towards is automatic species forking based on genetic distance.  If someone wants to do some deep thinking about when and how to effeciently recognize actual speciation, that would be helpful.

Other ideas are also welcome.  Things that operate from a single bot will be much more effecient than species wide graphs.  e.g. a graph that charts the average genetic distance to the oldest bot of a species is way way more effeceint than the one I mention above.  

And yes, I have plans to dump this to a CSV file for massaging in Excel, etc.

50

Internet Mode Commentary / Flypaper 3.2 finally kills off Nasty Plant

« on: December 03, 2007, 12:54:18 AM »

Looks likes Flypaper 3.2 finally killed off Nasty Plant.  There may still be a few left in offline sims, but NP now looks to be extinct in the currently on-line sims.  Flypaper mutates, whereas Nasty Plant did not.  It looks like after 300 or so mutations and 2500 generations, FP was able to adapt to the point where it could overcome the inherent advantage NP had in being an autotroph.  Go evolution!

NP died out first in sims with day/night cycles.  The nrg boost it got from being a veggy was mitigated at night and once FP was able to knock it's population down to the point where veggy repop could occur, NP slowly got edged out by native plant repopulation.   Not being able to reproduce when you want is a large handicap, one which free nrg for nothing perhaps can't quite make up for, especially when you can't evolve.  
 
One point of interest.  A quick glance at the DNA of a representitive FP shows 3 instances of the new dropbool operator in a genome 178bp long.  Pretty fast uptake.

Now I wonder what's going to be able to take out FP?

51

Tips and Tricks / Make New Species menu item

« on: December 01, 2007, 05:09:32 PM »

This new menu item on the robots menu (new in 2.43u) creates a new species starting from the bot with the focus.  Separate series will show up for this bot and all it's decendents in graphs and such and they can be tracked as s separate species both locally and in internet mode.

Unlike the Save DNA feature which allows you to rename a specific bot (but does not change it's species) this menu item creates an actual new species structure for the bot and all it's descendants.  This means that sysvars like .totalmyspecies will work correctly and reflect the population of only this bot and it's descendants.

The name for the new bot is programatcially chosen at present as the first 10 characters of the focus bot's name with a random 4 digit number appended.  Down the road I will likely add species renaming, but for now you are stuck with this name for the new bot.

A handy trick is to simply choose the Best Bot and then choose Make New Species.

A forthcoming feature will allow for automatic speceis forking of a set of related bots, not just a single bot, based upon human settable subspecies distance.

52

Suggestions / Camoflage

« on: November 30, 2007, 01:41:45 PM »

I propose a new sysvar, .camo , which would impact the degree to which a bot can be seen by other bots.   It can be thought of as a substance, like .slime.  It costs nrg to make, it degrades over time, I'd probably make it relatively expensive, say a 1:1 ratio with nrg (takes 1 nrg to make 1 .camo)

What I would do is use a bot's .camo value along with it's radius and distance from a viewing bot to determine whether to populate the eye(s) of the bot viewing it.  It would take more .camo to hide larger and/or closer bots, less when the bots are smaller and/or farther away.

As a first blush algorithm, I might do something like the following:

Compute the ratio of the .camo value to the bot's radius (call this A) and compare this value to what the viewing bot's eye value would be were there no camofladge (call this B ).  If A>B, the bot is invisible in that eye for the specific viewing bot that cycle.  If A<B, then the probability of the bot being invisible in that eye is proportional to the ratio of A/B.

An example.  A bot has radius of 50.  It has .camo of 200 that cycle.  Thus, A = 4.  If a viewing bot is far enough away that it's eye value without camofladge would be <=4 when viewing this bot, the bot is invisible.  If it's closer, say the eye value would be 8 absent any camofladge, then the probability of the bot being seen - of an 8 being populated for the viewing bot's eye sysvar instead of 0 - that cycle is 4/8 or 50%.

Note that I do not want to make the actual eye value larger or smaller as a function of camofladge.   Specific eye values to me are about distance, not camofladge.  In my mind, camoflage impacts whether a bot is seen or not, not how far away it appears to be if it is seen.  So, my proposal would result in the eye either having the same value it would have had were there no camoflage or 0 but not something in between.

Now, let me just head off an objection I know some people might make and that is that instead of just inventing a substance and making it work magically under the covers we should instead invest in lower level environmental artifacts such as color, texture, etc and allow camoflage to emerge out of this richer notion of vision.  For example, making it harder to see bots of a given color or testure against the background of a shape or the field itself of a similar color or testure.  

I'm all for this notion of camoflage and I hope we have it someday, but it predicates a bunch of stuff that doesn't exist today and will be costly from a cpu cycle perspective (e.g. a richer vision system, computing the visibilty of a bot against a background, etc.).  Personally, I'm most interested in spending cpu cycles evolving interesting behaviour, not sensory machinery, so I take the position that my proposal could encourage the evolution of interesting behaviour in this area today with neglible perfromance impact (e.g. did I really just see something?  Let me get closer to check even though I don't see anything now.  Oh no, here comes a peditor!  Quick, spend a bunch of nrg to create camo while fleeing or hiding in plain sight.  and so on...).

Additionally, my proposal is in keeping with the way such things as .shell or .slime work today.  While we want to have richer underlying facilities underlying such artifacts someday, we haven't yet invented mechanisms (for eaxmple) for aquiring calcium or other minerals and for creating an internal shell manufacturing process, a process for depositing substances on the outside surface or the bot, physics for different substances interacting with and potentially deflecting shots and so on.  We just made .shell work magically through a single sysvar.  I want the same thing for .camo, at least until things get rich enough to let it go.

The perf impact from this proposal would be neglible.  

Comments?

53

Suggestions / Tie sharing affects

« on: November 30, 2007, 12:05:27 PM »

I've considerred making nrg that flows through ties subject to the same body and waste side effects that nrg shots have.  Downside is impact on multibots where ties arn't preditory.  Not sure what to do if anything.  Suggestions in this area welcome.

54

Bugs and fixes / How to report a bug

« on: November 26, 2007, 11:56:12 AM »

What follows are some Best Practices for posting bug reports.  Following these recommendations will help the devlopers do a better job and may help you determinine if what you are seeing is actually a bug or not before you post it.  In the end, if you are in doubt as to whether what you seeing is actually a bug or confused by these recommendations, post it anyway.  We would rather see some incomplete information than miss something.  

First, is it really a bug?  Do a little research before posting a bug.  How is it supposed to work?  Have recent design changes changed how you think things should work?  Could it be a problem with your DNA?

Do some investigation before posting.  Find out as much as you can about the problem and put it in the bug report description.    If the problem is with a specific sysvar or with DNA execution, take a look at the bot's execution via the bot property dialog.  Is the gene firing?  Is the memory location value what you expect?  If a crash, can you make it happen again?  How?

Try to narrow down the scenerio to reproduce the problem.  Does it happen every time or only in certain circumstances?  Can you demonstrate the problem with a simple gene or a specific sim?

Choose as specific a title for the bug post as possible.  Titles such as "My sim doesn't work" arn't nearly as helpful as something more specific like "Reproduction fails when .nrg < 100".

Attach a sim file.  This is important.  A sim helps the developers see what settings you are using and other aspects of the environment: other bots, shapes, costs, etc. all of which can have an impact.  If the bug is a crash, an error.sim should be generated.  We need that.

Include the program version in the bug post.   We have to know what version you are running.  The bug may have been fixed already in a newer version.

Regress the bug.  Bug reports go through a life cycle.  The developers will edit the bug title to indicate which stage in the life cycle the bug is in currently:

No changes to Title - Developers haven't had a chance to look at the report yet.
OPEN - Developer(s) have looked at the bug.  Looks like an actual bug or developers don't know yet.  Some additional information may be included at this stage.  The most common is:

[blockquote]NEED REPRO  This indicates the developer needs more information FROM YOU to reproduce the bug.[/blockquote]
RESOLVED - Developer(s) think the bug has been addressed.  There are several ways bugs can be addressed:

[blockquote]FIXED - A code fix was made.  In such cases, a version number with the fix will be indicated in the title.
NO REPRO  The developer can not reproduce the bug and attempts to ask for more information have not resulted in enough information to reproduce the problem.
WON'T FIX - This indicates the developer(s) agree this is a real bug, but one that won't be fixed.  It may be too complex or involved to fix or there may be other limitations with the development environment or the programmer's skills which prevent the bug from being addressed.
BY DESIGN - This indicates the behaivour indicated in the bug report is by design.  It is how the program is actually supposed to work and no code change is necessary or forthcoming.
NO BUG - This indicates the post doesn't actually indicate any problem.  Surprisingly, we do get these occasionally![/blockquote]

CLOSED - A bug moves to this state when the original bug poster has regressed the fix (verified that the problem has really been addressed) and agrees that the problem has in fact been addressed.  IT IS YOUR RESPONSIBILITY TO REGRESS BUGS YOU FILE AND EDIT THE TITLE TO INDICATE THEY ARE CLOSED once you verify the bug has been addressed.  If you feel the bug has not been addressed in the indicated version (or for example, if the developer resolved the bug "no repro" or "by design" and you disagree) you should edit the title and change "RESOLVED" back to "OPEN" and post a reply to the topic with an explanation.

Thanks for your help in inproving the quality of Darwinbots!

55

Tips and Tricks / What do the different Internet Mode icons indicate?

« on: November 19, 2007, 01:12:27 PM »

Internet Mode allows many different instaces of DB running on different machines on the internet to connect together into a single virtual "megasim".  A special randomly moving Internet Teleporter sends local bots it encounters (transported as *.dbo files) to a common server via the FTP protocol and in turn downloads a random set of bot files other simulations have uploaded.  Downloaded bots are then loaded at random positions in the sim.

Bots are teleported out at the moment they encounter the teleporter, but they live in a local folder on the local machine until the actual syncronization with the server occurs.  This happens periodically every few minutes.  In no case will this happen more frequently than every 100 cycles.  For faster running sims with higher cycles/sec, the code will wait a longer number of cycles to perform the upload and download.  The idea is to make it fair and well distributed for both large and small sims and somewhat indepedant of sim executon speed.

Up to 10 bots will get downloaded at each syncronization event.  Up to 10 staged bot files (teleported out in previous cycles) will be uploaded at each event.  But only up to 9 bots will get teleported out by the internet mode teleporter between sync events.  If more than 9 bots encounter the teleporter between syncronization events, the teleporter transforms into an intrasim teleporter until the next successful syncronization with the server and bots it encounters get teleported to other random places in the sim, not to the internet.  This insures that bots don't pile up waiting to go to the server when there are server connection or upload problems and if some do pile up, the local directories will slowly drain once the connection to the server comes back.

Each sim also uploads a "population" file at each sync event which lists the population of each species in the sim (if greater than 0) currently as well as downloading the popualtion files from all the other sims.  The information contained in these files are what popualates the Internet Mode Species and Sim population graphs.

Things don't always work perfectly.  Server or network problems, permanent or transient, may occur at any stage and the code is supposed to be resiliant to this.  Only a some of the files might get uploaded or downloaded in each sync event, another sim may have a file open at that moment preventing it from being uploaded or downloaded and so on.  The icons on the Internet Mode button are designed to give some high level indication of what is going on when connection problems or file transfer problems occur.  

The computer in the forground represents the local machine, the one in the background represents the server.  When both are green, everything is working as it should as far as the code knows.  When the local server is orange, it means that more than 9 bots have been teleported out for this sync event and the internet teleporter has changed to intra-sim.  When the server is red, it means there is no connectivity with the server.  When the server is orange, it means there is partial connectivity.  Not all files may have been downloaded last cycle or similar.  The Internet Mode log window gives more details on what exactly went wrong.

Unless the server is truly unavailable or there is some other serious network problem, connection issues should be transient and fix themselves over time.

56

Suggestions / .shotspeed

« on: November 18, 2007, 04:28:13 PM »

Kind of think shot speed should be under the control of the bot.  I'm all set up in the code to do this.  Would probably make the cost polynomial like .shootval.

Thoughts?

57

Suggestions / Increase the tie limit

« on: November 18, 2007, 04:24:39 PM »

Today a bot can have up to 10 ties (I think it's actually 9 from looking at the code).  This is all ties - ties they create, ties others connect to them, etc.  10 max total.

I propose effectively removing this limit.  I'll make it 100 or similar.

Now, I appreciate arguments along the lines of multibots using up all the ties to their own cells as a defense against tie feeding like Helios did in the old days.  But I envision a day not too far from now where ties are visible, we have tie collision detection with bots, tie fuild resistance, etc. so that the limit for whether a tie can be created between two bots becomes a function of physics I.e. being able to see the bot, having a clear path to the bot for the tie, having room ont he bot for the tie to connect (maybe) etc.  So I see increasing the tie limit as a step down this road.

Opinions?

58

Suggestions / Make body<->nrg conversion limit a function of size

« on: November 18, 2007, 04:15:57 PM »

Today there is a hard limit of 100 nrg equivalent on the amount of nrg that can be stored to body or body converted to nrg per cycle.  Bots can loose much more nrg than this per cycle to preditors, costs, etc.

I propose making upper limit on nrg<-> body conversion be 100 nrg equivalent or the nrg eqivalent of 5% body, whichever is greater.

Thus, a bot with a body of 100 would be able to convert up to 100 nrg per cycle to body and vice versa as today but a bot with 1000 body would be able to convert up to 500 nrg to body per cycle or more importantly, convert up to 50 body per cycle to nrg.

Opinions?

59

DB Art / Lionfish 3 and Nano battle it out in Internet Mode

« on: November 17, 2007, 05:59:14 PM »

A big LionFish 3 locked in battle with several hundred Nanos in Internet Mode.

60

Bugs and fixes / Tieports and multiple ties RESOLVED 2.43r

« on: November 13, 2007, 12:06:07 PM »

I'm no tie expert, but I'm in the code now and there are some fuzzy areas I'm trying to address.  Here's what I'm doing for tieports and multiple ties.  Please comment if you like.

So, two or more ties can have the same tie port.

Lets say my code does:

.tie inc

and creates three ties to three different bots over the course of several cycles.

I will have three ties each with a tieport of 1.

.tiepres will be 1.

.numties will be 3.  .numties will always reflect the number of ties I have, whether I created them or not.

.tielen and .tieang will reflect the length and angle of the last tie created or connected.  If the last tie of the three gets deleted, .tielen and .tieang will change to reflect the length and angle of the second tie created.  Same with trefvars.  Same with .tieloc and .tieval and any tie related sysvar that only operates on a single bot on the end of a specific tie.

On the otherhand, sysvars which act on ties themselves such as .fixlen and .fixang will be applied to all ties with the tieport specified in .tienum (or .tiepres if .tienum is 0).  Thus, I can set the length and angle of all three ties I created in one cycle (once they harden) if I so choose without using .tieang1, .tielen1, .tieang2, .tielen2, etc.
 
When a bot ties to me, the tieport of that tie from my point of view will be whatever .numties is at the end of the cycle in which the tie was created.  That is, if I have 3 ties that I created, all with a tieport of 1 and a bot comes along and ties to me, then my .tiepres will become 4 and .tielen and .tieang will change to reflect the properties of that tie unless the bot explicitly sets .tienum to 1 in which case they will shift back to the last tie created with that tieport, but only for that cycle unless the bot continues to store 1 in .tienum each cycle.

Note that if one of the three ties I created gets deleted in the same cycle as another bot ties to me, the .tiepres of that tie will be 3, not 4.  But once the tieport of that tie is set, it will not change even if all the other ties go away.  It will remain 3 even if I delete all ties with tieport 1 and .numties drops to 1.  I better catch it (using .tiepres) before another tie to me happens (and changes .tiepres) if I ever want to address that tie.

Chime in if I have things wrong...