It's been awhile, but I think I just put in every aoe spell without thinking about if they could do friendly fire or not. Thanks for bringing this up, but at this point I am no longer actively modding for DAO so probably will not fix this.
I would be happy to give pointers to anyone who does want to fix it.
I was just able to download it from the "download manually" link using the Dallas, Tx server (the one closest to me). Might have been a temporary internet/nexus problem - try again.
Good question, one I hadn't considered before. I reviewed the code and the new cluster detection function should process for any tactic using the enemy clustered with X allies condition, regardless of what the resulting command is if the condition is true.
Keep in mind that the cluster function changes the radius in which it searches for a cluster of the specified size based on the ability being used, and at present it is only programmed to detect the radius of most of the AoE spells, and will default to searching a radius of 10m (the size of blizzard) for everything else, including items.
Traps and bombs AoE radius is 2.5 (look in abi_base.gda, aoe_param1 column), so the function currently will default to 10 and drastically overestimate the radius. Keep in mind that a radius that size is so small that it will be very difficult to hit 2 enemies, much less 3 or more; 99% of the time that tactic condition will probably fail if I did have the radius set correctly in the clustered function. Basically bombs are only good for hitting a single enemy or maybe if placed perfectly when fighting in a confined area 2 enemies, and hence are best used manually or with single target conditions. If the radius were a little bigger this would be different, and anyone is free to change that radius as they see fit.
My current project is working on the Dragon Age Overhaul mod with redrum, so I don't have time to fix this right now (however all my sources are included so anyone with the toolset could fix it themselves). My next project will be to release a new and improved version of the Advanced Tactics mod which will include bug fixes, all the changes in my CNTS, advanced potions, and cluster condition mods, and possibly some other new features; whenever I do this I'll make sure all applicable radius's are included in the function. In fact, I'll probably just have it look up the value directly in the gda file, rather than off a custom list in the script that way it will work even if the radius's are changed from vanilla or if it is a new or user created ability.
That is basically calculating a random number and comparing it to the specified ally fail chance. So if I set ally fail chance at 80%, meaning 80% of the time I want my spell to fail if an ally is in the AoE, but 20% of the time it will still cast, then if the calculated random number is less than or equal to 80 (which statistically it should have an 80 out of 100 chance of this, or 80% as long as it is truly random) then it executes the code to make the spell fail.
nAllyFailChance != 0 or nAllyFailChance == 100
You would only use something like this if you only allowed 2 settings - always fail or never fail. And there's more efficient ways of coding that type of check anyways.
I think the intention of the author was to provide flexible functionality (being able to specify any probability of failure if ally present) even if it wasn't going to be used right then in case he wanted to change it in the future. It's a lot easier to go back and change 1 value (the fail chance) then to recode the whole thing with the added flexibility. It's also possible the author planned to implement that functionality and then change his/her mind somewhere down the line for whatever reason.
Yes. It is taken into account by checking a list of abilities that do FF, and changing the ally fail chance from 0 to 100 if the ability is on the list.
This is the list of abilities that have a 100% fail chance if an ally is in the AoE area, per the original AT mod. I did not change the chance or the abilities in the list. I haven't done an exhaustive check of what is on or not on the list, so I don't guarantee that there isn't something on it that shouldn't be, or something not on it that should be - if that is the case blame anakin .
case AT_ABILITY_INFERNO: case AT_ABILITY_GREASE: case AT_ABILITY_EARTHQUAKE: case AT_ABILITY_BLIZZARD: case AT_ABILITY_TEMPEST: case AT_ABILITY_STORM_OF_THE_CENTURY: case AT_ABILITY_DEATH_CLOUD: case AT_ABILITY_ARCHDEMON_VORTEX: case AT_ABILITY_FLAME_BLAST: case AT_ABILITY_FIREBALL: case AT_ABILITY_BLOOD_WOUND: case AT_ABILITY_CONE_OF_COLD: case AT_ABILITY_SHOCK:
19 comments
I would be happy to give pointers to anyone who does want to fix it.
I was just able to download it from the "download manually" link using the Dallas, Tx server (the one closest to me). Might have been a temporary internet/nexus problem - try again.
-Tinman
Good question, one I hadn't considered before. I reviewed the code and the new cluster detection function should process for any tactic using the enemy clustered with X allies condition, regardless of what the resulting command is if the condition is true.
Keep in mind that the cluster function changes the radius in which it searches for a cluster of the specified size based on the ability being used, and at present it is only programmed to detect the radius of most of the AoE spells, and will default to searching a radius of 10m (the size of blizzard) for everything else, including items.
Traps and bombs AoE radius is 2.5 (look in abi_base.gda, aoe_param1 column), so the function currently will default to 10 and drastically overestimate the radius. Keep in mind that a radius that size is so small that it will be very difficult to hit 2 enemies, much less 3 or more; 99% of the time that tactic condition will probably fail if I did have the radius set correctly in the clustered function. Basically bombs are only good for hitting a single enemy or maybe if placed perfectly when fighting in a confined area 2 enemies, and hence are best used manually or with single target conditions. If the radius were a little bigger this would be different, and anyone is free to change that radius as they see fit.
My current project is working on the Dragon Age Overhaul mod with redrum, so I don't have time to fix this right now (however all my sources are included so anyone with the toolset could fix it themselves). My next project will be to release a new and improved version of the Advanced Tactics mod which will include bug fixes, all the changes in my CNTS, advanced potions, and cluster condition mods, and possibly some other new features; whenever I do this I'll make sure all applicable radius's are included in the function. In fact, I'll probably just have it look up the value directly in the gda file, rather than off a custom list in the script that way it will work even if the radius's are changed from vanilla or if it is a new or user created ability.
-Tinman
Just a wonder: Does this also work with grenades like Acid Flask and Freeze Bomb?
Thanks
That is basically calculating a random number and comparing it to the specified ally fail chance. So if I set ally fail chance at 80%, meaning 80% of the time I want my spell to fail if an ally is in the AoE, but 20% of the time it will still cast, then if the calculated random number is less than or equal to 80 (which statistically it should have an 80 out of 100 chance of this, or 80% as long as it is truly random) then it executes the code to make the spell fail.
nAllyFailChance != 0 or nAllyFailChance == 100
You would only use something like this if you only allowed 2 settings - always fail or never fail. And there's more efficient ways of coding that type of check anyways.
I think the intention of the author was to provide flexible functionality (being able to specify any probability of failure if ally present) even if it wasn't going to be used right then in case he wanted to change it in the future. It's a lot easier to go back and change 1 value (the fail chance) then to recode the whole thing with the added flexibility. It's also possible the author planned to implement that functionality and then change his/her mind somewhere down the line for whatever reason.
-Tinman
RandomFloat()*100.0f <= IntToFloat(nAllyFailChance)
I was expecting something simpler looking like...
nAllyFailChance != 0 or nAllyFailChance == 100
Anyway, thanks for this fix!
Yes. It is taken into account by checking a list of abilities that do FF, and changing the ally fail chance from 0 to 100 if the ability is on the list.
This is the list of abilities that have a 100% fail chance if an ally is in the AoE area, per the original AT mod. I did not change the chance or the abilities in the list. I haven't done an exhaustive check of what is on or not on the list, so I don't guarantee that there isn't something on it that shouldn't be, or something not on it that should be - if that is the case blame anakin
case AT_ABILITY_INFERNO:
case AT_ABILITY_GREASE:
case AT_ABILITY_EARTHQUAKE:
case AT_ABILITY_BLIZZARD:
case AT_ABILITY_TEMPEST:
case AT_ABILITY_STORM_OF_THE_CENTURY:
case AT_ABILITY_DEATH_CLOUD:
case AT_ABILITY_ARCHDEMON_VORTEX:
case AT_ABILITY_FLAME_BLAST:
case AT_ABILITY_FIREBALL:
case AT_ABILITY_BLOOD_WOUND:
case AT_ABILITY_CONE_OF_COLD:
case AT_ABILITY_SHOCK: