Author Topic: Something stopping a bot from reproducing, and screwing with other things too  (Read 7410 times)

Offline Trafalgar

  • Bot Destroyer
  • ***
  • Posts: 122
    • View Profile
I'm not sure what's going on, but I have a bot here which cannot be forcibly reproduced - however, it's due to something on the bot itself, not its DNA. If I start a new sim with that DNA, it can reproduce. If I start a new sim and insert the saved organism, it cannot reproduce.

Each cycle repro remains at 50 without changing, and the bot does not reproduce.

This screenshot shows odd discrepancies between everything shown on the bot info panel, and what the console returns:


The console is for the bot shown there, of course.

Along with the values shown in the console, slime, shell, venom, and poison are all 0. The bot panel shows energy as 16025, which is what refnrg from the bot to the northeast also shows, whereas the console shows .nrg as 3307. The bot panel shows body different from the console, as well, and waste too.

I attempted to set .shoot and .shootval to -4 and 100 respectively, to get the bot to fire its waste to see if that was causing the oddness, but it didn't work - the values are persisting from cycle to cycle, it is not shooting, and waste is not changing.

I even tried setting .up to 1000 and running one cycle. The bot didn't move (and the console reports .fixed as 0), but .up at least did reset to 0.

I can upload the organism somewhere if someone wants to look at it. Or I could upload a sim file which is filled with bots suffering from this...

My best guess is that something is going completely and totally FUBAR and causing the memory inputs to be mostly ignored, and causing most of the memory outputs to not be updated properly.

Edit: For further testing, I'm trying setting memory locations and then checking them (on the console), while the sim is actively running. I theorized that memory writing is breaking down at some point, since .up appeared to be getting properly cleared, so I began looking for the location where it breaks.
I only checked memory locations below 20:
Memory locations that are being overwritten (which is usually normal): .up (1), .dn (2), .sx (3), .dx (4), .robage(9), .mass (10), .maxvel(11), 12 (Not in sysvars list on wiki... hmm, this is apparently a robage which wraps around to -32000 when it exceeds 32000!)
Memory locations that are not being overwritten if I write to them in the console: .aimdx (5), .aimsx (6), .shoot (7), .shootval (8), .aim (18), .setaim (19)

