Combat 'hit' system changes

[Watermelon]

It seems a missed projectile doesnt do any damage at all in wz,even if it does hit another object that is not 'psTarget',for instance:
a 'missed' missile hit another enemy unit/structure accidently.

I think the current 'combat hit' system is a blend of none,it doesnt have the flexiblity of 'real' projectile with bounding box,nor the resource-saving feature of a 'pure DICE' system.

The 'missed' shot's 'miss spread' is too big too,I think the 'miss spread' value should be calculated from a droid's base accuracy and other factors,not some #define values and some rand() things.

I think we should change the current 'combat hit' system to 'real' projectile,maybe treating each projectile as a droid,which can get its own 'Naybors' and HP/other stats,possibly make larger projectiles shootable.Whenever a projectile gets too close to one of its 'Naybors' and vector z diff between the projectile and the 'Naybor' is acceptable,it explodes and causes damage to the 'victim Naybor(s)'.(to 'fake' bounding box and saves some resources)

List of things need to be changed:
1.GetNaybors for projectile objects in projectile.c.
2.Global info for projectile naybors in projectile.c.
3.Change the 'hit'/'missed' calculation to be more 'realistic',uses x,y offsets instead of #define constants.
4.Some changes in projectile update/inFlight/impact functions in projectile.c.

Any thoughts/ideas?

[DevUrandom]

Don't use z only. All vectors with Pythagoras instead. Bounding bubble. Needs the size of a unit.
I guess there are functions for such calculations in the graficscard, so maybe we can do it there in nearly no-time...
Perhaps give an alternative dice (as in roleplaying games) system for people with real poor hardware.
Another idea is to use dices for projectiles no player will see anyway. (When he is watching another part of the map.)

[Watermelon]

Don't use z only. All vectors with Pythagoras instead. Bounding bubble. Needs the size of a unit.
I guess there are functions for such calculations in the graficscard, so maybe we can do it there in nearly no-time...
Perhaps give an alternative dice (as in roleplaying games) system for people with real poor hardware.
Another idea is to use dices for projectiles no player will see anyway. (When he is watching another part of the map.)

Maybe 'real' projectile for heavy weapons/missiles and rapid firing weapons still use the 'old' DICE+projectile hybrid.

[DevUrandom]

Slowfiring projectiles shouldn't be a problem performance-wise.
Indirect fire needs a bit more calculation. (Use an "indirect-fire" flag on them to save performance on others.)
Mass firing wpns could be more problematic. (If there are problems at all.)

Also: Try running WZ through Valgrind: You get _real_ low FPS. You bullets don't fly anymore, they beam from one place to the next. This needs to be taken care of when doing the-real-projectile-calculations.

[Watermelon]

Slowfiring projectiles shouldn't be a problem performance-wise.
Indirect fire needs a bit more calculation. (Use an "indirect-fire" flag on them to save performance on others.)
Mass firing wpns could be more problematic. (If there are problems at all.)

Also: Try running WZ through Valgrind: You get _real_ low FPS. You bullets don't fly anymore, they beam from one place to the next. This needs to be taken care of when doing the-real-projectile-calculations.

yep it's frustrating to debug at 5 fps to test changes,dont know why it runs that bad with debug build+any debugger.

I changed combFire in combat.c and some projectiles functions in projectiles.c,changes I made:
1.Changed the random miss 'offset' to be based on weapon's accuracy,so weapons with better accuracy's 'miss offset' value is much more smaller now.
2.'Missed' projectiles are no longer 'sure miss' now,they can still hit other targets after it misses the 'intended' target.
3.Added functions for projectiles to get Naybors within 4 'tiles'(droid's DroidGetNaybor function gets Naybors within 8 'tiles')
4.Weapon projectiles should no longer be able to 'shoot through' enemy tanks to hit the target behind it,instead it will collide with the obstruction and impact(exploded) and causes damage to the obstructive object.
5.Added switch 'case' for object type OBJ_BULLET(projectile) in EstablishTargetRadius,maybe it'll be useful one day when we want to implement a 'counter-missile' weapon.
6.Added a weaponSubClass called WSC_COUNTER.(counter missile)

[DevUrandom]

Watermelon: For whatever you implement, please keep in mind that you should be able to provide _seperate_ patches for each single feature. So at no time a mass-change-with-1000-new-features patch will be accepted. The chance that it breaks something are big and it is _very_ difficult to debug it afterwards.
Best practice is:
1. work on a single feature
2. create a patch
3. revert the working copy
4. work on the next feature
5. create a patch
...

If you have patches which depend on each other you should just skip step 4 and just revert if you start to work on something independend.
Other method is to make a dev commit your patches very fast. (For that to work your patches should be created with (T)SVN, so Windows devs (Troman) can apply your patches as well.)

[Kamaze]

6. ?????
7. PROFIT!

*SCNR* :)

