bonusShield is dead! Long live flankingBonus!
Moderator: Moderators
I should have the patch done Friday.
These angles are specified in the .fbi in degrees. The first two are positive to the left, and negative to the right, and the second two are positive to the top, and negative to the bottom.
An example armorzone:
armorZone1Left=70;
armorzone1right=-70;
armorzone1up=30;
armorzone1down=-30;
armorzone1mult=.4;
The area from 70 degrees to the left, to 70 degrees to the right, and up to 30 degrees to the top or bottom is armorzone #1. Any attack hitting here triggers armorzone #1, and does 40% of its original damage.
A second example:
armorZone2Left=180;
armorzone2right=90;
armorzone2up=90;
armorzone2down=-90;
armorzone2mult=2;
Any attack that isn't in armorzone #1 will be tested to see if it's in armorzone #2. Here, if an attack is in the back-right quadrant, at any height, it triggers armorzone #2 and does twice the damage.
If you're confused on how the angles work, look at this link. http://www.math.umn.edu/~nykamp/m2374/r ... /sphcoord/ They are basically theta and phi.
Oh yeah, my complicated mode 2 code? I think I did it in a way that would work, but I sat down and figured out that all I need is a dot product with frontdir, updir, and rightdir. Oh yeah, and what I had done before was a way-too-complicated way of doing so.
Another thought: with this implementation of armorzones, you are limited from -180 to 180. So if you want to make an armorzone stretch across the back of a unit, you will have to split it into two pieces.
Been there, done that. And more.ginekolog wrote:implementing true flanking and backattacking damage would rox. This "fuzzy" stuf is weird, there should be constant more damage zones but nothing too complicated : 90% from front, 140 from sides and 190% from behind in 90° angles or sth.
Each armorzone is defined by four angles relative to the front of the unit.Archangel of Death wrote:Could you give a bit of detail on the armorzones and how they work?
These angles are specified in the .fbi in degrees. The first two are positive to the left, and negative to the right, and the second two are positive to the top, and negative to the bottom.
An example armorzone:
armorZone1Left=70;
armorzone1right=-70;
armorzone1up=30;
armorzone1down=-30;
armorzone1mult=.4;
The area from 70 degrees to the left, to 70 degrees to the right, and up to 30 degrees to the top or bottom is armorzone #1. Any attack hitting here triggers armorzone #1, and does 40% of its original damage.
A second example:
armorZone2Left=180;
armorzone2right=90;
armorzone2up=90;
armorzone2down=-90;
armorzone2mult=2;
Any attack that isn't in armorzone #1 will be tested to see if it's in armorzone #2. Here, if an attack is in the back-right quadrant, at any height, it triggers armorzone #2 and does twice the damage.
If you're confused on how the angles work, look at this link. http://www.math.umn.edu/~nykamp/m2374/r ... /sphcoord/ They are basically theta and phi.
Oh yeah, my complicated mode 2 code? I think I did it in a way that would work, but I sat down and figured out that all I need is a dot product with frontdir, updir, and rightdir. Oh yeah, and what I had done before was a way-too-complicated way of doing so.
Another thought: with this implementation of armorzones, you are limited from -180 to 180. So if you want to make an armorzone stretch across the back of a unit, you will have to split it into two pieces.
-
Archangel of Death
- Posts: 854
- Joined: 28 Jan 2005, 18:15
lurker:
An easy way to do this might be to use a 3d vector and an angle value.
It would allow you to place the circular shield anywhere, is fairly intuitive,
easy to implement, and would run faster. It isn't quite as nice as your
spherical arc segments from an aesthetics point-of-view, but then that
doesn't much matter unless you're planning on rendering them
armorzonedir1=1 0 0 // x y z
armorzoneangle1=45 // in degrees to make it easy?
armorzonemult1=0.5
An easy way to do this might be to use a 3d vector and an angle value.
It would allow you to place the circular shield anywhere, is fairly intuitive,
easy to implement, and would run faster. It isn't quite as nice as your
spherical arc segments from an aesthetics point-of-view, but then that
doesn't much matter unless you're planning on rendering them
armorzonedir1=1 0 0 // x y z
armorzoneangle1=45 // in degrees to make it easy?
armorzonemult1=0.5
just got an idea. Would it be better for units to have their "front armor" acording to weapon position and NOT the base ?
Tanks have thickest armour in front of their firing turret and whichever direction turret is facing there is also the strongest armour. I think this way is better as it makes surrounding units more effective. Or it should be perhaps mod/unit dependant.
Tanks have thickest armour in front of their firing turret and whichever direction turret is facing there is also the strongest armour. I think this way is better as it makes surrounding units more effective. Or it should be perhaps mod/unit dependant.
Lurker: Wouldn't something like left: -90, right: 90 armor the back or would it be confused with that kind of angle?
Trep: That wouldn't allow good handling of top zones and cause issues with the layout of any standard tank, i.e. a cube. With sphere parts you end up with either gaps or unshapely overlaps. Circular areas also can't be long and thin which would be desirable for most small zones because you wouldn't want minor height differences make shots miss the zone.
Also I wish we could define weapon firearcs in squares rather than circles because you usually want different horizontal and vertical traverses, you can't make a unit with a very narrow firearc to simulate a fixed gun because then the slightest height difference will mess it up.
ginek: I think lurker said he'll allow COBs to modify the armorzones so you could just turn them with your turret.
Trep: That wouldn't allow good handling of top zones and cause issues with the layout of any standard tank, i.e. a cube. With sphere parts you end up with either gaps or unshapely overlaps. Circular areas also can't be long and thin which would be desirable for most small zones because you wouldn't want minor height differences make shots miss the zone.
Also I wish we could define weapon firearcs in squares rather than circles because you usually want different horizontal and vertical traverses, you can't make a unit with a very narrow firearc to simulate a fixed gun because then the slightest height difference will mess it up.
ginek: I think lurker said he'll allow COBs to modify the armorzones so you could just turn them with your turret.
I too think rectangular armor zones are better. It's much easier to cover the entire unit with them without overlapping.
As for the rotating turret: modern tanks have quite weak hull armor on their sides, so strong turret armor won't help much against hits in the hull no matter which way the turret is facing (the area of the turret's side projection is less than that of hull side projection, so hits in the hull are more likely). This means we'll need separate armor zones for hull and turret, and the turret armor zones should be able to rotate with it.
As for the rotating turret: modern tanks have quite weak hull armor on their sides, so strong turret armor won't help much against hits in the hull no matter which way the turret is facing (the area of the turret's side projection is less than that of hull side projection, so hits in the hull are more likely). This means we'll need separate armor zones for hull and turret, and the turret armor zones should be able to rotate with it.
Tanks are supposed to take cover. When they're behind a good chunk of wall or something and only expose their turret they basically get bonus armor.
BTW, how is the direction of the shot determined? The explosion itself won't necessarily be on the side the shot came from because it only checks collision every so often and sometimes doesn't notice it hit until it's almost out the other side of the unit. I'd propose using the velocity vector of the shot, even if the shot was off to the side and would have hit another armor zone IRL usually differnet angles behave diofferent even on the same plate so I wouldn't be too worried about misdetections that way. If that's not doable use the position of the shooter. Using the impact position will only cause trouble.
If boxes are too expensive we need at least the option to use only the XZ components of the vectors (we also need that for weapon arcs) because slopes in Spring are pretty extreme and most of the time we don't actually want to restrict the height, only the horizontal angle.
BTW, how is the direction of the shot determined? The explosion itself won't necessarily be on the side the shot came from because it only checks collision every so often and sometimes doesn't notice it hit until it's almost out the other side of the unit. I'd propose using the velocity vector of the shot, even if the shot was off to the side and would have hit another armor zone IRL usually differnet angles behave diofferent even on the same plate so I wouldn't be too worried about misdetections that way. If that's not doable use the position of the shooter. Using the impact position will only cause trouble.
If boxes are too expensive we need at least the option to use only the XZ components of the vectors (we also need that for weapon arcs) because slopes in Spring are pretty extreme and most of the time we don't actually want to restrict the height, only the horizontal angle.
Okay, lots of things to respond to:
1) You can have unlimited armorzones, but in case of blah blah blah, arbitrary justification, it's set to go up to 1000 right now. (Which is more than enough to give each 10x10 degree area a different number. But that would be slow. So don't do it.)
2) The original reasoning for the rectangular zones was partly what people have said here, and partly because all armorzones would be triggered, and that way would let them be lined up and non-overlapping.
Is the load that bad for a cople ifs, rather than the multiplication and addition to do a dot product for each armor zone? If so, I might be able to speed it up some.
3) I will now put in a couple flags to allow you to set whether 1 armorzone is triggered, or all that overlap the attack, and to set whether you want a direction and an angle, or a rectangular zone. There will also be one for you, KDR, to decide if you want the dir to the explosion, or to the attacker. (currently, I don't believe any wepon velocity data is passed to the explosion handler, and I don't want to mess with that right now. Maybe in v2, if the overhead isn't too high.)
4) it uses a linear mapping of the space around the unit. It doesn't wrap. So -90 to 90 is the front half, and -179 to 179 is everything but the very back.
5) I'll also try to implement rectangular firearcs soon, but not in this patch.
6) This gives me an excuse for lateness <_< >_> <_< for forgetting the family trip to visit relatives that I may or may not be able to bring my laptop to, and even if so, may not be able to get online.
7)"I think lurker said he'll allow COBs to modify the armorzones so you could just turn them with your turret." Already done, and if no new cob commits come up before my patch is done, will go into slot #101
<--I like this guy.
9) I'll look at the explosion calls to see how the weapon location works and maybe change it so it can be centered on the hitsphere where it goes through rather than inside.
10)KDR: it took me entire minutes to make it use the direction of the attack. And you don't want it? Minutes of my life! And now more for an exception for you?
I really do think the attack dir, when possible is better, but meh. d:
1) You can have unlimited armorzones, but in case of blah blah blah, arbitrary justification, it's set to go up to 1000 right now. (Which is more than enough to give each 10x10 degree area a different number. But that would be slow. So don't do it.)
2) The original reasoning for the rectangular zones was partly what people have said here, and partly because all armorzones would be triggered, and that way would let them be lined up and non-overlapping.
Is the load that bad for a cople ifs, rather than the multiplication and addition to do a dot product for each armor zone? If so, I might be able to speed it up some.
3) I will now put in a couple flags to allow you to set whether 1 armorzone is triggered, or all that overlap the attack, and to set whether you want a direction and an angle, or a rectangular zone. There will also be one for you, KDR, to decide if you want the dir to the explosion, or to the attacker. (currently, I don't believe any wepon velocity data is passed to the explosion handler, and I don't want to mess with that right now. Maybe in v2, if the overhead isn't too high.)
4) it uses a linear mapping of the space around the unit. It doesn't wrap. So -90 to 90 is the front half, and -179 to 179 is everything but the very back.
5) I'll also try to implement rectangular firearcs soon, but not in this patch.
6) This gives me an excuse for lateness <_< >_> <_< for forgetting the family trip to visit relatives that I may or may not be able to bring my laptop to, and even if so, may not be able to get online.
7)"I think lurker said he'll allow COBs to modify the armorzones so you could just turn them with your turret." Already done, and if no new cob commits come up before my patch is done, will go into slot #101
<--I like this guy.9) I'll look at the explosion calls to see how the weapon location works and maybe change it so it can be centered on the hitsphere where it goes through rather than inside.
10)KDR: it took me entire minutes to make it use the direction of the attack. And you don't want it? Minutes of my life! And now more for an exception for you?
I really do think the attack dir, when possible is better, but meh. d:
The Spring 1944 team has done extensive testing. They abandoned the idea of calculating the hitzone themselves in HitByWeaponId because it happens too often that a shot is registered on the wrong side of the unit, making a frontal attack count as a rear hit. The explosion is only guaranteed to be somewhere inside the unit's collision primitive, there is no guarantee whatsoever that it'll be on the side the shot came from unless you use beamlasers or really slow shots.
Unless that's not what you spent those minutes on implementing.
Unless that's not what you spent those minutes on implementing.
Fine, I'll leave it disabled for a bit, and fix the collision code to hit with the proper vector. Where should the explosion center be? on the hitsphere? 50% out? centered on the unit?KDR_11k wrote:The Spring 1944 team has done extensive testing. They abandoned the idea of calculating the hitzone themselves in HitByWeaponId because it happens too often that a shot is registered on the wrong side of the unit, making a frontal attack count as a rear hit. The explosion is only guaranteed to be somewhere inside the unit's collision primitive, there is no guarantee whatsoever that it'll be on the side the shot came from unless you use beamlasers or really slow shots.
Unless that's not what you spent those minutes on implementing.
No.Neuralize wrote:Is this disabled in 75?
Also, I'm almost done? >_> <_< >_>
I may just give up on the explosion position fixing if I can't get motivated enough and just submit what I have.
I'll have a good patch within a couple of days.
I'm having trouble figuring out what does what with the weapons code, but that's normal looking at spring
.Avoidfriendly=0, with Collidefriendly=1. Been that way for ages. The problem would be getting 'healing' weapons to fire automatically at friendlies, i would think (Though i dunno why you'd bother with this at all, a patrol command with regular repairing seems more elegant?)What makes a unit able to target friendlies? I didn't think it was possible, but you can order a unit such as the Simbase Rocket Artillery to attack one of your units, and it will track it and the rockets even guide toward it.
Does it have comething to to with command-fire?
Okay. Thank you.Saktoth wrote: Avoidfriendly=0, with Collidefriendly=1. Been that way for ages.
Now, as far as the mode where a single shot can trigger multiple armorzones, would it be useful to implement a flag get/set system for cob nd then pass the armorzones hit from 1 to 31 or 32 in a single int? Is there anything that could do flags easily already? I think it would be quite simple to implement.