Thread history

Fragment of a discussion from Talk:Oculus
Viewing a history listing
Jump to navigation Jump to search
Time User Activity Comment
No results

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

Sorry for the confusion caused. I just named things the wrong way. When I say segment intersection, I mean the safe area generated by the intersection of those segments, like in bullet shadowing. What I wonder is if, in a perfect universe where computers can compute with perfect precision, two bullets laying on opposite rays would collide or not. Note that the lines actually intersect, so the segments. The safe area, though, degenerates to a single point. So my doubt was like: Robocode actually checks for an intersection of those segments or for a non-degenerate safe area?

Note this degenerated from an actually valuable discussion into a stupid curiosity. :P

Rsalesc (talk)04:26, 30 August 2017

Robocode doesn't care about that safe area at all. In segment intersection algorithm, The first thing is to determine whether they are on the same line. If so, robocode just ignores the intersection. This behavior look strange at first, but it is friendly to those who new to robocode. This way they (when trying two stationary robot, etc. sample.Fire) won't confuse — why my robot collides its bullet with another all the time?

Xor (talk)04:31, 30 August 2017

Yeah, I was just interested in the behavior. Thank you again, that was pretty enlightening and makes total sense, it would be stupid if those bullets collided. Gotta take some time to make sure I understand all the Robocode mechanics.

Rsalesc (talk)04:46, 30 August 2017
 

After a long night, I just have to say that Bullet Shielding is the hardest thing... ever. You deserve a huge prize, man.

Rsalesc (talk)11:09, 30 August 2017