Topics

151

Suggestions / New Cost coming in 2.42.2

« on: April 09, 2006, 02:40:34 PM »

I've implemented a new cost for 2.42.2 (release should be out this week) which deserves some explanation.

Costs provide selective pressure.  Without them, everything would be free and environmental selection at least wouldn't work but what we and/or the system decide to tax pushes selection in certain directions.  Charging costs per DNA bp or cond statement or store operation or .body upkeep provides selective pressure for bots to become more effecient w.r.t. their usage of these things.  Similarily, charging for behaviours such as shots or ties selects for more judicious use of these tools.

But it you want to encourage complexity without such restrictions, to put absolutely no restrictions on DNA length and all the various wacky different solutions to being alive yet still provide environmental selection pressure to cull the ineffecient and keep populations down to where the system runs reasonably, then IMHO at least, what we were missing was a cost which taxed mearly being alive.  Thus, if you use this cost and no other, then there is no downward selection pressure on DNA length or body size or shot formation, etc. yet there is selective pressure to be effecient, to do something to gain energy and perhaps reproduce before your time runs out.  Of course, if you want to tax these other things instead or in addition, well, that's fine too.

So, it's simply a cost of nrg per cycle for mearly existing.  The default is 0 of course and it is 0 in F1 mode.

-E

152

Bugs and fixes / Should Memory shots obey Shot Formation cost?

« on: April 09, 2006, 01:19:43 PM »

Positive valued shots currently don't cost anything (2.4x).  That is, they do not currently respect the Shot Formation value in the costs dialog.  I tracked this down.  The line to actually subtact the shot cost from the bot's erngy was inside an IF statement for -1 shots and never gets executed for postive shots.  I've changed it as below.

Case Is >= -1
    shtype = shtype Mod MaxMem
    If shtype = -1 Then
      If rob(n).Multibot Then
        value = 20 + (rob(n).body / 5) * (rob(n).Numties + 1)
      Else
        value = 20 + (rob(n).body / 5)
      End If
      value = value * multiplier
      'rob(n).nrg = rob(n).nrg - cost
    Else
      rngmultiplier = 1
    End If
    rob(n).nrg = rob(n).nrg - cost ' EricL Moved this here from above as postive shots weren't costing anything
    newshot n, shtype, value, rngmultiplier
  Case -2......


I assume my change is the correct one, that all shots should respect the Shot Formation cost, but since this is a core change, I thought I would be explicit.  Does anyone have any objections?

-E

153

Evolution and Internet Sharing Sims / South Pacific Sim

« on: April 07, 2006, 02:46:17 PM »

Looking for stress and stability bugs in 2.42.1, I needed to construct long running sims (> 1M cycles) at the largest field size where I could have complex bots with lots of mutation evolve indefintly without runaway selection or other short-sighted adaptations causing the entire sim to go extict - a common occurance in some of my previous evo sims where bots evolved to kill off all the plants or became canibalistic, forgot about plants, and killed each other off.

I also wanted to try to keep the bot population somewhere around 1000 or so; low enough to keep things moving fast and not bump up against the artificial 5000 bot limit but high enough to get some real population variation and mutation in different directions.  Additionally, I wanted population isloation.  That is, to set up an evironment where speciation would occur.  I wanted enough isolation that it was difficult, but not impossible for bots to migrate from one local ecosystem to another without using walls.

The solution was to create a veggy "chain of islands" not unlike the Pacific Ocean Island chain.  What I did was use a small number of very high energy, stable, fixed veggies - no more than 25 or so for the largest sim size and strung them out across the screen.  Each "island" provided essentially infinite food, but physical access to that resoruce is limited by space.  Each island is far out of sight form the other, so bots have to balance staying put and competing for a limited resource versus venturing out into the blue and taking their chances on finding a new undiscoverred resourse in some random direction.

