New Version - June 2nd (6-2)

Status
Not open for further replies.
Having followed the last several points, I'll admit to being completely confused about how the current system is working. And I don't want to discuss further changes until we all are 100% aware of how its working.

I am aware of the following entities:

1) UnHappiness determined by needs.
2) UnHappiness capped by type (only X% can be from distress, Y% from poverty, etc).
3) UnHappiness capped by total population
4) UnHappiness reduced by 1 with certain buildings.

But I am not clear how these entities currently work together, and in which order. @Gazebo, can you walk us through a really good example of how the system is utilizing each of these pieces, and show us when the caps are applying, when they are not....and then ultimately how the UI is showing them? I know you did one earlier but I'll admit I am still very confused.
 
You claimed throwing everything out was absurd for like 2 years, then you threw out that system to create this one, and I don't think anyone even suggested throwing it out completely this thread. Frankly this a gross misrepresentation of the people who are criticizing, who are trying to improve the mod.

I have to be honest I can't make sense of the current UI, I don't understand what you are changing. From a mechanics point of view, I'm just lost. I understand just as someone who plays the game. From playing, I understand that I regularly get 2, sometimes 3, new unhappiness for growing in the Industrial era, which is making me value food extremely lowly. Maybe the removal of the pop scaler helps, but what this happiness system is telling me is that production strong, food weak. From a gameplay perspective, that is what it encourages, not the goals you listed earlier.

I believed your explanation from earlier today, but apparently it was totally wrong? There are other explanations which contradict each other, and I can't tell who is right. So, I really have to challenge that the UI is "doing its job"; this whole discussion is evidence that it isn't.
You're right. I was reading it wrong, thinking it was showing the same values as the previous betas. It might be my fault, but it's true that this can't be clear to someone unfamiliar with the system.
 
Ok. Buildings reduction are not reducing the cap, but the effect is even stronger than I thought, making the whole unhappiness from needs complexity unnecessary.

As it is, the biggest factors are city pop size and the reduction buildings. See.
Unhappy = deficit (capped by pop) - reductions
In the case above, where the cap is at 4 in the worst case, and reduction is 1 from buildings, unhappiness can never be bigger than 3 from this need, which would be the same as the reduced cap value. But it's even stronger since having a deficit value lower than the cap will still benefit from the reduction. If deficit is 2, capped at 4, reduced by 1, the unhappiness is 1.

Anyways, the example discussed by Biteinthemark, where all the deficits were well over the pop cap, shows that we can ignore yields as long as we can provide happiness for the reduced cap value (which is obtained by hammers).

If that is going to be the case, I understand CrazyG proposal for dumping the whole yield needs mechanics. We don't need such luggage for such trip.

Alternatively, the reduction could be applied to the deficit values before the cap, making yields relevant as long as the pop cap is not hit.
For example,
Deficit 8, pop cap 4, reduction 2,
Unhappiness should be 6 (8-2), capped at 4, thus 4.
Now we can just work on caps so they are slightly lower than the happiness we may find to guarantee that some care must be taken to our yield efficiency.

This will have the side effect that building a barracks won't immediately reduce distress by 1, if deficit is well over the cap. But unhappiness from needs will be connected to yields for longer.

Aha! I see the confusion. To note, it’s not capped. There is no cap. The ‘real’ value is simply the unmodified unhappiness from a yield, and the reduction is the effect of buildings built in the city.

Well technically the cap is your total population. But you get the idea. So yields do matter, quite a bit. The current build shows that especially, as the needs modifiers are much lower. ‘Throwing it all out’ is absurd. I abhor defeatism.

G
 
You're right. I was reading it wrong, thinking it was showing the same values as the previous betas. It might be my fault, but it's true that this can't be clear to someone unfamiliar with the system.
People unfamiliar with the system don't need to know how it works, the UI just needs to tell them how to deal with their unhappiness.

The system @Gazebo gave us a glimpse of tells you these things:
  • How many total yields of a given need you are missing. This is the Deficit.
  • How much unhappiness that deficit is creating, and how much is being reduced by need reduction buildings. This is the Actual X :c5unhappy: / Reduced by Y.
  • How many yields you need to add to reduce unhappiness from a need by one. This is the (X from unhappy :c5citizen:).
 
Having followed the last several points, I'll admit to being completely confused about how the current system is working. And I don't want to discuss further changes until we all are 100% aware of how its working.

I am aware of the following entities:

1) UnHappiness determined by needs.
2) UnHappiness capped by type (only X% can be from distress, Y% from poverty, etc).
3) UnHappiness capped by total population
4) UnHappiness reduced by 1 with certain buildings.

But I am not clear how these entities currently work together, and in which order. @Gazebo, can you walk us through a really good example of how the system is utilizing each of these pieces, and show us when the caps are applying, when they are not....and then ultimately how the UI is showing them? I know you did one earlier but I'll admit I am still very confused.

