View source for Talk:GresSuffurd

I randomly came across this discussion today on oldwiki:The2100Club:

Phoenix was at .721 when I entered, and Dookious was at 1.27 when you entered? We've had some weird versioning stuff happening lately, man. =) -- Voidious

• wait till I get to 0.2.17 . . . -- GrubbmGait

I wonder what kind of weird thing will happen with your next version? =) --Voidious 00:32, 19 September 2009 (UTC)

Probably passing Phoenix and becoming third, or winning from the whole top-50 and losing from ad.last.Bottom. The frightning part is that I do remember this remark . . . --GrubbmGait 01:10, 19 September 2009 (UTC)

I had something special in mind for version 0.2.17. I wanted to take the #1 of begin October 2004 (CassiusClay 1.9.9.24 or Ascendant 0.9.1), rename/rebuild it and enter it in the rumble. This was ment as a honour the #1 at the time I entered my first bot. But then the truth struck me, it would end up lower than my current version. Now I will just make an update to my movement and this time I will test it against a few more bots than just my old version. Top-20, here I come ! --GrubbmGait 00:00, 24 September 2009 (UTC)

That's a funny train of thought. =) The top bots when I started definitely hold a special significance to me, too. Ascendant, CassiusClay, PulsarMax, Shadow, and SilverSurfer formed the top 5, I believe. Those bots definitely still represent specific milestones to me; I was so happy when Diamond passed Ascendant, even tho he hasn't been King for years! --Voidious 00:35, 24 September 2009 (UTC)

Bin Smoothing

I thought it might be useful for you to know about some testing I did a while ago, with regards to bin smoothing. I was trying to speed up my binsmoothing implementation by only using normal smoothing on the +-20 bins each side of the hit, and the rest of them just smoothing them towards 0 (the formula simplifies to just multiplying the bin value by a constant when smoothing towards 0, which was much faster). When I did this though, I lost a significant amount of score. I put this down to DrussGT not being able to say which way was 'safer' if it was stuck in an area that had never been within those +-20 bins.

My thoughts are that wavesurfing, when performing at optimal levels, has very little data to work with as there are very few bullet hits to log into the bins. Once I get a bullet hit, there are two possibilites that cover 95% of the bots in the rumble: either they are a learning gun and have seen me at that angle a lot, or they are a simple gun and always shoot at that angle for that set of conditions. There is a reason for both types of targeting that binsmoothing can help: for learning guns, that peak is not likely to be perfectly in the one point, due to the variation in movement etc. For the learning guns, if next time you move just slightly to the side, it is likely you have been there before, so they will quickly learn, as they don't have to add many wave hits to make that the new highest peak. In simple guns the segment covers a finite width of values, meaning that bullets on either side of this hit are likely when using this data for surfing in the future. As an example for this I imagine a linear targeting with a segmentation on lateral velocity, segmented say 0-2, 2-5, 5-8. A hit in the 2-5 segment, say with a lateral velocity of 3, will end up being used to predict bullets fired with lateral velocity of 2 or 4. Now, you could wait until you have enough bullet hits to say that there is danger all along the relevant range, but wouldn't you rather avoid those hits by just avoiding the entire area? =) Anyways, just my ramblings, although I do think you could gain quite a bit of score by using binsmoothing =) --Skilgannon 10:02, 9 July 2011 (UTC)

I understand your point, and it is a valid one. It really concerns 'surfing' on the slope of danger, instead of avoiding bricks with the chance of collateral damage. It is worth to test, as I am busy experimenting with my movement and botwidth-dangers. Binsmoothing in a gun I always found strange though, and with the knowledge of Precise Intersection it is an outdated technique in this field. --GrubbmGait 16:08, 9 July 2011 (UTC)

I'm in agreement that (bin)smoothing in a gun is strange. In fact, I never use it because I've always had precise intersection, and the times I've tried smoothing in targeting have always reduced performance. In contrast, I've always had smoothing in surfing, for the kind of reasons Skilgannon talks about. Actually though... I'd theorize that what might be optimal for surfing is to only use smoothing for tiebreaking... I think that should cover the issues Skilgannon mentions... --Rednaxela 18:44, 9 July 2011 (UTC)

"safe spot created by colliding bullets"

One little question. You say "Not because it is a safe spot, for that wave the complete range is safe", but isn't it the case that the spots of hypothetical wave-intersection are safe even if the bullets don't actually collide? When there is no actual collision, there is a safe spot, but it is not the case that "the complete range is safe". --Rednaxela 14:04, 14 August 2011 (UTC)

You're right, but that is not my intention. For now I only want to 'trick' the opponent into believing that I would be hit if the bullets had not collided, in other words: polluting his stats. When bullets collide, that wave is turned harmless and I just want to do something extra with that wave. I don't expect much influence on the ranking though. Implementing real bulletshielding would imply a close interaction between gun and movement, and this is not on my agenda. --GrubbmGait 17:11, 14 August 2011 (UTC)

Ahh, I see what you mean. I just meant, that even without a "real bulletshielding" gun, safe spots with no collision are created as a side effect. There seems to be a middle ground that doesn't require gun/movement integration. --Rednaxela 17:31, 14 August 2011 (UTC)

Currently I am busy with transforming my rough 'black' shadows (setting risk to zero) to more sophisticated 'gray' shadows, reducing risks depending on how much shadow is present per bin. Also due to Bullet Shadow/Correct. The problem is now that I get hit quite often while under a shadow (15% of the hits) or that I get a BulletHitBullet event just outside the shadow (also 15% of the events).

When determining the wave that hit me (or my bullet) I use the enemyBullet location as hit-location, and compare the distance between firelocation and hitlocation with the distance the enemybullet would have traveled. For real hits it is always spot on, only some rounding behind the comma. For BulletHitBullet hits, it is always 1 bullettick (70%) or 2 bulletticks (30%) off.

So basically, I don't trust my shadows as the BulletHitBullets don't line up with the real hits. Does anyone of you have the same experience and has any solution for my problem. I do know that I don't do everything perfect yet, f.e. I don't remove shadows on other waves when there is a BulletHitBullet event.

According to Robocode/Game Physics:

1. All bullets move (including the bullet fired in the last tick) and are checked for collisions.
2. All robots move (gun, radar, heading, acceleration, velocity, distance, in that order. gun heat is also decreased in this step).

However there are details not noted. If bullets get collided, they are moved back 1 tick. If bullet get collided before it moves (due to order of updating), they are also moved back 1 tick, resulting 2 tick behind in total. I remembered doing same thing, and discovered correct bullet shadow, but did not implement due to having problems with integral risk.

Ah, thanks for the info, so I am doing it the correct way. Now I only have to hammer the details right.

Congrats!:) Where you, Skotty, Skilgannon and AW take ideas, inspiration and strength for moving forward?:) I cannot find a way to improve Tomcat and Violet (my new Tomcat-based bot) is [more] worse and I can not get the ball rolling...

Normally I wouldn't want to lose third place, but I'll be rewriting my movement so maybe it won't happen.

1) According to the TCRM, you could make some huge improvements in targeting. I would suggest switching to GF KNN for the moment. I have some ideas on a new PIF based targeting strategy, but as far as current guns go, I think GF's are best.

2) Next, it appears from Tomcat's graphics that you have bugs in your bullet shadows where you place a new shadow over an old one (which could result in negative danger.)

3) Also, if you really want to improve ranking, you could probably squeeze some points out of classification schemes that are more complex and are enabled at certain hit rates. Personally, I like teh way you currently do it much better, but when I originally tried a similar method in pre-release versions of Gilgalad, my results were not very good. Regardless, I think you could gain some points by having hand selected classification schemes that included reverse wall distance, etc.

4) Maybe bullet power. Don't know how you do this, but you appear to fire with lower bullet power than I would usually use.

5) And of course, the real way to improve is probably bug hunting. A perfect score against HawkOnFire over 1000 rounds MUST be possible.

As regards a perfect score against HawkOnFire, I have been running some tests, and it appears that HowkOnFires shoots at angles quite distant from guess factor 0.

