New Beta Version - October 10th (10/10)

Status
Not open for further replies.
Reading trough the file, the computation is:

Code:
size_t nt = (viTechMedian.size() * GC.getBALANCE_HAPPINESS_THRESHOLD_PERCENTILE()) / 100;
if ((int)viTechMedian[nt] > m_iGlobalTechAvg)
        m_iGlobalTechAvg = (int)viTechMedian[nt];
With BALANCE_HAPPINESS_THRESHOLD_PERCENTILE being 40 per default (from CP, maybe changed in CBO).

In your example, the table is [54, 54, 55, 55, 59, 59, 59, 61, 65]
40% of 9 (size of the table), rounded down = 3.
So we take the cell "number 3" of the table, so the 4th cell (since it start from 0)
Which is 55 (the second one).
Plus agriculture, its 56.
 
Reading trough the file, the computation is:

Code:
size_t nt = (viTechMedian.size() * GC.getBALANCE_HAPPINESS_THRESHOLD_PERCENTILE()) / 100;
if ((int)viTechMedian[nt] > m_iGlobalTechAvg)
        m_iGlobalTechAvg = (int)viTechMedian[nt];
With BALANCE_HAPPINESS_THRESHOLD_PERCENTILE being 40 per default (from CP, maybe changed in CBO).

In your example, the table is [54, 54, 55, 55, 59, 59, 59, 61, 65]
40% of 9 (size of the table), rounded down = 3.
So we take the cell "number 3" of the table, so the 4th cell (since it start from 0)
Which is 55 (the second one).
Plus agriculture, its 56.
Good job. And again, if the value used for needs valuation is 55 or 56, and your civ has 59 techs, then being ahead is not a problem. The problem of needs arises when the rest of the world has better technologies. Or is it using the difference between our #techs and the lowered median?

Edit. OK I see. It's the difference what matters. Actually it's difference ^3, which steeps very highly, limited by a set number.

So, taking a lower percentile is making unhappiness higher.

I wonder if that dummy tech, Agribusiness, may be at fault. Could it be that it's being counted for player number of techs and ignored when getting the 'average' global tech? This would increase the difference after that tech is researched globally.
 
Last edited:
The game just frezeed during barbarian turn on turn 237. Is anyone having the same issue ? Specs are more then enough and other Mods that i use are Cultural Diversity,Infixos Mods UI Mods,Wonder Mods,Infoaddict,RAS,Ynaemp,Unique city states.
 
Reading trough the file, the computation is:

Code:
size_t nt = (viTechMedian.size() * GC.getBALANCE_HAPPINESS_THRESHOLD_PERCENTILE()) / 100;
if ((int)viTechMedian[nt] > m_iGlobalTechAvg)
        m_iGlobalTechAvg = (int)viTechMedian[nt];
With BALANCE_HAPPINESS_THRESHOLD_PERCENTILE being 40 per default (from CP, maybe changed in CBO).

In your example, the table is [54, 54, 55, 55, 59, 59, 59, 61, 65]
40% of 9 (size of the table), rounded down = 3.
So we take the cell "number 3" of the table, so the 4th cell (since it start from 0)
Which is 55 (the second one).
Plus agriculture, its 56.

This is accurate.

G
 
Good job. And again, if the value used for needs valuation is 55 or 56, and your civ has 59 techs, then being ahead is not a problem. The problem of needs arises when the rest of the world has better technologies. Or is it using the difference between our #techs and the lowered median?

Edit. OK I see. It's the difference what matters. Actually it's difference ^3, which steeps very highly, limited by a set number.

So, taking a lower percentile is making unhappiness higher.

I wonder if that dummy tech, Agribusiness, may be at fault. Could it be that it's being counted for player number of techs and ignored when getting the 'average' global tech? This would increase the difference after that tech is researched globally.

Dummy tech from what now?
 
Reading trough the file, the computation is:

Code:
size_t nt = (viTechMedian.size() * GC.getBALANCE_HAPPINESS_THRESHOLD_PERCENTILE()) / 100;
if ((int)viTechMedian[nt] > m_iGlobalTechAvg)
        m_iGlobalTechAvg = (int)viTechMedian[nt];
With BALANCE_HAPPINESS_THRESHOLD_PERCENTILE being 40 per default (from CP, maybe changed in CBO).