I’m on mobile today hard to type lots of stuff. But in short I’ll note that 2 is not a thing. There isn’t an artificial cap. Cap is pop only.

G
 
You claimed throwing everything out was absurd for like 2 years, then you threw out that system to create this one, and I don't think anyone even suggested throwing it out completely this thread. Frankly this a gross misrepresentation of the people who are criticizing, who are trying to improve the mod.

I have to be honest I can't make sense of the current UI, I don't understand what you are changing. From a mechanics point of view, I'm just lost. I understand just as someone who plays the game. From playing, I understand that I regularly get 2, sometimes 3, new unhappiness for growing in the Industrial era, which is making me value food extremely lowly. Maybe the removal of the pop scaler helps, but what this happiness system is telling me is that production strong, food weak. From a gameplay perspective, that is what it encourages, not the goals you listed earlier.

I believed your explanation from earlier today, but apparently it was totally wrong? There are other explanations which contradict each other, and I can't tell who is right. So, I really have to challenge that the UI is "doing its job"; this whole discussion is evidence that it isn't.

When people start throwing around the words ‘total rework’ and ‘throw out needs system’ I consider that ‘throwing everything out.’ The recentish change to localized happiness was actually pretty trivial code wise. Hardly a total rework.

I posted Ui point for feedback. So explicit rundowns of what you don’t understand would be helpful. Vague comments are hard to actualize.

G
 
People unfamiliar with the system don't need to know how it works, the UI just needs to tell them how to deal with their unhappiness.

The system @Gazebo gave us a glimpse of tells you these things:
  • How many total yields of a given need you are missing. This is the Deficit.
  • How much unhappiness that deficit is creating, and how much is being reduced by need reduction buildings. This is the Actual X :c5unhappy: / Reduced by Y.
  • How many yields you need to add to reduce unhappiness from a need by one. This is the (X from unhappy :c5citizen:).
Thanks. X from unhappy people can be obtained dividing the deficit value by the total unhappy people from this need.
In illiteracy 2
Deficit 8 (4 per unhappy pop)
This is like saying that for every 4 deficit points, one citizen gets unhappy from illiteracy. Not sure if this this is simply a derivated value.
 
Thanks. X from unhappy people can be obtained dividing the deficit value by the total unhappy people from this need.
In illiteracy 2
Deficit 8 (4 per unhappy pop)
This is like saying that for every 4 deficit points, one citizen gets unhappy from illiteracy. Not sure if this this is simply a derivated value.

The point of my suggestion, which Gazebo said he will try to implement, is to replace "X from unhappy" (which is deficit divided by unhappiness) by the actual needed to reduce the unhappiness need by one (which I called "X for -1 :c5unhappy:")
 
I’m on mobile today hard to type lots of stuff. But in short I’ll note that 2 is not a thing. There isn’t an artificial cap. Cap is pop only.

G

Completely understand, take your time and do it right. I just think that any further discussion on this issue should be halted until you have had the chance to show us. We are all arguing from ignorance, which never generates fruitful ideas.
 
The underlying system works as follows:
  1. For a given need, a city requires X yields per :c5citizen:. This is determined by the global median plus any modifiers that city has (empire size, tech, etc).
  2. For every 0.25* yields per :c5citizen: that a city does not meet, that need produces 1 unhappiness. There is no cap to the amount of unhappiness this can create.This is reported as Actual.
    Eg. If we only produce 1 :c5gold: per :c5citizen:, and the need is 4:c5gold: per :c5citizen:, then poverty produces 12:c5unhappy:.
  3. Multiply the missing yields per :c5citizen: by :c5citizen: to get the Deficit. It is purely informational. The line also states how many yields is required to reduce unhappiness by 1, reported in X per unhappy :c5citizen:. This is also purely informational, and somewhat inaccurate.
    Eg. If we have a population of 10, then our deficit is 3:c5gold:/:c5citizen:*10:c5citizen: = 30:c5gold: (2.5 per unhappy :c5citizen:).
  4. Buildings can reduce the unhappiness produced from a yield/source. The reduction is reported in Reduced by X and the modified result is reported in X from <yield/source>. It may be further reduced in #5. It does not modify the deficit line.
    Eg. If the city has an aqueduct, then poverty is only producing 11:c5unhappy:.
  5. Total unhappiness has a cap of city population. Unhappiness follows a hierarchy, with a source higher on the the list being added before a source lower in the list (including unhappiness from all sources, not just needs). If the sum of all (modified by buildings) unhappiness is greater than the population, then unhappiness sources at the bottom of the list (starting with boredom) are reduced until unhappiness is equal to the population. When boredom is reduced to zero and unhappiness is still higher than population, then illiteracy is reduced, etc. This is the final number in X from <yield/source>.
    Eg. If we have 3 distress, then our 10:c5citizen: city will have 3:c5unhappy: from distress and 7:c5unhappy: from poverty (reduced from 11). All other unhappiness sources have been reduced to zero (assuming zero raw unhappiness sources set between distress and poverty).
  6. Sum all unhappiness entries to get total unhappiness produced by the city.
    Eg. We have 10:c5unhappy:.
