Difference between revisions of "User talk:J Litewski"
(→Wiki issues: be bold =)) |
RednaxelaBot (talk | contribs) m (Using <syntaxhighlight>.) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 45: | Line 45: | ||
Gunheat code (rapid-cooked now, hasn't test yet) | Gunheat code (rapid-cooked now, hasn't test yet) | ||
| − | < | + | <syntaxhighlight> |
class GunheatTracker { | class GunheatTracker { | ||
private double gunHeat; | private double gunHeat; | ||
| Line 70: | Line 70: | ||
} | } | ||
} | } | ||
| − | </ | + | </syntaxhighlight> |
You must detect energy drop yourself. I will write more when I come home. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 09:37, 5 June 2009 (UTC) | You must detect energy drop yourself. I will write more when I come home. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 09:37, 5 June 2009 (UTC) | ||
| Line 79: | Line 79: | ||
I built an Utilities class that uses a very simplistic method to track of stuff. Currently, with the help of some quick hacks, it helps weed out non-bullet waves. I'm running a 500 round test now to see if it improved anything. --[[User:J Litewski|Jacob Litewski]] 00:54, 6 June 2009 (UTC) | I built an Utilities class that uses a very simplistic method to track of stuff. Currently, with the help of some quick hacks, it helps weed out non-bullet waves. I'm running a 500 round test now to see if it improved anything. --[[User:J Litewski|Jacob Litewski]] 00:54, 6 June 2009 (UTC) | ||
| + | |||
| + | == 2D Segmentation Smoother == | ||
| + | |||
| + | Ok, this woke me up out of the deepest sleep I had in years. I was trying to figure out the best way to log hits with [[GravityWave]]'s new segmented array. I thought the original logHit function was doing it's job. Well, it hit me, it saw storing the data like a 1D array, not like a 2D segmented array. For instance, data on <code>test[8][8]</code> (which is a 9x9 array) is laid out like this: | ||
| + | <pre> | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | </pre> | ||
| + | When it was storing the data, it would store it like this (if hit on the 2D GuessFactor of 0 (5x5)): | ||
| + | <pre> | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 1 2 3 4 3 2 1 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | </pre> | ||
| + | Instead, it should be storing it like this: | ||
| + | <pre> | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | 0 0 0 0 1 0 0 0 0 | ||
| + | 0 0 0 1 2 1 0 0 0 | ||
| + | 0 0 1 2 3 2 1 0 0 | ||
| + | 0 1 2 3 4 3 2 1 0 | ||
| + | 0 0 1 2 3 2 1 0 0 | ||
| + | 0 0 0 1 2 1 0 0 0 | ||
| + | 0 0 0 0 1 0 0 0 0 | ||
| + | 0 0 0 0 0 0 0 0 0 | ||
| + | </pre> | ||
| + | Note that it will not be this dramatic of a spike. But if this works the way I think it will, it will be a 2D BIN Smoother, or 2D Segmentation Smoother as I call it, since it does smooth the BINS biased on where the hit took placed on the Segment. This should make it easier to go from one segment to the next without to much fuss (like I have been having) and optimize the danger checker. Here is the code: | ||
| + | <syntaxhighlight> | ||
| + | public void logHit(EnemyWave ew, Point2D.Double targetLocation, int segment) { | ||
| + | int index = getFactorIndex(ew, targetLocation); | ||
| + | |||
| + | //New 2D Segmentation smoother | ||
| + | for (int x = 0; x < 13; x++) { | ||
| + | for(int y = 0; y < BINS; y++) { | ||
| + | _surfStats2[x][y] += (Math.pow(segment - x, 2) + 1) / (Math.pow(index - y, 2) + 1); | ||
| + | } | ||
| + | } | ||
| + | |||
| + | } | ||
| + | </syntaxhighlight> | ||
| + | Tell me what you think please :) --[[User:J Litewski|Jacob Litewski]] 03:56, 12 June 2009 (UTC) | ||
| + | |||
| + | It's been done by a few people before and isn't a bad idea. However, the two things that should be kept in mind: '''1)''' You generally want less smoothing across segments than across bits but doesn't hurt to experiment, and '''2)''' This will get SLOW when/if you start having upwards of 5 different segmention axis like many/most high ranking bots have. Additionally, here's another thing you can try: | ||
| + | |||
| + | if you're writing and you're halfway between segments, write half in each like this: | ||
| + | <pre> | ||
| + | 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 | ||
| + | 0.0 0.5 1.0 1.5 2.0 1.5 1.0 0.5 0.0 | ||
| + | 0.0 0.5 1.0 1.5 2.0 1.5 1.0 0.5 0.0 | ||
| + | 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 | ||
| + | </pre> | ||
| + | and if you're closer to one side than another, weight your insertion towards that side. Then when reading, you do a similar thing, like if you're halfway between segments looking like | ||
| + | <pre> | ||
| + | 0.0 0.0 0.0 0.5 1.0 1.5 2.0 1.5 1.0 | ||
| + | 1.0 1.5 2.0 1.5 1.0 0.5 0.0 0.5 0.0 | ||
| + | </pre> | ||
| + | you will shoot by taking the highest point of | ||
| + | <pre> | ||
| + | 1.0 1.5 2.0 2.0 2.0 2.0 2.0 1.5 1.0 | ||
| + | </pre> | ||
| + | Which is a technique that massively boosts score in [[Rednaxela/SaphireEdge]]... though... nobody other than me has implemented it to my knowledge... as it does get a little complicated when you get into a large number of segment dimensions... :) --[[User:Rednaxela|Rednaxela]] 04:13, 12 June 2009 (UTC) | ||
| + | |||
| + | I haven't even thought of shooting yet... heh | ||
| + | Anyways, after testing it, I noticed my score drop massively. so I looked into the fight and saw my problem: I didn't have 'levels' of arrays for bullet power. So, I'm testing my new(er) Leveled 2D Segmentation Smoothing, Leveled with 4 levels biased off of bullet power and segmented with a 2D array biased off of distance and BINS respectively ( or [power][distance][BINS]). Hopefully this will work better and learn faster. --[[User:J Litewski|Jacob Litewski]] 04:29, 12 June 2009 (UTC) | ||
Latest revision as of 09:42, 1 July 2010
|
Welcome! Hello, J Litewski, and welcome to RoboWiki! This place contain a wealth information about Robocode, from basic to more advanced. I hope you enjoy creating a robot and being a robocoder! If you are posting a comment on this wiki, please sign your messages using four tildes (--~~~~); this will automatically insert your username and the date. If you are not familiar with MediaWiki, these links might help you out:
If you need help, check out the frequently asked questions or ask it on this page. Again, welcome! —— Nat 23:26, 14 May 2009 (UTC) |
Hey, welcome! Good luck with your bots, and feel free to post any questions you have. Also, by the way, info about you should technically go on your user page, while this page would be for posting questions / comments to you (or about your page, I guess). --Voidious 17:47, 14 May 2009 (UTC)
Hi! Write more about yourself to your userpage, I'd be interested in it. And don't afraid of submitting your bots to RoboRumble. :) (it's very motivating and educational)--HUNRobar 18:02, 14 May 2009 (UTC)
Wiki issues
Hi! Please mark an edit as minor edit when you just correct grammar or adding links. And please write edit summary when edit, it help other robocoder to know what is changed briefly. Mroe information about this can be found on Wikipedia. Thanks! » Nat | Talk » 06:35, 18 May 2009 (UTC)
Hi Litewski. In your recent contributions to Bin Smoothing page and some other pages, you use CamelCase words in some links text, such as GuessFactorTargeting, which is, by the standard of this new wiki, deprecated. The correct name with proper spaces is defined. The old CamelCase page still work as a redirect page, but it is better to link to the exact page instead of redirect page.
Another issue: Standard heading level of the wiki is start at 2, threfore you should use level 2 heading (== Heading ==) instead of level 1 heading, which is use by page title itself. In some od your contributions to the page GITS and its subpages, you have the level 1 heading which have the same text as page title, which is not needed and make the table of content look funny. Thank you! » Nat | Talk » 03:00, 9 June 2009 (UTC)
- sorry for the problems, still kinda new to this. --Jacob Litewski 03:12, 9 June 2009 (UTC)
Handle
Hay, why "HACKhalo2"? » Nat | Talk » 14:40, 21 May 2009 (UTC)
"HACKhalo2" is my XBL handle way back when I had Xbox Live. I just used it from then on because I liked it. It's also because I use to hack Halo on the PC and create custom CD's that booted like the original. --HACKhalo2 16:41, 21 May 2009 (UTC)
Talk about GravityWave
As some of you guys know, GravityWave, my newest Sandbox for GITS, is a combination of Wave Surfing and Anti-Gravity Movements. It focuses mainly on Wave Surfing, using Voidious' BasicSurfer as a base and building off of that. It'll use a modified Anti-Grav Movement for enhanced wall smoothing and enemy avoidance. Anyways, I need help working on some of GravityWave's features, since I'm new to this advanced stuff. Here is some things that I would like to add in sooner or later (with more to come):
- Segmentation (always a plus)
- Better Algorithms
- Enemy GunHeat Class (to weed out non-bullet waves) (finished)
- And more stuff I can't think of
I did tweak the base a little bit (changed the radar, added in some more debug graphics, minor things), but other than that, nothing to drastic yet. So, go wild with your comments! --Jacob Litewski 03:05, 5 June 2009 (UTC)
Gunheat code (rapid-cooked now, hasn't test yet)
class GunheatTracker {
private double gunHeat;
private final double coolingRate;
public GunheatTracker(AdvancedRobot r) {
gunHeat = r.getGunHeat(); // initialize gunheat to 3
coolingRate = r.getGunCoolingRate();
}
public double eachTick() {
gunHeat -= coolingRate;
gunHeat = Math.max(gunHeat, 0);
}
public double enemyFire(double power) {
if (!isFirable())
throws new IllegelStateException();
gunHeat += 1d + power / 5d; // according to Robocode rules.
}
public boolean isFirable() {
return gunHeat <= 0.000001;
}
}You must detect energy drop yourself. I will write more when I come home. » Nat | Talk » 09:37, 5 June 2009 (UTC)
OK, at home now. I don't think you need to detect enemy gunheat unless you are in melee (which need a lot of other components to make the class above work), or want the extra 2 ticks (as in DrussGT and RougeDC) to surf. Otherwise, it is much more easier to detect the thing by energy drop (you will need to do that if you want the class above work too) and adjusted the energy on the events (onHitRobot, onHitByBullet and onBulletHit). Anyway, this only work for one-on-one, in melee, you need to interpolate (a lot), do some statistical recording to predict the whole battle (two months work, don't seem to make much progress). » Nat | Talk » 13:33, 5 June 2009 (UTC)
Well, I just want a simplistic GunHeat class to weed out non-bullet waves that GravityWave seems to surf, mostly into bullets. It's more or less if enemy fired with x power, don't calculate waves for x ticks type thing. --Jacob Litewski 15:55, 5 June 2009 (UTC)
I built an Utilities class that uses a very simplistic method to track of stuff. Currently, with the help of some quick hacks, it helps weed out non-bullet waves. I'm running a 500 round test now to see if it improved anything. --Jacob Litewski 00:54, 6 June 2009 (UTC)
2D Segmentation Smoother
Ok, this woke me up out of the deepest sleep I had in years. I was trying to figure out the best way to log hits with GravityWave's new segmented array. I thought the original logHit function was doing it's job. Well, it hit me, it saw storing the data like a 1D array, not like a 2D segmented array. For instance, data on test[8][8] (which is a 9x9 array) is laid out like this:
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
When it was storing the data, it would store it like this (if hit on the 2D GuessFactor of 0 (5x5)):
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Instead, it should be storing it like this:
0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 2 1 0 0 0 0 0 1 2 3 2 1 0 0 0 1 2 3 4 3 2 1 0 0 0 1 2 3 2 1 0 0 0 0 0 1 2 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
Note that it will not be this dramatic of a spike. But if this works the way I think it will, it will be a 2D BIN Smoother, or 2D Segmentation Smoother as I call it, since it does smooth the BINS biased on where the hit took placed on the Segment. This should make it easier to go from one segment to the next without to much fuss (like I have been having) and optimize the danger checker. Here is the code:
public void logHit(EnemyWave ew, Point2D.Double targetLocation, int segment) {
int index = getFactorIndex(ew, targetLocation);
//New 2D Segmentation smoother
for (int x = 0; x < 13; x++) {
for(int y = 0; y < BINS; y++) {
_surfStats2[x][y] += (Math.pow(segment - x, 2) + 1) / (Math.pow(index - y, 2) + 1);
}
}
}Tell me what you think please :) --Jacob Litewski 03:56, 12 June 2009 (UTC)
It's been done by a few people before and isn't a bad idea. However, the two things that should be kept in mind: 1) You generally want less smoothing across segments than across bits but doesn't hurt to experiment, and 2) This will get SLOW when/if you start having upwards of 5 different segmention axis like many/most high ranking bots have. Additionally, here's another thing you can try:
if you're writing and you're halfway between segments, write half in each like this:
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.5 1.0 1.5 2.0 1.5 1.0 0.5 0.0 0.0 0.5 1.0 1.5 2.0 1.5 1.0 0.5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
and if you're closer to one side than another, weight your insertion towards that side. Then when reading, you do a similar thing, like if you're halfway between segments looking like
0.0 0.0 0.0 0.5 1.0 1.5 2.0 1.5 1.0 1.0 1.5 2.0 1.5 1.0 0.5 0.0 0.5 0.0
you will shoot by taking the highest point of
1.0 1.5 2.0 2.0 2.0 2.0 2.0 1.5 1.0
Which is a technique that massively boosts score in Rednaxela/SaphireEdge... though... nobody other than me has implemented it to my knowledge... as it does get a little complicated when you get into a large number of segment dimensions... :) --Rednaxela 04:13, 12 June 2009 (UTC)
I haven't even thought of shooting yet... heh Anyways, after testing it, I noticed my score drop massively. so I looked into the fight and saw my problem: I didn't have 'levels' of arrays for bullet power. So, I'm testing my new(er) Leveled 2D Segmentation Smoothing, Leveled with 4 levels biased off of bullet power and segmented with a 2D array biased off of distance and BINS respectively ( or [power][distance][BINS]). Hopefully this will work better and learn faster. --Jacob Litewski 04:29, 12 June 2009 (UTC)