[Watermelon]

Thanks for the instructions/tips,the multiple-turret patch is finished and tested,and it'll be reviewed/fixed by Troman.

This projectile feature is independent from multiple-turret patch,its main propose is to make 'hit' and 'miss' in combat system relative 'hit' and 'miss'.(more realistic)

Brief explanation of 'old' combat 'hit' system:(maybe due to the limitation of the original sys reqs)

Firstly,roll 'DICE'(0-100),if DICE < attacker.accuracy * visibility modifier + accuracy bonus,it's 'sure hit'
else 'sure miss'.

1.sure hit:I throw a grenade at you,you see the grenade and run 100 miles away from the grenade's predicted destination while the grenade is in flight,then it explodes at the predicted destination and you are killed by the grenade 100 miles away from the location where the grenade exploded...

2.sure miss:I throw a grenade at you,the grenade missed you and hit another person,the grenade explodes and causes no damage to the person being hit by the grenade...

'New' combat hit system:

Firstly,roll 'DICE'(0-100),if DICE < attacker.accuracy * visibility modifier + accuracy bonus,it sends a projectile to the target position without offsetselse send a projectile to the target position with offsets based on weapon accuracy.

1.the projectile will get 'Naybors' when it's in flight and check whether it collides with any of 'Naybors' or obstruction.

2.a 'missed' shot can hit too while a 'hit' shot can miss too.

the only problem with the 'New' combat hit system is that it's very hard to hit a moving target,because all projectiles in wz are too slow to reach the target's original position in time.

[Troman]

I like the idea, but your last sentence is what making me worry too. How well will it work with VTOLs, have you tested? I think AA weapons never hit VTOLs while they are flying at full speed.

This will cause for some rebalance in the game: faster units and weapons with faster projectiles will become deadlier while slower units and weapons with lower projectile speed will become less effective.

Maybe we should apply an intercepting algorithm. Like adding another dice roll for a chance of unit applying interception, or degree of interception. Interception chance could also be affected by unit's rank.

[Watermelon]

I like the idea, but your last sentence is what making me worry too. How well will it work with VTOLs, have you tested? I think AA weapons never hit VTOLs while they are flying at full speed.

This will cause for some rebalance in the game: faster units and weapons with faster projectiles will become deadlier while slower units and weapons with lower projectile speed will become less effective.

Maybe we should apply an intercepting algorithm. Like adding another dice roll for a chance of unit applying interception, or degree of interception. Interception chance could also be affected by unit's rank.

AAGun needs some changes too,with 'new' hit system the current AAGun will never hit moving VTOLs,it's like trying to shoot down a modern aircraft with a WWII AA weapon.

I added a 'radius multipler' to all projectiles except the weapon subclass 'LAS_SAT'(not sure what it does to be honestly).

MGs:(2)
targetHitboxRadius *= sqrt(2);

Cannon/Laser/Gauss:(3)
targetHitboxRadius *= sqrt(3);

Missiles/Rocket:(4)
targetHitboxRadius *= 2;

AAGuns(9)
targetHitboxRadius *= 3;

So moving units should be a bit easier to hit now with the 'real' hit system,esp VOTLs(3x radius).

Old 'miss offset algorithm':(random + based on target distance)
xDiff = ABSDIF(psAttacker->x,psTarget->x);
yDiff = ABSDIF(psAttacker->y,psTarget->y);
missDist = (xDiff > yDiff ? xDiff + (yDiff >> 1) : yDiff + (xDiff >> 1));

