AIs and the Art of War

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? :dunno:

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.
 
Much of the "problems" the AI has for Attacking, Taking Cities, Stack composition and Usage of units in stack, When to "sacrifice units" to wear down City defenders and City defenses is all in the multiple globaldefines xml files.

They have been mostly overlooked, from what I can see, for sometime.

Of course there is New lines of defines for the various New Concepts that T-brd has added to the mod.

But this poses the question; if these Global defines that have been in the Mod all along had been adjusted and tested why would this paragraph below even be necessary?
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.

Since I'm not "allowed to mod without permission", I will soon be introducing a Modmod that uses the various GlobalDefine settings (multiple files) concerning these areas I have questioned. I am of the belief that just adjusting these files can make the AI better at Taking Cities, especially player cities. That it will cause the AI to actually Use their Stacks, not just sit outside of a city or sit just inside their border when at war. And the composition of their Stacks will not be 90% Siege (although the "hated" Modification I did with Stack Limits on Siege has reduced this already).

JosEPh
 
Much of the "problems" the AI has for Attacking, Taking Cities, Stack composition and Usage of units in stack, When to "sacrifice units" to wear down City defenders and City defenses is all in the multiple globaldefines xml files.

They have been mostly overlooked, from what I can see, for sometime.
There's possibly some truth to this. As Koshling and I have worked on the code we see where global defines play a role that goes far beyond the ability of someone to describe it to us. Some may or may not still have the same effects they once had but for the most part many likely remain true to their original function and perhaps some tweaking of them could help in some places.

But this poses the question; if these Global defines that have been in the Mod all along had been adjusted and tested why would this paragraph below even be necessary?
I really think you'd have to see the code itself to understand any further than I've already explained. I don't know how accurate to the original basis of BBAI design things are but I know Koshling was in there making major adjustments before I ever took a look.


Since I'm not "allowed to mod without permission", I will soon be introducing a Modmod that uses the various GlobalDefine settings (multiple files) concerning these areas I have questioned. I am of the belief that just adjusting these files can make the AI better at Taking Cities, especially player cities. That it will cause the AI to actually Use their Stacks, not just sit outside of a city or sit just inside their border when at war. And the composition of their Stacks will not be 90% Siege (although the "hated" Modification I did with Stack Limits on Siege has reduced this already).

JosEPh
See what you can figure out. If your testing proves accurate then that's good and could help to diminish future workload.

I've not yet said anything about the stack limits on Rams but since you mention it... I do think it's a terrible way to address an AI problem because of how it would limit the player needlessly.
 
I've not yet said anything about the stack limits on Rams but since you mention it... I do think it's a terrible way to address an AI problem because of how it would limit the player needlessly.

Really am not concerned about player inconvenience in this instance but rather in improved AI performance. If both Player and AI lose some of their 20 Rams/Siege weapons they will just have to build some more and ship them to the front. 20 Seige units accord to you all should be More than enough to knock down a Preh era city defenses. At least that's what you all have been "preaching".

If You all don't like it, but rather it tests out bad, change it. You all are the senior modders after all. All I am is the :old:, knows absolutely nothing about C2C, or how to play it after 8 years, newbie modder. Faustmouse will vouch for that without a doubt, he is with out any argument the Better everything.

And if you all have not figured it out by now, yes I'm :mad:. :mad: as a Black hornet that has had a rock thrown thru it's paper nest. And it's still got me buzzin' after 2 days!
Apologies to everyone. All posted in anger because someone got a Mod involved. And it stung me bad.

JosEPh
 
All it means to me as a player is that I won't be able to build the excess amount that I would use to take down the whole nation I go to war with before the war begins. It's not about how many it takes to bring down one city but how many it would take to bring down the whole of all the enemy cities. This, btw, is also one of the things the AI is considering when it appears to be 'overbuilding' so many rams. It's not about one target it's about all of them. Once a stack is engaged at the front, it's very difficult to get reinforcements safely to them, particularly for the AI.

I understand your thinking and how you valued to make that decision. I'm simply stating that it's a sticky tape patch for poor performance in other areas. Sometimes sticky tape is good when the true fix can't be addressed for a while. And that's what we're looking at now.

However, have you been seeing much in the way of a problem there recently? I've been seeing in my limited tests some fairly good stack compositions lately but I admit those have been very limited test runs for other reasons.

