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