Edits: fixing some formatting to try and make it easier to read.

* Current value as per this post.
 
Last edited:
Thanks. X from unhappy people can be obtained dividing the deficit value by the total unhappy people from this need.
In illiteracy 2
Deficit 8 (4 per unhappy pop)
This is like saying that for every 4 deficit points, one citizen gets unhappy from illiteracy. Not sure if this this is simply a derivated value.
It is simply a derived value. It overestimates how much is actually required, assuming the unhappiness isn't being modified by anything, and gets more inaccurate as the unhappiness for that need gets further away from its actual unhappiness.
 
Last edited:
The underlying system works as follows:
  1. A city requires X yields per :c5citizen:. This is determined by the global median plus any modifiers that city has (empire size tech etc).
  2. For every 0.25 yields per :c5citizen: that a city does not meet, that need produces 1 unhappiness. There is no cap to the amount of unhappiness this can create. Eg., if we only produce 1 :c5gold: per :c5citizen:, and the need is 4:c5gold: per :c5citizen:, then poverty produces 12:c5unhappy:. This is reported as Actual.
  3. Multiply the missing yields per :c5citizen: by :c5citizen: to get the Deficit. It is purely informational. The line also states how many yields is required to reduce unhappiness by 1, reported in X per unhappy :c5citizen:. This is also purely informational, and somewhat inaccurate. Eg., if we have a population of 10, then our deficit is 3:c5gold:/:c5citizen:*10:c5citizen: = 30:c5gold: (2.5 per unhappy :c5citizen:).
  4. Buildings can reduce the unhappiness produced from a yield/source. The reduction is reported in Reduced by X and the modified result is reported in X from <yield/source>. It may be further reduced in #5. It does not modify the deficit line. eg. If the city has an aqueduct, then Poverty is only producing 11:c5unhappy:.
  5. Total unhappiness has a cap of city population. Unhappiness follows a hierarchy, with a source higher on the the list being added before a source lower in the list (including unhappiness from all sources, not just needs). If the sum of all (modified by buildings) unhappiness is greater than the population, then unhappiness sources at the bottom of the list (starting with boredom) are reduced until unhappiness is equal to the population. When boredom is reduced to zero and unhappiness is still higher than population, then illiteracy is reduced, etc. This is the final number in X from <yield/source>. Eg. If we have 3 distress, then our 10:c5citizen: city will have 10:c5unhappy:, 3 from distress and 7 poverty (reduced from 11). All other unhappiness sources have been reduced to zero (assuming zero raw unhappiness sources set between distress and poverty).
  6. Sum all unhappiness entries to get total unhappiness produced by the city.

Reading in a hurry but this looks spot on.
 
During normal play, #5 should not be necessary. The system is not meant to have unhappiness maximized, as both yields and unhappiness reduction buildings become meaningless, causing us to revert to Vanilla unhappiness mechanics.
 
The underlying system works as follows:
  1. For a given need, a city requires X yields per :c5citizen:. This is determined by the global median plus any modifiers that city has (empire size, tech, etc).
  2. For every 0.25 yields per :c5citizen: that a city does not meet, that need produces 1 unhappiness. There is no cap to the amount of unhappiness this can create.This is reported as Actual.
    Eg. If we only produce 1 :c5gold: per :c5citizen:, and the need is 4:c5gold: per :c5citizen:, then poverty produces 12:c5unhappy:.
  3. Multiply the missing yields per :c5citizen: by :c5citizen: to get the Deficit. It is purely informational. The line also states how many yields is required to reduce unhappiness by 1, reported in X per unhappy :c5citizen:. This is also purely informational, and somewhat inaccurate.
    Eg. If we have a population of 10, then our deficit is 3:c5gold:/:c5citizen:*10:c5citizen: = 30:c5gold: (2.5 per unhappy :c5citizen:).
  4. Buildings can reduce the unhappiness produced from a yield/source. The reduction is reported in Reduced by X and the modified result is reported in X from <yield/source>. It may be further reduced in #5. It does not modify the deficit line.
    Eg. If the city has an aqueduct, then poverty is only producing 11:c5unhappy:.
  5. Total unhappiness has a cap of city population. Unhappiness follows a hierarchy, with a source higher on the the list being added before a source lower in the list (including unhappiness from all sources, not just needs). If the sum of all (modified by buildings) unhappiness is greater than the population, then unhappiness sources at the bottom of the list (starting with boredom) are reduced until unhappiness is equal to the population. When boredom is reduced to zero and unhappiness is still higher than population, then illiteracy is reduced, etc. This is the final number in X from <yield/source>.
    Eg. If we have 3 distress, then our 10:c5citizen: city will have 3:c5unhappy: from distress and 7:c5unhappy: from poverty (reduced from 11). All other unhappiness sources have been reduced to zero (assuming zero raw unhappiness sources set between distress and poverty).
  6. Sum all unhappiness entries to get total unhappiness produced by the city.
    Eg. We have 10:c5unhappy:.
