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.
