battlecode
Send final Bullet location before destroying it
There a are currently some weird visualization effects, and I think this might fix it.
Email chain:
I just replayed it at full-speed sever times (with interpolation) and the interpolation shows those two bullets appearing to hit the scout, which corresponds to where damage is actually being done. I believe the server is processing everything correctly according to match specs, and there is some issue with how the server conveys this information to the client for visualization.
On Wed, Jan 11, 2017 at 3:03 PM, Nick McCoy [email protected] wrote:
I believe the first file is some strange interpolation thing with the client, and the server is performing calculations correctly. I'll look into it more if I have time.
The second one, however, is very interesting. I believe the damage isn't coming from the bullets grazing it, but is coming from the bullets that appear to be hitting Gardener 11666 in turns 151 and 152. Note that this isn't dealing damage to the Gardener. I will try to see if this a collision detection bug or another client quirk.
On Wed, Jan 11, 2017 at 2:30 AM, Phillip Harris [email protected] wrote:
Start at more like t=140 i mean.
On Wed, Jan 11, 2017 at 1:29 AM, Phillip Harris [email protected] wrote:
Now i'm really puzzled. Look at t=152, at the scout in the lower left. It looks like the first 2 bullets just barely graze by it... yet the scout gets damaged twice! What??
On Tue, Jan 10, 2017 at 11:24 PM, Nick McCoy [email protected] wrote:
Ah, thanks for pointing out the inconsistency! This will be revised in the near future.
Yes, what makes this even more weird is that when you play at normal speed (which render interpolated frames for smoothness) it shows the bullets moving towards the center of the two soldiers and then disappearing when they "collide." I'll process the file and see what's in it.
On Wed, Jan 11, 2017 at 12:19 AM, Phillip Harris <[email protected]
wrote:
In javadocs it says "The radians at which this direction is facing based off of the unit circle; i.e. facing right would have 0.0 radians, up would have PI/2 radians, etc. Note: radians = (-Math.PI, Math.PI]"
And yeah, it is strange, because there is one frame where the red robot is alive and the blue robot is gone... yet the there are still no bullets rendering in the middle. only after both robots are gone do they render in the middle
On Tue, Jan 10, 2017 at 11:13 PM, Nick McCoy [email protected] wrote:
I'm currently looking into this. It seems like the bullets are being processed correctly, but aren't rendered correctly. I'll check to see what data is actually saved in the file.
Regarding angles, that is due to the viewing spec. The origin is at the top left of the viewing window, and the y axis points downward.
On Tue, Jan 10, 2017 at 11:36 PM, Phillip Harris < [email protected]> wrote:
Go to t=104 and look at the two robots shooting each other on the left.
The robot's centers are 5.7 units apart, and the bullets have speed 2. You can see the bullets that have been fired on t=104 are visible, on the edge of the robots. But there should also be two more bullets visible in the middle. These middle bullets become visible once the robots die.
Also, I think the angles are still reversed: Bullets travelling upwards from the red robot have degree -98. If right is 0 degrees and degrees go clockwise, it should be +98.
This seems to not be a problem when running with interpolation, but if you're analyzing step-by-step it can make results seem weird when bullets disappear relatively early.
As an example, these two pictures are adjacent steps. All of those bullets hit the archon without being shown moving closer. In a situation with many units, it would be very hard to see which bullets hit which units.
