Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Sushi on June 24, 2009, 01:23:37 pm
-
So, it totally sucks when the AI runs out of ammo for primary weapons. If primary weapons have limited ammo, AI ships that survive long enough will eventually run out. The result is a useless, neutered, dumb-looking ship that flies around trying to shoot you but with nothing to shoot. This is a bit less of a problem when support ships are available, but what if they're not?
The question is, what should we do about it? I'd love to hear some ideas.
Ideas I've had so far:
1. Add a SEXP or something that triggers when a ship is out of ammo, and let the FREDders deal with it. I don't know how feasible this one is, someone will have to tell me.
2. Always give AI ships infinite ammo for primary weapons.
3. Let them run out, but magically give them back 10% after being empty for 15 seconds (or something, specific numbers can be fiddled). That way, when they "run out", they can still fight, but less effectively. The idea is to make it look like the ships are nursing their ammo by firing less often.
Any other ideas, or comments on these ones?
-
I would prefer solution 1.
More work for FREDders, but I believe the AI should not cheat.
-
You already can get primary ammo and do something with it.
It would look like that:
When
=
get-primary-ammo
0
add-goal
AI-keep-safe-distance
This should make AI try to keep safe distance from enemy after they run out of ammo.
-
depending on the situation
option 3 if you are in a situation where the player will have chance to notice e.g. lots of light action
option 2 if the situation is intense where the player is not likely to notice and will probably need the help of their allies, would have to be done in FRED if you plan to allow the player to change weapons for their wingmates
-
I don't like the idea of the AI having more ammo then it would as a player ship. If the player is good enough to evade until the AI run out then why penalize him? A sexp to check would be good but that only helps in certain situations. I can't see where it would really help in a TvT or coop where the AI normally would be a player ship.
Giving any ship that could be a player ship extra ammo would be giving an advantage especially in TvT.
Default behaviors if the ship runs out of ammo aren't really a solution either unless they are both mission and ship specific.
One thing that might help would be better handling of the use of ammo in the first place. Bursts instead of continuous fire, dropping the amount of those bursts when the ammo falls below a certain %, that sort of thing so there is less chance of them running out in the first place.
-
Yep, fixing the AI to care about it's ammo is where I would suggest starting on a fix for the problem too.
-
Better ammo handling would indeed help, but the problem is still there (just pushed a bit further back). One way or another, they'll still eventually run out.
-
Well when they run out there should be a standard defensive tactics routine. They should quit doing obvious attacks (although an occasional fake attack wouldn't hurt) and basically fall into formation and try to take some fire off of their wingmates.
Now this should be overrideable by events like Kamikaze, evade, warp out etc. Those are only a few of \the things AI without ammo could do.
On a curious note what do the AI do when they have their weapons subsystem destroyed? I usuall don't give them a chance to see the outcome.
-
After somewhere between 30 seconds and a minute the game blows them up. :p Same for disabled enemy fighters.
Friendlies do get to call in support of course.
-
So you can disable them but as long as weapons are intact they'll stay immobile?
-
What? He means that disabled fighters blow up after 30-60s, and so do fighters with no weapons subsystem. Either one will cause them to die within a minute.
-
Oh.
-
You already can get primary ammo and do something with it.
It would look like that:
When
=
get-primary-ammo
0
add-goal
AI-keep-safe-distance
This should make AI try to keep safe distance from enemy after they run out of ammo.
I have a feeling that this won't work. What if you're in a super slow fighter, and just met up with a fighter with 0 ammo that you have to kill to beat the mission? He runs away, and you'll never catch him till you collide with yourself.
-
Then add something other in place of AI-keep-same-distance .
That's only an example ,I think running away is the best thing you can do without ammunition and perspectives of rearming.
You can for example use AI-warp goal for fighter to jump out ,or place first part in departure cue ,ordering the ship to return to carrier when out of ammunition.
Just order it to do something that makes sence.
-
Make them ram the player ship. With self destruct..
-
some ideas
modding side:
reduce fire rates if possible
decrease cargo size variable
add a turret with an energy weapon (see below)
programming side:
make ai use wanderer's turret features if they dont do so already
make them call for support when they use up some percentage of their ammo
make them use ammo more efficiently, meaning closer tolerances in target leading / more advanced lead calculation
firing in short controlled bursts, and only when there is a high probability of hitting the target.
if multiple ammo weapons are available, avoid linking them, use the weapon with the highest velocity at range, powerful guns at medium range, and all guns at short range only.
from the fredding side of things:
always equip an energy weapon on ships that have more than one slot.
issue dumb fire rocket type weapons like tempests to at least one secondary bank
make ships that are out of ammo return to base, and then launch a replacement fighter a short time later to simulate a touch, arm, and go rearm.
-
Not every mod has support though. And they should call in support when low on ammo already.
-
you could also add an ai bank capacity or something like it
-
make ai use wanderer's turret features if they dont do so already
Thanks for the ideas, but could you please explain this one?
-
thats really kind of difficult since im not really ll thatfamiliar with the turret features, i just know some of them ive wanted for awhile. mainly the ai would be aware of its turrets, and the turret ai aware of what the ship ai is trying to do. so it can bring its turret weapons to bear if need be. i remember many times in fs1 just keeping on the tail of a ship in a bomber, leaving it exposed to the turret, and got many kills this way.
-
make ai use wanderer's turret features if they dont do so already
Thanks for the ideas, but could you please explain this one?
Wanderer made turrets on bombers target independently of the players target. They actually do something with his script.
-
I want that!
-
None of this actually has anything to do with the subject that Sushi was on about. So back on topic.
-
What's with all the ruckus? The problem is rather simple.
IF you don't want support ships in your mod then either don't use primaries with limited ammo or give them massive amounts of ammo (far more than they would need for a mission).
Kicking out ressuplies and then crying when you (or the AI) run out - that's like a whole new level of stupidity.
-
The fact is that the AI makes no attempt to conserve ammo in the same way a human player would. Giving the AI insanely high amounts of ammo is not a good solution. In fact it's a ****ty one. It simply suggests that we make the AI cheat (or give the player the same amount of ammo, thereby making even having ammo pointless in the first place.
Most sensible people would see this as a problem and want to fix it. Feel free to prove you aren't a sensible person by arguing against Sushi's desire to write better AI though.
-
better ai is good. but i think giving the enemy support ships can add a lot to gameplay. i also like my return to your mother ship, reload and get back into the fight idea.
-
That's fine too but there are several mods where it would be impractical. Diaspora comes immediately to mind. Giving the Cylon Raiders support ships would be hugely non-canon and they don't jump in with a basestar in every mission.
Yes, enemy support ships are a nice idea in the long run too but getting the AI not to waste its ammo in the first place helps all mods immediately.
-
improving the ai seems to work the best regardless. but in situations where theres no support it might just be better to bug the ship out if its no longer capable of fighting. so id add the fred check too so the fredder can do something sensible with the excessively trigger happy ais. the player merely doesn't get the points for killing it.
-
Well the tools to do stuff in FRED are already there, it's just up to the FREDder to use them once the AI has been fixed to be less of an idiot.
-
The fact is that the AI makes no attempt to conserve ammo in the same way a human player would. Giving the AI insanely high amounts of ammo is not a good solution. In fact it's a ****ty one. It simply suggests that we make the AI cheat (or give the player the same amount of ammo, thereby making even having ammo pointless in the first place.
The AI doesn't conserve ammo at all (missiles or primaries) - not a real problem when the AI can call in support ships.
I can see this ammo conservation having merit in settings/mods that clearly have no support ships (altough a question is raised - why not? If you can build space fighters, why are support ships so unconcievable?). And if you haven't noticed kaj, that was the question I was actually raising, not questioning the improving of AI.
-
The fact is that the AI makes no attempt to conserve ammo in the same way a human player would. Giving the AI insanely high amounts of ammo is not a good solution. In fact it's a ****ty one. It simply suggests that we make the AI cheat (or give the player the same amount of ammo, thereby making even having ammo pointless in the first place.
The AI doesn't conserve ammo at all (missiles or primaries) - not a real problem when the AI can call in support ships.
I can see this ammo conservation having merit in settings/mods that clearly have no support ships (altough a question is raised - why not? If you can build space fighters, why are support ships so unconcievable?). And if you haven't noticed kaj, that was the question I was actually raising, not questioning the improving of AI.
Have you seen support ships rearming fighters in BSG? Actually, the FS way of having a small, mostly unarmored ship packed with tons of weapons it can't use itself flitting around on a battlefield is very unrealistic.
-
I noticed one thing: In BtRL demo ,wingmen were shooting asteroids with KEWs ,wasting ammunition.
It would be useful to prevent AI from shoting at asteroids when they don't pose a threat to friendly ship.
-
The AI doesn't conserve ammo at all (missiles or primaries) - not a real problem when the AI can call in support ships.
...getting the AI not to waste its ammo in the first place helps all mods immediately.
Exactly.
-
in the case of battlestar it would be nice to be able to touch down on the hanger deck rearm and take off again. while that kind of method isnt quite bsg cannon, it seems plausible that in an extended battle such a rapid rearming would be necessary. general support for mothership repair and rearms, assuming the mother ship is in system, go back for ammo. if not warp out for a time and then warp back in fully armed and possibly repaired. either way the ship is removed from gameplay for a short time and then returns to battle as the same ship (im not sure if it was ever made possible to temporarily remove a ship from gameplay, i know the fsrts sorta requested it but im not sure if its been done or if the ship copy meathod was used instead).
its an idea for the future, but not really something pertinent to what neds to be done to conserve ammo now. possibly ai ammo usage couldbe part of the ai profiles, since you might want to add stingy secondary usage as well (which effects reverse compatibility). id make the ammo concervation skills variable depending on ai skill level, newbs trigger happy, vets more disciplined. by default have primary conservation on and secondry conservation off.
-
Have you seen support ships rearming fighters in BSG? Actually, the FS way of having a small, mostly unarmored ship packed with tons of weapons it can't use itself flitting around on a battlefield is very unrealistic.
Why unrealistic? It's fast, shielded and has the ability to jump. This gives it good chances at survival.
Any military force has supply ships. They usually don't get involved into the battle, but they also don't usually have the abiltiy to cross half a system really fast.
EDIT: In the AI table isn't there a wait time or something? How long the AI will wait for a better shot before shooting?
-
The AI table settings do very close to bugger all.
-
Why unrealistic? It's fast, shielded and has the ability to jump. This gives it good chances at survival.
It also carries an enormous arsenal of assorted missiles, it has the capability to distribute those missiles to fighters, while at the same time repairing the subsystem damage those fighters have suffered during combat, combat that is usually happening in close proximity. Not to mention that resupplying means stopping dead in space and playing a target for any hostile lining up for a cheap kill. Driving one of those flying Pez dispensers must surely be the most sought-after posting EVER.
So, even if we're assuming that it somehow works in the FS universe, transplanting this element into other Universes (like BSG) that didn't provide proof for their existence just because the bloody AI cannot control its trigger finger sounds damn stupid to me.
-
It sounds like the general consensus is that AI conserving ammo better + existing FRED options are the way to go.
Time for a brain-dump of ideas for "smarter" AI burst-fire:
One option: a "shot probability" function. This probability would be reevaluated once every second or so, which would be the effective resolution of bursts (bursts will always last X seconds).
Something like:
P(shoot) = (percentAmmoLeft) * (dotProdToTarget)
Where P(shoot) would have some sane minimum/maximum values. P(shoot) would have a similar effect to weapon subsystem damage: the lower the percentage, the less often the AI will shoot.
This would result in the AI shooting less when pointed further away from the target and when lower on ammo.
The main disadvantage of this is that it would produce very "jagged" bursts (a problem mitigated by the 1-second resolution). Main advantage is that it's very easy to implement.
Another option: bursts are controlled by four parameters.
Min Burst Length
Max Burst Length
Min Burst Delay
Max Burst Delay
The actual length of a burst (or a delay between bursts) would be rolled randomly between the specified bounds. These params would all be controlled somehow by FREDDers and modders. This is less "smart" than the solution above, but gives the modders more control over what's going on (which is sometimes even smarter! :)).
Or heck, maybe combine the two. The first method with the function is used, but the length of bursts and the length of delays between bursts are constrained by the parameters from the second method.
One problem with both of these ideas is that it may look weird if the AI is shooting at a big ship or an immobilized ship that's a perfectly easy target and still firing in bursts instead of unloading a steady stream (most efficient). So, we may want to have the AI not use bursts at all in those situations.
-
Though i have not looked at any of the code behind FS/SCP and its been 3+ years since i did any coding
but
in my opinion 2 would be the simplest not much more than the 4 lines of code listed and random generator code in the game. but this would probably need 4 variables in the AI table to allow modding
Option 1 would be better from the point of view of fine tuning behavior, you could then have two sets of the code depending on if the AI was shooting at a ship it its sub system which then would allow for example the AI to be more careful (especially when perusing disarm/disable player orders). and would probably only need 2 additional variables in the AI table to set hit probability and burst length
EDIT
Can i also point out a vaguely related topic running atm
http://www.hard-light.net/forums/index.php/topic,63954.0.html
-
After prototyping option 1, I think that some variant on it will work nicely. Stay tuned. :)
-
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).
-
One thing you might want to factor in is % of ammo remaining. Get more conservative the less ammo that is left.
-
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.
-
Not to mention that %left would actually look like a lot more complex AI behaviour than it actually requires in the code. :D
-
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.
-
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. :)
-
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.
-
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:
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.
-
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:
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... :P
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.
-
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.
-
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.
-
It would also become a consideration if/when support ship ammo can be limited. That was always planned as a team loadout feature.
-
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.