I wanted to favor DNA complexity, so I removed all the costs on DNA operations so that having a longer DNA or executing more genes is not in and of itself disdvantageous.  But I had to tax something to provide selective pressure so there is a body upkeep cost of 0.1 per cycle as well as costs on things like venom and shell.  This way, DNA complexity can evolve and selection favors action effeciency.  They have to eat, they to have to find food and compete for limited resources or they will die.  The genes they use to do that can be as many or as complex as they need.  Generally a bot with typical energy can live long enough to reach the next island if they happened to set out in the right direction, but if they didn't, leaving your island tends to be fatal.

The limited number of veggy islands, the restrictiosn in physical access to these resources and the body upkeep cost tends to keep the population between 1000 and 15000, about where I want it.  (I actually had to increase the body upkeep cost over the first few 100,000 cycles as bots got more effecient.)  Sometimes a population spike or fall off will occur as a bot evolves cannabalistic tendencies or some other new short term strategy that gives individuals massive advantage in the short term, but if such an adaptaion is disadvantagous for the species and ecosystem (will leads to extinction relatively quickly) it won't spread to all the islands due to the time and cost it takes to do so.  Island populations can go extict, but they get resettled eventually by populations from surviving islands which did not develop the fatal adaptation.   Thus, the sim as a whole never seems to die.  Things change, sub species change and evolve, and go extinct, but the sim as a whole lives on.

The Settings file is attached.  I'd attach the sim, but even zipped, its 818k...

-Eric

154

Bugs and fixes / 2.42.2 Changes

« on: April 06, 2006, 03:09:42 PM »

This topic is just a place for me to keep track of the changes I make from one version to another, in this case from 2.42.1 to 2.42.2.  It is not  the complete list of stuff in the next drop, just the stuff I have completed to date.  I will edit this post as I complete changes and start a new topic for each new release.

1) Body, Venom, Shell and Slime now displayed in bot properties dialog.   (Yes, you can get these through the console, but having them in the dialog is more convienent and as these are already calculated, there is no computation cost and it only takes about 4 lines of code to display them, so it's easy to do.)
2)  General cosmetic cleanup of bot properties dialog (grouping fields into logical groups, some field alignment.)
3) The tool tip text of a label in a graph now displays the last graph datapoint for that series.  Simply hover the mouse over the label to display the value.
4) Overflow protection in ManageBody() .  Added the following line:
  If .BODY < -32000 Then .BODY = -32000 'Ericl 4/6/2006 Overflow protection.
Not certain how it happened, maybe something to do with altzheimers, but I caught a crash and traced it back to here where .BODY was < -2^15 so I added this protection.  Does not address whatever the underlying issue is, but prevents the crash.
5) Added similar protections against large magnitude negative sysvar values in VoluntaryForces which limits the magnitude of the resulting calculated acceleration vector to 40 and limits the energy cost to be between -100 and +100.
6) Added a COND flow statement counter in ExceuteDNA() so that rob(n).condnum now actually gets updated.  There was no code to keep track of this before, which is why the "number of cond statements" graph never worked.  It works now.
7) ExecuteDNA now updates rob(n).genenum correctly for the robot with the focus.  This means that "number of genes" now displays correctly in the robot properties dialog.
The "Bot Insertion" dropdown was not getting populated after loading a sim.  The work around was to open the Options dialog then hit the Change or Start New button.  Added code in simload() to populate it directly from the loaded sim info so that this is no longer necessary.
9) Moved the initialization of SimOpts.TotRunCycle from StartSimul() to OptionsForm.Startnew_Click() so that changing the settings for a sim no longer zeros out the cycles counter in the status bar.  Only starting a new simulation will zero the counter.  This is a personal preference thing.  It did not make sense to me to reset the cycles counter when small changes are made to a sim such as tweaking the number of veggies.  Let me know if anyone has strong feelings the other way.
10) Cleaned up graph titles
11) Age graph now in displayed in hundred's of cycles.  Previously, since max graph value is 32000, any bots older than 32000 cycles would just be topped out.  Now displays ages up to 3,200,000 cycles.
12) 'Reset All Graphs' in the graph dropdown now resets the graphs immediatly instead of waiting until the next update interval.
13) Memory shots now respect the value in Shot Formation on the costs dialog.  Memory shots were free before.
14) Removed an entire loop in the core routine UpdateBots() which simply checked for value overflows (.nrg > 3200) by combining it with the loop above.  Shoudl not have any impact on logic, but should have a small (positive) improvement on perfromance.
 See #20 Below
