Topics

136

Announcements / Version 2.42.5 Released

« on: May 26, 2006, 01:19:51 PM »

Version 2.42.5 is now available!

Direct Download Link.

Major Changes /Features:
Shot collision detection completely re-worked.  Numerous issues with return energy shots, small radius bots, shot ranges and so on addressed in this version.
New sim energy calculations displayed on tray and a new energy graph added (See Below).
The .stifftie sysvar has been (re)implemented.  There are now no *known* compatability issues with 2.37.6.


A detailed list of the changes from version 2.42.4 can be found here.

A few words about 2.42.5.
Shot collision should now be bulletproof (pun intended).  If a collisoin should occur, the code now correctly detects a collision, even for fast moving shots and small radius bots.  Fast moving shots should no longer be able to pass through bots in a single cycle to hit those behind, returning shots should now have the same effective range as those that initiated them and they should correctly begin their retrun journey from the point of impact.  Be aware that the graphic radius as drawn for bots can be shown as slightly larger then the reality so shots which are displayed as passing through the very edge of a bot may, correctly, not actually impact in the underlying physics.  

The new shot collision detection routine is more accurate and correct then the previous, but also more CPU intensive.  Additionally, the "lifespan" of returned energy and body shots was doubled (their speed is half that of the initiating shot) so they hang around twice as long, increasing the average number of shots in a sim at any given time.  The shot collision code is sensitive to the number of shots in the sim, so these two things may decrease the performance of sims with lots of shots (the tray now displays the total number of shots in the sim).  I have done the best I can at speeding it up (and this version includes several other performance improvements in other areas designed to offset this) but anyone who wants to take a look at the routine and suggest ways to improve it is welcome to do so (NewShotCollision() in the Shots Module).  It is very well documented, so people should not have too much difficulty folowing what I did.  One of my goals for the next version is to do some profiling and make further performance improvements.

Note that I also changed the way cycles/sec is calculated so that it is now averaged over the past 10 seconds instead of being a snapshot of just the past second (it therefor may read funny for the first 10 seconds of a sim, either new or just loaded).  This gives greater accuracy and resolution, particularly for larger slow running sims with cycles/sec in the low single digits or below 1.  Additionally, I handle timer events in a lot more places in the code then before.  This makes the UI more responsive and the timers more accurate so, again, especially for large, slow sims, the running time should better reflect reality.  But this also may have the effect of displaying a lower cycles/sec than before.  The sim may not be running any slower, it's just that cycles/sec is actually be calculated more accuratly.  Note that running time still runs slow relative to real time.  The whole way time and timer events are handled needs to be improved.

Lastly, the total energy in the sim each cycle is now displayed in tray along with an "Nrg Ratio".  The goal here is to give you some idea of how much energy is flowing into and out of the sim each cycle.  The Nrg displayed is the sum of all the energy and body (* 10) of all the bots in the sim at the end of the last cycle.  Energy tied up in shots is not included until it is absorbed by a bot.  Additionally, other forms of converted energy such as venom, posion and shell are also not included in the calculation.

The Nrg ratio is the ratio of the past cycle Nrg value over the average of the sim energy over the past 10 cycles.  If the ratio is >1, the net energy in the sim is increasing.  If the ratio is < 1, the net energy is decreasing.  Note that events such as veggie repopulations can bring an enormous amout of new energy into the sim in a single cycle, playing havoc with the "smoothness" of the ratio calculation, so be sure to wathc for this if you are using this to try to maintain a certain energy average.  Additionally, a new graph is now available which plots the total energy of each species over time.  This can be used over longer periods to examine net energy flows and smooth out the massive inflows from re-population events.  

As always, please bring bugs or other isuses to my attention.

Once again, and especially now that .stifftie is (re)implemented, I will also renew my call for people to test bots, especially multibots, from 2.36.7 and bring any behavioural differences between the versions to my attention.

Enjoy!

137

Bugs and fixes / Got bots that behave differently in 2.37.6 and 2.42.4?

« on: May 15, 2006, 12:09:20 PM »

After fixing serious bugs such as crashes, my number one priority for continued work on the 2.4 code fork is closing the gap on issues with bots which work in 2.37.6 but which do not work in 2.42.4 or which behave radically different in that version.