Edits: fixing some formatting to try and make it easier to read.

Thank you Rekk, this makes more sense. Just confirming, I thought Urbanization was now at the bottom of the pile, so it would be dropped before boredom would it not?
 
Thank you Rekk, this makes more sense. Just confirming, I thought Urbanization was now at the bottom of the pile, so it would be dropped before boredom would it not?
It doesn't matter where Urbanization falls. If you have maximized unhappiness, you won't have any spare happiness to use on specialists in the first place. Local happiness is capped at population size just like unhappiness. In our 10:c5citizen: example, the best we can do is 10 local :c5happy:, which when compared to whatever combination of sources creating the max 10:c5unhappy:, results in a net of 0, disallowing any specialists other than free ones.

So yes, urbanization is always reduced first, but only because the city stops working specialists.
 
Last edited:
It doesn't matter where Urbanization falls. If you have maximized unhappiness, you won't have any spare happiness to use on specialists in the first place. Local happiness is capped at population size just like unhappiness. In our 10:c5citizen: example, the best we can do is 10 local :c5happy:, which when compared to whatever combination of sources creating the max 10:c5unhappy:, results in a net of 0, disallowing any specialists other than free ones.

So yes, urbanization is always reduced first, but only because the city stops working specialists.

Urbanization is calculated last, not first.

G
 
The underlying system works as follows:
  1. For a given need, a city requires X yields per :c5citizen:. This is determined by the global median plus any modifiers that city has (empire size, tech, etc).
  2. For every 0.25 yields per :c5citizen: that a city does not meet, that need produces 1 unhappiness. There is no cap to the amount of unhappiness this can create.This is reported as Actual.
    Eg. If we only produce 1 :c5gold: per :c5citizen:, and the need is 4:c5gold: per :c5citizen:, then poverty produces 12:c5unhappy:.
  3. Multiply the missing yields per :c5citizen: by :c5citizen: to get the Deficit. It is purely informational. The line also states how many yields is required to reduce unhappiness by 1, reported in X per unhappy :c5citizen:. This is also purely informational, and somewhat inaccurate.
    Eg. If we have a population of 10, then our deficit is 3:c5gold:/:c5citizen:*10:c5citizen: = 30:c5gold: (2.5 per unhappy :c5citizen:).
  4. Buildings can reduce the unhappiness produced from a yield/source. The reduction is reported in Reduced by X and the modified result is reported in X from <yield/source>. It may be further reduced in #5. It does not modify the deficit line.
    Eg. If the city has an aqueduct, then poverty is only producing 11:c5unhappy:.
  5. Total unhappiness has a cap of city population. Unhappiness follows a hierarchy, with a source higher on the the list being added before a source lower in the list (including unhappiness from all sources, not just needs). If the sum of all (modified by buildings) unhappiness is greater than the population, then unhappiness sources at the bottom of the list (starting with boredom) are reduced until unhappiness is equal to the population. When boredom is reduced to zero and unhappiness is still higher than population, then illiteracy is reduced, etc. This is the final number in X from <yield/source>.
    Eg. If we have 3 distress, then our 10:c5citizen: city will have 3:c5unhappy: from distress and 7:c5unhappy: from poverty (reduced from 11). All other unhappiness sources have been reduced to zero (assuming zero raw unhappiness sources set between distress and poverty).
  6. Sum all unhappiness entries to get total unhappiness produced by the city.
    Eg. We have 10:c5unhappy:.
Edits: fixing some formatting to try and make it easier to read.
It's very informative, thank you!

I strongly support @Moi Magnus 's idea to the UI. When I'm playing and facing a challenge, I'm interested in how can I solve it explained as briefly as possible: e.g. I have 3 Unhappiness from Poverty? How can I solve it? *hovering over Unhappiness in City view* Ahha! I need 10 more Gold in this City to eradicate it all! Nice, I'm going to assign some Specialists / build Villages / whatever. I have a clear solution to the problem and I can find it just a "hovering away". Awesome!

I personally think that the shift to the Local Happiness system is one of the best things that ever happened to this mod! :love:
 
Status
Not open for further replies.
Back
Top Bottom