Good work that should help alot with the turn times.
It suggests that caching never really worked, i though it did so i didn't look at the checksum
. There must be some error in the algorithm that is used in CvChecksum that leads to collisions in case you add 1 to it.
CvChecksum is used for other things as well so it could cause more issues.
That explanation was actually found to be incorrect.
Yesterday I spent the day trying to reprogram the whole method only to find that the way I wanted to go about it would not work because the function is declared a const and won't allow some of the things I wanted to do for struct vector based caching.
However, in the process, I noticed that the first time through the routine, when iValue is being found, the first unit that is a valid target, even if it doesn't come up with an iValue, is automatically assigned as the best unit. However, if the value is 0 and every unit that is a valid target is found to have a 0 value then when the function is run and all values are cached and it only finds 0 value units to target then on every subsequent check it really finds NO best unit.
The problem was with this part of the code but it also led to an understanding that the Assassinate missions weren't finding any units to be valid to target because there were some validity assumption checks that weren't being ignored as they should have been for that particular type of situation.
So my initial discovery was correct, that all cached values were coming up with a value of 0. The problem wasn't in the caching so much as it was these two flaws, that when a default defender was found and identified, it wasn't at least assigned some value when this was done for the sake of the caching to find the same default defender later, and that the calculation of value for assassination targets was not working properly.
Both issues are now resolved and we pretty much have the same caching system we did again. Do I have some suspicions there are flaws with the caching? Yes, I do still have some suspicions. But slight inaccuracies there are not equal to the slowdown not having it presents AND my attempt to deepen it failed (though I may later try to add a few new things to the way the current method works now that I understand it a bit better.) I wonder exactly how the checksum mechanism does work and if it gets around accidental mislabeling somehow but I'm not going to further stress on that. It could be the reason for some of those moments when you think you're going to attack one unit and instead you end up attacking another once you complete the command.
After applying the last 2 "fixes" to this Epic Deity game the turn times range from a low of 3:10 to a high of 23:43. To play 8 full turns plus taking the 9th turn to the EoT Red Button took 2 hrs and 44 min. I am 1 turn into the Classical Era @ turn 349.
If you need a Current save game let me know.
Well... you provided one but if you can catch one you know leads right into one of those really long ones it could help. You're obviously, as suspected, hitting something fairly severe.
1. A combat rd for each unit in a battle is 6 rds unless killed, correct?
Incorrect. A combat consists of as many rounds as is necessary to complete the combat. In each round, both units get an attack on one another. Both of these attacks can hit or miss, so in a round, you can have:
1) Unit A strikes Unit B AND Unit B strikes Unit A OR
2) Unit A strikes Unit B BUT Unit B misses Unit A OR
3) Unit A misses Unit B BUT Unit B strikes Unit A OR
4) Both units miss each other.
The likelihood of a unit striking another is based on the ratio between the strengths of the two units in battle. (the core odds)
When a hit takes place, the ratio of strength between the two units is also the major player in defining how much damage takes place. That damage can be modified specifically by tags for that.
After each round of battle, the odds are recalculated due to the new strength ratios based on the current health of the units. (As a unit is weakened, it loses combat worthiness and it becomes harder for it to hit its foe and does less damage when it does.)
Therefore, units that avoid damage and dish out damage early in the battle can get an upper hand that builds momentum against the opponent unit.
Once one unit no longer has any Health remaining because it has taken enough damage to eliminate it, the battle concludes.
I can get into how this works with withdrawal and so on as well if you like. But that's the basic barebones of it all.
2. A unit while in this 6 rds of fighting Can achieve a Battlefield Promotion, correct?
3. Or are Battle Promos assigned After the fight?
I'd have to check for sure but I believe that a BP is only assigned at the end of the battle. The only promotions that can be given DURING the battle would be poisons and critical hits, which have not yet been fleshed out.
4. If unit is attacked multiple times and survives how many BPs can they achieve and how many checks are run?
The BP is checked at the point where the unit would normally be given XP. It can replace the granting of experience points. Only one check but after each full combat. So if a unit is attacked many times in a turn, it could theoretically get quite a few. Generally speaking, the system is supposed to make it more possible to get a BP when the battle would have awarded a LOT of XP due to the difficulty of success. That's a formula that I think needs some review as a high chance of withdrawal (or automatic withdrawal due to combat limit) does not reduce this chance which is based entirely on the difficulty of a completely successful battle. Therefore a terrible chance of success but a high chance of withdrawal is a great way to earn lots of Battlefield Promotions.
5. Or are the BPs assigned at End of All fighting before the next turn starts.
No, at the end of a battle, not a turn, to replace the XP bonus from that battle or not.
6. I have observed that many times a unit will receive a BP but still die. Why are BPs awarded to dead units? If they die should not this routine for checking or adding BPs be bypassed in the coding? Surely this would cut down on Eot processing would it not?
That's something I've not seen but it could be possible simply due to the delayed death processing of a unit. Units cannot be immediately removed in their entirety after death but must wait til the end of the turn to be completely wiped. It's a crash avoidance issue and drives me nuts. But it's probably possible to put a check to make sure the unit is still alive before it starts getting into assigning a BP. What may be happening in this case is both units can potentially kill each other in a battle now and maybe when that happens, one or the other may seem to be the winner to the system.
7. Finally why is combat 6rds? Can it be reduced? Even by 1 turn?
Again, this is not a fixed number. If it often seems like 6 rnds, that may be helpful to establish as the most common amount. I've been having the code estimate that as 10 rather than 6 and there could be some benefit to getting zeroed in a little more accurately to the standard real average.
Some combats can go as long as 20 or more turns. It depends on a lot of factors. As equipments come into play, diversifying unit capabilities even further, you'll see fights that go on for a lot of rounds because neither side can do much damage to the other due to high armor or high dodge. These kinds of effects will exacerbate or minimize effects like strengthening or weakening with each round, which units will gain with morale or berzerking or encumbrance. Should get very interesting eventually to look at the story as it plays out in the combat log. I've gotten a bit better at understanding how to add to the combat log as well so more info will be going there once I get back to those projects.
