Versus.***.ForceFire=

Tratos · General **Joined**: 01 Jan 2003

Firstly, for the purposes of this question assume the armor class is 'Cardboard'

If a unit has a primary weapon that can damage Cardboard armor class but has Versus.Cardboard.ForceFire=no set and I attempt to forcefire on an object with Cardboard armor class will it fallback to using its secondary (the secondary can affect Cardboard armor) or will it just disregard the attack order?

EVA-251 · Posted: Mon Aug 17, 2015 1:20 am Post subject:

It will be unable to attack that target.

_________________
YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead Developer Star Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007)

Millennium · Posted: Mon Aug 24, 2015 11:58 pm Post subject:

I've pointed this out before and it has been confirmed that this is a bug - the intended behaviour is that it should use the Secondary. I'm not sure when, or if ever, this is going to be fixed though.

When I reported this issue, people have pointed out to me that if the intention is to create a Primary weapon that should not be used against some kind of target, but should damage that kind of target if it accidentally gets caught in the blast zone (in my case, the example was a tank not firing its main gun vs infantry, but infantry being hurt nonetheless if it stands too close to something the main gun is fired upon), then the solution is to use 0% on the Primary instead of Versus.* tags and put an airburst weapon (with near-zero AirburstSpread) on the projectile. That airburst weapon gets a non-zero verses on the target type that you don't want the Primary to fire upon. That way, even if the Primary doesn't fire on that kind of target, if the target happens to be too close to the impact, the AirburstWeapon will still deal damage, despite 0% on the Primary.
This may be helpful for your case, too.

_________________

Tratos · General **Joined**: 01 Jan 2003

My intention was to have a primary weapon that would only fire against garrison-able buildings (the buildings having their own separate armor class), said buildings having a UC.Passthrough of 0.01 and the weapon having SubjectToTrenches=

The idea was a weapon that would clear garrisoned buildings if the enemy was in them, the infantry with it would garrison if the building was empty and using versus.**.forcefire the infantry would use their secondary to attack the buildings if force-fired (i.i friendly units are inside or you want to destroy a building you could otherwise enter.

In doing so though I think I came across another bug, that is that a weapon with SubjectToTrenches that only affects the armor class of the building will just do sod all to the infantry inside.

EVA-251 · Posted: Tue Aug 25, 2015 3:46 am Post subject:

Hm, wouldn't Versus.xxx.ForceFire= actually help in that case?

_________________
YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead Developer Star Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007)

Millennium · Posted: Tue Aug 25, 2015 10:42 am Post subject:

Tratos wrote:

My intention was to have a primary weapon that would only fire against garrison-able buildings (the buildings having their own separate armor class), said buildings having a UC.Passthrough of 0.01 and the weapon having SubjectToTrenches=

The idea was a weapon that would clear garrisoned buildings if the enemy was in them, the infantry with it would garrison if the building was empty and using versus.**.forcefire the infantry would use their secondary to attack the buildings if force-fired (i.i friendly units are inside or you want to destroy a building you could otherwise enter.

This is a very interesting application. However, I believe (I'm NOT sure) that Versus.*.ForceFire/Retaliate/PassiveAcquire actually STACK onto the next-lower firing condition, and so using ForceFire=no also implies Retaliate/PassiveAcquire=no, so your Primary would never get used on that particular type of target. That would be another issue to overcome.
I think Ares just doesn't have the means to support your idea yet.

Quote:

In doing so though I think I came across another bug, that is that a weapon with SubjectToTrenches that only affects the armor class of the building will just do sod all to the infantry inside.

This is not a bug, but quite intentional - damage that gets passed to the occupants of a building is subject to the same damage rules as if that damage would get applied to them out in the open. This allows for far more customization (eg having flamethrower infantry with asbestos suits inside a building take minimal damage when the building is shot at by fire-based occupant-killing weapon, while regular rifle guys are toast) than just passing the damage on to the occupants unmitigated.

Also, if occupant-killer weapons are fired on an unoccupied building, the damage gets passed to the building itself, meaning that if you are not going for a purely graphical change between the two weapons, you will do quite fine with just one weapon that will kill occupants IF the building is occupied, and damage the building itself if it is NOT occupied if you force-fire it.

_________________

Tratos · General **Joined**: 01 Jan 2003

Millennium wrote:

I believe (I'm NOT sure) that Versus.*.ForceFire/Retaliate/PassiveAcquire actually STACK onto the next-lower firing condition, and so using ForceFire=no also implies Retaliate/PassiveAcquire=no, so your Primary would never get used on that particular type of target. That would be another issue to overcome.
I think Ares just doesn't have the means to support your idea yet.

Does it have the same effect if all 3 conditions are stated individually;
Versus.*.ForceFire=no
Versus.*.Retaliate=yes
Versus.*.PassiveAcquire=yes

Are the retailate/passive conditions be ignored in favor of the 'higher-tier' one despite being defined as the opposite?

Millennium wrote:

This is not a bug, but quite intentional - damage that gets passed to the occupants of a building is subject to the same damage rules as if that damage would get applied to them out in the open. This allows for far more customization (eg having flamethrower infantry with asbestos suits inside a building take minimal damage when the building is shot at by fire-based occupant-killing weapon, while regular rifle guys are toast) than just passing the damage on to the occupants unmitigated.

I admit this does make sense. However, leaves little room for weapons designed purely to clear out structures as they must also be effective against targets not in structures.

Millennium · Posted: Fri Aug 28, 2015 7:21 pm Post subject:

Tratos wrote:

Millennium wrote:

I believe (I'm NOT sure) that Versus.*.ForceFire/Retaliate/PassiveAcquire actually STACK onto the next-lower firing condition, and so using ForceFire=no also implies Retaliate/PassiveAcquire=no, so your Primary would never get used on that particular type of target. That would be another issue to overcome.
I think Ares just doesn't have the means to support your idea yet.

Does it have the same effect if all 3 conditions are stated individually;
Versus.*.ForceFire=no
Versus.*.Retaliate=yes
Versus.*.PassiveAcquire=yes

Are the retailate/passive conditions be ignored in favor of the 'higher-tier' one despite being defined as the opposite?

Uncertain - I believe I tried this, and they were. But it can't hurt to re-test.

Millennium wrote:

This is not a bug, but quite intentional - damage that gets passed to the occupants of a building is subject to the same damage rules as if that damage would get applied to them out in the open. This allows for far more customization (eg having flamethrower infantry with asbestos suits inside a building take minimal damage when the building is shot at by fire-based occupant-killing weapon, while regular rifle guys are toast) than just passing the damage on to the occupants unmitigated.

I admit this does make sense. However, leaves little room for weapons designed purely to clear out structures as they must also be effective against targets not in structures.[/quote]

Which is where usually Versus.ArmorType.'' kicks in... but your case is really special. What you could try is making the occupant-killing effect on an AirburstWeapon with CellSpread=0. This would make it function on structures and whole-cell objects. Vehicles occupy an entire cell, but they are not potential building occupants, so you can just make the warhead not affect them. The weapon will maybe miss infantry entirely out in the open due to CellSpread=0, but when hitting a structure, it will work on the structure and the damage will be passed on to the infantry inside.

_________________