In your example, the table is [54, 54, 55, 55, 59, 59, 59, 61, 65]
40% of 9 (size of the table), rounded down = 3.
So we take the cell "number 3" of the table, so the 4th cell (since it start from 0)
Which is 55 (the second one).
Plus agriculture, its 56.
1. Why should you take 40%? Thats no median anymore. You have a median, if 50% have higher values and 50% have lower values, and not 40/60. Why do you artificially decrease the value and increase the needs?
2. Agriculture is already counted. There is no dummy tech. Load a save and count the techs, its already in integrated.
 
Load a save

maxresdefault.jpg
 
1. Why should you take 40%? Thats no median anymore. You have a median, if 50% have higher values and 50% have lower values, and not 40/60. Why do you artificially decrease the value and increase the needs?
2. Agriculture is already counted. There is no dummy tech. Load a save and count the techs, its already in integrated.
My bad, I thought it was Agribusiness. I should have been sleeping.
 
The game just frezeed during barbarian turn on turn 237. Is anyone having the same issue ? Specs are more then enough and other Mods that i use are Cultural Diversity,Infixos Mods UI Mods,Wonder Mods,Infoaddict,RAS,Ynaemp,Unique city states.

You probably want to submit a report on github with the relevant logs and save file.
 
Reading trough the file, the computation is:

Code:
size_t nt = (viTechMedian.size() * GC.getBALANCE_HAPPINESS_THRESHOLD_PERCENTILE()) / 100;
if ((int)viTechMedian[nt] > m_iGlobalTechAvg)
        m_iGlobalTechAvg = (int)viTechMedian[nt];
With BALANCE_HAPPINESS_THRESHOLD_PERCENTILE being 40 per default (from CP, maybe changed in CBO).

In your example, the table is [54, 54, 55, 55, 59, 59, 59, 61, 65]
40% of 9 (size of the table), rounded down = 3.
So we take the cell "number 3" of the table, so the 4th cell (since it start from 0)
Which is 55 (the second one).
Plus agriculture, its 56.
OK, I want to summarize. Gazebo is working this mod long enough to know the possibilities of coding. And this weird way of calculation may be the result of it. (DAMN YOU FIRAXIS)
But this system didn't work proper if it works that way. For games with an uneven civ number of 7 or greater, it will always give the value of the player below the median;
7*0,4 = 2,8 ~2 ... +1 for the index = 3. But the median of a system of 7 values is always the 4th highest/lowest.
For even numbers it will pick always the lower one instead of the average of the 2 middle values. Starting from 12 civs, it will also give out the value of the civ which is under the real median civ.
While I see this mess, Iam more and more in favor of tu_79 suggestion to make a population weighted tech median. This would solve this and would also represent the real technological progression of the world better.

