Not Stopping in Time

I recently tested reading hard-coded SAG lengths from a String table in EpeeistMicro. In theory, it should be more precise, and therefor more effective than Skilgannon's method. The problem is, against bots that aim using linear targeting and fire power 2 bullets, EM doesn't stop in time and gets hit.

I calculated that a 56 pixel length would move for 12 ticks, and would therefor be completely safe against guns that fire power 2's, which take 14 ticks to cool in between shots.

What did I do wrong?

Thanks

Hi mate. Sounds like you are to close to the other bot. The closer you are, the less dodge moves you get. For your example you only have 12 ticks at a distance of 168.

There are 3 things I can think of:

• Range, as Wompi already mentioned, could be a factor.
• Perception delay, your perception of opponents firing lags 1 or 2 ticks and then the move starts a tick after that, so maybe 2 or w ticks there.
• Firer inaccuracies. The firer may have a bug (delay as above, firer's movement etc) which causes it for fire slightly differently from what you expect.

Distance should not affect the performance of SAG. (Well, it can in certain circumstances, but those are irrelevant here.) If the bot stops in time, any form of targeting that projects movement based on current velocity will aim head-on. Even at very close range, if the enemy's gun is too hot to fire, EpeeistMicro should be safe.

@Nz.jdc
I already account for the two tick perception delay. It's possible that certain enemies have bugs in their guns that cause them to aim earlier than they fire, but it seems the negative effect is almost universal against bots with linear and circular targeting.

I tried changing the length for power 2's from 56 to 48, and now it crushes bots like AdeptBSB.

Any other ideas why 56 didn't stop in time?

It lags because of the fact that the enemy gun fires before it is turned. So they fire at what they saw last tick, which still had you moving. BTW, the 'extra term' I have in Toorkild 0.4.1's StopAndGo should account for any improvement you can find, but I tested and didn't get any improvement from them. Of course, if a string table is smaller codesize than the one we are using now, there is still a motivation for it I guess, and it wouldn't hurt to leave it out.