(From a 1000 round battle, GF = -100.0 means I failed to detect the wave when it was fired or couldn't find a match for some other reason.)

---

148Hit GF = -100.0

---

207Hit GF = 0.1636332953564261

---

89Hit GF = -0.11944245243219632

---

208Hit GF = -0.2328668375113637

---

75Hit GF = -100.0

---

84Hit GF = -0.12453026743165671

---

88Hit GF = -0.13356419636603006

---

273Hit GF = -100.0

0.1 seems to be a fairly large deviation from 0.0. Any thoughts? Anyone else see this before?

Yes, it's old and known "problem". I did not research it, but i think, that its Hawk's issue

Isn't it because HoT targeting shoots one turn after it calculates the angle?

Example:
both bots are perpendicular to each other on the x axis and have a distance of 100 - the calculated angle would be 90deg
bot one moves +8 and bot two -8
if bot one shoots the next turn with 90deg angle it would be 9deg difference to the center he targeted the last tick.

Of course this is the worst case and scales on distance and relative velocities to each other.

As far as I remember HOF doesn't use setAdjustGunForRobotTurn and also just spins its radar, so if you get a bad combo it isn't anywhere near GF0. I've seen as bad as GF+0.3. I'm sure you could improve your score by also dodging the bullet if it was fired at your last 8 locations and adjust the angle based on if they are turning and hadn't adjusted their gun for it yet this tick. Trouble is it will hurt against other bots :-)

HoF has an infinity lock, which slips quite frequently. And it looks like, he shoots whit in the run method and not in onScannedRobot(..) what makes the HoT angle even worse. Not sure about the setAdjustXX(..) but it would make it even more unstable.

As conclusion i would say there is no bot that shoots at GF0 all the time.

Except maybe GF guns with precise future position aiming against SittingDuck.

But even if you have perfect prediction of your opponents targeting, there is still the occasional ramming score due to bots spawning too close to each other in the beginning of a round, making perfect scores almost impossible against moving opponents.

You can get unlucky with an enemy that spawns to close and starts moving before it knows where the enemy is, or has a bad movement. Which then rams into your robot. But not much you can do in robocode against bad luck. Except try to minimize it.

Wow, cool analisis from direct competitor:) Thank you, but unfortunately for me i know all this issues - i don know how to solve them - Any change in Tomcat last few month lead me to score loss

Congratulations on the improvements in the latest version. My inspiration is mainly that I am still having fun. I still have a number of aspects to my robot that can be optimized further. As for unique innovative ideas, I often brainstorm by myself, but most of my ideas don't pan out. I do have one idea right now that I think is promising, but it will take some work so I probably won't get around to it for quite some time.

Thanks! The ideas are all around in the discussions on this wiki. When I 'get' something, and I like it, I try to apply it to my situation (like Precise_Intersection). Only this autumn I finally understood what a flattener is (just one remark from someone), and I am working on one now. The drive for the current change is plain simple: I wanted to be in the top-10 at the end of the year. Time is the limiting factor. The last couple of years I have only 'bursts' of activity, lasting a few weeks and after that a few months of silence. My drive is not to be the best, my drive is to be as good as possible doing it my way, with the limitations I choose. I am proud of GrubbmGrb, which is just a collection of simple concepts together with some specific ideas (like distance dependend drive-in protection). But it outperforms BasicGFSurfer which concepts are clearly better. Frankly, I am proud of all my bots, because I made them and they do more or less what I intended. Sometimes I am happy to run my client for a month, delivering 9000 battles a day. The point is, what do YOU want. Do you only want to be the best? Then you'll get frustrated that you are only nr 4. Do you want to be as good as possible? You already succeeded, beating 966 out of 970 opponents. My list of 'things to do' is still long, but when I have time and feel like it, I pick a thing from the list and try to do just that. It took me two years to have the best Dutch bot, it took me 5 years more to enter the top-10. I don't mind, I will be around next year and the year after.

To make it short: you decide what drives you. Good luck with finding inspiration.