Plains

Plains is my new robot, with a SandboxFlattener (with no WallSmoothing yet) and DynamicDistancing in a micro. I'll add more information when i have time/release it. --Starrynte

Ok, I need a bit of help with the WallSmoothing. Also, if you would be kind enough, Simonton, Skilgannon, other CodeSize writers, could you kinda shrink the code (if possible) and if you want comment the part you changed (srri about the comments, those were from debug). Thanks all! --Starrynte/Plains

The skipped turns (and occasionally stopped) decreased if the wall stick length was reduced and/or the '0.2' in the code changed to '0.3'. Version 0.9 will be released soon. (Note: this is an OpenSource bot). --Starrynte

If you want, you can uncomment the paint() stuff and look at where the bot goes when it smooths, although i don't know if that will help with the skipped turns...which is what i REALLY need help with as the bot is completely STOPPING every like 3-5 rounds! HELP, please! Code is at Plains/Code. As a side effect, if you want to shrink the code, please point out where I can! Thanks --Starrynte

• Oh, and also using FloodGrapher, there seems to be a huge spike at GF 0.0 and nowhere else...which I assume is due to the stoppings/skipping turns --Starrynte

What are you using to program this bot? And wow this is really obfascated, it might take me awhile to unravel. Other than that I see som places you could save some codesize, (ergo you only use x once, so no need to assign getX() to a variable). All I can really say is expand your code, write it out, make it work then optimize for size, otherwise you could lose yourself within the many many brackets. --Chase-san

• about the x thing: its mainly for protection of the calling of getXXX() functions too many times...as for the codesize...well...the only real "problem" is in the WallSmoothing, which i ASSUME is causing the stoppings and skipping turns...however i'll conduct a little survey to find out :) --Starrynte
• If you want it, you have my full permission to rip the wallsmoothing out of jk.nano.Machete. It works flawlessly, is small, and I think it's pretty easy to understand. That commented line is what you use instead to enable to painting. Or you could just compare it to your smoothing, step for step. Oh yes, I stuck tempMove in there because it reduces the codesize, but otherwise it could be replaced with move. Take a look at my way of constructing the goAngle, as well. -- Skilgannon
• thanks! ok it nearly works, except...
  • sometimes it doesn't even smooth! (i.e. it crashes into the wall)
  • sometimes it gets disabled because of too many getXXX() calls, presumably in the wallsmoothing
• probably because it was transferred directly from Machete?...oh well, after another hour of frustration i should be able to get it... --Starrynte, code not yet updated on the wiki

Nearly forgotten about this bot...Anyways: everything works, EXCEPT, 10% of the time (for real), it stops...I'll see if i can fix it tomorrow by DiveProtection OR by using a loop where the amount "smoothed" gets more and more as there are more iterations...anyways the bot works perfectly except for the WallSmoothing...since there is a GF0 spike at velocities lower than 3, but no spikes at all at velocities higher than 3. (according to FloodGrapher) --Starrynte

• Hrm, all I can think of is if its a generic problem somewhere or if they entire setup is mssed up somewhere, check for basic problems, say integer problems (1 = integer, 1d or 1.0 is double), reassignment problems (check to be sure all values are assigned correctly). Eclipse can help on atleast the second for checking for unused declarations. --Chase-san

I'll release version 0.9 today or tomorrow...WallSmoothing works now...here's the flattest i've been able to get using the SandboxFlattener :
(red is StatistRobot, blue is FloodGrapher)
Also, I have 38 bytes of free code to play with, any suggestions? (maybe a better gun, the one so far is only HOT) --Starrynte Any suggestions for a gun when I have 105 bytes of code to play with now? (credits to major code shrinking) --Starrynte

Hmm, well there are some small pattern matchers out there, but I'm doubting one could fit in 105 codesize. Maybe some thing like Splinter, who shoots at random places between HOT and linear targeting but mostly closer to linear could fit?