Love the game, but...

I was already wondering about this "Lead From Behind".

If you look at this in CvSelectionGroupAI::AI_getBestGroupAttacker

Code:
						// From Lead From Behind by UncutDragon
						if (GC.getLFBEnable() && GC.getLFBUseCombatOdds())
						{
							PROFILE("AI_getBestGroupAttacker.LFBgetBetterAttacker");

							pLoopUnit->LFBgetBetterAttacker(&pBestUnit, pPlot, bPotentialEnemy, iBestOdds, iValue);
						}

It bypasses the complete odds calculation and uses a simpler but faster calculation. But if this faster calculation gives bad results we should use the normal calculation.
I believe there's other problems than just a bad result. As I understand it, LFB is supposed to NOT send the best first (Lead from Behind means having lesser but still effective units in the stack make the first attacks so as to share the XP rewards and reduce the likelihood of your best unit dying in the first wave.) So I'm pretty sure it's working 'oddly' at the moment.

The thing I've been reluctant to try to sort out is which calculation is used for which between the forecast of the combat help panel and the actual chosen attacker. Without delving very deeply into the whole picture (which is why I estimate so much debugging time to accomplish this) I don't currently understand why we would want different functions to control each.

We have similar problems with the pathing generator where what you see is not always what you get (I suspect some adjustments on one end of that matter that debugged terrain and feature double move capabilities now need to be applied somewhere else at this point).

These issues are probably our most annoying and complex current code bugs. I know they are there but I'm focused elsewhere at the moment... I've decided on a one job at a time policy.
 
It's a dumb point to make I know, but you can always compensate for being able to use surround and destroy, while the AI doesn't, by using a higher difficulty level. Except for the whole thing about the AI getting cheaper techs and buildings as well as the the cheaper units costing less maintenance you're going for.

Anyone who could code the AI to use something like surround and destroy would be a legend. How could you program in a sense of chess-like pattern finding and strategic thinking? But more than that I wonder how I'd counter such tactics?

Capable strong detachments off my main stack still in range of my general to prevent the enemy from getting behind me? Screening units of fast cavalry with high withdraw who'll steal the enemy's movement when they try and take their positions?
 
We've got some concepts for developing AI for S&D too... it's just all bundled in with larger AI projects that nobody who CAN do it currently has the time to develop. But it should be happening fairly soon.
 
I believe there's other problems than just a bad result. As I understand it, LFB is supposed to NOT send the best first (Lead from Behind means having lesser but still effective units in the stack make the first attacks so as to share the XP rewards and reduce the likelihood of your best unit dying in the first wave.) So I'm pretty sure it's working 'oddly' at the moment.

That is one part of LFB, performance another. We don't need different calculations for the same thing. Only one is needed and was that LFB code even updated with all the new combat stuff?
 
That is one part of LFB, performance another. We don't need different calculations for the same thing. Only one is needed and was that LFB code even updated with all the new combat stuff?

There were attempts made to update it yes but there could've been some overlooked spots, particularly where one might've been fixed but then not updated everywhere it needed to be. Differences in the way the code comes together may have accounted for some of that as searching for key phrasing was largely how a lot of the spots that needed to be adjusted were often found. If one of those 'updates' missed one of a few places it should've been put then it'd be an issue.

I totally agree only one calculation should be needed! That kind of code cleanup project was something Koshling and I both saw and agreed should be done at some point. Just haven't gotten there yet.
 
I just noticed but... In the Assets/XML folder there's a file called LeadFromBehind_GlobalDefines and the first line says - more or less - 'LFB_ENABLE = 1'


Would setting that to '0' keep the game from sending the wrong units in to their deaths?
 
Could help to make sure you get the same results as what you see yes. Try it and let me know! We may wish to consider making it default to 0.
 
I just noticed but... In the Assets/XML folder there's a file called LeadFromBehind_GlobalDefines and the first line says - more or less - 'LFB_ENABLE = 1'


Would setting that to '0' keep the game from sending the wrong units in to their deaths?

That xml file and the rest of LeadFromBehind is unused in C2C so changing that has no effect.
 
That xml file and the rest of LeadFromBehind is unused in C2C so changing that has no effect.

