xVelocity = xDelta / timeDelta; yVelocity = yDelta / timeDelta; bulletTravelTime = distance / bulletVelocity; bulletTravelTime *= 1 + Math.sign(enemyX - robotX) * xVelocity / 14; bulletTravelTime *= 1 + Math.sign(enemyY - robotY) * yVelocity / 14;It works quite well. Suprisingly well using LinearTargeting. But now I suspect that it lowers my score using PatternTargeting. -- PEZ
Questions (can i ask them like this?) But of course! :
-- PEZ
I'w post some interesting links about the subject from the RobocodeRepository forums. The first one is about this specific topic.
https://www.robocoderepository.com/jive/thread.jsp?forum=18&thread=977
https://www.robocoderepository.com/jive/thread.jsp?forum=18&thread=1081
https://www.robocoderepository.com/jive/thread.jsp?forum=18&thread=1052
-- Albert
Thanks! But, for some reason I need to scroll several meters sidewise to read each sentence. It makes it almost impossible to follow. Maybe you could repeat whatever interesting thing you posted there, here? I know it's asking for much, but it would be much more accessible on this site since it won't be dug down in an old forum thread, but instead will gets it's own page(s). And, continuing to ask for much, if you find some OceansOfSpareTime, maybe you could try the crazy code snippet I posted above and validate the results against a more serious approach? I would be very interested in results against Walls in particular, since the later versions of Marshmallow gets their ass kicked against it. -- PEZ
The x should be Math.sin(), the y should be Math.cos(). -- Kuuran
Ahhhhhhhhhhh, now i actually understand what he means. They don't call me brain fade for nothing...:) Brainfade
I don't think Math.sign() there represent cos() or sin(). It was a while ago, but I think I had a function in my BotMath class that was named sign() and which returned the sign of its argument. -- PEZ
I'll let the above code snippet stand just a day more or so, just to give your comment some context. I don't use it any longer and we should try to get someone else post a working calculation. I don't have LinearTargeting in my bots any longer. It works only against Walls and is not worth it I think. And my pattern matcher calculates bullet travel time while it is iterating the enemy movement instead of doing a linear estimate. This seems to work better. -- PEZ
Although it looks logical to use Math.sin() and Math.cos() in the snippet above it makes your gun much less accurate than just using a prediction of time based on where they are now. As for linear targetting it is a great way for dummies like me to pretend that they use decent targetting (although firing directly at a robot tends to be quite successful). For some reason i have a complete inability to write a gun with any kind of success. I still have a linear targeting gun, just because i use a system that sounds very similar to Pez's virtual guns (Except i only have direct, linear and circular guns rather than the plethora that he uses), where i plot the trajectory of each gun every time i fire an actual bullet and store statistics of the hit-rates. I then fire the gun that has the best hit-rate (I used to think this was what virtual bullets were but now i hear i got it wrong). The disadvantage of using linear targetting by itself is that if the opponent is oscillating then you tend to fire miles either side of it. Pattern matching is clearly the way to go... if only my effort wasn't so bad :( -- Brainfade
Iteration through all the discrete values until you found the actual point of intersection along this projection is the best way. That or you can use Calculus. Both of these give exact travel times. -- Kuuran
There is a geometric way to do it, which I mused about on the page about LinearTargeting. I since tried it and debugged it and it is used in SpareParts (which can be used without wading through too much code, because it's in a class called "LinearGun?" or something). When nano was testing his new curve-flattening movement that he's been working on, he tested the robot against SpareParts and SpareParts's console indicated he was using his linear-projection gun after so many rounds. -- Kawigi
Yes, that sounds like VirtualGuns alright. Interestingly enough my VG array doesn't include linear nor circular targeting. I probably should include it, but in theory my pattern matcher should take care of that. Funny that you ended up with VGs when you misunderstood VBs, that's exactly what happened to me. =) You will find that VGs work better if you segment your statistics. Marshmallow segments on distance and angular velocity. Maybe you should let your pattern matching efforts rest a while and you might find it is easier when you return to it in a week or two. Meanwhile you could plug in Gouldingi style targeting in your VG array. It's quite effective against oscillators. Add one or two random targeting guns as well and you'll have an array much like Marshmallows. -- PEZ
The law of sins is something you're told many times in physics and other practical classes to never use, because it can result in incorrect values, due to the nature of sin in different quadrants. It should generally work in this case, however, because unless a bot is buzzing you, it shouldn't come up. However, I'm willing to bet the gun goes a bit wacky when a bot comes into point blank and does a straight line across. Though yes, that method does eliminate the requirement of knowing the time the bullet travels.
Anyway, there is another method I failed to mention involving the summation of an infinite series, that you could easily use to determine very precise travel times. So with three methods that can precisely determine the times, I don't see why a bot not restricted on code size would really need to avoid finding it. -- Kuuran
Please post some code snippets =) For me it's just that only my pattern matcher really needs an estimate of the bullet travel time and the iterative nature of my implementation produces the travel time as a side effect anyway. -- PEZ
![[Home]](/images/RoboWiki.png)