[Nuke]

id do number 1 but factor in size, distance, and speed of the target. a hit is more likely if the target is slow, close, or really big so as to make it impossible to miss (of coursre the dot would handle distance and speed).

[FUBAR-BDHR]

One thing you might want to factor in is % of ammo remaining.  Get more conservative the less ammo that is left. 

[chief1983]

Yeah, at least in the case of BSG, even if we do see them spraying quite a bit of ammo, you know they'd be rethinking that tactic once they start to get low.  Early on they're probably thinking 'ammo is cheap, life is expensive', but when ammo's low it starts to have a new value to you.

[karajorma]

Not to mention that %left would actually look like a lot more complex AI behaviour than it actually requires in the code.

[Tomo]

I'm not convinced that the dotProdToTarget would produce realistic results - if a ship is travelling across the field of fire, it'd be practically certain not to fire because it must aim away from the ship to hit it, which yields a very low dot product.

dotProdToTargetDiamond would work, but might make it feel like they are too conservative.

Also, there's already a function in there that controls aiming - they don't fire until there's a reasonable probability of a hit anyway, so evaluating that twice is unnecessary.

To start with, try using PShoot := (PercentAmmoRemaining) * (AI_Conservation_Multiplier)
- Dead simple, and may work well enough.

[Sushi]

Good ideas.

THe "prototype" as I have it so far is basically just

pShoot = max(0.25f, percentAmmoLeft)

which actually is pretty convincing (and dirt easy).

I like Nuke's idea of factoring in distance somehow too: I would imagine more aggressive shooting at point-blank.

I'm also considering squaring (or ^3, or ^4) some parameters in order to make them decay a bit faster (so that perceptible "ammo conservation" bursts start kicking in sooner). Something to try.

Tomo, you're right that the dotProdToTarget isn't quite what it seems, since the optimal aiming point is usually some angle off from the target. On the other hand, lower deflection shooting usually means you're more likely to hit. My thought is that the dot product to target represents a quick&dirty heuristic for how much deflection is involved in the shot.

Also, the dot product stays quite close to 1.0 even for fairly large differences on the screen. An angle difference of 25 degrees yields a dot product of 0.9, which as a multiplier doesn't affect things too much (again, I may experiment with squaring/cubing/etc this value to make it more impactful).

Of course, I expect that of all these ideas only a few will really be needed to make something convincing. I like brainstorming a lot, then settling on the simplest solution that will do the job well.

[Nuke]

the dot would work with normalized velocities, numbers far away from zero means more direct shooting. but then only as just one more weight on the equation. other things you might consider is travel time for the weapon. if the target has more time to evade then hit probability is less likely.

[Sushi]

the dot would work with normalized velocities, numbers far away from zero means more direct shooting. but then only as just one more weight on the equation. other things you might consider is travel time for the weapon. if the target has more time to evade then hit probability is less likely.

That will be implicit in the dot difference (since the AI will already be aiming further "ahead" for slower weapons, increasing the deflection angle).


Here's the current equation I have, giving me results I'm pretty happy with so far:

Code: [Select]

distanceFactor = 1.0 - distToTarget/(2 * weaponRange)
burstFireProb = (0.2 + (0.4 * percentAmmoLeft) + (0.4 * distanceFactor)) * (dotToTarget^4)
Distance factor is always scaled between 0.5 (at max range) and 1.0 (at point blank). The dotToTarget is nearly always close to 1.0 anyways, making it a good "global" modifier for the equation. Using dotToTarget^4 increases its effect a bit. I'm still testing and tweaking this, of course.


Another question: how should this feature be controlled?
1) Per-weapon flag.
2) AI_Profiles.tbl and/or AI.tbl flag (global for all primaries with ammo)
3) Other?

Also, would anyone be interested in applying this "burst" logic to energy primaries as well? It could help the problem where the AI burns through their energy reserves too quickly for certain weapons.

[Angelus]

the dot would work with normalized velocities, numbers far away from zero means more direct shooting. but then only as just one more weight on the equation. other things you might consider is travel time for the weapon. if the target has more time to evade then hit probability is less likely.

That will be implicit in the dot difference (since the AI will already be aiming further "ahead" for slower weapons, increasing the deflection angle).


Here's the current equation I have, giving me results I'm pretty happy with so far:

Code: [Select]

distanceFactor = 1.0 - distToTarget/(2 * weaponRange)
burstFireProb = (0.2 + (0.4 * percentAmmoLeft) + (0.4 * distanceFactor)) * (dotToTarget^4)
Distance factor is always scaled between 0.5 (at max range) and 1.0 (at point blank). The dotToTarget is nearly always close to 1.0 anyways, making it a good "global" modifier for the equation. Using dotToTarget^4 increases its effect a bit. I'm still testing and tweaking this, of course.


Another question: how should this feature be controlled?
1) Per-weapon flag.
2) AI_Profiles.tbl and/or AI.tbl flag (global for all primaries with ammo)
3) Other?

Also, would anyone be interested in applying this "burst" logic to energy primaries as well? It could help the problem where the AI burns through their energy reserves too quickly for certain weapons.

I would go for AI tbl.
Personally, i'd like to see the feature also for energy weapons, but i can sense a "that's not fs2-ish" debate coming...
Would it be possible to make the ammo primaries global via AI.tables and the energy ones controlled via weapon flag without becoming a pita?
This way the AI shoots ammo primarys always in bursts, and anyone can decide if they want to use the energy burst primaries simply by adding a flag to the weapon.

[karajorma]

I'd change the first number (the 0.2) into an AI table setting and then simply turn the feature off if it's not present. Right now you've not given table designers any way to tweak this behaviour.

[FUBAR-BDHR]

Not sure where to put it but will there be anyway to override the behavior.   I don't think you would see a kamikaze ship conserving ammo.   Maybe a sexp to toggle it on/off.  It gives the FREDder a bit more control for it the fight is going to be a short one or something happens in the mission and you actually want the fighters to go out of or into a conservation mode.  Loosing a support ship or carrier might be an example of where you would want to turn it on if it's off by default. 

[karajorma]

It would also become a consideration if/when support ship ammo can be limited. That was always planned as a team loadout feature.

[Nuke]

id be against a weapons.tbl flag, as it would make balance more difficult. id add a default fudge factor to each ai rank setting. so higher ranks would have smarter ammo conservation than lesser ranks. on the other hand you could make a special ai setting for kamikazes which doesnt care about ammo usage.

is there any way to expand this to include all kinds of weapons? have factors for energy conservation and missile conservation as well? of course they would need to be off by default for reverse compatability.