To that end, I am soliciting examples of such behavioural differences.  If you have a gene or bot which works in 2.37.6 but does not work in 2.42.4 or which demonstrates significant differences in behaviour between the two versions, please reply with details to this topic.

Please be as specific as possible.  I'm happy to go get bots from the beastiary and run them in the two versions myself and read the DNA and reverse engineer what it should be doing and what it is actually doing, etc. but that takes time, time I could be using writing code or fixing bugs and I'm only one guy.   So, the extent to which you can help me out by pointing me to the specific differences or ideally to the actual DNA area or sysvars which behave differently, that would be much apprecated.  Uploaded sims which illustrate this are of course, much apprecaited.

Also, 2.42.4 fixed a bunch of things, so please use that version and not previous versions of 2.4 for your testing.

Known issues with 2.42.4:

.stifftie is not yet implemented.
.fixlen and .fixang work, but multibots which rely upon specific tie physics for crawling or using tie length for acceleration, etc. probably behave differently.  Please report such differences.
I have not personally tested .tielen1-4 and .tieang1.4 so they may or may not work in 2.42.4.  Specific help here requested.
Viruses have been reported to work in 2.42.4, but I have not tested them.
I am still investigating issues with retruned energy shot ranges and small bot evaporation.

Thanks for your help!

138

Bugs and fixes / 2.42.5 Changes

« on: May 15, 2006, 11:09:55 AM »

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.4 to 2.42.5. 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.

If you have feature requests or bug reports for this version, please report those as separate topics.

1) Fixed a divide by zero problem with virgin installs.  In the case where recent builds (post the fixes to settings file formats) are added on top of a virgin 2.11 install and no LastExit.set exsits, the chartingInterval parameter was being incorrectly read in from default.set as 0 causing a divide by zero error.  Not a great first time expereince.  This had been fixed previously in the sim file load path, but not the settings file load path.  Now when 2.42.5 is installed on top of a virgin 2.11 install, things work as expected.
2) The simulation option MaxVelocity was not being saved or loaded from sim and settings files.  Now it is.
3) If you run a sim that was saved on a different machine with a different installation path or you don't have the robot txt files for that sim on your machine, then when the engine needs to load new bots (as opposed to bots reproducing) such as when auto-repopulating veggies, an endless series of message boxes could appear telling you the robot path is invalid.  These endless message boxes steal the focus and make it difficult even to close the program.  Now when a bot path is found to be invalid, the path is set to "Invalid Path" and the code checks for this to avoid the endless dialogs.  Also added a different msgbox informing the user (each time) of the invalid path if adding such a bot manually is attempted via the insert bot dropdown.
4) Added some string manipulation for species path names in the sim load routine so that the pathes to bot files are now potentially modified to point to the local install point instead of whatever the main directory was on the machine where the sim was saved.   Net net is that if you load a sim from someone else and the sim needs the original bot text files (for example when you explicitly add bots manually or when veggies get low) the program will now look for a path relative to the local main directory as opposed to the path from the machine where the sim was saved.  Putting the appropriate bot files into your \robots directory should be enough to get things to work in most cases.
5) Added a new shot collision detection routine which takes into consideration both bot and shot motion, shots which pass completely through a bot in a single cycle and shots and bots of arbitrary speed.  See this topic for details.
6) Doubled the lifetime of returned energy shots and body shots to make their effective range in terms of distance on the field equivalent to the range of the shot that invoked them.  See the linked topic in #5 for details.
7) Fixed a bug where shot collisions on their last cycle of life where not being registered.
Fixed a bug where returning shots (of any flavor) were not begining from the point of impact but were instead beginning where the shot that caused them would have been at the end of the cycle on which the collision was detected.  See the linked topic in #5 for details.
9) Perf improvement in VectorMagnitude().  Removed an uncessary condition.
10) Perf improvement  in DrawRobAim().  Moved conditional to test for walls, etc. up front.
11) Fixed crashing bug when Cancel is selected from the robot file browse dialog.
12) Trimmed all the robot properties displayed in the robot properties dialog so as to display only 2 digits after the decimal place.
13) DoEvents() now called every 500 shots in UpdateShots() to make the UI more responsive during this very CPU intensive routine.  This should also help address issues with the sim time running counter and cycles/sec display not being accurate.
14) Added number of shots to the tray and general tray field sizing clean up.
15) Added condition in takenrg() and other shot routines so that walls and corpses can't absorb energy shots, waste shots, venom, etc.
16) The total energy in the sim is now calculated each cycle and displayed in the tray as is the "NRG Ratio" which is the ration of the energy in the current cycle to the average energy in the sim over the past 100 cycles.  Note that this ratio will be incorrect during the first 100 cycles of sim execution either for a new sim or one loaded from a saved sim file.  
17) As part of the process of adding feature 16, lots of violations to conservation of sim energy were discoverred and in some cases addressed.  Mainly, these are places in the code where a bot near the end of it's energy is allowed to shoot or give off a shot or otherwise perform some operation which requires more energy than it has.  The shot or whatever is created, perhaps with some default minimum (which could exceed the bot's energy level) and the bot's energy set to 0, resulting in a net increase in sim energy.   There are similar cases where a bot does not have enough energy to create a shot given the shotcost, or similarly perform other operations, but is allowed to anyway if their energy is set to 0.  The code still allows this in some cases, but the total energy calculation takes it into consideration.  Thus, while sim energy can be created this way, the energy total will reflect it.
17) Improved the cycles/sec counter calculation so that it now averages over the past 10 cycles, displaying a more accurate number, particularly in larger, slower sims.  Note that cycles/sec may be inaccurate during the first 10 seconds after a sim is loaded.
18) Added a new graph with displays the total energy for each species.
19) Implemented the .stifftie sysvar.  The specific underlying values for tie elasticity will likely need to be tweaked in subsequent versions.
20) Perf Improvement.  Modified CalcStats() so that graph data is only calculated for the graphs which are currently visable.
21) Small tweak so that now any negative waste threshold level, not just -1, effectively turns off altzheimers.
22) Perf Improvement.  TieHooke() and TieDragForces() now check for .numties > 0.

139

Announcements / 2.42.4 Now Available

« on: May 09, 2006, 12:45:22 AM »

2.42.4 is now available.  The list of changes from 2.42.3b can be found here.

Of particular interest in this release is multibot tie behaviour.  Ties now stiffen after 20 cycles (they didn't in previous versions of 2.4) and multibot tie commands such as fixang and fixlen should work correctly.  Multibots such as inchworm appear to work as designed in this version though there likely remain some differences in behaviour due to the different underlying physics of the two versions.  For example, bots which are sensitvie to specific tie stiffness nuances or the specific force exerted on a bot due to fixing a tie length or angle may appear to behave differently in this version and 2.37.6 even though the underlying sysvars are working correctly.  Please bring specific examples of behavioural differences between the two versions to my attention.  In particular, the Hooke forces for stiff and elastic ties will likely still require tweaking.

Note that the stifftie sysvar has not yet been implemented in this release.

Also in this version is a "fix" for the saved sim file corruption problem experienced when long running evo sims are saved with bots that have more than 2^15 bytes worth of mutation details.  This version should be able to read those sim files and save new ones with the potential for essentially infinite mutation details in a (mostly) backward compatabile manner without causing corruption.  See the above linked topic for details.

This version also includes several bug fixes (including fixes for the impossibly long tie bug, the kinetic friction bug and the problem where trefvars only lasted a cycle).  There is also some UI cleanup and a couple of new knobs to turn such as the coeffecient of elasticity for collisions.  Gene activations have also been added back into the robot console command window.  Lastly, this version now also provides a new menu item which allows you to save sim files without mutation details, greatly reducing their size for uploading.

Enjoy.  As always, please make me aware of any issues.

Direct download link

140

Bugs and fixes / The root of much Tie evil in 2.4

« on: May 07, 2006, 04:36:50 PM »

Prior to 2.42.4, stiffening a tie (and thus becoming a multibot) did not work.  The reason is that (as was the case with fixang and fixlen prior to 2.42.3) the code to listen to .stifftie (or stiffen ties over time) was simply never ported over from 2.37.6.  This of course, has been the root of all sorts of tie and multibot issues in 2.4.  If you can't stiffen a tie, you can't become a multibot (so I have learned) and lots of tie operations such as fixing tie angles and lengths depend on first being a multibot.

In 2.42.3, I (mistakenly) made it so that any bot with a tie instantly became a multibot without having to stiffen a tie first.  This combined with my porting the fixang code over allowed for certain tie operations like fixang and fixlen to start working for the first time but exposed some other issues.

I'm pretty sure the bug we see in 2.42.3b where impossibly long ties appear for a cycle and then disappear is a consequence of altzheimers writing a large value to .fixlen.   There was no parameter checking on .fixlen and thus becuase every bot with a tie was a multibot, for a cycle at least, a super long tie could be created and displayed before code earlier in the order of execution noticed and deleted the tie on the following cycle.  This was compounded by some underlying physics (having to do with natural tie length) which changed radically from 2.37.6 to 2.4.

I am making good progress on making all this work in 2.42.4, but I have some questions that stem both from my newbeness and from some physics changes between the versions.  I coudl take guesses and get them mostly right I think, but I have been bitten by going with my own assumptions in releases before, so my thanks in advance.  Answers to these will help me deliver the tie behaviour people expect.


Ties stiffen over time even without the bot writing to .stifftie?  How long should this take?  (I assume 20 cycles.)  Should this be progressive (I.e. should a tie be stiffer after 20 cycles then it is after 10?)  To what ultimate stiffness?  As stiff as possible?

Is stiffening a tie the only way to become a multibot?  I assume so.  If a bot does noto explicitly stiffen a tie, but it just becomes stiff over time, does it become a multibot?  I assume so, but when? After 20 cycles?

Should the birth tie stiffen over time as well?  I assume not.

Should the explicit operation of stiffening a tie to any value, even making it super springy, make the bot a multibot right then?  I assume so.  Should the bot be able to make a stiff tie more springy via .stifftie?  I assume so.

What is the maximum length of a tie beyond which the code should delete it? (Right now it is 1000)  Can the bot set a tie to be this length or only a more limited length?  (Right now, bots can only set tie lengths from 0 to 200).  What should setting a tie to length 0 mean?  What should the code do if negative tie lengths are attempted (say by altzheimers)? (Right now in 2.42.4 they equate to 0 and lengths exceeding 200 equate to 200.)

How strong should ties be?  Should bots be able to break ties via acceleration or centrifical force or collisions?  What about in the case where the bot has a high mass?  Right now they can.

Thanks in advance for your answers.

141

Bugs and fixes / 2.42.4 Changes

« on: May 04, 2006, 12:20:45 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.3 to 2.42.4. 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) Addressed the overflow issue with loading saved sim files which contain bots with mutation details strings whose lengths total exceed 2^15 bytes.  Details of the problem and the fix can be found here.  In breif, older corrupted files should now load in 2.42.4, but only the most recent 2^15 bytes worth of mutation detail strings will be loaded and the values of the few per-bot properties which follow the mutation details in the bot file format will be defaulted.  In some cases these default values may result in unexpected sim behaviour.  Sims saved in 2.42.4 are formatted such that older versions can load them (the mutation details will be lost for bots with mutation details >2^15 bytes and a few bot properties will be random as above).  Of course, if loaded with 2.42.4 or above, sim files saved with 2.42.4 or above will include all mutation details no matter what the length.
2) Backed out #8 in 2.42.3.  Multi should not be set until a tie hardens per PY here.
3) Added console-based gene activations ala 2.37.6.  Now, when the single cycle button or the play button is pressed in any open console window or on the main dialog, gene activations are displayed in the console window for each bot with an open console window.  IGene actications are not displayed during normal execution or when the cycle or play button is pressed from the main MDI window, even if there are open console windows.  See this topic for more information.
4) BEHAVIOUR CHANGE.  Fixed the problem with trefvars only persisting for a single cycle.  Now, as described in #10 here, the trefvars will populate automatically when a tie is created (only for the bot creating it) and they will continue to be updated in subsequent cycles until either the tie is deleted or a value is written into .readtie.
5) Changed the Coeffecient of Kinetic friction calculations to operate directly on a bot's velocity rather than creating an Impulse restitution vector.  The restsitution vector is used for all sorts of forces opposing the velocity of the bot including repulsion forces from the field boundaries and internet gates.  Where kinetic dynamic friction is always a function of a bot's velocity, these other forces are sometimes not, so the force vector was overloaded. This could cause strange problems such as bots being propelled by friction.  Note that for kinetic friction to work, there must be some Z axis gravity.
6) Added length checks to tie setlen and fixlen.  Now, tie lengths longer than 1000 are equaivalent to 1000 and negative tie lengths are equivalent to their absolute value.  
7) Bot properties such as mass were being coverted to an Integer before being displayed in the bot properties dialog, which made it difficult to debug low mass bots for example.  Now their native Single values are displayed.
Reworked the UI for the default viscosity and friction settings on the Physics portion of the options dialog.  Changed the bottons to radio buttons and added a new "Custom" choice.  Added a new parameter to the SimOpts and TmpOpts structure to help with UI initialiazation.  Insured this roundtrips through sim ann settings files appropriatly.
9) Fixed the bug with impossibly long ties, sometimes tied to nothing being displayed occasionally.  It was something stupid I did in 2.42.3.  I don't want to talk about it.
10) Added some code to TieHooke and Maketie to stiffen ties after 20 cycles.  Except for the birth tie, ties will stiffen after 20 cycles at which time the bot will become a multibot and sysvars such as fixang and fixlen will work.  This seems to have been the key to making such bots as inchworm work properly.  Note that mutlibot sysvars will fail to work on ties younger than 20 cycles even if the bot has multibot status.
11) Reworked the UI for the costs section of the options dialog to match the new Physics radio button UI.  Makes it easier to set 0 costs or F1 costs.  Insured everything round trips through sim and settings files correctly.
12) Added a new 'Save Sim Without Mutations' menu option on the File menu.  This saves the simulation without mutation detail strings, dramatically reducing the size.
13) Exposed the coeffeficient of elasticity which governs the degree to which bots bouce off each other in colissions.  The control is a slider which generates values from -1 (bots are ghosts and essentially pass through one another without interacting) to +1 (bots are marbles which bounce off each other hard in a totally elastic collision).  Values in between will exhibit different levels of spongyness with the mass of a bot having much to do with its behaviour during collisions.