16) Addressed crashing bug where Mutations button was pressed on Species tab of options dialog without first selecting a species in the listbox.  Now a msgbox is presented which requests that the user select a species.
17) Fixed another overflow bug where a bot fully loaded with venom takes a high magnitude venom shot FROM A CONSPEC.  The venom shot got added to the bot's own and tucked into the mem array without a check for overflow.  I've now added a check, venom will now get clipped at 32000 in such cases.  It should be noted that in the case of conspec venom shots, shell is not factorred in.  That is, a bot's shell has no impact on conspec venom shots currently.
18) Added initialization code for the DecayType control in DispSettings() so that its value gets displayed correctly when the options dialog is opened.  DecayType was getting saved and loaded from settings and sim files correctly, but the value of the radio button array on the dialog was not getting initialized correctly when the dialog was opened.
19) Changed the event which saved the value of DecayText and FrequencyText into the TmpOpts structure from lostfocus to change.  Not sure why these guys were hooked to the lostfocus event, but this is why the values of these controls only got saved into the TmpOpts structure (and thus saved into settings and/or sim files or persisted across dialog invocations) when you clicked away BEFORE hitting Start New or Change.
20) Added three new costs related to aging available on the Advanced Costs dialog.  The first, Age Cost (const AGECOST in the code) allows the user to specify a cost per cycle in nrg to charge the bot.  The second cost (const AGECOSTSTART) in the code is less of a cost and more of a trigger value which determines at what age in cycles to begin charging the Age Cost.  The third (AGECOSTMAKELOG in the code) is a checkbox which specifies whether to increase the Age Cost over time by multiplying it by the log of the bots age.  These age costs replace the per cycle cost of being alive in #15 above.
21) Fixed a crashing integer overflow bug in VShoot() where a large value in mem(VshootSys) was being multipiled by 20.  This one took a long time to finially catch in VB!
22) Fixed total cycles count bug where TmpOpts.TotRunCycle was not getting initialized correctly from SimOpts.TotRunCycle when the options dialog was opened.  This meant whatever value was in TmpOpts.TotRunCycle got saved back into the SimOpts structure when Change or Start New was clicked, which reset the cycles counter back to the last time the options were changed or a saved sim file loaded.
23) Added logic to check for older versions of settings files and special logic for lastexit.set and default.set.   Program will now refuse to load older settings files and will display an appropriate warning message.
24) Removed the limits keeping rob(n).age capped at 32000.  It was already defined as Long in the robot structure.  Now it can rise above 32000.  The sysvar robage will still top out at 32000 in the mem array as it is Integer valued, but the actual age of the is now accuratly tracked by the system.  I think this may also have addressed a problem with bots older than 32000 cycles not mutating.
25) The robot age in cycles is now displayed in the robot properties dialog (not the age in 100's of cycles) and it can rise aboce 32000.

155

Suggestions / Sim thermodynamics

« on: April 05, 2006, 12:53:24 PM »

I've run into a couple of other strange altzheimer's related behaviours recently (like high energy, high body bots suddenly dying becuase their nrg or body was set to negative ) and a crash in a different area having to do with a huge negative value in .body.  All are the result of altzheimer's writing wacky values into a set of key locations when waste gets high.

I do not think it is the right thing for Altzheimers to be able to permanently change bot memory locations which are really state information "about the bot" (like .nrg, .body, .mass, .waste) maintained and set by the engine as opposed to information set and maintained by the bot, as means of for contoling it's behaviour or interacting with its environment - .dn, .aimsx, etc.   Allowing the former lets altzheimers  go beyond it's purpose IMHO, to go beyond making the bot act "funny" due to internal waste build up and instead adversely impact what I will call the "laws" of the sim - for example, the law of conservation of mass/energy.

Ignoring the crashes for a moment, do we really want a build up in waste to cause a bot with 32000 body and 32000 ernegy to die suddenly in one cycle and take all that energy out of the sim in one cycle?   Do we really want altzheimers to suddenly and magically give low energy bots massive energy or suddenly make a scrawy bot instantly massive?   Where did that energy come from?  Where did it go?  Altzheimers has the ability to magically invent it and destroy it.

I put forward the premise that energy/mass in a sim should be conserved.  Energy should only enter the sim via sunshine on veggies at the rate specifed and only leave via utilization - movement, shots, DNA execution, whatever.  The more I think about it, the more I dislike the notion that energy can be magically added or removed by Altzheimers.

I suggest that memory locations which constitute engine-maintained state about a bot should be off limits to Altzheimers.  

Comments?

-E

156

Bugs and fixes / Need your input on a fix

« on: April 03, 2006, 09:36:07 PM »

So, this is a crashing bug I've been working on for some time.  I think I have the root cause, but I need some advice on the right fix.  FYI, debugging this one is very invovled and catching it in VB and then backtracking to the root cause has been a real pain.  I probably have 3 or 4 hours into this one so far.  

The overflow occurs in the readtie() routine when the nrg of a tied bot (I'll call it botB) is being copied into the .trefnrg sysvar of botA.  At the surface, it looks like another simple case of a single being copied into a positon in the integer valued mem array.  But the tied bot's energy is often a crazy value, like -56000 or something.  This causes the overflow, but how could the tied bot's energy get so wacked?  Well, the calculation that is causing it is the vector arithmetic in VoluntaryForces().  When it calculates the energy usage associated with botB's voluntary movement, it can end up a crazy large (positive) value.  When that large value gets subtracted from botB's nrg, it goes way negative then when trefnrg is set in botA, things go boom.

Now, it appears to happen more often for older, massive bots (like .mass >200) because .mass is used as a multiplier in the energy usage calculations for voluntary movement.  Another symptom is that one of the direction sysvars (e.g. .up, .dx. etc.) is a huge value, like in the thousands or ten thousands.  This is what throws the vector math for a loop and results in the crazy high ernegy usage calculations.

So, this was really puzzling me.  I suppose another bot could be using venom to write really wacky values into .up, etc. or maybe the bot mutated to do it to itself, though I thought the code did a good job of policing those values and chopping them if they were excessive.  Then I noticed the waste on botB is sufficiently high to trigger the altzheimer routine.  So, what I suspect (though have yet to really prove) is that in the case where a massive bot builds up enough waste, random stuff gets stuffed into the mem array and this bypasses the special location limit checking and if that value has a large enough value independent of sign and is in the right mem location (like .up, etc) then the calculations lead to the crash.

So, I have a philospohical question.  I can prevent the crash, but what is the right behaviour for botB?  All the memory locations of a bot are not created equal.  In theory, they are all Integers and one could take the position that the altzheimer routine (or venom or a mutation or a virus) should be able to write any value from -32000 to +32000 into any location and the engine should just handle that and do what that means and if that means that a huge bot with lots of mass and energy gets it all used up in one cycle becuase the altzheimer random write tells the engine to try to accelerate .up at 30,000 then so be it.  Poof, a huge, healthy, otherwise well evolved bot takes a ton of energy out of the sim in one go just because it didn't take a crap - excuse me, manage it's waste correctly (I think this is happening today).  Or, should I try to police "special" locations in the mem array from the altzheimer routine and potentially other ways crazy values can get written by limiting accelerations to between 0 and 1000 (as it indicates in the wiki), limiting energy loss to 100 max per cycle, etc.

I hate special cases and privledged locations and special code to police magic numbers, but I do think I want to do the latter.

Any and all advice is welcome.

-E

157

Announcements / 2.42.1 available

« on: April 02, 2006, 11:10:48 PM »

Okay, 2.42.1 is out on the FTP site.  I beleive that all of the issues raised by Testlund and Griz in this thread are addressed (with one small execption listed below).  Hopefully, I managed not to screw anything up this time.

I did not do an exhaustive test pass on the round-trip-ability of every last setting, in particular I have not tested settings associated with areas I have not played with or are known not to work such as database logging (the former) or leagues and internet organism sharing (the latter).  However, I did test the rest of the settings fairly thoroughly.  If you find a setting that is not roundtripping through sim or settings files, please let me know after reading note #2 below.

IMPORTANT NOTE #1:  2.42.1 fixes some really bad bugs in saving and loading to/from sim and to a lesser extent, settings files.  Everything should work just peachy for newly created files, but I CANNOT GAUREENTEE THAT OLD SIM or SETTINGS FILES WILL LOAD CORRECTLY.  I didn't knowingly break anything and I did do some testing with old files and I think most files should work fine but the code was just plain broken before (though it was pretty far down the file, so most stuff is still in the same spot) so it is possible that the settings you get when you load an old file may not reflect what you think they should be.  What's more, it's possible DB could crash (right there at load time, not later, at least, not later for any reason having to do with sim files) due to the differences in positional formatting of old and new files.  In a few cases I actually added code to avoid certain problems with loading old files (like divide by zero crashes where a zero is now being read in unexpectedly now that the positional loading is "correct") but I could have missed some cases.  Anything you manage to load or set explicitly and then save should be fine from that point on and saving it again should create a correctly formatted file that should re-load just fine.

EDIT: Please read the README file.  You will need to replace your default sim and settings files with those included in the download and also delete your lastsave.set file.

IMPORTANT NOTE #2:  In some cases, settings are not round-tripped through saved sim files BY DESIGN.  This is the case for example, in the path names for recording files as well as the database name for database recording.  The intent I presume is not to overwrite potentially important previously recorded sims by accident.   I did not change any behaviour where there was code to explicitly avoid round-tripping of such settings so these settings not round tripping is not a bug.

The small exception listed above is the issue Griz mentions with the color selection dialog coming up unsummoned when bots with custom colors are selected in the species list.  I didn't really investigate this and don't know if there is a bug here or not.  If people find it annoying, I can do something about it in the next drop.

For those interested, the issue with the restart when all bots are dead checkbox was a reversed expression in the restart dialog initialization routine where TmpOpts.restart was getting assigned to RestartMode and it should have been the other way around.  This was the reason that 1) it wasn't working and 2) the setting was not being preserved.  The issue with the recoding every X minutes sim and bot settings both having the same values had to do with a problem initializing the control's text values - both values got set from the same value.

Have fun!

-Eric

158

Announcements / 2.42.0 Now Available

« on: March 31, 2006, 08:09:07 PM »

Lots of good stuff including:

Several fixes to some really nasty stability bugs and crashes.  This version should be pretty solid for extended sims.
Several crashing or other serious problems with loading saved sims addressed.
Mutation values are now reloaded from saved sims correctly.
Settings now change to match a loaded sim.
Lots of graphing improvements including cofigurable update interval and "update now" button.
Graph colors now match bot colors.
error.sim outut is enabled on crashes.
Various other little fit and finish changes.

For a special treat, try clicking and holding down (not scrolling) the mouse scroll button over some portion of the field...  :)

