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 MC49k7 and MC59k7 (Etna 1.4 vs Scarlet 1.0's movement versions respectively). :) — Chase-san 13:15, 23 August 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.

Make that 3 times. =) Since it's the GigaRumble, I don't mind just setting my client to 1024mb. But if this is a frequent problem at 512mb, I could see this killing a lot of RoboRumble clients.

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.