PieceOfMind's Advanced Combat Odds

[PieceOfMind]

I thought I would FINALLY get around to trying this mod out. Unfortunately I can't get it to work with worldbuilder/scenario saves. I'll often get a problem about a missing .xml file, and while I can get a game to run, the entire GUIs are all stripped out.

But if I just play a straight-up regular game, it works.

I'll look into it. Generally speaking when entire GUIs are stipped out it's a Python related problem (as far as I know, EF knows better though) and unlikely to be caused by ACO.

Is your CustomAssets folder completely empty? I assume you were loading ACO as a mod, yes?

Also, is it normal for DLL mods to work with worldbuilder saves? I've not tried that.

 

[EmperorFool]

Generally speaking when entire GUIs are stipped out it's a Python related problem.

Yes, the interface is drawn by Python, and when it disappears it is typically because the CvMainInterface gets borked in some way: one of its drawing functions is failing repeatedly or the object itself fails to get created during startup.

I don't see how the DLL could be causing this problem. Missing XML or art files at worst would give you pink blobs and "TXT_KEY_ACO_VS" text in the hover.

Also, is it normal for DLL mods to work with worldbuilder saves? I've not tried that.

I think you can load the DLL and then start a new game using a custom scenario, but I'm not sure on this one.

 

[EmperorFool]

In my current game I have twice now seen where the defender (and odds) shown when moving to attack a mixed stack of friendly and enemy units was a friendly unit. I have never seen this before, and I'm very anal about picking my battles (too much so). I have not changed anything in the ACO code in BULL since last merging it many months ago. Have you seen this?

I'm attaching a saved game, and hopefully the active unit is a Samurai next to a stack of mixed units to the NW. When I hover over that stack, it shows me attacking Sitting Bull with whom I am not nor ever been at war.

I thought it was a fluke, but it appeared again a few turns later with Louis XIV. Sorry, I didn't save that game as I was preoccupied making dinner.

 

[PieceOfMind]

As far as I can tell, it looks to be a bug in the standard game. Turning off ACO reveals that the odds are still for Sitting Bull. After all, ACO doesn't choose the defender to show the odds for - that is done before the ACO code takes over. Still, I'm sure it's something we can look at fixing for ACO.

I'm not sure if I got your save loaded completely correctly by the way. I assume you did a BULL install over your original DLL and used CustomAssets because there was no mod name when the save tried to load. All sorts of python exceptions were happening but I was able to reproduce the ACO behaviour anyway.

 

[EmperorFool]

After all, ACO doesn't choose the defender to show the odds for - that is done before the ACO code takes over.

That's what I was thinking too. At first I thought it was just the visible defender feature that you added, but the odds were also acting like the visible defender would defend. I'll take a look at the BTS code to see how easy the fix is. It should be simple enough to ignore any defender you're not at war with. As I said, I had never seen this before in all my games.

I assume you did a BULL install over your original DLL and used CustomAssets because there was no mod name when the save tried to load.

Correct. I alwyas play that way because I'm constantly working in my CustomAssets folder. While I could move stuff just as easily into a mod folder, this is how I started.

All sorts of python exceptions were happening.

This shouldn't happen. There's nothing in the saved game that is different. Even an older version of BUG should be able to handle the script data of my newer BUG. If you have the exceptions still, I'd be curious to check them out.

 

[PieceOfMind]

This shouldn't happen. There's nothing in the saved game that is different. Even an older version of BUG should be able to handle the script data of my newer BUG. If you have the exceptions still, I'd be curious to check them out.

I think they were to do with the smart map. I don't know what smart map is, whether it's script of a feature of BULL or something, but the game couldn't find it. It might be because I didn't copy over all the assets of BULL. To be honest, I hate having to work with the custom assets folder. . Everytime I want to clear it out I have to re-install blue marble again, which is usually the only thing that gets to reside in my CA folder.

 

[EmperorFool]

SmartMap is a map script that is included in BUG. It might be in your PublicMaps folder. I keep a ZIP of the CustomAssets folder containing only BlueMarble handy for just such occasions.