Edit again: If another bot rams one of these, it bounces off without affecting these, even though fixed does not appear to be set (according to the console, which doesn't mean much, I suppose).

One affected bot's DBO file, zipped: http://shadowlord13.googlepages.com/wontrepro.dbo.zip

Edit more: Upkeep is being run, as evidenced by the energy shown on the robot data panel decreasing over time. Therefore the bot is not a corpse (corpse mode is disabled, anyhow). If BotDNAManipulation was being run, the mkvirus memloc being set would start vtimer counting down - but it isn't. BotDNAManipulation is run if the bot is not a corpse and doesn't have DisableDNA set (and if the robot exists).

It LOOKS like the affected bots may have somehow wound up with DisableDNA set. I don't know how that's possible, though - These bots were not DNA disabled when the sim was started, yet somehow they act as if they are DNA disabled now.

Additionally, by checking older save files, I've determined that at 28k cycles, some of the bots had just become affected by this (their console .nrg and robot data panel energy were not decreasing in sync, but were still very close), whereas other bots in the sim were still not affected. At 48k cycles, all or almost all of the bots in the sim that I checked (except the shepherds) were suffering from this. After 48k cycles, the bot population and dna conditions graph lines became a flat horizontal line, indicating that birth, death, and evolution in general had been completely halted by this problem.

It's like the bots evolved DNA disabling as a means of avoiding being culled. D:
« Last Edit: August 04, 2007, 06:04:12 PM by Trafalgar »

Offline googlyeyesultra

  • Bot Destroyer
  • ***
  • Posts: 109
    • View Profile
Is it a veggie? If so, the bot's population may have hit the maximum population.

Offline Trafalgar

  • Bot Destroyer
  • ***
  • Posts: 122
    • View Profile
Quote from: googlyeyesultra
Is it a veggie? If so, the bot's population may have hit the maximum population.

Nope, only the shepherds are veggies. (And the bot population is higher than the veggie limit. It's at 67, and the veggie limit is 30.)

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
That's definately weird.

The mem location 12 that doesn't seem to be documented is probably .timer.  You can write values to it at anytime.  It basically just knows how to count up every cycle.  It's main advantage is that it's passed to children so that parent and child will be in sync.  It's sort of a generational timer, only it doesn't start at 0 for the first generation (value is random).

It does sound like bot DNA has been disabled somehow.  Probably the boolean checking to see if DNA is disabled isn't being cleared when a new robot is put into the robot array.

Offline Trafalgar

  • Bot Destroyer
  • ***
  • Posts: 122
    • View Profile
Quote from: Numsgil
It does sound like bot DNA has been disabled somehow.  Probably the boolean checking to see if DNA is disabled isn't being cleared when a new robot is put into the robot array.

The reproduce function sets rob(nuovo).DisableDNA = rob(n).DisableDNA
(line 1417 in Robots.bas)

The SexRepro function doesn't appear to set DisableDNA, but these bots are being forcibly reproduced using repro through tieloc/tieval. But I suppose it's possible that the bots evolved sexrepro on their own, if it isn't disabled (I thought I read somewhere, or someone here said, that it was disabled).

Edit: Looking at their genome now.
Of the sample bot whose DNA (and DBO file) I saved, it has:
Many 0 0 stores
4 0 store
-1 0 store
No incs
One 0 dec, no other decs

I conclude that it is impossible for it to be doing sexrepro on its own, unless of course the bot's parent evolved sexrepro and a lucky dna deletion removed it from the dna-disabled child's dna. Hmm.

The only other alternative explanations I can think of are:
1. When I searched the source for all references to DisableDNA, I missed something that can set it, or
2. A buffer overflow with a nearby (in memory) array or string or the like is causing it to be set, or
3. Something is happening which I didn't realize from looking at the code (Like I tried looking up what is being read to be shown as slime on the bot data panel, and it looked like it should be showing, well, slime), or
4. The source identified as being for 2.43 on the wiki's source download page isn't actually 2.43 source, or
5. 'Darwin2.43.exe' from the download page on the wiki is a mislabelled 2.42.0.9 or something like that. (When I hover the mouse over the exe, it shows File version: 2.42.0.9, but I was assuming that it was just an oversight that the version didn't get changed in the resource file when 2.43 was released)

I also find it interesting that in every one of these crippled bots, "slime" on the bot info panel was showing as 32000.

Another edit: If I'm reading the source right, the memory location for slime seems to only be updated when mkslime is called. The rest of the time, .Slime degrades and the memory location isn't updated. But that's not what's wrong with the bot info panel - it seems to show shell where the slime label is, and not actually show slime anywhere (or something). Of course, the memory location for shell on the broken bots shows 0, but if it isn't being written to because they're dna-disabled, then their shell could be 32000 or whatever without the memory indicating it (The question then would be: How would they get shell if they're dna disabled?).
« Last Edit: August 05, 2007, 12:11:04 AM by Trafalgar »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Seems to be a whole slew of errors.  That's the problem with a program like this.  If you're playing half life 2 and it does something weird after 10 hours of continuous game play, it's considered an amazingly stable game.  If Darwinbots does something weird after 48 hours of continous game play, it's a huge problem.  I'll leave it to Eric to see if he wants to hunt this down or turn it over to someone else (like me :/)

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
I will certainly dig into this, but not for a couple of weeks.   Vacation looms.

A posted sim would be very useful.  Thanks.
Many beers....

Offline Trafalgar

  • Bot Destroyer
  • ***
  • Posts: 122
    • View Profile
Quote from: EricL
I will certainly dig into this, but not for a couple of weeks.   Vacation looms.

A posted sim would be very useful.  Thanks.

I've zipped up 3 saved sim files along with a small readme explaining which is which, and shepherd.txt (since the sims will try to load it), and uploaded them here (681 KB): http://shadowlord13.googlepages.com/dnaDisabledBotsSims.zip

Those saved sim files are from different points in time, one from cycle 28k (only a few bots were affected), one from 48k (some or all of the bots were affected), and one from 89k (all the bots were affected).

Also, a warning: The version of shepherd included in that zip will attempt to destroy any affected bots if it scans them. It keeps timestamp tags in 976 and 977 and compares them to tags in the out vars on the target to determine whether it's time to check a bot again - this determines whether it will scan a bot, and thus whether it will attempt to destroy an affected bot. Once it feeds a bot or whatever, it updates those tags on the bots to correspond to 1000 cycles in the future or so. If the shepherds are all killed and replaced, they then fly around doing nothing for a while until their timestamp tags catch up to what's on the bots in the sim.

(It determines whether a bot is affected by checking to see if repro is set, or by noticing that it attempted to poison/venom instakill a bot and the bot is still alive on the next cycle. The way it kills affected bots is by draining their energy and/or body through the tie.)

Also, a slight correction on something I said in an earlier post: I found one affected bot (by comparing bot data panel energy to printmem .nrg on the console) which doesn't have 32000 showing for Slime in the bot data panel. I did find something else out, however. Looking at a sim where only a few of the bots suffer from this, the affected bots' mutation details show as 'No mutations', whereas the unaffected bots show their mutation history properly.

Another interesting bit of information: I have an affected bot here who shows as having had one offspring. That would seem to imply that becoming DNA disabled did not happen to the bot when it was created, but possibly as a result of a random mutation.
« Last Edit: August 05, 2007, 09:52:36 AM by Trafalgar »

Offline Trafalgar

  • Bot Destroyer
  • ***
  • Posts: 122
    • View Profile
I suspect there's something wrong with either saving or loading as well now. After implementing and testing the anti-dna-disabled-bot code in my shepherd bot, I started a new sim with the same base bots, and ran it for a good long while. I made several save files, the last of which was made when the best bot had 42 genes. I restarted DarwinBots after making that save, but first I checked a sample of the bots to make sure that there were no dna-disabled ones in the sim. I didn't find any, but after I loaded the save, *all* the zerobots had become dna-disabled and were showing 32000 for slime in the bot data panel.

Another symptom seems to be that dna-disabled bots report 0 to the dna conditions graphs - It was rather conspicuous when the dna conditions graph for the zerobots started showing 0 after I loaded, when it was far far higher than the Shepherds' 2 conditions at the time that I saved.

(To get around the problem, I saved the DNA for several of the 42-gene bots and started a new sim with them)

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
In general, saving and loading seem to be bugged and imperfect.  Ideally when you save a sim and reload it, it's exactly like running the sim straight.  There's one inparticular I've had in mind for a while now: When the random number generator is seeded, the string of random numbers is predetermined.  When you save and load, this string gets reset.  So a loaded sim will run the same everytime, but it will be different from the original sim's evolution.  Which makes debugging from saved sims iffy at best.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
The Cond graph isn't working because the number of Cond statements isn't being counted.

The number of cond statements isn't being counted because the DNA isn't being exected (Cond's are counted each cycle by the DNA execute routine).

The DNA isn't being executed becuase DisableDNA is being intrepreted as being True.

DisableDNA is being interpreted as True because it is set to a random, non-zero value.

Still working on why this is the case...
Many beers....

Offline Jez

  • Bot Overlord
  • ****
  • Posts: 788
    • View Profile
For someone who wasn't going to start on bug fixing for a few weeks; you do truly exceed expectations Eric!  
« Last Edit: August 06, 2007, 03:51:37 PM by Jez »
If you try and take a cat apart to see how it works, the first thing you have in your hands is a non-working cat.
Douglas Adams

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Quote from: Trafalgar
...I started a new sim with the same base bots, and ran it for a good long while. I made several save files, the last of which was made when the best bot had 42 genes. I restarted DarwinBots after making that save, but first I checked a sample of the bots to make sure that there were no dna-disabled ones in the sim. I didn't find any, but after I loaded the save, *all* the zerobots had become dna-disabled...

I would be very interested to know if this is reproducable when using the "Save without Mutation Details" option.  One theory I am exploring is that I have a bug in some old code in the save sim routine which was once used to provide backward compatability for very old sim files with bots that had a mutation details string >16k bytes.   Have not found it yet through code inspection.  If this does reproduce with a sim saved with stripped mutation details, that would eliminate this hypothesis....
Many beers....

Offline Trafalgar

  • Bot Destroyer
  • ***
  • Posts: 122
    • View Profile
Quote from: EricL
Quote from: Trafalgar
...I started a new sim with the same base bots, and ran it for a good long while. I made several save files, the last of which was made when the best bot had 42 genes. I restarted DarwinBots after making that save, but first I checked a sample of the bots to make sure that there were no dna-disabled ones in the sim. I didn't find any, but after I loaded the save, *all* the zerobots had become dna-disabled...

I would be very interested to know if this is reproducable when using the "Save without Mutation Details" option.  One theory I am exploring is that I have a bug in some old code in the save sim routine which was once used to provide backward compatability for very old sim files with bots that had a mutation details string >16k bytes.   Have not found it yet through code inspection.  If this does reproduce with a sim saved with stripped mutation details, that would eliminate this hypothesis....

I've been saving exclusively with without mutation details since this morning, and so far haven't gotten any dna-disabled bots yet (though I've only loaded twice or so). So your theory might be correct, but this doesn't really prove it (since it's not really possible to prove something with an experiment). If I do find a dna-disabled bot after loading a no-mutation-details save, I'll be sure to post about it.
« Last Edit: August 06, 2007, 09:09:29 PM by Trafalgar »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
If mutation details are indeed the culprit, you might be better off turning them into a formulation instead of fixing the problem.  Just store an array of values representing the event, and interpret them as a readable string when the user wants to look at them.