Darwinbots Forum
Code center => Bugs and fixes => Solved Bugs => Topic started by: Testlund on November 01, 2005, 09:51:18 AM
-
Ok, I can confirm that version 2.37.4 works much better now, but not full proof. Here's a bug report:
Tonight after I had run a simulation for 3 h 41 min I got a run-time error 6 overflow, but in a new place:
CODE:
rob(n).mem(poison) = rob(n).poison
LOCATION:
Shots_Module line 402
HOVERING INFO:
rob(n).mem(poison) = 30830
n = 837
poison = 827
rob(n).poison = 39630,29
Then I started a new simulation wich has been running with no problem for 10 h 10 min and is still running. So it works better but you might want to check out this one.
It runs very slowly, though. Check out screenshot.
-
Eh? Didn't you like my screenshot, PY? :huh:
-
Screenshot?
I'm very confused.
-
what value does "power" have in this subroutine. the level of poisin is defined by the "power" variable. If it has somehow become negative then I can understand this bug.
Also where do you get the line numbers from? I don't have any line numbers in my code.
For others who need more info, this crash is in routine "Releasenrg" in the "shots" module.
-
I uploaded a screenshot to my report but then someone started kicking around my post here on the board and now my screenshot is gone. That's ok, it wasn't that important.
-
For some reason the screenshot disappeared when I moved the post.
I didn't delete it on purpose. feel free to add it back in by edit of your post if you still have the link.
-
someone started kicking around my post here on the board
That was because it was OT for the thread in which you posted it.
I know that topics on the DB forum are normally very lax but in this bug forum I am trying to keep a tight reign on them.
-
what value does "power" have in this subroutine. the level of poisin is defined by the "power" variable.
Here's the whole subrutine:
' robot n, hit by shot t, releases energy
Public Sub releasenrg(n As Integer, t As Integer)
'n=robot number
't=shot number
Dim vx As Integer
Dim vy As Integer
Dim vs As Integer
Dim vr As Single
Dim power As Long
Dim h2 As Integer
Dim range As Single
Dim scalingfactor As Single
Dim Newangle As Single
h2 = Half / 4
vx = (Shots(t).vx - rob(n).vx) / -2 + rob(n).vx
vy = (Shots(t).vy - rob(n).vy) / -2 + rob(n).vy
If SimOpts.EnergyExType Then
power = Shots(t).value * (Shots(t).nrg / Shots(t).range)
Else
power = SimOpts.EnergyFix
End If
If power > 8000 Then power = 8000
If power > rob(n).nrg And Not rob(n).Corpse Then power = rob(n).nrg
If rob(n).Corpse Then power = power * 0.5
range = Shots(t).range 'new range formula based on range of incoming shot
If rob(n).poison > power Then 'create poison shot
createshot Shots(t).x, Shots(t).why, vx, vy, -5, n, power, range, vbYellow
rob(n).Waste = rob(n).Waste + (power * 0.1)
rob(n).poison = rob(n).poison - (power * 0.9)
If rob(n).poison < 0 Then rob(n).poison = 0
rob(n).mem(poison) = rob(n).poison
Else ' create energy shot
createshot Shots(t).x, Shots(t).why, vx, vy, -2, n, power, range, vbWhite
rob(n).nrg = rob(n).nrg - power * 0.9 'some of shot comes from nrg
rob(n).body = rob(n).body - power * 0.01 'some of shot comes from body
rob(n).Radius = rob(n).body / factor
End If
If rob(n).body < 0 Or rob(n).nrg < 0 Then
rob(Shots(t).Parent).kills = rob(Shots(t).Parent).kills + 1
rob(Shots(t).Parent).mem(220) = rob(Shots(t).Parent).kills
End If
Shots(t).Exist = False
End Sub
-
Oh, and I have included this fix as you can see:
If power > 8000 Then power = 8000
-
[hint]use the code tags to copy code up to the board or else you lose all formatting[/hint]
I know which routine it came from. I want to know what the hover value is for power when it crashed.
-
Then I have to wait for another crash, right?
-
did that fix it? :blink:
It shouldn't have made any difference.
If rob(n).poison > power Then 'create poison shot
createshot Shots(t).x, Shots(t).why, vx, vy, -5, n, power, range, vbYellow
rob(n).Waste = rob(n).Waste + (power * 0.1)
rob(n).poison = rob(n).poison - (power * 0.9)
If rob(n).poison < 0 Then rob(n).poison = 0
rob(n).mem(poison) = rob(n).poison
Else ' create energy shot
as you can see with the line..
rob(n).poison = rob(n).poison - (power * 0.9)rob(n).poison is reduced by a value equal to 0.9 time power.
If power is big then it should be reduced more
I suspect that power is actually negative since poison has increased.
That should NOT be able to happen.
-
Then I have to wait for another crash, right?
'fraid so.
Once it crashes then you can do all kinds of stuff.
When it's happily running you are effectively shafted as far as debugging goes.
That is precisely the problem that Num and I have been up against for so long.
-
I've had to just leave it running over night. The problem is that interesting simulations tend to have all the bots die from time to time...
-
No, I mean the above fix I put in was for the crash you had recently. I just read about it and put it into the subroutine I posted above. I thought that was related to this issue.
So... If I crash next time at the same location you want the hovering info from THIS code instead?
rob(n).poison = rob(n).poison - (power * 0.9)
Is that what you mean?
-
That's what I mean.
The line that you added from my other (possibly related) fix was for a specific bug regarding a value of >32000 being sent to the "Createshot" routine from "Releasebod". It may be related to this one in some way but I wouldn't recomend adding that line into this routine as it could limit power too much.
-
Hmm... That's a little confusing. So that was just some temporary fix, or what? Should I remove it?
-
Change it to 32000 instead of 8000 perhaps.
And set a floor of 0 on it in much the same way.
-
Could you be more specific what you mean with 'floor'? :)
-
Hmm... That's a little confusing. So that was just some temporary fix, or what? Should I remove it?
No it wasn't a temporary fix.
It was a specific fix designed for the releasebod routine. It is not valid in the releasenrg routine as, despite the similarities, they do slightly different things with slightly different parameters.
Num's suggestion would work however. Set a ceiling of 32000 and a floor of 0 for power. It certainly won't hurt and may even help.
Then again the real issue could be somewhere else completely and may not even be in this module. All we know is that poison is getting too big. We don't know why yet so applying a fix is somewhat premature.
-
Could you be more specific what you mean with 'floor'? :)
Ceiling = upper limit
Floor = lower limit.
-
You mean like this:
If power > 32000 Then power = 0
If that's wrong you need to tell me exactly what to type. I'm no coder.
-
If power > 32000 then power = 32000
if power < 0 then power = 0
Like that.
-
If that's wrong you need to tell me exactly what to type. I'm no coder.
Stick with us and you soon will be. ;)
-
Ok. Now I understand. :D
I'll let you know if I crash again, but that might take quite some time. In the mean time maybe you could check through that subroutine and see if something might be wrong in the code that could cause the crash I got. See you later.
-
Got the same crash again.
ERROR:
Run-time error 6: overflow
CODE:
rob(n).mem(poison) = rob(n).poison
HOVERING INFO:
rob(n).mem(poison) = 25283
n = 1662
poison = 827
power = -27954
I hope that's enough info.
-
power = -27954
Thought as much.
Somehow power has gone negative.
Since power is calculated as.
power = Shots(t).value * (Shots(t).nrg / Shots(t).range)
it would be helpful to know those three values alao
-
Testlund ...
can you upload a 'settings' for this ...
or perhaps a zip of the sim just prior to the crash?
(meant to impliment that write error sim in 2.37.4 too ... how difficult is that Num?!)
perhaps I or someone can then duplicate it ...
I've taken to setting a user 'seed' as well ...
so I have a better shot at repeating the problem.
-
nrg is probably what's going negative, I'd bet.
-
Could be
A robot's energy can go negative during any part of the main loop, It is only zeroed again in "Updatepos" (I think)
-
Testlund ...
can you upload a 'settings' for this ...
or perhaps a zip of the sim just prior to the crash?
I can upload my settings file. A saved sim is no use as you can't load a saved sim anyway, can you? Also I can't no when I'm going to crash either. When you have loaded my settings file you need to change the following as it isn't saved in the settings file:
Set waste treshold to 100.
Turn boyancy on.
Enable corpse mode.
Set repopulation cooldown period to 50.
Happy bughunting! ^_^
-
can upload my settings file. A saved sim is no use as you can't load a saved sim anyway, can you? Also I can't no when I'm going to crash either. When you have loaded my settings file you need to change the following as it isn't saved in the settings file:
no.
not so.
that is the problem with 2.36 ...
2.37 does save and upload sims and settings ...
but until now was not as stable as 2.36.
believe me ... it is easy to become confused with the differences of all these versions!!!
so you should be able to upload a saved sim...
certainly if it was saved with 2.37.
and if you zip and upload it here ...
I should be able to load it as well ...
and yes ...
as long as you provide me the settings that for whatever reason ...
don't load in with the sim and/or settings.
also ...
I suggest enabling using a user defined 'seed'.
I think this is under the General Tab.
with this as part of your settings ...
the random number generator is forced ...
(iif the program doesn't re-randomize to the timer during some operation)
to use the same starting sequence to generate the pseudo random sequence ...
which will be exacty the same if you designate the intitial 'seed' ...
and should provide exactly the same results.
otherwise ...
every sim is begun using a sequence that is different ...
and unrepeatable (at least for our purposes).
so yes ...
do zip and upload a sim that you find leads to a bug ...
or even to interesting behavior ...
you know ... the ones you develope that keep you watching. ;)
that's what I am interested in sharing ....
our own experiments that we find to be of interest.
-
DAMN! You were right! It WORKS to load a saved simulation in this version. ..and nobody told me before when I was complaining. I guess because it didn't work in some versions I never thought about trying it in this version. Ok, it's 3:26 am over here. I'll start a new sim now, go to bed and if it hasn't crashed before the morning I'll save it. If it crash after I've saved it I can upload the save here and you can check it out too. Goodnight. :sleep:
-
Sometimes it works to load a sim, sometimes it don't. I have a saved sim here that I can't load. It says Alga_Minimalis.txt is not a valid robot. Doesn't make any sense.
-
That just means that the saved path to "alga minimalis.txt" in the file is incorrect. You can edit this manually in Notepad if you like.
-
Sometimes it works to load a sim, sometimes it don't. I have a saved sim here that I can't load. It says Alga_Minimalis.txt is not a valid robot. Doesn't make any sense.
like Nums says ...
That just means that the saved path to "alga minimalis.txt" in the file is incorrect.
You can edit this manually in Notepad if you like.
This often happens if you use a setting/sim from someone else ...
as they may keep, or have loaded, their bots in from a different location than you.
I think its about the 8th line of so in the settings file ...
which will show you where it expects to find the first one ...
and this is repeated further down for each species of bot.
so when using other's settings, you have to check to see if that path is the
same as yours ... and .... that you have the bots they are calling for.
I see your Darwin2367.set uses "&#\Robots".
so that would look in the same parent directory as the settings folder ...
for the Robot folder.
another way to avoid this is ....
once you have loaded in the settings ...
to delete all of the species, and then load them in yourself from wherever
you keep your Robots.
then resave the settings and the path to them will be correct.
btw ...
I renamed Num's new remix of Animalis remix ....
and that may be something other that the name you have for it ...
so you have to watch for that as well ... and load in the bot under
whatever name YOU have for it.
I'll have to go put the original name on it I guess ...
just seemed overlong so I had streamlined it ...
not thinking ahead that it might cause others a problem if they
load in my settings. that's for 2.4x anyway.
-
OK the poison bug has reared its ugly head again.
This time I managed to track the reason for it.
The "power" variable had somehow gone negative, causing a shot to contain negative poison which then overflowed the mem(poison) register in the bot's memory when it got hit by the poison shot.
This bug is well and truly squashed for the next release. (hopefully later this week)