User talk:Chase-san/NeoRoboRumbleParticipants

Stand by, there seems to be extra configuration somewhere in the server code that bars wrong number of battles. (you should put all this in the config Dark!) — Chase-san 13:50, 8 July 2011 (UTC)

The config file was meant for server-specific configuration, that's it (I suppose the server title could go in there too). Game types are defined in GameType.php -- that's where you'll want to make all your changes. --Darkcanuck 22:33, 8 July 2011 (UTC)

All fixed! — Chase-san 13:56, 8 July 2011 (UTC)

Changed to 3 rounds, a single round causes too much traffic and lags the server pretty badly. — Chase-san 14:51, 8 July 2011 (UTC)

Also as a side note, i'll be running this only once and awhile and not constantly until there are enough robots in it to justify running it constantly. As things are still on a trial basis, changes to the rounds run, field size and datasaving/other rules are still up the air a little bit. — Chase-san 15:18, 8 July 2011 (UTC)

If this takes off, send me a patch (or the changed files) and I can add this to the server. --Darkcanuck 22:33, 8 July 2011 (UTC)

I would prefer if the number of rounds were kept at 1 instead of 3. I don´t care if the client keeps uploading data most of the time. The time taken to stabilize the scores will be fast either way.

I would also prefer if battlefield size were 800x600. So NeoRumble becomes a benchmark for RoboRumble 1v1.

I can upload all battles again in the case of a database reset.

A point of the neoroborumble was to make it a new rumble. Not just the roborumble but shorter.

I wanted to prevent wholesale moving of robots from the roborumble to the neoroborumble. Changing the size means people at least had to go in and adjust bots in which the field size is hard coded.

I really jsut like 3 battles more. 1 battle doesn't really tell you enough about its early behavior, except if it got unlucky position or not.

I like 3 much more myself, but it is opinion based.

But mostly because 1 seemed to hit the server hard and fast and constantly which is not so good for the poor server. 3 seemed more acceptable in the time it took before uploading again.

Telling me that 'you don't care' doesn't make me want to change my mind so much.

Additionally the neoroborumble was mostly made for new (robot) participants. So they didn't have to go through the pain of fighting the rankings with 600 other, possibly very older robots.

I was going to remove the some of the seed robots after more got added, but that never happened really.

Increasing the number of battles per batch from 10 to, maybe 350, can workaround the issue of constant uploads.

Testing locally, I noticed 1 round and 3 rounds have a lot of difference. Combat does about 45% average against Seraphim in 3 rounds, and about 18% average in 1 round. Uploading lots of battles averages out unlucky positions.

And its funny to see the client console scrolling with a lot of battle results popping up fast.

I suppose I can reset it to a single round if we do that.

Wow doing that makes me feel like Robocode should have some kind of bulk upload method, instead of one at a time.

Suggest setting it to at most 200 battles at a time. :)

I think the same whenever I see a client uploading 45 pairings per battle in meleerumble.

...as a comment, I was working in another client/server optimized for batch processing, including batch uploads, but after working 2 weeks in a GAE compatible server, I discovered they don´t accept free deploys anymore. So the project is stuck.

Wouldn't it be as simple as something like.

• Take all items in results text file
• Transfer it to the server via POST
• Server reads each entry and puts it where it belongs.
• You're done.

http://www.javaworld.com/javaworld/javatips/jw-javatip34.html http://php.net/manual/en/reserved.variables.post.php

If uploading was the only thing being changed, yes. But building this client/server came from that discussion about rankings a while ago.

Seraphim and Combat were flipping ranks quite a lot, until about 500 battles per bot, but I let it run until like 2k battles so APS score stopped changing and I could measure the difference in scores.

Ah well, I guess I was wrong then. But mostly concerned with all the extra data the few early robots would have before more entered.