Thread history

From Talk:Oculus
Viewing a history listing
Jump to navigation Jump to search
Time User Activity Comment
12:34, 1 September 2017 Xor (talk | contribs) Comment text edited  
12:30, 1 September 2017 Xor (talk | contribs) New reply created (Reply to Bullet Shielding)
22:14, 30 August 2017 Skilgannon (talk | contribs) New reply created (Reply to Bullet Shielding)
21:27, 30 August 2017 Skilgannon (talk | contribs) New reply created (Reply to Bullet Shielding)
15:13, 30 August 2017 Xor (talk | contribs) Reply split to a new thread (Bullet Shielding)

Bullet Shielding

Looking at your results, I was quite curious about bullet shielders. It's the first time I actually understand this strategy, just watched a game. You get almost zero score against DrussGT, for example. It just sit there and block your bullets. I think I may safely assume those were all head-on shots. One thing I noticed is that DrussGT can't block Roborio, even though it was supposed to shoot head-on for the first shots, while there is no data. Does that mean that I'm not shooting head-on at all, right? That's weird...

Rsalesc (talk)20:50, 29 August 2017

One thing that is very important is that a BulletShielder needs to know the EXACT firing angles of your targeting. Even if there is a little deviation, it just don't work. That's why SimpleBot and Roborio should has no problem with shielders.

Xor (talk)03:00, 30 August 2017

Yeah, what intrigues me is where this deviation actually come from, since there is a lot going under the hood, and why Oculus doesn't have such "problem". I know it makes perfect sense. It's just too obscure.

Rsalesc (talk)03:08, 30 August 2017

First, a BulletShielder would simulate a traditional HOT that is aimed from one tick before, not real fire position, as that position is your position when aiming (onScannedRobot). If it still hits, it would fallback to simulate a state-of-the-art HOT that is fired from real position, which means an advanced firer that predicts its own movement one tick forward on aiming.

However, if you are firing at real position, it is impossible for a BulletShielder to shield without moving. Therefore, for those who fire at real position, a shielder must move a little to be able to shield. And that's where the deviation comes from.

Therefore for a learning gun which fires from real position and is able to learn that tiny move, BulletShielders don't work.

Xor (talk)03:21, 30 August 2017

Hmmm, it should be obvious, right? Traditional HOT isn't actually going straight to the enemy's center, so the bullet's intersection has positive length. Anyway, I also thought that the condition for bullets intersecting considered somehow imprecise calculations and that this would be enough to catch traditional HOT bullets, like the use of some epsilon when checking for the intersection. But it seems it's more like the intersection of the segments having positive length or something.

Thanks for clearing it up!

Rsalesc (talk)03:50, 30 August 2017

No, the bullet intersection code of robocode is exact, and the deviation of traditional HOT must be calculated exactly as well.

What do you mean by "positive length"? I thought every length should be positive ;p

And I also thought an intersection of two segment (bullets are segments when calculating intersection) is a point ;p It has no length at all.

Xor (talk)04:06, 30 August 2017
Oculus doesn't have such problem because it does some checking to be sure that the bullet would hit %100 if enemy movement predicted correctly.
Something like this
boolean fire = (gunHeat == 0 && a.getGunTurnRemainingRadians() < 18 / (currentBattleInfo.distance -18));
Dsekercioglu (talk)09:23, 30 August 2017

I would say just use getGunTurnRemainingRadians() == 0, as any deviation would decrease your hit rate if your statistics is right.

Xor (talk)09:56, 30 August 2017

In the next version I will make it even more precise(with anti-bullet shielding of course). This version uses the angular bot width.

Dsekercioglu (talk)10:11, 30 August 2017