introducing... BotAim 2!

[Pierre-Marie Baty]

yes! it's here

BotAim 2 plugin for metamod that gives your bot the most configurable (and hopefully the best) aiming ever!

whoopee

http://filebase.bots-united.com/inde...on=file&id=274


well and here's the readme

*******************************************
* BotAim 2 - human-like bot aiming Plugin *
*******************************************
by Pierre-Marie Baty <pm@bots-united.com>

This metamod plugin allows bot server administrators to change the way their bots turn and aim in any Half-Life MOD to a more realistic method.
Technically, any bot that use the "idealpitch" and "ideal_yaw" field of its entity variables structure for storing the final aim angles can be affected by this plugin. Since most bot authors used botman's template, many bots are ok.

PLEASE NOTE that this plugin does not change the bot's AI, it does not alter their decisions and ESPECIALLY IT DOES NOT CHANGE WHERE THEY WANT TO LOOK. It just enables them to move the crosshair in a smoothened way. If you see your bots aiming at stupid locations, or trying to look through walls, blame the bot, NOT the plugin!

The algorithm implemented assimilates the crosshair movement to a spring with several physical constraints. Since the generic equation describing a spring's movement is well-known by modern physics, this modelization enables the user to define the bot aiming's parameters as the stiffness and damping coefficient of the equivalent spring.

The aiming system is HIGHLY configurable. You can set it to suit your tastes in all domains. The aiming can be greatly affected by your changes, and not two servers using this plugin will feel the same if the settings are not identical. You are warmly encouraged to toy with the CVAR's values to find the perfect aiming that will challenge you ;-)


featured CVARS:

botaim_enable (default: 1)
Enables or disables the plugin. Set to 1 (enabled) by default. Set to 0 to disable BotAim and restore the bot's original aiming algorithms.

botaim_spring_stiffness_x (default: 13.0)
VERTICAL (up/down) spring stiffness of the aiming system. This value affects the quickness of the crosshair movement, as well as the frequency of the resulting oscillations.

botaim_spring_stiffness_y (default: 13.0)
HORIZONTAL (left/right) spring stiffness of the aiming system. This value affects the quickness of the crosshair movement, as well as the frequency of the resulting oscillations.

botaim_damper_coefficient_x (default: 2.0)
VERTICAL (up/down) damping coefficient of the aiming system. This value also affects the quickness of the crosshair movement, and the amplitude of the resulting oscillations.

botaim_damper_coefficient_y (default: 2.0)
HORIZONTAL (left/right) damping coefficient of the aiming system. This value also affects the quickness of the crosshair movement, and the amplitude of the resulting oscillations.

botaim_deviation_x (default: 20.0)
VERTICAL (up/down) error margin of the aiming system. This value affects how far (in game length units) the bot will allow its crosshair to derivate from the ideal direction when not targeting any player in particular.

botaim_deviation_y (default: 90.0)
HORIZONTAL (left/right) error margin of the aiming system. This value affects how far (in game length units) the bot will allow its crosshair to derivate from the ideal direction when not targeting any player in particular.

botaim_influence_x_on_y (default: 0.25)
Perpendicular influence of the vertical axis on a HORIZONTAL movement. This value affects how much (in fraction of 1) the bot will be disturbed when moving its crosshair on an axis by the inherent movement on the other axis.

botaim_influence_y_on_x (default: 0.17)
Perpendicular influence of the horizontal axis on a VERTICAL movement. This value affects how much (in fraction of 1) the bot will be disturbed when moving its crosshair on an axis by the inherent movement on the other axis.

botaim_offset_delay (default: 1.2)
Maximal value in seconds after which the aiming system will re-evaluate its ideal direction. This affects how often a bot will attempt to correct an imprecise crosshair placement by moving the crosshair inside the error margin bounds defined by the botaim_deviation CVARs.

botaim_notarget_slowdown_ratio (default: 0.3)
Fraction of the full speed the aiming system will adopt as speed when aiming at nothing in particular. This affects how slow the bot will move its crosshair when targeting nobody, relatively to its full speed capacity.

botaim_target_anticipation_ratio (default: 0.8 )
Fraction of the estimated target's velocity the aiming system will rely on when aiming at a moving target. This affects how well the bot will be able to track moving targets on the fly, and whether it will have a tendancy to aim ahead of it or behind it.

botaim_fix (default: 1)
This CVAR tells whether the vertical (x) component of the bot's body angles should be negated, due to a very common bug in Half-Life bots that was already present in botman's template, causing these angles to be reverted. If you see the bots looking up when they should look down and inversely looking down when they should look up, try setting this CVAR to its opposite value. The default is 1 (aimbug fix activated).

Long live bot servers!

[The Storm]

Is this based on the your new aim algoritm ?

[Pierre-Marie Baty]

yes, that's the one we've been discussing with Aspirin and the others. It's also explained in the wiki btw

[@$3.1415rin]

nice, but I'd rather use that k^2 = 4dm relation and give the user just a factor how much larger, i.e. how many more oscillation he wants and let him just edit one of those, either k or d.

hm, once again using frametime inside the speed calculations ?! well, or I gotta read that after the physics test tomorrow, maybe I see it then.
hm, why commented out the bot movement itself ? worked fine here ...

PS: "modern" physics, lol

[The Storm]

I tested the plugin and I see very good aim. But from my point I think that the shot after the bot fire is automaticality go in me. The bots shoot no stop and all shots go in me. Maybe your plugin need a some fix .

Maybe my english need a fix .

[Pierre-Marie Baty]

argh, you were right! Paulo-La-Frite's aim fix bug struck again I corrected it and uploaded a new version. You can download the plugin again, it should be fixed. Note that if you find the aiming too skillful, you can tweak its parameters yourself.

@aspirin: "hm, why commented out the bot movement itself ? worked fine here ..." well yes... in theory it should work fine, that's what I was thinking too... but in practice the effects are horrible, the bots can't aim crap with that thing turned on. I must have screwed something, or else I got it all wrong... Weird Anyway I'm fully satisfied with the aiming as it is, and I think I'll leave it as is until someone complains.

[@$3.1415rin]

looked it up again. the reason, like I already told you about your post in the wiki, that you multiply your speed already with the frametime. this isnt a good idea, because in the next frame, you'll have problems with the damping, because you then have sort of frametime^2 there. and it's not fps independant when doing it the way you do it. just multiply with the frametime when adding the speed to the current angles. you might also check that when regarding the units in your equations I think.

[Pierre-Marie Baty]

hm yes, you are right. Something could be improved here. Hold on...

[Cool438]

I've noticed an enormous aim improvement with this plugin BUT only against human players. When multiple bots fight each other, they constantly miss and shoot above the head, then they go close up and fire single shots at each other :'(. This is very annoying as it takes a long time for the round to finish. Please try to fix this problem. I am using the latest P0DBot_mm.dll.

[Pierre-Marie Baty]

8D
You were right and I finally found the bug! Phew, that was a pesky one

The bots were simply forgetting they were targeting someone, and thus switched back their aiming into "no target" mode. This could happen because in order to know if the bot targets someone I was firing a TraceLine in the direction of its ideal angles. BUT, because the plugin needs to work on the StartFrame_Post() hook, the player's origin had already been moved by the game DLL and my traceline was simply missing its target...
I fixed that by adding a delay between switching back to no target mode. This way, if one traceline fails the whole combat aiming won't be compromised.

I have also fixed the frame time problem as suggested by aspirin. This leads to new values for the damping coefficients.

I'm uploading the plugin again.