Have you officially disabled LFB now?
 
No it was already disabled and probably never really used in C2C.

Well that's certainly strange then, since I've long since been having problems where the game would send in totally inadequate units into combat, the game displaying great odds for my anti-melee units only to send in a unit that's far weaker.

Consistently - not just once or twice - but consistently suiciding a unit, where the mouseover before combat displays odds like 92% or 87% or some other good roll for my City Raider swords, but then when actually sending the stack in it sends in the Spears or Archers instead, with the Combat Odds displaying 11% or some similarly low combat odd.


The very first version of C2C I downloaded, way before I found out about the C2C Forums (I found it off-site originally) never had this problem. Eventually I updated with the SVN and then *boom*. Never could trust the displayed combat odds again while playing the mod.



I set that to 0 earlier and I'm not quite sure... From what I could see, if I had a stack of units and attacked another stack, I often got say 82% odds on the display, but the combat log would report the remaining 18% instead, sending in spears instead of axes against melee units.
If I was attacking a single unit though, the displayed odds always matched up with the odds shown in the combat log after battle.

This was only a few tests, but that's what I could gather from the limited tries I took.
 
I guess my suspicions were incorrect... will have to take a deeper look at what makes the two calculations (projected and actual) differ (and why we use two differing calculations in the first place.)
 
That xml file and the rest of LeadFromBehind is unused in C2C so changing that has no effect.


No it was already disabled and probably never really used in C2C.

So I guess, removing the relevant XML files and any cpp code will help in reducing memorry usage.
 
Removing the code will not cause any noticable drop in memory usage. Code itself uses very little memory (the few MB that the DLL takes up is all the code is in memory). Changing the core data structures of the game would have a much larger affect. Removing 1 field from the tiles would have more effect than removing 10000 lines of general purpose code, in terms of game memory.
 
I guess my suspicions were incorrect... will have to take a deeper look at what makes the two calculations (projected and actual) differ (and why we use two differing calculations in the first place.)

IIRC.

If you are not attacking an adjacent tile.

If you have a lot of units on a tile, the odds are based on all those units attributes. But, if they are not all stacked together, when you make the attack - only the attacking units odds are used.

Example: 5 units, all seperate on a tile - unit A selected, mouse over gives 95% chance of victory (computer assuming all 5 will attack). You attack - but only the selected unit A moves, the odds are now different (only 1 unit not 5) but obviously much lower than 95% - maybe as low as 10% who knows. So the unit dies.

You have to remember the differance between units that are stacked together, or just units on the same tile. :)
 
IIRC.

If you are not attacking an adjacent tile.

If you have a lot of units on a tile, the odds are based on all those units attributes. But, if they are not all stacked together, when you make the attack - only the attacking units odds are used.

Example: 5 units, all separate on a tile - unit A selected, mouse over gives 95% chance of victory (computer assuming all 5 will attack). You attack - but only the selected unit A moves, the odds are now different (only 1 unit not 5) but obviously much lower than 95% - maybe as low as 10% who knows. So the unit dies.

You have to remember the difference between units that are stacked together, or just units on the same tile. :)

Which is a concept I've never seen until I updated my old version of C2C so long ago. Until then, the displayed odds were always shown for the best possible unit you could send in and it didn't really ever seem to matter if they were grouped (All Selected?) or just 'sitting there coincidentally on the same tile. "Grouped" is calculated differently than "Selected"? :confused:

It had frustrated me to no end, and made combat so terribly un-fun. I no longer have that very old version of C2C that (As far as I remember) never had this different method of calculating, otherwise I'd be playing that instead. If this problem ever gets solved though, I'd quickly update to the version that fixes it (At the cost of losing the hours I spent messing with the XML for the units, buildings, and civics in the current older version I'm playing currently :lol: It'd be worth it though!)
 
From what I could see, if I had a stack of units and attacked another stack, I often got say 82% odds on the display, but the combat log would report the remaining 18% instead, sending in spears instead of axes against melee units.
If I was attacking a single unit though, the displayed odds always matched up with the odds shown in the combat log after battle.