As for my personal opinions, if your deep and long involvement in this mod hadn't been appreciated and your commentary hadn't been more often beneficial to the mod team than not, you'd not be ON the team.

However, if you're going to be more than willing to dish out harsh criticism elsewhere, perhaps you'd do well to consider how to handle the same harshness of criticism when it's aimed at you. I say this without offering agreement nor disagreement for Faustmouse's statements... just that we've all been equally fired at by you as well and it would be good to keep that in mind. And what many of us have done in these cases is rather than firing back words of anger and irritation (well... trying mightily not to at times... lol) is at least take pause and consider the statements made, not as an attack, but as an observation. Consider what prompted them and why and take your emotions out of that equation for a moment before further commenting.

Breaking down what he said, which I felt he had to be extremely brave to say at all, was that as a player and member of the mod team he feels that there may be elements of unit design that you are not fully appreciating before adjusting and that in light of this, some discussion would be good preceding such changes.

Probably most of us on the mod team have had to learn the hard way to bring up most of what we do for open discussion before DOING it. I'm certainly guilty to the 4 corners of the Earth of that myself. But I've been learning and trying hard to be pre-transparent with plans before implementation (making it all the more frustrating when this has been done and then after the fact of implementation someone throws a fit like they were never told it was going to take place!)

Sometimes when disagreement is presented it just comes down to begging others to see the suggestion implemented in the game before vetoing the plan. In these cases I usually I think I've shown, through application in the game, that the concept was valid. But at least I gave an opportunity to voice and take into account the concerns of others on the team. And when it comes to my own observation of the manner in which the project really pans out, I'm looking to see if the problems indicated in that previous discussion are as bad or not as bad as envisioned. In many cases those statements become another challenge to resolve the project in a more satisfactory manner for those with that opinion.

Trust for each other is a factor here as well. I can understand you reading between the lines to hear that there's a bit of a lack of that for your adjustments and feeling some offense in that statement. However, there are REASONS for that lack of trust that aren't to be taken personally but should be considered IMpersonally first.

Certain comments you've made and resistance to seeing value in strategic suggestions you've been given on how to overcome certain strategic challenges have gone ignored and discounted. Instead you continue to insist that those challenges should not exist, when in fact they are very appreciated by many equally insightful players and modders on the team. This can lead other team members to feel that you aren't seeing the light on the intent and purpose of those aspects of design. This harms the ability to trust your judgement in this regard. When those statements are brought up directly, it's not to jab your ego but to show the cause for that lack of trust so that you can understand the reasoning that brought that commenter to that point. You might wish to address those rather than simply making angry statements.

Keep in mind that what HASN'T been said, nor was any comment ever intended to mean, is that there is a feeling that you bring no value to the team. I know you're trying to find a niche that goes beyond some simple rebalances and I know you do see things that some of us don't. I realize there's a lot of frustration there. I don't blame you for that frustration. Just keep in mind that even many of the strongest modders on the team are using modmod labs for their own testing before moving to implementation. Often this is not even so that they can get the feedback of others as much as so they can get their own experienced concept of strengths and weaknesses in their concept before taking that concept to the group for inclusion in the core. I'd do more of this myself if it weren't for so much of what I do being related to the beating heart of the game that is the dll. And believe me... my options are MY answer to this same approach. Sure, I'd love to think that with each option I introduce that it would be sweepingly approved to be the core of the mod but with so many dissenting voices coming forth with every concept, this has not proven to be the way my modding goes. As you've pointed out, I could probably still improve on isolating my modding efforts behind options even more often at times but there are some adjustments that are too fundamental to always be able to do this.

We all have to gradually earn the trust of one another in how we mod. The care with which we evaluate existing structure and the attentiveness we show one another for the things we post we're planning goes a long ways towards that goal. When I started here that was a big problem for me and I recognize that this has needed to improve tremendously for establishing trust with the team. Looking back and understanding this better today than I did then, I don't blame many for being irritated with me when I started here. Then again, we probably all take as much care as we think we need to where others will see more needed to be considered... this is why we should use our modding labs as much as we can. In short, I do have regrets for my early modding behavior and I'm sure in a few years I'll look back and continue to for the way I behave still today that I have yet to fully appreciate the flaws in.