Not included but coming in 2.43.0 (say, by mid April maybe)
  Internet Organism Sharing  
  Leagues

Please report bugs as always.

My thanks to the administrator who moves this post to the annoucements forum.

Enjoy!

EricL

159

Off Topic / I just have to know...

« on: March 30, 2006, 01:58:15 AM »

DB appeals to such an interesting mix of backgrounds that I thought I would do a poll...  Just choose the one that is closest.

160

Bug reports / Working on 2.42.0

« on: March 29, 2006, 09:42:21 PM »

I've been working towards a new drop of the VB version.  Will probably show up this weekend or next week.  Here's what I've fixed so far:

Saving and loading settings with field sizes > 8 was broken.  DB saved a long but was trying to load it into an int.  Overflow crash.

Loading a sim from a file now changes all the settings to match the values in the sim.   Allows for easy tweaking without having to manually set everything.

Lots of misc. fit and finish changes in charting.  They update immediatly upon opening, the lines fit in the chart space correctly, resizing charts works correctly, etc.

Chart dialogs now have an "Update "Now" button which will refresh that chart (and that chart only) immediatly without having to wait the built-in 200 cycles for another data point and refresh.  You can ust click away if you want a bunch of data points right now.  (I'm not planning on adding many features on the 2.4 VB fork, but this was easy and I kind of wanted it so I did it.)

