Code center > Solved Bugs

runtime 6/compile error

<< < (13/15) > >>

PurpleYouko:
Regarding the change I made to the code by separating out the acceleration resets and .fixed stuff.

--- Quote ---
--- Code: ---If .mem(216) <> 0 Then
  .Fixed = True
  .vx = 0
  .vy = 0
Else
  .Fixed = False
End If
--- End code ---

and change it to


--- Code: ---If .mem(216) <> 0 Then
  .Fixed = True
Else
  .Fixed = False
End If
if .Fixed then
  .vx = 0
  .vy = 0
Endif
--- End code ---

--- End quote ---

Numsgil answered


--- Quote ---To me it seems that they are identical in effect (not in implementation obviously). Try walking trhough it manually with different values for different things and see if you can provide a case where they're not. I could just be a little sleepy.
--- End quote ---

I agree totally. In terms of code the two would appear to be exactly the same. In practice though they don't seem to be. I often find this with VB.
by putting break points in both conditionals I have caught my new conditional in a true state without the first one running at all.
I can't explain why because this is logically impossible. Nevertheless it happened.  :blink:
And that is why I made this change. VB is weird!

PurpleYouko:
OK I just got the same damn crash again.

This time rob(o) is NOT fixed.
Every other time it has been but not now.

Looks like I may have been on the wrong track all along with this.

Welcom to the world of debugging programs.  :)

Do you see why Num and I take so long to get this stuff sorted now? It isn't easy.

Back to the drawing board again. Please ignore all previous fixes on this thread as none of them really hit the root cause of this problem.

Some of the workarounds that Num posted will get the program running but they don't address the true problem that is causing all this.
I hate workarounds but DB is full of them.  :angry:

PurpleYouko:
I take it all back.

My fix DID work.

This time the offending robot changed from a fixed normal robot to a corpse during the cycle in which the program crashed.
By doing this it managed to bypass both of the velocity control loops in the program during its first cycle as a corpse.

The bugger found a loophole  :blink:

I have plugged it and am waiting to see if it finds another one.

The modification is right at the top of "updpos" in the "physics" module.

I changed


--- Code: ---With rob(t)
  If t <> moving and not .fixed Then
    Maxspeed = 30 / (.mass / 2) 'Set maximum speed. Absolute max = 60
--- End code ---
to

--- Code: ---With rob(t)
  If t <> moving Then
    Maxspeed = 30 / (.mass / 2) 'Set maximum speed. Absolute max = 60
--- End code ---

This line of code was deliberately preventing fixed robots from having the velocity limits applied to them. After all they aren't moving so why would they need it.

No more loophole now.

Numsgil:
I'd leave them in, if for no other reason than that they don't hurt the program.

PurpleYouko:
The resetting of ax, ay, vx and vy aren't bandaids. they are a necessary and integral part of the program.

Fixes that check the value of stuff directly before acyually using it ARE bandaids and as Nums says, they are at worst doing no harm other than to add a tiny bit of time to the program cycle.

Personally I would like to get rid of all bandaid fixes and get to the root of each problem but often that is extremely tricky to do.

I am now at 40,000 cycles since the last fix and going strong.

Damn this is slow. About 4 cycles per second with all graphics off.

Navigation

[0] Message Index

[#] Next page

[*] Previous page