Tested it, and, well... I personally think that just causing BlockShot to occur randomly based on a tag would be a better idea... the way that this works now, you've simply changed from one bad weighting system that causes too many wasted shots... to another one. I don't think this is a real improvement, but I've already said why, and we all know that a perfect solution is unlikely. I vote for fudge and random number generators- simpler mechanics, and will almost certainly have better results than this does.
To test my assertions, folks... try testing ProximityPriority, which if I read it correctly, applies to all weapon types now... try, say, putting that, with a value of -5.0, onto flak guns, then run a bomber raid against a bunch of them... you'll quickly see why I'm underwhelmed.
Sorry KDR... almost everything else I've tested from your patches has been a distinct improvement over what we had before, I just don't think this really improved behavior- the root problem is essentially unsolvable, at any rate in a perfect sense, and I don't think this really provided enough randomness to alleviate the core problem, which is targeting code that is always going to arrive at the same answer, every aiming cycle, as things stand now.
ProximityPriority
Moderator: Moderators
KK. I'll test it when it's available. I am very interested to see if he can come up with a real improvement over the current system, insofar as issues of aiming at clusters of high-speed targets is concerned, because that could have dramatic effects on the gameplay of PURE (imagine, for example, if a fighter aircraft designed as an interceptor could be expected to fire at all 5 bombers it's heading towards, instead sending 5 missiles at the leader...).
It's not for preventing wasted shots, it's for telling a unit what it should prefer. Usually units prefer targets closer to them but if their weapon has dyndamage (or another mechanism) to work better at larger ranges then you'll want to use this to make them shoot at their optimal targets and leave the closer ones for the direct fire units to worry about. Similarily, when you have a unit that can destroy targets quickly but must never let any get close to him you can use the tag to increase the priority boost being close (actually it's an antipriority boost with larger distance but the effect is the same) gives.
For preventing wasted shots you should use this patch: http://spring.clan-sy.com/mantis/view.php?id=675
Make sure to read the notes, the original interface was rejected. If you compile a build with this patch (or wait until one becomes available) you can try the Experiment faction in KPDZ PB6, the scripts reduce wasted shots so much that you rarely see one miss (of course the shots are perfectly accurate homing missiles but it's still a sight to behold when a large number of these arties open up on an even larger swarm of enemies). Be careful, retargetting takes some CPU time (BlockShotX is called every frame if you block the shot so be careful!) and of course having target weights takes some more on every retarget. I deemed that acceptable as the Experiment will never have that much arty in play (my performance tests were with 100 arty and 200 available targets with all shots blocked forcing a retarget every frame or at least at the fastest speed a weapon will retarget, realistic numbers are 10 arty vs up to 80 available targets, probably less since only visible targets count).
Depending on the travel time of your shots it might be enough for your purposes to retarget every x shots with no weighting. That would be pretty fast.
For preventing wasted shots you should use this patch: http://spring.clan-sy.com/mantis/view.php?id=675
Make sure to read the notes, the original interface was rejected. If you compile a build with this patch (or wait until one becomes available) you can try the Experiment faction in KPDZ PB6, the scripts reduce wasted shots so much that you rarely see one miss (of course the shots are perfectly accurate homing missiles but it's still a sight to behold when a large number of these arties open up on an even larger swarm of enemies). Be careful, retargetting takes some CPU time (BlockShotX is called every frame if you block the shot so be careful!) and of course having target weights takes some more on every retarget. I deemed that acceptable as the Experiment will never have that much arty in play (my performance tests were with 100 arty and 200 available targets with all shots blocked forcing a retarget every frame or at least at the fastest speed a weapon will retarget, realistic numbers are 10 arty vs up to 80 available targets, probably less since only visible targets count).
Depending on the travel time of your shots it might be enough for your purposes to retarget every x shots with no weighting. That would be pretty fast.
That's pretty much what I think should be done- using weighting would just add a lot of maintenance hassle, frankly. Are you going to re-submit that code, or this is more-or-less defunct? Because what's in the current dev. build doesn't really help with that problem, which is the bigger issue imo...
The code for retargetting is not part of the dev build yet AFAIK so it's no wonder that it doesn't work for you 
.
Weighting is necessary to prevent your units from picking an overkilled target, remember that Spring prefers targets with less HP remaining. Set CHANGE_TARGET only makes the weapon pick another target, it does not prevent it from picking a target you don't want and it does not remember more than the last target when determining what to shoot at next. For my artillery I saw that the effectivity was much better with the weighting, otherwise the unit will not know that it won't be able to shoot at that target anyway.
I think it was roughly like this with a group of 20 artieson a pool of 300 targets: Without the lasttarget weight change (happened in changeTarget1.patch) only one or two units would keep shooting. With that about half thr group would keep shooting, the rest was still jammed. With TargetWeight the group was shooting at 90% or more of the maximum fire rate.
For your fighter I'd recommend using TargetWeight. Without that the fighter will probably keep oscillating between two targets (no problem if you make the missile fast enough so that the first target is dead by the time the third missile is ready to fire), with it you can make it cycle through any number. Using UNIT_VAR to store which target already has a missile fired at it the firing will also be coordinated between multiple units so 1 fighter hits 5 bombers in one run, 5 fighters hit 25 bombers in one run.
BTW, I don't think the load of constant retargetting is any higher than the load of the retargetting when a unit has only badTargetCategory targets in range (those force a retarget as well).
.Weighting is necessary to prevent your units from picking an overkilled target, remember that Spring prefers targets with less HP remaining. Set CHANGE_TARGET only makes the weapon pick another target, it does not prevent it from picking a target you don't want and it does not remember more than the last target when determining what to shoot at next. For my artillery I saw that the effectivity was much better with the weighting, otherwise the unit will not know that it won't be able to shoot at that target anyway.
I think it was roughly like this with a group of 20 artieson a pool of 300 targets: Without the lasttarget weight change (happened in changeTarget1.patch) only one or two units would keep shooting. With that about half thr group would keep shooting, the rest was still jammed. With TargetWeight the group was shooting at 90% or more of the maximum fire rate.
For your fighter I'd recommend using TargetWeight. Without that the fighter will probably keep oscillating between two targets (no problem if you make the missile fast enough so that the first target is dead by the time the third missile is ready to fire), with it you can make it cycle through any number. Using UNIT_VAR to store which target already has a missile fired at it the firing will also be coordinated between multiple units so 1 fighter hits 5 bombers in one run, 5 fighters hit 25 bombers in one run.
BTW, I don't think the load of constant retargetting is any higher than the load of the retargetting when a unit has only badTargetCategory targets in range (those force a retarget as well).
Really? I would've thought the weighting calc. would be a bit heavier. It's fairly trivial overall, anyhow, my main worry is how much maintenance it'll require. Sounds like it won't be too bad, though- once I've set up a distinct category and weighting, and it works, it should do what I need it to do...