Here's a possible explanation. When you stack attack, the engine takes that to mean you are willing to expend all but one of these units to kill the top defender (the rest of the defensive stack is ignored as you can't attack it). Assuming this is what you're trying to do (it usually isn't...), your best chance is to attack with your best attacker last, sacrificing all the others before it (in order from worst to best).

Therefore, unless you don't mind losing your entire stack, and only getting the given odds of killing one defender, don't use stack attack. You wouldn't trust the AI to run your civ, so don't trust it to manage your stack in battle...;)

Further, I strongly suspect this is standard Civ/BtS behaviour. If you try and think like BtS AI:crazyeye:, you'll realize the explanation is along these lines...
 
Therefore, unless you don't mind losing your entire stack, and only getting the given odds of killing one defender, don't use stack attack. You wouldn't trust the AI to run your civ, so don't trust it to manage your stack in battle...;)

Further, I strongly suspect this is standard Civ/BtS behaviour. If you try and think like BtS AI:crazyeye:, you'll realize the explanation is along these lines...

I don't want to lose my entire stack per battle, that's why I stopped playing C2C shortly after I updated it so long ago!

In CivIV vanilla, Warlords, BTS, and every mod I've ever played - the game would always send in the unit that had the best odds of surviving (With the exception of when Drill promotions were bugged). I couldn't trust the AI to run my empire, but I could trust it when it said I had a 99% chance of killing an enemy archer defending in a city. Not anymore - now it wants to send in the spearmen I had following me protecting my units from Horse Archers instead of the City Raider IV swords. Yeah, in that situation I could just go in and manually send the swords in, but out in the field when the AI is marching around a large number of mixed units with varying promotions, I don't want to spend several minutes shuffling through my troops trying to see which ones actually get the odds the game was showing me - for each and every time I attack - every turn until one of our stacks are dead.

I never had to do that up until that time I updated C2C. In any other mod and in Civ unmodded, I can at least trust the combat odds that the game displays to me. I can't trust it in C2C anymore. I've never been a micromanaging sort, with the possible exception of my capitol or when I'm prioritizing a specific Great Person from a city, so I really grew annoyed when that sort of micromanagement became seemingly mandatory for every battle I took part in because I couldn't trust the combat odds the game displayed to me.

It's not that bad in the Prehistoric, Ancient, and early Classic - but once it gets into and past the Medieval it just gets too tedious for me to handle and I start a new game or switch mods. Even in AND and RI, once it takes ten minutes to pass a turn I lose interest in the game I'm playing, and when that time gets doubled on because I have to pick through dozens or hundreds of units every turn, I don't even want to continue at all. I hated how the Stealth Bombers had such massive range, and shuddered at having to direct them all over every turn until I realized there was an Automate Airstrike function.


I really like how this mod plays, raising a mighty empire out of literally nothing, building it all the way up from the mud and into an interstellar civilization - it just fascinated me. I don't like however having to manage every single unit every single turn. A little bit of assistance from the AI to me is a good thing. Automate Explore/Spread/Hunt, the City Governer for non-critical cities and ones not building Wonders... "Hardcore" players may avoid these things like the plague, but I find them critical for me to enjoy such massive games like this. If all the automations were disabled and you were expected to hand-manage every aspect of the game for every turn and every unit in your empire, I wouldn't even bother. That's why I got so frustrated with this combat 'bug' - because that level of micromanagement was just tiring me out and severely killing the fun factor for me, and as I pointed out - no other mod or base Civ had that feature, and the first version of C2C I tried didn't either.
 
Removing the code will not cause any noticable drop in memory usage. Code itself uses very little memory (the few MB that the DLL takes up is all the code is in memory). Changing the core data structures of the game would have a much larger affect. Removing 1 field from the tiles would have more effect than removing 10000 lines of general purpose code, in terms of game memory.

Well, that's interesting. So, having multiple properties that propagate along tiles is really memory-intensive.
 
Well, that's interesting. So, having multiple properties that propagate along tiles is really memory-intensive.

Yes. Having any data attached to game tiles should be avoided as much as possible. The map accounts for 50-80% of the memory usage of the game (depending on map size. The larger the map, the higher percent of memory usage). Units are the second biggest usage of memory.
 
Top Bottom