142

Off Topic / Alife X is in Bloomington, Indiana

« on: May 01, 2006, 09:16:23 PM »

The tenth International Conference on the Simulation and Synthesis of Living Systems is June 3-7 in Bloomington, Indiana.  Is anybody planning on attending?  I would be going, but I have to be in Hawaii.  Darn.

www.AlifeX.org

143

Announcements / 2.42.3b Now Available

« on: April 29, 2006, 05:10:15 PM »

2.42.3b is now available.   Major Changes since 2.42.2:

Genetic Memory is now working.
All Tie operations (except possibly .tieang1-4 and .tielen1-4) should now work.  In particular, .fixang, .fixlen and energy sharing now work and have been tested with the battery bot gene on the wiki.
Collision Detection is now much improved and incorporates 2.5 behaviour.
Stores to location 0 once again cost no energy.
The Battery bot free energy hole is plugged.
trefvars are now populated immediatly and automatically.
The debugging robot "vision grid" can be turned on and off.
2.5 code backported for CompareRobots which helps big bots avoid going sumo.
Authenticated FTP support for Internet Organism Sharing added.  Testing has been limited, but appears to work fine.
Some major and minor bug fixes including fixing a couple of runtime crashes.

Complete details of the changes in this release relative to 2.42.2 can be found here.