As you said, we're not that different. I thought that was a good insight.
 
If You all don't like it, but rather it tests out bad, change it. You all are the senior modders after all. All I am is the :old:, knows absolutely nothing about C2C, or how to play it after 8 years, newbie modder. Faustmouse will vouch for that without a doubt, he is with out any argument the Better everything.

And if you all have not figured it out by now, yes I'm :mad:. :mad: as a Black hornet that has had a rock thrown thru it's paper nest. And it's still got me buzzin' after 2 days!

JosEPh

Wow.
Literally ALL I said was:

- don't change core game elements without discussion.
- Try new things (like ram promotions)
- Basically just treat others, and the work of others, the same way you want to be treated.

TB is way better than me in explaining this, which is partly based on the fact that English isn't my native tongue. But I never said you are bad and never said that your work isn't appreciated. If you still chose to be offended by this, that's your choice.
 
Nvrmnd
 
The stuff in GlobalDefines is the base Civ IV stuff. I expect that the BBAI stuff which was added by modders later overwrites this value in the code making the original obsolete. At least that is the way I would code it. It would be difficult to document anyway.
 
The Siege Tower define then is a very poorly done one if it is actually for Graphics and Not for How the Tower is used in gameplay. And it's from the Original Civ IV base? That makes it even worse in what it actually does.

JosEPh
 
The Siege Tower define then is a very poorly done one if it is actually for Graphics and Not for How the Tower is used in gameplay. And it's from the Original Civ IV base? That makes it even worse in what it actually does.

JosEPh

Agreed. However, the original Civ IV base had set up the effect a little more properly. A bit more like Toffer proposed iirc.
 
Indeed someone had to change it from 10 to -1 in C2C. They probably liked the siege tower animation so wanted it on all the time. I vaguely remember turning it on for some units and off for others in RoM. In particular modern units.
 
I'm currently seeking to capture a city defended by 130 guards and.... 1350 healers!!! I'm surprised I haven't had this happen before. Is there any way to speed this up at all. Needless to say I don't have 1500 units to attack with (more like 200).. Each attack the AI takes 15-45 seconds to pick the best defender, and if I try to attack with multiple units selected, this is increased considerably. Meanwhile a fair few one-move attackers don't even get one attack, due to being redlined by passive city defences.

I know my version is old, but I will say again (ftl) I think the whole mod would work better if city civilian units were all replaced by some sort of specialist, much like settled slaves. Armies would still need healers travelling with them, but do these need to have a combat strength at all?
 
I'm currently seeking to capture a city defended by 130 guards and.... 1350 healers!!! I'm surprised I haven't had this happen before. Is there any way to speed this up at all. Needless to say I don't have 1500 units to attack with (more like 200).. Each attack the AI takes 15-45 seconds to pick the best defender, and if I try to attack with multiple units selected, this is increased considerably. Meanwhile a fair few one-move attackers don't even get one attack, due to being redlined by passive city defences.

I know my version is old, but I will say again (ftl) I think the whole mod would work better if city civilian units were all replaced by some sort of specialist, much like settled slaves. Armies would still need healers travelling with them, but do these need to have a combat strength at all?
There's obviously something causing it to want too many healers. I'll look into it. No we're not changing the roles of units or how they work when it's clearly just an AI problem. The brokerage often surprises me what it selects and why. Very frustrating system tbh. What could possibly have it needing so many healers is mystifying. Is this its last city and you've just caused them all to flee from the previous ones by chance?
 
There's obviously something causing it to want too many healers. I'll look into it. No we're not changing the roles of units or how they work when it's clearly just an AI problem.

This case may be as you suggest, but removing the whole possibility of stacks insanely bloated with law enforcement and healers - who are all imo not really valid units in a war context - will reduce the slowdowns in between turns and even during the player turn as I stated above.

The brokerage often surprises me what it selects and why. Very frustrating system tbh. What could possibly have it needing so many healers is mystifying. Is this its last city and you've just caused them all to flee from the previous ones by chance?

No not so. They are still a big civ of over 30 cities, in fact they are still I think second in power. However this city has become isolated, and all the other cities have had around 20-30 total defenders, so I guess they would have pulled this surplus bunch back elsewhere if they could.

Thanks for the quick reply TB. Happy New Year to everyone etc.
 
