BotAim 2 announced. Best aiming ever.

[[BBB]sluggo]

Aspirin.... are you totaly (in)sane??? :-)

I love that people are good at different things so that I don't have to learn that level of math. ;-)

[ghost of evilspy]

bad forums, no delete post

[@$3.1415rin]

there are reasons that deleting posts isnt permitted, it's not a problem of this forum.

currently hearing a lecture on numerical solving of differential equations ( http://numerik.uni-hd.de/~lehre/notes/num1/numerik1.pdf ), maybe I should apply some of that stuff to the botaim code

[ghost of evilspy]

IMHO easier way to make more human aim is to make bot predict position of player by using old stored data of enemy's position and velocity. That way if enemy suddently changes direction of movement and/or speed it takes some time for bot to follow this change (instead of noticing instantly). I think this happens with humans too.. you don't see world instantly since processing data (brain) from your imaging device(s) (eyes) takes time and this slight time different is fixed by prediction.

Following example code uses linked list for storing timestamped position data (origin and velocity). Position data is stored every 33ms and GetPredictedPlayerPosition picks two data slots near time value passed to it and makes simple prediction of player's position. Works good on my bot/server 9_9

http://evilspy.1g.fi/botpredv1.txt

[Pierre-Marie Baty]

This is also a good method, although the one used in botaim2 isn't flawed because of that ; that latency time it takes a bot to notice a change in direction is affected by the aiming momentum. With your method the setting values will be different, but the result will be the same.

[ghost of evilspy]

Is it ok, if I use botaim_mm code for my bot?

[@$3.1415rin]

some illustrations about the aiming algorithm, currently working a bit on it to improve my practical differential equation skills



you see that the ideal position in blue always tries to approach the ideal value. but the interesting part might be the time after 5 seconds. you see that the position value is not able to follow the slope. only when providing the accurate ideal speed, aiming works perfectly.

this image has been produced using quite conservative parameters, therefore no oscillations and slow approaches, but this way the important part is easier to recognize

btw, even with some more oscillations and a "framerate" of 10fps, you see only very little difference between the method currently used and a higher order approximation :


but if you take parameters closer to reality, you might get oscillations when having a low framerate. if you take a higher order approximation, you will have less oscillations like you see now :



ghost of evilspy's idea for storing a kind of vector field for each map representing the main movement directions and speeds sounds nice too, but you mostly aim at targets you already see, therefore you can get the speed information without being accused to have cheated directly

[ghost of evilspy]

Originally Posted by @$3.1415rin

ghost of evilspy's idea for storing a kind of vector field for each map representing the main movement directions and speeds sounds nice too, but you mostly aim at targets you already see, therefore you can get the speed information without being accused to have cheated directly

Well, that isn't what I meant.. but your idea would be great for wall gaussing bots 8o

[Pierre-Marie Baty]

Ah but I understand better why Joe wanted to know the spring and damper coefficients that I use !

Anyway these graphs are very interesting.

[[NvT]_KaszpiR_]

interesting topic

anyway notice that you are using the non discrete math in the explicly discrete task

i believe it is okay, but i assume there are some extra things that can be used to speed up the aim approximation - because of discrete math you can use easier or faster calculation algorithms.

Of course the first step is to implement the theoy into practice, but 'practically' you will end with more simple algorithms.


One more thing. Looking a the graphs and the program that shows the bot aiming (bot aim 2) i predict RACC will have bots with characters, where you can define such things like damping, spring etc, or the probability of the occurence of the time, that bot would prefer to eat pizza now nd steer with one hand


one more thing. i wonder how the aiming will be implemented - like, does the bot will treat every frame as a point of aiming or will get updates of enemy positions every XX mseconds (like player that gets the initial change of the player position few moments after the enemy moves (due to lage between wwhat we see, what our brain decides to do and the time the nerve impulses react to move the hand).

and another thing, i believe this can be hard to implement. Notice player does not have 'infinite' hand as bots (the limitations of the glidin furface like mouspad, or cable - man gotta toss mouse overn move it back, lay it down and move it again to continue aiming, especially the ones with low sens).
Also there is an issue of sudden movements (like inhuman turns). People got it sometimes too i bet you happened to kill enemy instantly because of the instinct reaction, especially when surprized )

anyway, the current algorithm is very satisfactory