Like this:
TECHPOP= [#citizen (civ A) * #tech (civ A)] + [#citizen (civ B) * #tech (civ B)] + [....
TECH-MEDIAN = TECHPOP / #WorldCitizen

Cause multiplying population and tech gives relative big values, and the total pop of the world should be also relative big and steady, jumps and rounding errors should be very small.
 
OK, I want to summarize. Gazebo is working this mod long enough to know the possibilities of coding. And this weird way of calculation may be the result of it. (DAMN YOU FIRAXIS)
But this system didn't work proper if it works that way. For games with an uneven civ number of 7 or greater, it will always give the value of the player below the median;
7*0,4 = 2,8 ~2 ... +1 for the index = 3. But the median of a system of 7 values is always the 4th highest/lowest.
For even numbers it will pick always the lower one instead of the average of the 2 middle values. Starting from 12 civs, it will also give out the value of the civ which is under the real median civ.
While I see this mess, Iam more and more in favor of tu_79 suggestion to make a population weighted tech median. This would solve this and would also represent the real technological progression of the world better.

Like this:
TECHPOP= [#citizen (civ A) * #tech (civ A)] + [#citizen (civ B) * #tech (civ B)] + [....
TECH-MEDIAN = TECHPOP / #WorldCitizen

Cause multiplying population and tech gives relative big values, and the total pop of the world should be also relative big and steady, jumps and rounding errors should be very small.
You know? This is not a median anymore. It's the average tech level of the people in the world. But I think it can be more steady than the current median value.

Maybe if we can get some numbers, I'd plot it to compare. We need like 10 consecutive turns in industrial with the following data: each civ population and number of techs.
 
You know? This is not a median anymore. It's the average tech level of the people in the world. But I think it can be more steady than the current median value.

Maybe if we can get some numbers, I'd plot it to compare. We need like 10 consecutive turns in industrial with the following data: each civ population and number of techs.
Damn, that's right. :)
But do you know, Gazebo wants to calculate the median, but in his code his equation is called GlobalTechAvg. ;)
Before Polynesia (India game) get conquered, it looked like this:
20*56 + 340*57 + 90*57 + 90*60 + 210*63 + 220*65 + 280*65 + 240*65 + 220*71 = 107980
Divided by total pop 1710 = 63,14

Median in this case:
Mathematical: 63
Current system: 59(+1?)
Weighted Tech: 63

Seems fair. Some more data from other games and we could validate, if this method would fitting better.
 
OK, I want to summarize. Gazebo is working this mod long enough to know the possibilities of coding. And this weird way of calculation may be the result of it. (DAMN YOU FIRAXIS)
But this system didn't work proper if it works that way. For games with an uneven civ number of 7 or greater, it will always give the value of the player below the median;

7*0,4 = 2,8 ~2 ... +1 for the index = 3. But the median of a system of 7 values is always the 4th highest/lowest.
For even numbers it will pick always the lower one instead of the average of the 2 middle values. Starting from 12 civs, it will also give out the value of the civ which is under the real median civ.
This is not really a problem. If we want a real median, something like this can be done:
Code:
size_t nt = ((viTechMedian.size() * 50) / 100));
new_val = ((int)viTechMedian[nt] + (int)viTechMedian[nt-1])/2;
if (new_val > m_iGlobalTechAvg)
       m_iGlobalTechAvg = new_val;
While I see this mess, Iam more and more in favor of tu_79 suggestion to make a population weighted tech median. This would solve this and would also represent the real technological progression of the world better.

Like this:
TECHPOP= [#citizen (civ A) * #tech (civ A)] + [#citizen (civ B) * #tech (civ B)] + [....
TECH-MEDIAN = TECHPOP / #WorldCitizen

Cause multiplying population and tech gives relative big values, and the total pop of the world should be also relative big and steady, jumps and rounding errors should be very small.

As said by tu_79, this is an average. A median based on population would be possible, like this:

Code:
viCivSortedTech = [civA,civB,civC,...] // the civ sorted by tech level.
temp_pop = 0;
i = 0;
While temp_pop < #WorldCitizen/2 do
   temp_pop += #citizen(viCivSortedTech[i]);
   i++;
done;
TechMedian = #tech(viCivSortedTech[i-1]);

This would give the tech level such that at most half of the citizens have strictly more, and at most half have strictly less.
 
Last edited:
This is not really a problem. If we want a real median, something like this can be done:
Code:
size_t nt = ((viTechMedian.size() * 50) / 100));
new_val = ((int)viTechMedian[nt] + (int)viTechMedian[nt-1])/2;
if (new_val > m_iGlobalTechAvg)
       m_iGlobalTechAvg = new_val;


As said by tu_79, this is an average. A median based on population would be possible, like this:

Code:
viCivSortedTech = [civA,civB,civC,...] // the civ sorted by tech level.
temp_pop = 0;
i = 0;
While temp_pop < #WorldCitizen/2 do
   temp_pop += #citizen(viCivSortedTech[i]);
   i++;
done;
TechMedian = #tech(viCivSortedTech[i-1]);

This would give the tech level such that at most half of the citizens have strictly more, and at most half have strictly less.
Correct and nice.

From a computational point of view, which method is lighter?
 
The first one, because it has O(0) while second one has O(#WorldCitizen). However it shouldn't be noticeable.
 
The first one, because it has O(0) while second one has O(#WorldCitizen). However it shouldn't be noticeable.
Correct, but technically false:
- O(0) is not a complexity that makes sense (nothing is instantaneous). O(1) is.
- O(#WorldCitizen) is an over-approximation. It is probably O(#Civs), and possibly O(#Cities) if the total pop of each civ isn't stored.

The conclusion remain correct. The first one is lighter, but unless accessing the total population of civs is long, the difference isn't noticeable.

Note: as a byproduct of a citizen-base average or median, it means that conquering (or nuking) cities from the tech leader increase happiness.
 
Status
Not open for further replies.
Back
Top Bottom