Limit aim-ahead
Moderator: Moderators
Limit aim-ahead
For slow travelling weapons (e.g. high trajectory) the aim-ahead feature is really awful. E.g. high arc vs. fast moving units can often lead to the unit shooting into your own group or just firing completely outside the playing field because the target could have moved that far. Would be nice if we could limit the distance a weapon will aim ahead so e.g. the Titan in CvC won't bombard your own base when it sees enemy drones moving towards it. After a certain travel time the linear prediction is useless anyway since there's no way the target won't turn or stop during that time.
I think the problem goes a bit further
Normaly units refuse to fire, when they 'think' they will hurt a friendly unit. This works well for direct weapons like laser or small tank shells. But when the weapon has a big AOE it will sometimes hurt friendly units. (Do they even check the AOE?)
The problem gets much worse if the weapon is inaccurate. Artillery with a high target error fire happily in the center of the base assuming all off their shoots will hit this one squareinch which is safe for friendly fire... Anyone who saw this unit 'defending' your base know what I mean: Catapult - Heavy Rocket Kbot
Units which slow and or inaccurate weapons should make a worstcase desicion including AOE, wobble and Accuracy first and maybee even consider a linear extrapolation for the unit position of friendly units.
But I fear doing this right would require way to much calculation power
---
How to defend a T2-Defence:
Send a constant beam of Fleas into the defence. The defence will take care of itself.
Normaly units refuse to fire, when they 'think' they will hurt a friendly unit. This works well for direct weapons like laser or small tank shells. But when the weapon has a big AOE it will sometimes hurt friendly units. (Do they even check the AOE?)
The problem gets much worse if the weapon is inaccurate. Artillery with a high target error fire happily in the center of the base assuming all off their shoots will hit this one squareinch which is safe for friendly fire... Anyone who saw this unit 'defending' your base know what I mean: Catapult - Heavy Rocket Kbot
Units which slow and or inaccurate weapons should make a worstcase desicion including AOE, wobble and Accuracy first and maybee even consider a linear extrapolation for the unit position of friendly units.
But I fear doing this right would require way to much calculation power
---
How to defend a T2-Defence:
Send a constant beam of Fleas into the defence. The defence will take care of itself.
They only check if anything is blocking their line of fire. I think the only real way to prevent area bombardement from being launched at something inside your base is Hold Fire but for high arc weapons they'll often shoot in places where the target would never move, e.g. defense turrets turning around and shooting behind themselves.
1. Units use predictive targeting for some weapons. The variable is targetMoveError.
I do not think that lowering that to 0.5 or whatever (iow, aim at 1/2 the predicted position, which by code is just calculated by straight-line, not by full curve, so is obviously off by large margins every time) is likely to lead to the results you want, KDR, but let me know if anything works. It works great with lineofsight guns, though.
2. Not every weapon type is affected by avoidFriendly. Ballistic weapons are not affected.
A. It's been that way forever. You're just noticing this? Gimme a break, dude.
B. It's reality. If you're stupid (or clever, depending on circumstances) enough to have an assault force coming under fire from your own artillery, the artillery should not magically know that it's doing something wrong. Friendly fire is a big part of real warfare.
C. It'd require far too much code to be worth bothering with. That's an insane list of conditions.
D. IRL, the way that the military deals with "worst-case" situations like this is by only firing artillery when they are pretty sure they aren't going to kill their own people. "Pretty sure" is not 100% sure.
E. If you're dumb enough to use something like a Catapult as a defensive unit, without microing it out of your base but within range of your heavier artillery, then I don't have any sympathy for you. That unit was designed for crowd-control and assault duties, not as a defensive unit
I do not think that lowering that to 0.5 or whatever (iow, aim at 1/2 the predicted position, which by code is just calculated by straight-line, not by full curve, so is obviously off by large margins every time) is likely to lead to the results you want, KDR, but let me know if anything works. It works great with lineofsight guns, though.
2. Not every weapon type is affected by avoidFriendly. Ballistic weapons are not affected.
No. No. No! Because:Units which slow and or inaccurate weapons should make a worstcase desicion including AOE, wobble and Accuracy first and maybee even consider a linear extrapolation for the unit position of friendly units.
A. It's been that way forever. You're just noticing this? Gimme a break, dude.
B. It's reality. If you're stupid (or clever, depending on circumstances) enough to have an assault force coming under fire from your own artillery, the artillery should not magically know that it's doing something wrong. Friendly fire is a big part of real warfare.
C. It'd require far too much code to be worth bothering with. That's an insane list of conditions.
D. IRL, the way that the military deals with "worst-case" situations like this is by only firing artillery when they are pretty sure they aren't going to kill their own people. "Pretty sure" is not 100% sure.
E. If you're dumb enough to use something like a Catapult as a defensive unit, without microing it out of your base but within range of your heavier artillery, then I don't have any sympathy for you. That unit was designed for crowd-control and assault duties, not as a defensive unit
TargetMoveError is the setting. I'm pretty sure its not for setting how far off it is, but rather it just controls how far ahead it will lead the target. It either aims within its ability or it just leads the target at the maximum the setting tells it to aim ahead.
From the testing I saw it was great for making it difficult to hit faster moving targets of varying degrees, just enough to make 0 (default), .001, .333, and .666 worthwhile for distinguishing between units of varying technology levels when targeting ground units. With some faster targets, like when aiming at air units, you can get even more granular in ability.
From the testing I saw it was great for making it difficult to hit faster moving targets of varying degrees, just enough to make 0 (default), .001, .333, and .666 worthwhile for distinguishing between units of varying technology levels when targeting ground units. With some faster targets, like when aiming at air units, you can get even more granular in ability.
I don't think this are good arguments. If you compare the behavior of the units ingame to real warfare, the only realistic settings for artillery units are 'hold fire' and 'hold position'. In Spring the units take some desisions on their own if they are set on 'fire at will' and 'maneuver'. This normaly works well, because you don't have to think about fuel and ammunition and capture or capitulaten usually don't happen in Spring.Argh wrote:No. No. No! Because:
Reason A. - E.
By they way artillery units currently work, it is best to set them automatically to 'hold fire' and 'hold position' with an widget when they are build.
I am sure, that it is to complex, to make them behave 'clever' on 'fire at will', but I think some checks before automatic fire would be helpfull.
For example: artillery unit on 'fire at will'; emeny spotted:
1. make some predictive targeting
2. when the unit is ready to fire, calculate the mean error resulting from Accuracy
3. add the AOE-Range to this error
4. check if there is a friendly unit or building within this radius
5. only fire if no unit is found
Something like that should make artillery on 'fire at will' way more usefull, while the calculaton effort should be still bearable.
Y'know, I was going to rant about how mathematically complex this actually would get, but... I've actually come up with a halfway-decent solution to this. It would greatly increase CPU time, but any possible solution would, and this would involve the least new code added to Spring.
Simply put... we could set each unit up with a FBI variable called "collideFriendlyMult". The collision size on the map, XZ, could then be multiplied by that all the time, and weapons with ballistic arcs would have to simply satisfy the condition that their shots wouldn't collide with friendly units. If you set that large enough, you could have artillery very safely (but not 100% safely, due to the oval distribution pattern of their randomized shells) support your units. It would suck up a lot of CPU due to the fact that the larger Units get, the more CPU they use, but meh, there's nothing you can do about that- any solution requires a lot of math. And this would be simple and 100% optional, and would work fairly well.
Simply put... we could set each unit up with a FBI variable called "collideFriendlyMult". The collision size on the map, XZ, could then be multiplied by that all the time, and weapons with ballistic arcs would have to simply satisfy the condition that their shots wouldn't collide with friendly units. If you set that large enough, you could have artillery very safely (but not 100% safely, due to the oval distribution pattern of their randomized shells) support your units. It would suck up a lot of CPU due to the fact that the larger Units get, the more CPU they use, but meh, there's nothing you can do about that- any solution requires a lot of math. And this would be simple and 100% optional, and would work fairly well.
In some cases I'd rather have it shoot when my unit is in the way. It would probably be easier and make more sense for the artillery unit to just sense the densest spread of targets within range and have it shoot there, regardless of friendly units.
Take a limited scan of area, test each tile within for a unit lying over it. Mark enemy units over the tile with +3, tiles directly around that unit with +2, and tiles once removed with +1. Likewise mark friendly units over the tile with -3, tiles directly around that unit with -2, and tiles once removed with -1. By the time the area is marked with all of the modifiers you'd have the best possible firing solution.
Take a limited scan of area, test each tile within for a unit lying over it. Mark enemy units over the tile with +3, tiles directly around that unit with +2, and tiles once removed with +1. Likewise mark friendly units over the tile with -3, tiles directly around that unit with -2, and tiles once removed with -1. By the time the area is marked with all of the modifiers you'd have the best possible firing solution.