Darwinbots Forum
Code center => Bugs and fixes => Topic started by: EricL 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.
8) 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.
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.
-
Are you going to do any more on fixing up the GUI? I still find it kind of messy with values that doesn't stay put. I found for instance that the decay rate for corpse mode gets set to zero all the time. I don't think it did that before.
-
If you or someone else finds the issues, I'll be happy to fix them. I fix the things I find, but I don't find everything. I have yet to use corpse mode for example, so have yet to notice whether thigns work right there or not.
-
The only GUI bug I was able to isolate related to corpse mode was the decay type not being set to anything after exiting and restarting. Even saving and loading settings seems to be working fine. Everything else appears to be working 100%
I'll amend that previous statement, decay type doesn't seem to be tied into the settings files at all. Loading a settings file seems to keep decay type on whatever the previous settings had it.
Are you sure Testlund that you're clicking either "change" or "start new" when you make a change? If you just move a slider and then hit escape you aren't going to be saving that change to the settings. I think alot of what you're having problems with might be related to that.
-
Another thing I've just noticed:
Waste levels seem to be doing something odd in 2.42.1. After less than a thousand cycles one of my animal minimalis's had 222 waste. It seems to be related to feeding. I don't know if this is a fix from something that was broken or if this is unintended, but waste seems to be building up orders of magnitude faster.
While I'm on the subject of waste, I modified the C++ source a while ago to distribute nrg, body and waste, venom, poison, shell, etc. between parent and daughter bots.
For instance, a bot reproducing at 40% will create a baby with 40% of its nrg, body, and waste, etc.
I would suggest something similar be done for 2.42. Makes more sense to me, and makes it harder for bots to escape the effects of their waste.
-
Waste levels seem to be doing something odd in 2.42.1. After less than a thousand cycles one of my animal minimalis's had 222 waste. It seems to be related to feeding. I don't know if this is a fix from something that was broken or if this is unintended, but waste seems to be building up orders of magnitude faster
I haven't changed anything there explicitly. Could be a side effect of something though. I'll poke around and see if I can find anything.
For instance, a bot reproducing at 40% will create a baby with 40% of its nrg, body, and waste, etc.
I would suggest something similar be done for 2.42. Makes more sense to me, and makes it harder for bots to escape the effects of their waste.
Sounds good. I may not get this in for 2.42.2 as I want to try and drop that this week and since the kids are out of school this week, my time is limited but if not for 2.42.2, then for the next one....
-
I found for instance that the decay rate for corpse mode gets set to zero all the time.
Fixed it. It's addressed in 2.42.2. See #18 above.
-
I've explained it very detailed before in earlier posts exactly what is happening. I don't understand why you don't get the same results. Of course I click on start or change! Eric have said earlier that he found those bugs too and he fixed it as far as saving it in the sim goes, but if you click around in the GUI you SHOULD find that the values changes in some fields after you change them, click ok, go back in to look at them again.
Try this:
1. Start the program
2. Click on Start a new simulation.
3. On the general tab, check Corpse mode and select NRG. Set the Decay rate to size 10 and Period to 1.
4. Click on the 'Start new' button to start a simulation.
8. Click on the 'Start new simulation' button.
9. Click on the General tab. Look at the values in the decay rate. All 0's, right?
When it comes to values on the advanced controls and advanced costs I have just found out that the values gets set to whole numbers if you use decimals. Could it be that you are never using decimals? If so then I don't understand how you can run a successful sim, because there are several values there that doesn't work well in the sim if they are set to 1 or higher. For example, I've found that .001 for basic command and .002 for advanced command works nice. Higher values means the bots will lose energy too fast to make up for it. When it comes to planet eaters I've found that the value .01 works nice. If you set this to 1 or higher all veggies and bots on the screen will get sucked into a clump.
Fixed it. It's addressed in 2.42.2. See #18 above.
What?? You fixed that while I was typing the above post?
-
Got it. The issue with Decay Type (#18 above) was different from the issue with Decay Rate size and period (#19 above). Both are fixed in 2.42.2
What?? You fixed that while I was typing the above post?
Hey, I'm good.
I'll look at the advanced controls and costs thing later today.
-
Fixed it. It's addressed in 2.42.2. See #18 above.
Hehe, I got to like 12 and gave up. Bad Numsgil
-
I got to like 12 and gave up. Bad Numsgil
Naw. I just fixed it 5 minutes ago and added 18 and 19. I keep editing that post to keep it up to date.
-
Ah, that makes me feel better.
-
When it comes to values on the advanced controls and advanced costs I have just found out that the values gets set to whole numbers if you use decimals.
I can't seem to reproduce this. All the values on both the Advanced Costs and Advanced Controls dialogs accept decimal values and they seem to round trip through saved settings, sim files and dialog invocations for me just fine. Can you perhaps give me some more info on this to help me reproduce it?
I've addressed the bugs you pointed out with corpse mode settings in my fork of the source (see #18 and #19 in the first post in this topic) but I can't seem to reproduce the issues you mention with decimal values in the Advanced dialogs.
Note that becuase the saving of the value in #19 was triggerred off the "changefocus" event, this may explain why Nums and others could not reproduce the behaviour you were seeing. He was perhaps clicking somewhere else on the dialog before hitting Change or Start New which would have triggerred the save for the corpose mode controls. Amazing that something as subtle as clicking somewhere else - anywhere else - after changing Decay Rate Size or period would result in differnet behaviour, but there you go...
-E
-
I don't know how to explain it better. Click on the 'Physics and costs' tab. Click on 'Advanced controls'. Check 'Planet eaters' and change the value there to .05 and click on the 'Okay' button. Click on 'advanced controls' again. The value now says 0,05. Click 'Okay'. Click on 'Advanced controls' again. Now the value says 0. If you don't get this then I don't know what to say.
I think it's ok as long as one never goes back in to those dialogs after one has made the settings, but sometimes I'm not sure if I trust that the values I have set will really stay that way in the sim. Sometimes I might just want to go back in to change ONE value without reseting them all.
-
If you don't get this then I don't know what to say.
I'm sorry, but I still can't reproduce this. The value in planet eaters stays at 0.05 no matter how many times I go back tothe Advanced Controls dialog and I'm following the steps you specify exactly. A few things:
As assume it's a typo in your post and you are specifying 0.05 and not 0,05. Commas won't work. I'm sure you know this.
The values in the options dialog or any of its child dialogs like Advanced Costs or Controls aren't "committed" until either Change or Start New are clicked even if "Okay" is clicked on the Advanced Controls or Costs dialogs so as to allow for cancelation. Thus, if you specify a value in Platent eaters (or any cost for example) and then hit Okay but then go back and re-invoke the options dialog from the main menu by doing a "new simulation" or from one of the menu items on the edit menu without ever hitting Start New or Change, then the value you specifyed in Planet Eaters (or any other value) will be lost even though you hit Okay on that specific child dialog. The options dialog (and it's children dialogs) get re-invoked with whatever the values were from last "commit" - the last time Change or Start New was clicked. Is this what you are seeing?
Thanks for your help in tracking this down.
-
If it really is changing from 0.05 to 0,05 it might be something weird with the Visual Basic run time libraries. I know they're a little different on each platform I've used them on.
-
Oooh. Yea. Testlund, your running US Windows using a US keyboard and driver, right?
-
Umm... No, I'm running a Swedish version of Windows XP Professional and Swedish keyboard layout, as I am from Sweden. I know I can't TYPE 0,05. That doesn't work, but oddly that's how the value is displayed the first time I go in to look at it. The second time I go in to look at it it has changed to 0. Are you saying it is affected by how the op is handling values in different countries or something?
-
Are you saying it is affected by how the op is handling values in different countries or something?
I think that may be the case for this specific bug.
You might try going into the control panel, opening the "Regional and Language Options" (or whatever that is called in Swedish) and customizing the number separator to be a period instead of a comma and then see if the same behaviour persists.
And just off-topic, I own a Hallberg-Rassy sailboat (made in Sweden). The factory is on an island on the West coast in a small town called Ellos north of Gotenberg. Cool place.
-E
-
Oh my god, you were right! Changing the comma to a period for numbers in the language settings helped! This has been bothering me since autumn!!!
-
Yea, VB6's support for authoring a single program which works well in different locales was pretty lame. The potential for doing much better exists in the C++ code.
Don't stop finding those bugs though. Most of the things you've brought to my (our) attention are real issues in the code.
-
The C++ version shouldn't have any issues with the program running differently on different platforms. Heck, you should be able to run it on a mac if anyone has a mac to compile the code on.
-
When I try to run a sim in 2.42.1 it crashes with a division by zero error
-
I think you need the default.set file that Eric posted together with this release. It should be somewhere here. Hmm... Maybe it is together now with this version on the FTP.
-
The big thing with 2.42.1 is to delete lastexit.set in the Settings directory.
-
Do you think maybe you could modify the program to automatically check for the older version and discard it?
The settings files have a -2 in the beginning of them. I'm using -3 to show that it's the C++ version settings file, maybe you could use -1.
-
Will do.
-
The big thing with 2.42.1 is to delete lastexit.set in the Settings directory.
It works
Thanks
However, I notice that when using minimalbot
cond
start
-1 .shoot store
stop
cond
start
10 .up store
stop
cond
*.nrg 10000 >
start
33 .repro store
stop
There doesn't seem to be any colision detection at all
When I place them manually against vegs, they do stuck against them (ie. colision detection works only for very low velocities), but they quickly die
Also, a general bug in 2.4 seems to be that ties do not work (though I don't like ties anyway), and they seem to snap incredibly easily, exerting no force on bots at all
-
You're probably running into issues with the physics engine.
Collision detection works fine, but collision response can be a little weak at times. WHen bots collide, basically a spring is put between the two bots and well, sprung.
Ties also exert a spring like force. It can be relatively weak if bots are really pushing.
The physics engine in the C++ version is better, and handles these sorts of things better.