Okay, so the bug is in the call to getBestDefender(). It passes false for "bTestWar" which means that it will consider every unit on the plot instead of only the ones you are at war with or could declare war upon. I think it is safe to change this to true because it's true in the call made when actually picking the defender during the attack.

Here's the attack call:

getBestDefender(NO_PLAYER, getOwnerINLINE(), pBestAttackUnit, [B]true[/B]);

And here's the odds call:

getBestDefender(NO_PLAYER, pAttacker->getOwnerINLINE(), pAttacker, [B]false[/B], NO_TEAM == pAttacker->getDeclareWarMove(pPlot));

The parameters after it are bTestPotentialEnemy and bTestCanMove, both default to false and don't matter here. I checked vanilla, and it is no different, so you're off the hook.

I'm going to hold off on the fix since I'm doing a BULL release this weekend and won't have time to thoroughly test it, but it looks fairly straight-forward.

 

[PieceOfMind]

Just one thing. Does the fix you have in mind still allow odds to be shown for a unit that you aren't at war with if there are no units on the tile you are at war with? That I think is something important to keep intact as I use it every now and then, and it would certainly occur more often than the at peace defender like your example.

 

[EmperorFool]

Does the fix you have in mind still allow odds to be shown for a unit that you aren't at war with if there are no units on the tile you are at war with?

Do you mean by holding down ALT and hovering over the tile, or does that work by holding the right mouse button down on the tile as well? There is a check for potential enemy if the tile you are entering will cause the game to ask if you want to declare war.

Give me a precise example of the scenario you're asking about and I can check the code to make sure (and test it later).

Edit: I just quickly tried the fix, and it works great. To see the odds against units you aren't at war with, hold down the ALT key.

getBestDefender(NO_PLAYER, pAttacker->getOwnerINLINE(), pAttacker, [B][COLOR="Red"]!gDLL->altKey()[/COLOR][/B], NO_TEAM == pAttacker->getDeclareWarMove(pPlot));

 

[PieceOfMind]

Do you mean by holding down ALT and hovering over the tile, or does that work by holding the right mouse button down on the tile as well? There is a check for potential enemy if the tile you are entering will cause the game to ask if you want to declare war.

Give me a precise example of the scenario you're asking about and I can check the code to make sure (and test it later).

Edit: I just quickly tried the fix, and it works great. To see the odds against units you aren't at war with, hold down the ALT key.

getBestDefender(NO_PLAYER, pAttacker->getOwnerINLINE(), pAttacker, [B][COLOR="Red"]!gDLL->altKey()[/COLOR][/B], NO_TEAM == pAttacker->getDeclareWarMove(pPlot));

Oh, I see your edit now.

I was going to say that whenever you hover OR alt over a unit a friendly combat unit you should still get the odds. I have a feeling this is not possible if it's not possible to declare war (e.g. 10 turn peace treaty) based on what you described EF.

Anyway, I'm happy with it requiring holding ALT to show the odds.

 

[EmperorFool]

Yes, I've often wanted to see the odds for attacking a unit that I cannot attack at the moment. With a little work I think that could be done (ALT + SHIFT?), but I'm a little swamped right now.

 

[Yokuyin]

I really liked this modcomponent, you did an awesome job.

I have a suggestion, is it possible to predict the combat odds when you give an unpromoted unit a certain promotion. For example, I have an unpromoted Crossbowman who wants to attack a Maceman in a city. Unpromoted you see he has 35% odds, but you see that if you give him Combat II, he gets 41% odds, with Shock he gets 52% odds and with Drill II he gets 46% odds. For some promotions it's easy to calculate (when attacking a city, CRI (+20%) is better then CombatI (+10%)), but with promotions like Drill it's a bit more tricky to predict.

For example (made in MSPaint )


I have no idea if people will find it usefull, or if it's possible at all. It's only a tingle in my mind thinking that it could be usefull in some situations.
Keep up the good work, and good luck with the project.

 

[EmperorFool]

That would be a great feature. The real trick is figuring out how to make the interface for it. You'd need some way to let the player pick which promotion(s) to assume the unit has.

