Darwinbots Forum
Code center => Bugs and fixes => Bug reports => Topic started by: Elite on May 29, 2006, 10:34:31 AM
-
Phantom Shots
How to get the bug:
Start a sim with a combat bot. After it's run for a couple of cycles, enough for the bots to start trying to eat a few vegs, click the "Start new simulation" button. Don't touch any of the settings and start a new sim (but start it paused this time). Cycle through a couple of cycles, keeping the sim paused, and you will see some shots magically appear out of nowhere.
Here's what's happening (or what I think's happening):
If you start a new sim while a new sim is in progress, the shots that are on the field at that time aren't cleared, so when the new sim starts, they are still there.
However, if you remove the bot that fired the original shots, the 'phantom shots' will not appear
-
You are absolutely correct Elite. The Shots array is not getting reset when a new sim is started. Any shots which exist in the previous sim will live out their lives in the new one until their age reaches their range.
Nice find. Fixed in 2.42.6.
-
Bots in a Viscous Medium
How to get the bug:
Set the friction settings to "Thick Fluid" and run a sim. The bots vibrate back and forth insanely. This shouldn't be happening.
What I think is happening:
With fluid dynamics, the friction increases with speed. If the bot sits there not moving, then they stay still. The problem comes if they try to move. It seems that the friction when moving is enough to overpower the bot's forward motion and actually force it backwards. Friction shouldn't be greater than the force that the friction is resisting.
Viscosity Glitch
How to get the bug:
Set the friction settings to "Thick Fluid" and run a sim. The bots should vibrate back and forth. Start a new sim but this time change the friction settings to "Sandpaper" or "Metal" or "Teflon". The viscosity is still the same as "Thick fluid". The bots still vibrate back and forth like they're in a thick fluid.
What I think is happening:
The viscosity isn't getting reset when the friction settings are changed to solid. You can see this if you change the friction settings to custom and look at the viscosity.
Overflow Bug
How to get the bug:
Set the friction settings to "Thick Fluid" and run a sim. The bots should vibrate back and forth. Start a new sim but change the settings to "Custom Physics" and change the viscosity. It goes down to 0.01. A couple of seconds after you hit the "Start sim" button, the program gives an overflow error and exits.
What I think is happening:
I haven't got a clue, but I'll bet it's linked with the above bug.
Zoom Overflow
How to get the bug:
While in a sim, unlock your view so you can see areas outside the field and then zoom out. Keep zooming out, and the program will eventually give an overflow error.
What I think is happening:
This is one of the simpler bugs. The area that you are viewing becomes so big that you get an overflow. I reccomend restricting the maximum possible view.
Shootval Bug - Uh oh - major, major bug here!!!
The number in .shootval is the energy cost for a shot, no matter what kind of shot is being fired. If a bot does this, for example:
.aimdx .shoot store
628 .shootval store
(ie. Icarus)
... then the bot will have to pay a whopping great energy cost of 628!
Bots should only have to pay an energy cost of the number in .shootval when they fire -1 shots and -6 shots, not for any other types of shots.
Viruses
OK, viruses could really do with a debugging
Some of the strange behaviors I've been noticing:- Rather than be fired forwards viruses fly off at random angles (although I think Nums did this on purpose)
- No matter what number is put into .vshoot, the viruses always have the same range
- Viruses loose their condition when fired (I think Nums did this on purpose too) and are getting themselves inserted into the middle of genes. One of my viruses hit a veg and was inserted directly into the middle of the reproduction gene - directly before the START of the first gene. This resulted in the veg going cancerous.
- Genes cannot make themselves into viruses. If the gene number of the current gene is stored into *.mkvirus (ie. with *.thisgene) then the virus will not appear.
'Touch' senses
These don't work at all
Here's what should happen:
These sysvars are supposed to detect collisions with other bots- If a bot is hit/touched from the front, *.hitup should readback 1
- If a bot is hit/touched from the back, *.hitdn should readback 1
- If a bot is hit/touched from the left, *.hitsx should readback 1
- If a bot is hit/touched from the right, *.hitdx should readback 1
Delgene
.delgene doesn't work at all
If you store a gene number into .delgene then that gene should be deleted, but this doesn't happen
.thisgene works fine though, so the problem isn't in the gene numbering as I originally thought
-
I think there is a little bug with the total veggies counter. If I for instance have 600 veggies it drops down to 245 and then back up to 600 within a cycle. It keeps doing that at irregular intervals. I've checked carefully through the veggies but I can't see that lots are dying out and gets born withing just a cycle.
Another thing I found strange is that when I started a new sim in 2.42.5 I chosed 3 veggies from a previous sim in version 2.42.4, they were at generation 7 and 8. I give them only 1 energy at start and they quickly gain up to 32000 energy. All their offspring though only has around 100 energy at birth and they never gain any energy. They quickly die out. In my previous sim I got a stable population going all the way to generation 8 and they gained energy and grew bigger, but here all offspring dies out. Only generation 0 stays alive until about 60000 cycles when old age is starting to rapidly take away their energy. I've set age cost to 0.1 and to begin at 20000 cycles, and I've checked the box below. This worked nice in my previous sim in 2.42.4. At 3040260 cycles I still had a stable population with tons of veggies. This was my last save in that version. Then I began a new sim in this version. I wonder if there might have been some bugs in 2.42.4 that made the veggies survive where they shouldn't. And now when those bugs have been fixed these veggies have a harder time surviving. Or there might be new bugs in 2.42.5. I could zip up a save if eric or someone whould like to take a look at it.
-
I tried this version and almost right away I found a bug. Or at least I think I found a bug. Bots get energy from nowhere, probably through some bug in tie-sharing/feeding. I found a group of three bots linked by tie and they had 1, 1, and 3 energy with about the same amount of body and these three bots stayed alive for multiple cycles. Check out the attached sim (change name extension to rar and unpack).
-
On the other hand, the problem may be with the "robot data" window not getting updated or reporting incorrect info. I looked at one bot and its stats have not changed at all over 20 cycles. Only Age was changing.
-
Here is another bug: highlight a bot, right-click and chose "Kill robot" - the viewing sectors for that bot remain where they were when the bot was alive.
-
Not a bug per se, but the colors on the graphs are very hard to see. They are quite faint.
On the plus side - the "Update now" button is pretty cool.
-
When the graphs are resized vertically below some level all lines disappear.
-
Uhm, I need to double-check that report on "energy from nowhere"... I did not notice that in the new version the costs are set to "no costs" by default. So maybe bots were surviving because they were not doing anything. Might be a good idea to set the default to F1 settings.
-
Also, I think the default settings are completely frictionless, which is quite disorientating
-
I got a corrupted save here. Whenever I load it I get an overflow error:
Also the total bots and veggies counters are acting weird. They jump between 0 and 500!
-
1. The program does not load the default settings at the start - it loads the settings that were used last.
2. Whenever I turn on the "transitory fluid" I get "Overflow error". See attached error.sim save.
-
1. The program does not load the default settings at the start - it loads the settings that were used last.
I think that changed on purpose in 2.4
How about including an option:
- Revert to default settings on startup
- Load settings at last exit on startup
2. Whenever I turn on the "transitory fluid" I get "Overflow error". See attached error.sim save.
Yeah, I noticed that too. It's up top
Selecting a fluid dynamics option jamms the viscosity settinge. Changing the viscosity after that (ie. manually or selecting a different fluid) crashes the program with an overflow
-
I think that changed on purpose in 2.4
How about including an option:
- Revert to default settings on startup
- Load settings at last exit on startup
I think there is no need to overload the program with options. At some point we should just decide on the best idea and go with it. A logical approach for me would be to load default settings on start-up as this is sort of the point of having default settings. The only time I would want last used settings is if a program crashes. And I would want a reminder at startup that the settings that were loaded are "last used".
What do you think?
-
I think there is no need to overload the program with options. At some point we should just decide on the best idea and go with it. A logical approach for me would be to load default settings on start-up as this is sort of the point of having default settings. The only time I would want last used settings is if a program crashes. And I would want a reminder at startup that the settings that were loaded are "last used".
What do you think?
Personally, I prefer it to load default.set each time it starts
And good point, what is the point in default settings if you don't use them?
Anyone disagree with that?
-
The reason for loading "last used" settings after crash is two-fold. One, it is easier to track bugs that way and two - I like to tweak settings a lot step by step and I don't like saving them after each tweak just to make sure that I have them in case of crash.
-
I really prefer the load last settings. It makes numerous things much easier for me, as there tends to be alot of coherence between simulations I run.
Default.set is useful to load if you ever get a weird GUI setting somewhere and want to start from a known good setting. Also, occassionally (rarely) something screwy happens and lastexit.set might not get loaded.
It wouldn't be hard to create some kind of ini file for the program that stores these sort of long reaching preferences. We could add a "show splash screen at start" toggle as well.
-
The sanpshot routine is messed up in this version too. It makes files with incorrect formatting.
-
Ouch, I'm getting tons of errors coming up when I try to load Eric's ex nihlo sim file, ending in a program-crashing overflow
It gives the following errors:
"Error while loading sim. Invalid procedure call or argument"
"File already open. Path: C:\...\Alga_Minimalis.txt is not a valid robot"
Sim starts, but a couple of seconds later ...
"Error. Overflow. Saving sim in saves directory as error.sim"
"Error while loading sim. Object variable or With block variable not set"
"Error while loading sim. ."
"Error while loading sim. Resume without error"
The sim resumes, but is frozen and I can't get it to unpause
If I click the cycle button ...
"Run-time error '6': Overflow"
Program spontaneously exits
-
FYI, I'm starting to work on the bugs identified in this thread.
Elite's issue with loading my evo sim was a corruption in the uploaded file itself when it was uploaded to the forum. I have re-uploaded the sim here (http://www.darwinbots.com/Forum/index.php?showtopic=1371&hl=). Not a bug.
Testlund's corrupted save and Elite's overflow when using "transitory fluid" are the same issue, an overflow error in SphereCD().
Testlund's jumping bot and veggy counters were an issue with event handling updating the tray before the calculations had completed.
Shvarz's issue with snapshot saves and loads of robots was a problem in the hash checksum routine.
More details on these fixes can be found here (http://www.darwinbots.com/Forum/index.php?showtopic=1369).
I will continue working on the rest of the bugs.
A buddy drop with these and a few other fixes is attached.
-
Good to see such quick feedback and fixes. Just want to clarify that I had a problem with snapshot, not with loading robot files. That's the button with the camera on it - it exports DNA of all bots in the sim in a single file in comma-delimited format for future analysis within Excel for common genotypes. That does not work (although I have not tried the new version 2.42.6 yet)
-
Good to see such quick feedback and fixes. Just want to clarify that I had a problem with snapshot, not with loading robot files. That's the button with the camera on it - it exports DNA of all bots in the sim in a single file in comma-delimited format for future analysis within Excel for common genotypes. That does not work (although I have not tried the new version 2.42.6 yet)
AH, got it. Thanks. I was confused as the bot save routine is actually called... Snapshot. I'll take a look at the uber export feature shortly.
-
A buddy drop with these and a few other fixes is attached.
I'm afraid your upload has been corrupted, Eric. I can't unzip it. Get a crc error.
-
I'm afraid your upload has been corrupted, Eric. I can't unzip it. Get a crc error.
Try it now. I re-uploaded and tested that the upload is okay. Somewhere along the line, something is dropping packets or something...
Note I'm still chasing a timing dependent bug in this build. It won't fail for me under VB (yet) but the naked exe gets an overflow occasionally....
-
I can't get it to work. I've tried downloading it several times now. I still get a CRC error and the file won't unzip.
-
Lets try a new post then...
Edit: Just verifed this one works for me...
-
Didn't try the earlier one but the new one dowloads and unzips perfectly for me
-
Yes, now it worked! :-)
-
And I found a bug in it already
It's only a minor one though.
In the console where the program lists the genes that have been activated, it's listing the wrong genes.
My test bot is Destinatus preliator. Evolution is disabled, as is altzheimers (as for some reason DP doesn't get rid of his waste in this version). All other settings are default.
The console says that gene 19 is being executed on each cycle whereas it is actually gene 18 that is really running.
The same 1 gene offset is present all the way down the list.
Now back to why the waste isn't going away
-
OK I now know why the waste doesn't go away. It has to be about the most bizarre reason that I ever saw.
The copy of DP that I am using physically does not have a waste removal gene
How the hell is that possible? It has been working perfectly for about a year or more and I'm pretty certain that it used to have waste disposal built in.
Surely DP hasn't been defective all this time. That makes me sad
-
And I found a bug in it already
It's only a minor one though.
In the console where the program lists the genes that have been activated, it's listing the wrong genes.
My test bot is Destinatus preliator. Evolution is disabled, as is altzheimers (as for some reason DP doesn't get rid of his waste in this version). All other settings are default.
The console says that gene 19 is being executed on each cycle whereas it is actually gene 18 that is really running.
The same 1 gene offset is present all the way down the list.
The DNA parser is acting funny for me too, when I look at the DNA of a bot in a sim it is numbering the genes oddly, and in certain cases combining several genes and treating them as one
Might it have something to do with .delgene not working?
-
Must admit I didn't really pay much attention to which gene was actually firing.
I looked at the genes list in the robot window and found that it didn't agree with the list of executed genes in the console. without looking through the actual DNA in notepad I can't tell which is correct.
-
As it turns out it is a bit of both.
The actual gene that is firing is gene 20 (as manually counted in notepad)
The DNA window shows it at gene 18
The console shows it as gene 19
This is a bit messy
-
Hmm ...
Whatever is stored to .vshoot, the virus always has the same range. Looks like something got broken somewhere along the line and the virus range isn't getting updated with the number in .vshoot
Been looking at the "2.42.6 changes" thread. Great stuff; can't wait. Again, well done
I'm pretty sure that viruses were acting buggy because of the gene counters messing up, so they'll probably be orders of magnitude more stable.