// Calculate where the shot will end up
missDist = missDist >> 2;
if (missDist x;
missY = aScatterDir[missDir].y * (rand() % missDist) + psTarget->y;

new 'miss offset algorithm':(random + weapon accuracy)
missDist = 2 * (100 - (weaponLongHit(psStats,psAttacker->player) * hitMod /100) + hitInc);
missDir = rand() % BUL_MAXSCATTERDIR;
missX = aScatterDir[missDir].x * missDist + psTarget->x + minOffset;
missY = aScatterDir[missDir].y * missDist + psTarget->y + minOffset;

[Kamaze]

Ok, i had the chance to test the new 'Hit-System'.
During the first fight you'll notice the changes instead!
(Like, if a building truck is behind an oil derrick, you cant hit the truck and will hit the derrick instead)

But a bit buggy, yet 

1) On a machine gun fight, only the units on the front line will get hits.
But the other ones behind them, could fire normally.

2) -like expected- i didn't hit a moving truck with my units.

3) See attachment, it was a bit annoying.

With a bit tuning, i would be a great addition!
(More strategical use of the different weapons and tactical micromanagement / unit placing)

[Watermelon]

1) On a machine gun fight, only the units on the front line will get hits.
But the other ones behind them, could fire normally.

hmm I think it's intended,dont think mg bullets can penetrate units on the front line.

2) -like expected- i didn't hit a moving truck with my units.

we need a target prediction(there is a research with the same name,but it doesnt work  ) when shooting at moving targets.I'll see if I can add a target prediction to targeting functions.

3) See attachment, it was a bit annoying.

With a bit tuning, i would be a great addition!
(More strategical use of the different weapons and tactical micromanagement / unit placing)

thx

Maybe it's because the 'hitbox' radius of the buildings are too big and the bullets got collided with the building radius before it could normally reach the building truck.

[Troman]

I added a 'radius multipler' to all projectiles except the weapon subclass 'LAS_SAT'(not sure what it does to be honestly).

LAS_SAT is a huge laser satellite beam coming from the sky.


If I understand it correctly with additional redius damage you try to compensate inability of a unit to hit a fast-moving turret, since bullets can miss their targets now.

Giving each weapon a (splash) radius is not a good idea imo. First of all such data should be defined in weapons.txt file, but then all weapons already have splash damage defined and I don't think machinegun (for example) having splash damage really makes sense. Doing this you are making obsolete some weapon data from weapons.txt.

I think we need another approach, like predicting the location of the target for example. An intercepting algorithm is both efficient and looks impressive in the game, since it makes unit behaviour look smarter and it gets rid of the side effects of all weapons haveing splash damage hardcoded into the game.

EDIT: I guess I was too slow with replying.

[Troman]

hmm I think it's intended,dont think mg bullets can penetrate units on the front line.
we need a target prediction(there is a research with the same name,but it doesnt work  )

Indeed, there are unused research topics for target pridiction for AA, howitzer, missiles and railgun weapons. (I wonder what the game would look like if Pumpkin implement finish all ideas they had).

We can probably add new research for each weapon system that would enable target prediction.

[Watermelon]

LAS_SAT is a huge laser satellite beam coming from the sky.


If I understand it correctly with additional redius damage you try to compensate inability of a unit to hit a fast-moving turret, since bullets can miss their targets now.

Giving each weapon a (splash) radius is not a good idea imo. First of all such data should be defined in weapons.txt file, but then all weapons already have splash damage defined and I don't think machinegun (for example) having splash damage really makes sense. Doing this you are making obsolete some weapon data from weapons.txt.

I think we need another approach, like predicting the location of the target for example. An intercepting algorithm is both efficient and looks impressive in the game, since it makes unit behaviour look smarter and it gets rid of the side effects of all weapons haveing splash damage hardcoded into the game.

EDIT: I guess I was too slow with replying.

to compensate inability of a unit to hit a fast-moving turret:Yes
splash damage:No

The way wz's projectile 'hit' system is a bit odd,there must be a 'chosen' target of a projectile,when the target exists and the projectile's state becomes 'IMPACT',it causes damage to the 'chosen' target only.So the projectile wont cause damage all units/structures within the projectile 'radius'.

Target prediction requires the velocity info of a droid,which doesnt exist in current 'droid' structure,to add that,we'll need to add at least 1 'iVector' value 'lastSeen' to droid struct to store the position where the droid was seen in previous 'frame',then add another function 'DroidGetVelocity' to droid.c,which will perform a 'diff between current x,y,z and lastSeen' calculation and return the diff as velocity.At last,do another calculation to predict the target location.( Distance/weaponFlightSpeed * DroidVelocity + DroidCurrPosition)