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