I have been working to identify and track down some of the inconsistent "Great Depression" occurrences and calculations. I have made modifications to the CvInfoScreen.py script to display more key data that is used in Stability.py script to determine when "Great Depressions" occur.
The most relevent information I have been interested in are those used in the final calculations of "iDifference (Stability.py)".
These would include the following -
-> pPlayer.calculateTotalYield(YieldTypes.YIELD_COMMERCE)
-> pPlayer.calculateTotalYield(YieldTypes.YIELD_PRODUCTION)
-> pPlayer.calculateInflatedCosts()
-> pPlayer.calculateTotalCommerce()
Note - "calculateTotalCommerce" is not used to calculate "iDifference", but used to calculate & display "GNP (Gold)" in the demographics and graph screens. In actuality, it is a highly inflated value that is not solely reflective of Gold (or even GNP), but is more of a summization of Gold, Research, Culture & Espionage; to include all the static culture bonuses acquired from wonders and buildings.
"iDifference" is roughly calculated in Stability.py as the difference of "iEconomy" and "iIndustry", adjusted for population.
(I'm going to leave out the population adjustments for simplicity)
iIndustry = pPlayer.calculateTotalYield(YieldTypes.YIELD_PRODUCTION)
iEconomy = pPlayer.calculateTotalYield(YieldTypes.YIELD_COMMERCE) - pPlayer.calculateInflatedCosts()
iDifference = iIndustry - iEconomy
I'm not going to argue if this is a correct approach to model a "Great Depression" occurrance and will presume it is.
The "iIndustry" calculation appears to be dead-on accurate, to include all the "hammers" produced by city specialists.
However, the "iEconomy" calculation is way too low and does not include any of the "coins" produce by city specialists.
So, adding "merchants" to a city will have no effect on the "iEconomy" component of the "iDifference" calculation. While, on the contrary, adding "engineers" to a city will directly increase the "iIndustry" calculation and lead to an exaggerated "iDifference" result. This, in-turn, is another factor in excessive "Greater Depression" occurances.
To put all of this into context, here are some numbers in my test-case game, where I have a very robust and booming economy, yet on the brink of a "Great Depression".
1. GNP (Gold) : 3626
2. Mfg. Goods (Prod) : 838 (used in iIndustry calculation)
3. Commerce Yield : 643 (used in iEconomy calculation)
4. Inflated Costs : 979 (used in iEconomy calculation)
** NOTE: the following leaves out the population adjustments for simplicity **
iIndustry would be derived solely from (2) as follows
iIndustry = 838 (Mfg. Goods)
iEconomy would be derived from the difference of (3) and (4) as follows:
iEconomy = 643 (Commerce Yield) - 979 (Inflated Costs)
iEconomy = -336
iDifference would be derived from the difference of iIndustry and iEconomy calculations as follows:
iDifference = 838 (iIndustry) - -336 (iEconomy)
iDifference = 1174
OUCH! A negative economy? My democracy has the largest economy in the world and is running a steady and consistent profit even at 70% research rate and accounting for the noticable inflation expense of 600 (out of 900). Even with only 30% of commerce flowing into my coffers, my economy is robust enough to easily meet the fiscal demands.
So, an "iEconomy" calculation of "-336" makes absolutely no sense. (even without adjusting for population)
Just from "eyeballing" the numbers, it is clear that "iDifference" is going to be calculated to trigger a "Great Depression" as soon as the (GameTurn mod 3) condition is met in stability.py.
The contributing factors to this are:
1. Calculation using an undervalued "Commerce Yield" that does not take into consideration "Merchant" specialists and appears to further ignore the multiplicative bonuses of forums, banks, etc, as well. This, in-turn is causing "iEconomy" to be artificially low.
2. A potentially overvalued "Inflated Costs" that does not appear to scale appropriately over time.
3. A rather counter-intuitive implimentation of calculateTotalYield(YieldTypes.YIELD_COMMERCE) & calculateTotalYield(YieldTypes.YIELD_PRODUCTION) that are inconsistent in their use of specialists and building modifiers. Unfortunately, one is NOT the counterpart to the other in this case.