Enjoy!

-Eric

144

Biology / Genetic Drift Simulator

« on: April 26, 2006, 12:49:23 PM »

Just a cool little program that allows for simulating how long it takes for an allele in a two-allele, single loci genome to drift (or be selected) to fixation as a function of population size, starting percentage in the population and a bunch of other stuff.  Intetersting to those interested in the impact of genetic drift and different selection pressures on variation.

UW PopG Simulator

145

Bugs and fixes / Why aren't you using 2.42?

« on: April 18, 2006, 11:53:23 AM »

Is there anyone out there still on 2.37.6?  I want to know why you havn't moved and I want to address any issues which prevent you from moving to 2.4X in the next release (2.42.3).  Unforseen issues aside, 2.42.3 may be the last VB release (at least from me) as I want to move over to the C++ fork and start working with Nums on the next generation code.  So this next release needs to be great for everyone.

Tell me what you need, what you miss, etc.  I will try to make it work.  A can't really entertain new features of any significant size, but tweaks and bug fixes and making anything that worked in 2.37.6 work in 2.42.3 are all fair game.  A couple of things:

I'm pretty pleased by the stability of 2.42.2.  I have several million cycles on my various sims on this release and I've yet to hit a run-time crash.  So if you do hit a run-time crash in 2.42.2, don't just shrug it off!  Please please please let me know and send me the error.sim.  I wantto fix any remaining mainline crashing bugs in 2.42.3.

