Cool. I'd love to help, but unfortunately I'll be out of the loop for a few days; I have several assignments to do due tomorrow, an assignment due in an hour and a half, and I'll be out of town till saturday night; the latest I'd be able to start is sunday, but I have a test and a midterm exam next week. Unfortunately I can't participate now, but hopefully soon when I catch up in my classes I'll have more free time to work on Fractal and RR@H. -- Vuen
OK, this is for the record. I've made an implementation of a data manager that should prevent the concurrent updates. Though it's a bit trickier than I had thought and I'm not sure I've got it right. I've sent it to Albert for review. If someone feels comfortable with this sort of multithreaded programming please let us know. -- PEZ
Now we have the updated data manager class deployed. Please try to observe the output from the RR@H client a little closer than usual and report any problems obeserved here. If the update should cause the updates to fail totally, no worries. Things at least should fail reliably and the client will upload the data once the server is fixed. -- PEZ
Albert, we still have that .5 at the end of the battle count. Is there some way I can clean the data files on the server to get rid of this? Also, the battles_roborumble.txt file is 15 megs in size. I might have asked this before; will it grow much more than that? -- PEZ
The battles_roborumble file will grow up and up. It logs all the records received by the file. Just delete it, it will not harm anything. I'w take a closer look into the .5 (I'm thinking it can happen even if the updates are OK). -- Albert