BTW, choosing between Combat I and CR1 is not always so easy. The +20% of CR1 is not as good as the 10% C1 when the attacker has a much higher strength than the defender because of how the modifiers are applied. PoM can speak better to this.

 

[Roland Johansen]

I also like the idea, especially for those players who haven't read the mathematical articles about how Civ 4 combat works.

To elaborate on Emperorfools point about city raider I vs combat I and to show one of the lesser known complexities of civ4 combat:

Emperorfool is right that CR1 isn't always better than combat 1 when attacking a city. However, this has nothing to do with the raw strength value of the defender, but with the defence bonus of the defender. When the defence bonus of the defender is very great, the effect of CR1 isn't that great because the promotion is used to reduce the defence bonus of the defender. Combat 1 is directly applied to the the strength of the attacker and it's effect thus isn't dependent on the the defence bonus of the defender. Reducing a defence percentage value of 250% by 20% is relatively less than increasing an attack value of 100% by 10% in civ 4 combat. It all boils down to a few linear equations and in this case city raider I is better for defence bonuses below 120% (total defence value of 220%) and combat I for defence bonuses above 120%.

Because city raider I allows access to the higher city raider promotions and such high defence bonuses are rare, city raider I is typically the obvious choice. To understand such intricacies completely, study the Combat Explained article in the War Academy. However, a new predictive expansion to this mod component would allow more players to make the right choices without understanding the relatively complex mathematics behind the civ4 combat model.

 

[PieceOfMind]

In all honesty it would be a significant project undertaking, compared with what has been done to this point.

The "cop out" answer I'd give would be to remind that there is a point where the interface needs to stop telling you everything. Some things you have to make judgement calls on yourself. It is actually already well known what effect on raw odds various promotions have. It doesn't take long playing the game to realise that if you are attacking a melee unit, Shock will normally give the best increased odds, followed by C1 then D1. Even if we were to add this extra thing to ACO, how would you decide what statistics to show? Showing just the raw survival odds is not all that informative and does not give you much information over what is commonly known.
It would bother me some to make one promotion look better than another based on just one of the statistics - it is part of the reason I made ACO - to stop the bashing of the lesser used promotions like drill which have a more subtle effect on combat outcomes.

There is also the problem ACO is already fairly chockers, making me suggest that features like the one suggested should get a different interface component. Putting the info in a hover for the promotion selection would probably be a better idea but it has the obvious drawback of not showing all the promotion effects side by side like in your painted example.

For the present discussion over CR1 vs. C1 etc., maybe what could be done is this:
Add a single line showing what effect adding another combat promo onto the attacker would have relative to the total defense modifier. But actually this information would be fairly pointless because it can be worked out by hand from the total defense modifier (available as an option in the most recent updates of ACO) and which combat promotion you are up to.

Roland already went into it a bit, but basically the combat promos become better than promos like CR1 only at certain values of the total defense modifier. I'd be happy to write up a short post on this and put it in the S&T forum.

 

[Roland Johansen]

I guess it would be hard to represent the information in an accessible and orderly fashion. And maybe only few players would actually use it enough to justify the amount of work to create such a mod component.

By the way, nice formula in the other thread, expressing the equivalent effect of combat promotions on the defender. I think it was the nicest way to express the relative effect of combat promotions.

 

[Yesod]

I just had to reinstall everything after finding out 3.19 never installed correctly. Now when I load this mod (newest version) there's no HUD (display) Everything loads like normal, but when the game starts the tech advisor comes up with a blank screen and after closing, there's no interface.

I'll post screenshots in a minute.

 

[Yesod]

It's essentially what happened here:

http://forums.civfanatics.com/showthread.php?t=343332

I just saw an error message after trying to revert to 1.41:

BugInit - cannot find XML file for mod init.

 

[Yesod]

Here's the Python error log.

Also, I'm using Bug 4.4. It works fine by itself, it just can't load the mod.

 

[Yesod]

Never mind, got it to work. Had to do this:

http://forums.civfanatics.com/showpost.php?p=8511749&postcount=1902

It's BUG's problem anyway.