Internet Organism Sharing will be working in 2.42.3.  I have added authenticated FTP support, so now so we can share via password protected FTP sites.  I will be offering up an FTP location for this on my own site if we don't want to provide one on the main server, but it will work with any FTP site.

I also plan to take a hard run at getting leagues working in 2.43.3.  No gaurentees, but I have scheduled some time for working on it.

If there are other things besides these which prevent you from moving, let me know now please.  I plan to drop the release at the end of the month or the first week of May.

Edit:  2.36->2.37.6

146

Bugs and fixes / Bots evolve to take advantage of a loophole in 2.4X

« on: April 14, 2006, 04:27:41 PM »

So the mainline routine that does all the bot execution, everything from doing all the tie and shot calculations to figuring out movement and costs and reproduction looks like this:

UpdateBots()
Do a bunch of stuff for all bots, including applying costs
Check for nrg <0 (and other things) and set it to 0 if it is
Do a bunch of other stuff for all bots including feeding from body
Kill bots with 0 or negative nrg
End

The bots in my South Pacific Sim have evolved a way to exploit a loophole inherent in this architecture.  Basically, in this sim, selection favors bots that can survive long enough to make it from one "island" to another.  There's no energy supply between islands and I have a per cycle cost of 10 nrg/cycle, so there is a pretty severe cost per cycle even when not doing anything.  So, selection would favor you if you could find a way to get by the per cycle cost.  Well, my bots have evolved to do this by storing energy away in body when near an island and then running with enegy very very low, like 1 between islands.  They let the cost calculations take their energy negative in the first part of the routine, get set back up to 0 in the middle, then feed from their body in tiny little bites, enough so their energy is back up above 0 by the time the decesion to kill off bots is made.  This lets them bypass most of the costs - all they are using is the tiny bit of body to take their energy from 0 up to 1 per cycle instead of paying the full cycle cost each time.

Pretty damn clever and just another example that evolution can surprise you in the solutions it finds!

I've addressed this in 2.42.3 so that negatvie energy is preserved all the way through the UpdateBots() routine so that there is no way to cheat.  If you don;t feed enough from body to get your energy back up above 0, you will get killed off.  I need to do some long term runs to make sure this doesn't open the door for some overflow/underflow bugs, but so far, so good.

147

Bugs and fixes / 2.42.3 Changes

