WeaponDefs/UnitDefs/Scripts setup for a "continuous aiming"
Posted: 06 Jan 2018, 14:16
Hello!
I am looking for an effective way to implement this behaviour for most units with weapons in Balanced Annihilation.
https://www.youtube.com/watch?v=TcOUcNOuNaM
The current trick i used to achieve this video was:
WeaponDefs: Create a dummy weapon from the original weapon with these differences:
FireTolerance = 1, => Increase aimweapon call rate
AvoidFriendly/ground/feature = false, ==> Get the aim ready even if cannot shoot yet
UnitDefs: Assign dummy weapon to a new slot, and slave it to the original weapon so they always have the same targets
UnitScript: Create an AimWeapon3 script for the dummy weapon, that is the same as the original's, except that it always returns (0) (or false) and doesn't send any aim signal (that would kill the AimWeapon1 thread).
The result is a unit that constantly adjust its aim from the dummy weapon because its firetolerance never allows it have a fine aim. Since the script returns false, there is no chance that the dummy shoots even if (with a lot of luck), the firetolerance condition is obtained.
Since the moved pieces are the original weapons', but the run of the dummy weapon script doesn't block the orginal's, it doesn't prevent it from reaching its goal and fire. The result is a constant readjusting of the pieces orientation rather than an occasional that happened only when the last aim was off and couldn't allow a new shot.
In game, it results in units being able to follow their target, and not lose their dps when manoeuvering (provided that the turret turn speed is higher than the unit's turnrate).
Thing is, this is a little expensive for "just" a behaviour that should have been default to the engine:
- Target anticipation: get the weapons ready even if the target still isn't reachable, so that when it is, the weapons will be able to fire almost instantly.
- The turretspeed should be the only factor in determining if a unit will lose dps upon turning or aiming moving targets. That is if the turretspeed is lower than the turnrate, then it will not follow properly and miss shots, or if the target moves too fast, the turret will not be able to follow its movements.
I tried some other ways to achieve a similar result without have to create/use dummy weapons. The closest was attained by combining allowNonBlockingAim = true and a lower fireTolerance. The low fire tolerance would force a higher aimweapon call rate, while each new call wouldn't block the last one.
I had guessed that then, the only factor that would allow or disallow the shot to actually happen would be if the turret orientation allows the shot (angle < firetolerance/2). But from trying ingame, shots would happen even if the current orientation of the turret is completly opposed to the shot trajectory (180 degrees > firetolerance/2).
After reading what firetolerance does, it seemed it compared the last weapon's called heading/pitch with the requested one, and if they are too different, block the fire and call the new aim. That probably means that, since the previous call was in the right direction, even if the pieces rotation havent happened, the old heading/pitch are in accordance with the requested ones.
In anycase, relying on firetolerance and allownonblockingaim still wont allow any anticipation to happen since if the lof isn't free or if distance > range, it won't even call any aimweapon script.
Before I spend xx hours getting this done the dirty way, if someone actually has a more convenient option, i'm all ears. :)
Also, about the range, can I get some explanations on how does a unit decides at which range it should place itself when fighting an enemy?
When I artificially increase a unit's MaxRange, it will place itself at a distance from which it cannot shoot (= maxRange), but if I artificially lower it, the weapon's max range will override it, and it will stop closing on its target as soon as one of its weapon can aim it (=maxWeaponRange).
I guess the meaning is that the "engage" range is max(maxRange, maxWeaponRange) where maxRange is the one showing in tooltip, that can be changed via gadgets, and maxWeaponRange is the one set in the unitDefs, by setting the weapons.
The issue here is that, if I want my unit to anticipate incoming targets, i have to set the dummy weapon to a higher range, but then the unit won't engage properly and stay at this maxWeaponRange distance even if I actually lower the maxRange via gadget. Also in other cases, it broke some units' attack order because they had secondary weapons with higher range that would make it stay to far away from target.
I am looking for an effective way to implement this behaviour for most units with weapons in Balanced Annihilation.
https://www.youtube.com/watch?v=TcOUcNOuNaM
The current trick i used to achieve this video was:
WeaponDefs: Create a dummy weapon from the original weapon with these differences:
FireTolerance = 1, => Increase aimweapon call rate
AvoidFriendly/ground/feature = false, ==> Get the aim ready even if cannot shoot yet
UnitDefs: Assign dummy weapon to a new slot, and slave it to the original weapon so they always have the same targets
UnitScript: Create an AimWeapon3 script for the dummy weapon, that is the same as the original's, except that it always returns (0) (or false) and doesn't send any aim signal (that would kill the AimWeapon1 thread).
The result is a unit that constantly adjust its aim from the dummy weapon because its firetolerance never allows it have a fine aim. Since the script returns false, there is no chance that the dummy shoots even if (with a lot of luck), the firetolerance condition is obtained.
Since the moved pieces are the original weapons', but the run of the dummy weapon script doesn't block the orginal's, it doesn't prevent it from reaching its goal and fire. The result is a constant readjusting of the pieces orientation rather than an occasional that happened only when the last aim was off and couldn't allow a new shot.
In game, it results in units being able to follow their target, and not lose their dps when manoeuvering (provided that the turret turn speed is higher than the unit's turnrate).
Thing is, this is a little expensive for "just" a behaviour that should have been default to the engine:
- Target anticipation: get the weapons ready even if the target still isn't reachable, so that when it is, the weapons will be able to fire almost instantly.
- The turretspeed should be the only factor in determining if a unit will lose dps upon turning or aiming moving targets. That is if the turretspeed is lower than the turnrate, then it will not follow properly and miss shots, or if the target moves too fast, the turret will not be able to follow its movements.
I tried some other ways to achieve a similar result without have to create/use dummy weapons. The closest was attained by combining allowNonBlockingAim = true and a lower fireTolerance. The low fire tolerance would force a higher aimweapon call rate, while each new call wouldn't block the last one.
I had guessed that then, the only factor that would allow or disallow the shot to actually happen would be if the turret orientation allows the shot (angle < firetolerance/2). But from trying ingame, shots would happen even if the current orientation of the turret is completly opposed to the shot trajectory (180 degrees > firetolerance/2).
After reading what firetolerance does, it seemed it compared the last weapon's called heading/pitch with the requested one, and if they are too different, block the fire and call the new aim. That probably means that, since the previous call was in the right direction, even if the pieces rotation havent happened, the old heading/pitch are in accordance with the requested ones.
In anycase, relying on firetolerance and allownonblockingaim still wont allow any anticipation to happen since if the lof isn't free or if distance > range, it won't even call any aimweapon script.
Before I spend xx hours getting this done the dirty way, if someone actually has a more convenient option, i'm all ears. :)
Also, about the range, can I get some explanations on how does a unit decides at which range it should place itself when fighting an enemy?
When I artificially increase a unit's MaxRange, it will place itself at a distance from which it cannot shoot (= maxRange), but if I artificially lower it, the weapon's max range will override it, and it will stop closing on its target as soon as one of its weapon can aim it (=maxWeaponRange).
I guess the meaning is that the "engage" range is max(maxRange, maxWeaponRange) where maxRange is the one showing in tooltip, that can be changed via gadgets, and maxWeaponRange is the one set in the unitDefs, by setting the weapons.
The issue here is that, if I want my unit to anticipate incoming targets, i have to set the dummy weapon to a higher range, but then the unit won't engage properly and stay at this maxWeaponRange distance even if I actually lower the maxRange via gadget. Also in other cases, it broke some units' attack order because they had secondary weapons with higher range that would make it stay to far away from target.