Thunderbrd
C2C War Dog
From GlobalDefines.xml
<!-- A way to directly enhance the value of bombarding units in city attack stacks (+%) -->
<!-- The structure should still keep them in a ratio according to the rest of the stack... this can simply help them to NOT be ignored EVER -->
<Define>
<DefineName>C2C_ROUGH_BOMBARD_VALUE_MODIFIER</DefineName>
<iDefineIntVal>-20</iDefineIntVal>
<
I believe this is direct conflict with some of the BBAI_AI_Variable_GlobalDefines that define and sets values on Bombard Usage and when the AI can ignore Bombardment when Attacking City and % of stack allowed to Be bombard units.
Also it is the only <iDefineIntegerVal> that uses a Neg integer. No other iDefine value in any of the other 11 "GlobalDefines" use a Negative integer.
Perhaps the Author did not realize the BBAI covered this area as well?
I do believe that most of the Problems with AI City attacking is in the BBAI_AI_Variable_GlobalDefines.xml and has been overlooked or not understood, perhaps a combination of both. Although the Author of the BBAI gives comments on usage for all settings.
This also raises the question has the mod had coding added that may have been unnecessary because of the lack of knowledge about what the BBAI_AI_Variable_GlobalDefines does?
Maybe all that was needed for sometime was to just adjust some of the values in BBAI_AI_Variable_GlobalDefines.xml. There is also some related values/settings in some of the other GlobalDefines as well.
So I ask these questions.
JosEPh
That tag has nothing to do with how the AI chooses to USE its siege weapons and everything to do with a final dial percentage modifier to the value of building another siege weapon after all the complex evaluations take place that do utilize the BBAI global defines. At least, it does when evaluating for the sake of building city attack stacks. When implementing that tag, it was implemented after seeing where all the other global values BBAI has in the mix take place, therefore it was made in the code with full visibility of the code. It does nothing to manipulate how siege weapons behave once in play.
It ended up being a negative because the tag was made to attempt to help to overcome the problem we were having that NO siege was being trained. Once the REAL problem with siege not being trained was discovered and fixed, we suddenly had a major overflow of siege being built and so far, it appears -20 seems to be the spot where we get pretty much the right balance of siege and other types in the stack so without the tag we still have an overbuild. The -20 means "build 20% less than you would normally think you'd want according to all the complex coding that has come before this final end of the evaluation point".
The way the stacks will arrange themselves will be changing fundamentally next version so this tag and others may disappear or take on new meaning. Koshling has suggested, and he's entirely correct in my opinion, that many problems we may be having with city attack stacks not finishing the job of taking the city is coming down to units that cannot finalize the attack themselves becoming the 'stack leaders' guiding the rest of the stack to behave as they believe themselves possible to behave. AKA, the way this is currently arranged allows siege units that have combat limits to become the leaders of the stacks because they are CITY_ATTACK AI just the same as the rest of the units and they end up taking charge of the stack when the leading City attack AI perishes. Therefore, for this and to make it easier and more time efficient for the code, splitting such siege units out into an entirely different unit AI and its own stack that compliments rather than completely melds with the core city attack stack is the step that's going to be necessary to solve these problems.