« on: April 14, 2006, 11:58:43 AM »

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.2 to 2.42.3. 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) Fixed Log(0) bug in the new Aging cost implemented in 2.42.2.  If the operator specified logrithmic increases in cost but wanted the cost to begin at age 0, log(0) was attempted and a program error would occur.  Now this cost is not applied or calculated for bots of age 0 when the operator specifices these settings.
2) Closed a loophole in UpdateBots() where bots could allow sim costs to take their energy negative, have that set back up to 0 in the middle of the routine and then take a tiny sip from body to bring their energy back up above 0 so as to avoid getting killed off.  Now negative nrg is preserved throughout the UpdateBots routine so that if a bot does not feed enough from body to bring their energy back above 0 by the end of the routine, the engine will kill them off.
3) CurrentFlow now gets set to CLEAR at the bottom of ExecuteDNA so as to avoid one bot inheriting the flow control of another in the case where it does not have a properly formed gene at the beginning of it's DNA.  See this forum for more info.
4) DNA store operations attempted to memory locations outside 1-1000 no longer cost anything.  See this topic for more information.
5) Fixed parse bug having to do with DNA Detokenization of bots where the number 0 preceeded a store sysvar by adding a check for the number 0 in SysvarDetok().
6) Addressed a run time divide by zero bug in updateshots().  It appears there are cases where newborns shoot their mother on their first cycle when the shot range can be 0.  This can cause a divide by zero error when the shot nrg is calculated.  The fix checks for 0 range shots and sets range to 0.01 in such cases.
7) Implemented Genetic Memory.  This feature was never ported to 2.4X.  Added the routine DoGeneticMemory() to robots.bas.  It gets called from UpdateBots() for robots of age less than 20 cycles and copies mem locations 971-990 from the parent to the child in order, one per cycle over the first 20 cycles of the offsprings life as long as 1) the birth tie remains in existance and 2) the values of the offspring's memory locations are zero.  If the offspring has a non-zero value in one of the 20 locations, that value is preserved (the other locations will still be copied).  Note that this behaviour is different from 2.37.6, in which the locations appear to have been copied beginning upon the child's 33rd cycle of life.
bot(n).Multibot was not getting set to true in maketie() when a tie was sucessfuly created.  Now it is.  This was preventing some of the logic assocated with ties from executing in UpdateTies() and looks to be just the first in a whole series of tie related bug fixes yet to come....
9) tmemloc was getting set (back) to 0 by readtie() as soon as either numties = 0 or tienum = 0.  This behaviour differed from 2.37.6 where tmemloc holds any value set there independent of the value in tienum or numties.  This behaviour is important for bots which want to set tmemloc once, perhaps even before any ties exist and then use it later, just like memloc.  Now the code behaves the same as 2.37.6.
10) BEHAVIOUR CHANGE.  Okay, when a tie is created now, the trefvars are populated automatically from the tie-ee bot (the one being tied) into the tie-er's (the bot that initiated the tie) memory.  This happens automatically and indpendent of any value that may or may not be stored in the tieing bot's .tienum or .readtie,  even if they are 0.  The inverse explicitly does not happen.  I.e. the trefvars of the tied bot are not touched when another bot initiates a tie to it.  The bot must initiate the tie for the tsysvars to get populated.   What's more, .numties and all the trefvars are now updated right when the tie is made and are available for the bot's DNA to operate on the very next cycle.  No more waiting two cycles until things reflect the results of creating a tie as in previous versions.  If a bot wants the trefvars to reflect the bot on a different tie, it need only put that tie's port number into .readtie.  That's it.  The trefvars for that tie will be loaded that cycle.  Trefvar values persist until either a different tie is selected using .readtie as above or .numties hits 0, in which case all the ties are gone and the trefvars are zeroed.  In particular, setting .readtie to 0 will not in and of itself 0 out the trefvars.
11) Ported over the routine TieTorque() from 2.37.6 (was called momenti).  This involved changing the calculations to use the new vector-based acceleration mechanisms as well as wiring it into UpdateBots().  Some modificatiosn were needed in UpdateTies() as well.  TieTorque() was never ported and thus fixing tie angles never worked in 2.4.  Now it does.  In particular, the battery bot gene posted by Elite in this discussion now works correctly in 2.42.3.
12) The .tienum sysvar is now sticky.  The code in 2.4 was setting .tienum to 0 after using the .tmemloc/.tmemval pair.  I've changed the behaviour so that now, like .tmemloc and .memloc, .tienum is sticky and stays at the value the bot specified until the bot changes it.
13) Added a new menu item on the Robot Options menu which controls whether the vision grid is displaed for the robot with the focus.
14) Swapped in Nums new CompareRobots routine with some changes so that it compiles (declaring eyevalue earlier).  I didn't walk through it in minute detail, but I think it helps larger bots see better (a benefit to being bigger) and also makes larger bots more easily seen (a disadvantage of being bigger).
15) Addressed an overflow crashing bug in shareslime() where the temporary Integer variable totslime could overflow when the Integer slime values from the two bots were added together.  totslime is now a Long.
16) delallties() was only deleting the first tie.  Not sure it matters since it is only called when bots die, but now it deletes all a bot's ties.
17) Unmaking venom or poison now takes the same amount of energy as making it.  Waste is created as a byproduct both ways.  Attempts to take the venom or posion stores above 32000 or below 0 still cost energy and create waste, but actual venom and posion will cap at 32000 or not be allowed to go negative.   This fixes the bug where battery bots could make themselves infinite energy by unmaking venom or poision and magically creating waste as a byproduct without any energy usage!  See the posts later in this thread.
18) Added authenticated FTP support to internet organism sharing.
19) Re-wrote the collision detection routine based in part on the code from 2.5 supplied by Nums in this topic.  The coeffecient of elasticity is internally fixed at 0.5 for 2.42.3a.  I added it to SimOpts and it is being saved and loaded from sim files, but I have yet to expose it in the UI.   Collisions now seem much better though further tweaking might still be needed.