Various overflow and stability fixes.

A few other non crashing fit and finish things:  The Mutation rate slider works better, the Edit menu items invoke the options dialog at the right tab setting and so on.

error.sim outlput enablement in the compiled version.

[you]Things I'm still working on that will probably be in the next drop:[/you]
A couple crashing bugs I'm still working on plus any others reported that I can find/fix.
The issue with mutation being off after saving.
A configurable chart update interval.  This is easy enough that I'm goign to just do it.
Internet Organism Sharing  (I want this!)
More fit and finish stuff.  If it pisses me off sufficiently, I will spend time to fix it.

[you]Things I'm working on that probably will NOT be in the next drop:[/you]
Leagues
Locality-based mutation experimentations.  (personal project)

If you have other priorities, let me know.  My philosophy is to drop a release once there is enough in it to justify people moving to it.

-E

161

Announcements / Version 2.41.0 now available

« on: March 23, 2006, 01:16:36 PM »

Version 2.41.0 is now available on the Download Page.  This version includes all my fixes made to the 2.4A version to date.

I plan to contiune to fix bugs as they arise (although perhaps at a more measured pace) so please report any bugs in the Bug Reporting Forum.

162

Bugs and fixes / How are leagues supposed to work?

« on: March 21, 2006, 01:51:45 AM »

Text Deleted.  Never mind, I think I can figure it out from the source.

163

Suggestions / What do you want fixed in 2.4?

« on: March 20, 2006, 01:12:41 PM »

While work proceeds on the C++ version, I'm going to be spending a little bit of time on 2.4 fixing bugs which will probably culminate in a 2.4B download at some point.  I'd like to know what you want fixed.  If there is something in 2.4 that bugs you, a crashing problem perhaps or some functionality that doesn't work quite right, please post it here and I will add it to the work list.  What I'm really looking for is an indication as to how important it is to you relative to other problems in 2.4 so I can prioritize.

Note that this is not the forum for full bug reports.  You don't have to give me tons of details here (but please referance the posting in the appropriate bug reporting forum if there is one).  This is just the place to post one sentence things of the sort "If this only worked in 2.4 I would buy you a case of your favorite beer and move off of 2.37.6 forever..."

164

DNA - General / Tie question (2.4A)

« on: March 19, 2006, 10:30:06 PM »

If I sucessfully shoot a tie during the execution of my DNA on cycle n, should *.numties and the *.tref sysvars be updated and able to figure into cond statements during the n+1 cycle?

I'm seeing behaviour in 2.4A where I shoot a tie, it suceeds, but *.numties, etc. don't get updated in time to be used in the following cycle.  They update for the n+2 cycle.  This makes my tie shooting gene which is conditional on numties fire twice.  

Looking through the code, I see that FireTies() is called pretty late in the cycle, after readtie(), which updates the tref sysvars and Update_Ties(), which updartes .numties.  So, at the end of a cycle, new ties may have been sucessfully created during that cycle, but that information is not yet reflected in the bot's memory arrays.  

Then, on the next cycle, ExecRobs() (which executes the robot DNA and evaluates the gene cond statements) is called pretty early, before readtie and Update_Ties get a chance to update the bot's memory with the tie results of the previous cycle.  This means that it takes 2 cycles before .numties, etc. read correctly.

Bug?

-E

165

Bugs and fixes / Fixed Console Crash in 2.4A

« on: March 19, 2006, 02:23:41 PM »

This was bugging me so I fixed it.  2.4A crashes with an error '91' if you attempt to execute a command in a console window that was opened on a bot that has since died.  The routine evnt_textentered() in console.frm did not check whether the robot's console was still valid.  I added a check (line 173 in console.frm).

Additionally, I added a line in KillRobot() in robots.bas to indicate in the console window when the robot for that console has died.   (line 1461 in robots.bas).

Source modules attached.  To find changes, search for the string 'EricL'.

-E