Thread history
| Time | User | Activity | Comment |
|---|---|---|---|
| No results | |||
Instead of switching to Distributed Robocode when the rumble stabilizes, which is hard to detect, doing the opposite, running rumble battles after challenge processing finishes is feasible.
For that you would have a graphical client in which you edit the process queue. You can queue as many challenge jobs you want, and can queue a rumble contribution job. Only rumble contribution is a job which consumes all instances, never ends and must be aborted manually.
This central client can group battle results before sending them to the server. It would accomplish 2 things. Uploads are independent from the number of instances, diminishing server load. It would also upload asynchronously (while battles are running), making it "lightning fast" even with the current protocol. But uploading one pairing at a time and downloading priority battles being dependent on uploads is still annoying.
