Along the lines of debugging the robotd that Hadley
wrote. 

I found that on random occasions, the robots would
stop reporting where it wanted to take the armies it
was carrying. 

Usually, it stopped anywhere between 2 and 5 hours of
playing. 

I was thinking MEMORY HOLE. But then, one day, I ran
the bot for about 18 hours. Lo and behold! It started
to report where it wanted to take the armies to again!

Turns out the _udcounter was turning negative. It runs
on an 18 hour cycle. And depending on what time of day
you run the bot. You can count on it to work close to
18 hours, or only 1 hour!!! And then the cycle repeats
itself.

My initial fix was a bandaid that took into account
that _udcounter would flip over and count backwards...
-10 -9 -8 -7... At least for the carrying
announcement. 

Turns out that udcounter is used all over the place in
the robot code! The intent was udcounter is to start
from 0 and always count forwards based on 100ms of
time elapsed. 

I don't know if starting from 0 is a requirement...
But, I didn't take a chance on this one, and re-wrote
the function, so it does what it is supposed to do. 

tested code. And now udcounter has counted forwards
for close to 31 hours! 

Then robotd crashed! (SIGSEV on mprintf, not sure why,
but I did a backtrace and had I nice screen I was
going to send to everybody, but the power went out,
and I lost everything that was on my screen.). 


Jimmy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-udcounter.dpatch
Type: application/octet-stream
Size: 14908 bytes
Desc: 3714928906-robotd-udcounter.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060523/d26e8491/attachment-0001.obj