View source for Talk:Scarlet

Scoring above Phoenix - very impressive! Which combo is this? --Skilgannon 10:25, 23 August 2011 (UTC)

Combination is Nene MC59k7 + RougeDC willow, and it completely surpassed our expectations. — Chase-san 10:33, 23 August 2011 (UTC)

Scoring above Phoenix where Etna 1.4 did not, was really mostly due the gain of bullet shadows between Nene MC49k7 and MC47k7. While not doing much to APS score, the switch to the RougeDC gun really makes it... not so much of a pushover when fighting strong bots like Shadow ;) --Rednaxela 12:48, 23 August 2011 (UTC)

He means between MC47k7 and MC59k7 (Etna 1.4 vs Scarlet 1.0's movement versions respectively). :) — Chase-san 13:15, 23 August 2011 (UTC)

(Er, yep. Silly numbers getting mixed up in my head) --Rednaxela 13:24, 23 August 2011 (UTC)

Strangely nostalgic for me to see Dookious drop another spot. =) Keep up the good work. --Voidious 15:24, 25 August 2011 (UTC)

Have you run Scarlet in RoboResearch? I was going to replace SilverSurfer in my tough-matchups test bed, but I'm getting this error in every Robocode version I've tried:

Thead 0: Unrecognized output from robocode, "cs.ags.Scarlet: Got an error with this class:
java.lang.IllegalStateException: Can't overwrite cause".  Killing battle.
Problem running sample match, aborting

It works fine running it in the same Robocode install used by RoboResearch, so I'm not sure what's going on. Both 1.0 and 1.1. Any insight? --Voidious 15:18, 27 August 2011 (UTC)

Er... I have run Scarlet under RoboResearch, and it worked just fine. That's a really strange error. Also, is there not a full stack trace sent to the command line? --Rednaxela 18:00, 27 August 2011 (UTC)

No stack trace. It's also "Thread 0", when normally battles are run on "1" and "2", so maybe it's in the setup phase (copying robot JARs into place and such), though that makes even less sense to me. Thanks for the feedback, I'll try and figure out what's up... --Voidious 18:07, 27 August 2011 (UTC)

Another piece of info is I get a similar message for sample.VelociRobot on a fresh install. That's happened for a while and I always just delete the sample bots and move on. I figured it was some anomaly with un-JAR'd bots and RoboResearch... This is on the CLI, not the GUI, btw. --Voidious 19:37, 27 August 2011 (UTC)

I'm thinking this is caused by the "robocode.jar" issues you're having with Roboresearch on User talk:Chase-san? I know Scarlet only works on Robocode 1.7 and up, and I'm pretty sure the same goes for sample.VelociRobot (I don't think that specific sample bot existed in 1.6). --Rednaxela 20:05, 27 August 2011 (UTC)

Yeah, definitely. Sorry this discussion got spread across two pages. --Voidious 20:08, 27 August 2011 (UTC)

The funnest part of this robot is that it works far better then I really figured it should.

Nene is very good at dodging simple targeting (not to shabby vs adaptive). Where as RougeDC is very good at hitting very adaptive movement (not to shabby vs random/simple).

Common Wisdom dictates that these two things should balance each other out and create an overall decent robot, by making up for each others weaknesses. The awesome part is that in this case this holds entirely true. But I entirely expected the exact opposite result (as things usually go).

— Chase-san 14:32, 17 October 2011 (UTC)

I've hit OOM errors for Scarlet twice in the past couple days, this time vs DrussGT. Anything you can do to alleviate that? I hate to risk my RR clients dying, but I'd hate to have to exclude Scarlet to avoid it.

Alright, I'll see if I can give it a go fixing that tonight.

Actually, I'm not sure why this would just start happening now. I think I've only seen it happen vs DrussGT, but I didn't think he changed his memory usage. If I'm the only one hitting it (and I've only hit it on my Mac), it's actually no problem to just up my client's memory to 1024mb. But overall that's not a good solution since everyone else is using 512 mb.

I had 2 clients go down with OOM as well. DrussGT is using more memory than it used to, but it has lazy allocation. The problem might be that Scarlet decides to shoot with 0.1 the entire battle because it can't hit me and then I end up using more memory than against anybody else. I'll reduce the depth of my buffers a bit and see if it helps.

I just had another OOM, this time DrussGT 2.7.3 vs Scarlet. I don't know how, because I tested locally and they don't get above ~350MB usage. Is Scarlet at all susceptible to dramatic increases in memory if the game goes on for longer than expected?

I just found an OOM against Diamond 1.8.7... so it seems to be a Scarlet-in-long-battles problem.

Recently I ran a bit of memory profiling and it seems that the dominant memory use is the "Single Tick" pattern matcher. I think the reason it uses so much memory is a combination of 1) how "flat" their movement profile is to pattern matching, and 2) how long the battle is...

It's interesting that we haven't seen the same occur with RougeDC which has the same targeting system, though Scarlet does get a bit 'cheekier' with bullet power in some situations and has a movement better capable of holding out longer...

Looking over some of that old code, I think I see some simple ways to reduce the memory usage, but it just occurred to me... this pattern matcher is storing a tree of maximum depth 15, with up to 55 branches per node... which means that in a sufficiently long battle against a sufficiently unpredictable enemy, the memory usage could eventually (if given a 128-bit addressed memory space and infinite system resources...) grow to a point where it would be measured in yottabytes :S

Wow, that's a yottabytes! (Sorry.)

Yeah, I just noticed it was removed from the rumble. I guess this is why. :)

Does the Single Tick PM even gain you anything? I'd try just disabling it completely...

Don't know, I only did the movement. :)

Actually, it's kind of essential for the anti-surfer abilities of the targeting system. It doesn't add much value most of the time, but it's a significantly different targeting system which it tends to "shake things up" with when the enemy learns it's main targeting too well.

I'd rather fix the memory use of the single tick PM than just disable it, partially because the targeting system's automatic weighting is a bit touchy.