This case may be as you suggest, but removing the whole possibility of stacks insanely bloated with law enforcement and healers - who are all imo not really valid units in a war context - will reduce the slowdowns in between turns and even during the player turn as I stated above.
Not happening. Their ability to be built up into something combat worthy is a part of the concept here. We're moving more in the direction of no unit having no power as all units should.
all the other cities have had around 20-30 total defenders, so I guess they would have pulled this surplus bunch back elsewhere if they could.
Ok, so they are consolidating from other previously threatened and attacked cities and they haven't continued because they can't keep going. Kinda smart for them to at least try to use them as fodder to buy time actually. Thing is, he's probably happy you're taking them out because they're costing a lot and I haven't dared to try any protocols to get them to get rid of Property Control units they don't need because it can be a much larger problem coming up short. That said, a lot of these are probably Healer AIs and there's probably some flaws in the evaluation for how many of those are actually needed. One major bug in this is probably that there are so many scattered city attack stacks, each asking for their own healer AIs (and probably asking for too many). You've probably smashed most of them up to this point. Either that or they were isolated and couldn't get to their stacks so kept building them. Some sides of the AI are just flat out crude right now because the real warfare AI really needs a deep rebuild.

Anyhow, it's fair enough to say that I need to start looking for an issue there. Would it be possible to get me a save from before you attack all them so I can see what kind of AI they are using? That tends to show where the problem needs to be found.
 
I'm playing on a version from late 2015, I think it's SVN 8722. Here's the save if you're still interested.

The city is Arbel, in Australia, at the extreme west of the map near the equator. I'm fairly sure from my notes that I hadn't started attacking Arbel on this turn (since I just took the neighbouring city Nineveh). I do have plenty of earlier saves if I have made a mistake, so just let me know.
 

Attachments

  • Shaka de Paris BC-0043g57.zip
    9.3 MB · Views: 110
I'm playing on a version from late 2015, I think it's SVN 8722. Here's the save if you're still interested.

The city is Arbel, in Australia, at the extreme west of the map near the equator. I'm fairly sure from my notes that I hadn't started attacking Arbel on this turn (since I just took the neighbouring city Nineveh). I do have plenty of earlier saves if I have made a mistake, so just let me know.
So many changes were since then, that this save is most likely useless for analysis.
Use SVN version
 
This save is currently incompatible. It is from a late v35 SVN build, within 50 SVN builds will be the release of v36. Multiple Save game breaking releases inbetween this SVN and current.
@T-brd,
Do you plan to build a .dll and debug .dll for version 8722 to look at this? Especially when you have a problem right now that is taking all day to process 1 turn?

@Yudishtira ,
Long time no see. :)

I can't speak for T-brd, but you must realize this game is so incompatible with current SVN that it will take some real special effort on T-brd's part to try to even look into it.

Suggestions Only: Continue your game As Is till it CTDs. Or abandon and look up the v37 Update and Patch thread and download the latest v37.5 Full Mod patch I have linked and uploaded for Non SVN users.
 
Do you plan to build a .dll and debug .dll for version 8722 to look at this? Especially when you have a problem right now that is taking all day to process 1 turn?
No. I've probably fixed the problem if its from that far back (somewhat) but I do have a more recent save and similar report to look into the issue with.
 
Playing vers10208, sieging a Neander city, I had a dozen or so units and so did they. I would've been relying on my Shock-promoted Ambushers getting easy kills faster than they could reinforce. Would've been if the AI had not moved all but one of the defenders out of the city in about the third turn of siege. This was a jungle/hills town (size 2) 75% terrain defence. Sometimes it may be easier to retake a tile than defend it (always questionable for a city since it can be razed), but that was not the case here. They had 11 units for the counterattack, used them all, and lost every one (they were all strength 3, I had at least one 6-strength melee - albeit injured obviously - and at least one Shock 3 Ambusher). This was late Prehistory.

At one stage this city had over 70 defenders. If they had stayed in the city, they would've been safe from my Ambushers (Ambushers seem to become visible if they park next to a city - you probably know that - and why it is - but it's my first game in v38+). But roughly half the defenders were always out in the tiles surrounding the city, where I could get them... at less than 1% risk... Why do they do that? It would make sense if they were forming a stack-of-death, but they never went more than two tiles except solo.
 
Top Bottom