148

Announcements / 2.42.2 Now Available

« on: April 13, 2006, 04:26:00 PM »

2.42.2 is now available on the FTP Download Page

Lots of little fixes, a couple of nice feature tweaks and most importantly, several serious core crashing bugs fixed.  Once again, I did not get a chance to dive into Leagues or Internet sharing, but I plan to focus on those areas next.

-E

The complete list of fixes in this release can be found in the following topic: 2.42.2 Changes

149

Evolution and Internet Sharing Sims / Selection for horizontal orientation

« on: April 10, 2006, 09:44:55 PM »

This is the minimal organism sim I have running where I started out with a pretty minimal 14bp single gene bot that only shoots (endlessly) and reproduces.  The only cost in the system is a small nrg/cycle cost to keep the population down.  After 600k cycles, the average DNAlen has grown to 17 and the average # of mutations is over 9.

But here's a funny thing.  All my bots are oriented the same way, firing a stream of shots pretty much horizontal either left or right.  I wonderred what would casue that?

It took me while to figure it out, but I think its selection for orientation.  Take a look at the attached jpg and you can see my incubator habitat for my bots.  Because they can't turn or move on their own (yet) I set up a ring of stable, high energy veggies to keep them in the nursury.  Some escape and die of starvation but enough remain that I'm 750+ generations down the road.

Now, clearly, if you arn't lined up like all the other guys in the nursury, you are at a disadvantage.  You tend to float into an endless stream of shots coming from the rest of the pack and you die pretty quick.  If you are lined up right, when you give birth, your offspring has the opposite orientation.  You each take a few shots until you spearate, but if you seperate fast enough, you have successfully repreoduced a bot with a survivable orienation.  Viola!  A heritable trait that isn't encoded in the DNA!!!.  The physics of the sim don't seem to impart much rotational momentum to the bots, so bots tend to keep their orientation for quite a while, even outside the hive as you can see.

Pretty damn cool.

-E

Well, hell it won't let me attach the image.  Guess we only get 100k total in all forums for attachments and I've used mine up.  Too bad.

150

Bugs and fixes / Should Shell impact conspec venom shots?

« on: April 10, 2006, 11:29:00 AM »

In the process of fixing an overflow bug which occurs when a bot fully loaded with 32000 of venom takes a high magnitude venom shot from a conspec (fixed in 2.42.2) I noticed that shell has no impact for conspec venom shots.  The code simply adds the full value of the venom shot to the bot's own venom store (although now it checks for overflow and clips at 32000 if necessary) indpendent of any shell the bot may have.

So, my question:  Should a bot's shell impact conspec venom shots?

At some point, we will need to re-work this whole area of the engine doing special things in the cases of conspecs.  We will have to so as to deal with speciation.  IMHO, at some point in the future, we will want bots who share a common ancestor to be able to us venom agaisnt each other once their genetic distance defines them as separate species.  Of course, we will need a more sophisticated notion of species identification and a mechanism for the engine to recognize and catagorize new species first.

But for now, with our current mechanisms, I am not suggesting that we open that door.  I am not suggesting we change the core behaviour that a venom shot from a conspec simply increases that conspec's venom stores.  But, should shell be taken into consideration when calculating how much venom to add?

-E