General Happiness Issues

If that's the case then unhappiness per need in every city could be stored as multiplied by 100 and total unhappiness in a city would be a sum of all unhappiness per need divided by 100.
So instead of:
Code:
5 * [ round(1/5)] = 5
it would be:
Code:
5 * [ round(1/5 * 100)] / 100 = 5 * 20 / 100 = 1

That change wouldn't affect happiness calculations outside a city, only inside.
@Gazebo is it feasible?

Problems:

Positive happiness is still managed city by city, as whole integers. And the other sources of unhappiness in a city are also handled as managed integers.

The UI would no longer be whole to give you a discrete breakdown of unhappy pops in a city if we were shunting all integer checks to the empire level.

G
 
Rude? Yeah, sometimes I forget me a bit, but in this case I feel totally fooled by him. The best way to make me quiet is to simply answer with arguments, instead one word answers or zynical words.

I can now definitely confirm, at least in the last version, rounding errors of the median are not the source of the jumps.
You can check it by yourself, compare the values in the turn of the save and the turn after (second save of page 7 10-10 thread). Between the turns I discovered a technology.
The medians are changing as followed:
Distress 4,78 - > 4.806 +0,5%
Poverty 4,43 - > 4,44 +0,22%
Illiteracy 3,706 - > 3,709 +0,08%
Boredom 4,047 - > 4,039 - 0,2%

Most interesting is boredom.... The median decreased, but unhappiness by boredom increased by 5 in my empire. And why? Cause in every of my city, for every category, the need modifier increased by 20%.
I don't have the picture here, but the modifier increased from around +100% to +120%. So distress need increased from 9,56 to 10,573 for every pop. A change of 1.013. Remember, the pure median changed by 0,026.
Modified with +100%, this is 0,052. To summarize, the pure increase of the median only makes 5% of the increase. The rest is all the modifier, which hit me.

There is no rounding error....

Violating my own vow of silence (look what you’ve done to my faith) to state that no kind of response works for you unless it is 100% agreement. I’ve tried facts, figures, jokes, sarcasm, sonnets, poems, limericks, physical comedy...and your constant comeback is ‘why won’t you just answer my question?’ Which I do. And then you accuse me of knowingly lying. If I weren’t a civilized, sophisticated man of letters I’d tell you to take a long walk with a tall stick, but in this case I think it’s better if you just yap into the void and/or at other people.

Bite....G has been extremely clear that he will not accept arguments from previous versions. I know you don't agree with that (I also don't agree with it), but he is the man making the mod, he gets to do things his way. Providing information from the previous mod is a waste of our time at this point, because G will not consider it valid and will not make any changes based on it. If you want to actually see changes happen, we have to make arguments with the latest version....its as simple as that.

For the record, it isn’t a philosophical opinion of mine, it is a logistical one. If I started debugging prior versions I’d spend all my time building old github repos to reproduce things.

I don’t know many dev teams, even big dev teams, that debug old versions of a product.

G
 
Violating my own vow of silence (look what you’ve done to my faith) to state that no kind of response works for you unless it is 100% agreement. I’ve tried facts, figures, jokes, sarcasm, sonnets, poems, limericks, physical comedy...and your constant comeback is ‘why won’t you just answer my question?’ Which I do. And then you accuse me of knowingly lying. If I weren’t a civilized, sophisticated man of letters I’d tell you to take a long walk with a tall stick, but in this case I think it’s better if you just yap into the void and/or at other people.



For the record, it isn’t a philosophical opinion of mine, it is a logistical one. If I started debugging prior versions I’d spend all my time building old github repos to reproduce things.

I don’t know many dev teams, even big dev teams, that debug old versions of a product.

G
It's nice of you to speak to me again, but you are only preaching, not arguing. If theres a mistake in my logic or data, show me the spot. And I am quiet.
The point is. Can you explain, why my need modifiers decreased by 50%, after Polynesia get conquered, even the tech median changed only by one? Saying you have fixed something you can't explain in the first place, is not really trustworthy.
 
It's nice of you to speak to me again, but you are only preaching, not arguing. If theres a mistake in my logic or data, show me the spot. And I am quiet.
The point is. Can you explain, why my need modifiers decreased by 50%, after Polynesia get conquered, even the tech median changed only by one? Saying you have fixed something you can't explain in the first place, is not really trustworthy.

Hey look, you did exactly what I said you’d do!

Now you can do what I said you can do.

G
 
As pineappledan also mentioned, the underlying mechanic is the same. No new wheel. Huge modifiers appearing and disappearing mysteriously everytime something with tech happens, while the median stays the same. And the creator of the mod can't explain why?
 
Positive happiness is still managed city by city, as whole integers. And the other sources of unhappiness in a city are also handled as managed integers.
What is a "managed integer"?
The UI would no longer be whole to give you a discrete breakdown of unhappy pops in a city if we were shunting all integer checks to the empire level.
I didn't mean empire level calculations, but per city. 5 in my example is 5 different needs in a city, not 1 need in 5 different cities. I should had made it more clear.
 
What is a "managed integer"?

I didn't mean empire level calculations, but per city. 5 in my example is 5 different needs in a city, not 1 need in 5 different cities. I should had made it more clear.

I’m still not exactly sure what you’re asking for. If you’re just calculating happiness as hundreds in a city there’s no appreciable difference between 500/100 and 5 unhappiness from boredom. The function would only have an appreciable value if you carried the hundreds place over to the empire level, which (in the city UI) would result in 1.41 unhappiness from boredom, which I think would just start to clutter the UK.

Managed integer = validated object (c++ thang)

G
 
I don’t know many dev teams, even big dev teams, that debug old versions of a product.

G

Firaxis. That's why we see old, solved bugs resurfacing 2 or 3 patches later, such as the infamous "Alert button" bug... :lol::lol::lol:
 
would result in 1.41 unhappiness from boredom, which I think would just start to clutter the UK.
G

:lol::lol::lol::lol::lol:... do you know for a fact that the UK is sooo boring?

(yeah, I know, I'm being silly, but nothing better than silliness to defuse density)
 
I’m still not exactly sure what you’re asking for. If you’re just calculating happiness as hundreds in a city there’s no appreciable difference between 500/100 and 5 unhappiness from boredom. The function would only have an appreciable value if you carried the hundreds place over to the empire level, which (in the city UI) would result in 1.41 unhappiness from boredom, which I think would just start to clutter the UK.

Managed integer = validated object (c++ thang)

G
I think he want to say, we should change the point, where the rounding happens. Instead of 5 calculated values which get rounded and then added, we calculate the 5 different values, add them at city level and then round it.
 
I’m still not exactly sure what you’re asking for. If you’re just calculating happiness as hundreds in a city there’s no appreciable difference between 500/100 and 5 unhappiness from boredom. The function would only have an appreciable value if you carried the hundreds place over to the empire level, which (in the city UI) would result in 1.41 unhappiness from boredom, which I think would just start to clutter the UK.
Maybe BiteInTheMark expressed it better:
I think he want to say, we should change the point, where the rounding happens. Instead of 5 calculated values which get rounded and then added, we calculate the 5 different values, add them at city level and then round it.

When in a city there is 1/5 unhappiness from boredom, illiteracy, poverty, distress and religious tension, in current calculation it will result in 5 unhappiness in the city:
Code:
 [ round(1/5)] + [ round(1/5)] + [ round(1/5)] + [ round(1/5)] + [ round(1/5)] = [1] + [1] + [1] + [1] + [1] = 5
where each square bracket represents unhappiness from one of the needs in this city (boredom, illiteracy, poverty, distress and religious tension)
In calculation that I propose it will be 1:
Code:
 ( [ round(1/5 * 100)] + [ round(1/5 * 100)] + [ round(1/5 * 100)] + [ round(1/5 * 100)] + [ round(1/5 * 100)] ) / 100 = ( [20] + [20] + [20] + [20] + [20]) / 100 = 100 / 100 = 1
It's all calculation at city level, not empire level.
 
The resonance to this thread isnt that, what I expected, but its nice to see which new nice ideas are appearing. :lol:
We should reall think about the integration of the weighted tech median and the city wise rounded happiness.
 
Maybe BiteInTheMark expressed it better:


When in a city there is 1/5 unhappiness from boredom, illiteracy, poverty, distress and religious tension, in current calculation it will result in 5 unhappiness in the city:
Code:
 [ round(1/5)] + [ round(1/5)] + [ round(1/5)] + [ round(1/5)] + [ round(1/5)] = [1] + [1] + [1] + [1] + [1] = 5
where each square bracket represents unhappiness from one of the needs in this city (boredom, illiteracy, poverty, distress and religious tension)
In calculation that I propose it will be 1:
Code:
 ( [ round(1/5 * 100)] + [ round(1/5 * 100)] + [ round(1/5 * 100)] + [ round(1/5 * 100)] + [ round(1/5 * 100)] ) / 100 = ( [20] + [20] + [20] + [20] + [20]) / 100 = 100 / 100 = 1
It's all calculation at city level, not empire level.

You’d end up with another layer of obfuscation. It’d be really hard to relate this to the player via UI. I don’t think it is viable.

G
 
You’d end up with another layer of obfuscation. It’d be really hard to relate this to the player via UI. I don’t think it is viable.

G
In UI you can just put a dot before second digit from right. So 100 => 1.00, 25 => 0.25
What does make it more obfuscate? The fact that it would be a rational number instead of integer?
 
In UI you can just put a dot before second digit from right. So 100 => 1.00, 25 => 0.25
What does make it more obfuscate? The fact that it would be a rational number instead of integer?

Because what is that 1.00? 'Needs?' Okay, how does the player know what to do with that information? 1 Unhappiness (20% of this is boredom): okay, but haven't we just dramatically reduced unhappiness potency in the city? And for what?

The math of this makes sense, but it does add a layer of obfuscation for the player (beyond the 100=>1.00 issue). You're looking at a total rework of the system in order to...do what, exactly?

I'll reiterate that people seem very keen to offer ideas but I'm seeing very little real data from 10-10. Go play.

G
 
The problem is people are throwing solution after solution when no one has demonstrated the problem in this version of the mod.
The addition of a weighted tech median doesnt need any problem to be an elegant solution.
You’d end up with another layer of obfuscation. It’d be really hard to relate this to the player via UI. I don’t think it is viable.
I dont think its a obufscation. The UI stays the same as it is now. If you hover over the happiness entry, every category shows how much unhappiness is generated and the needs. The difference is now instead of 2 happiness of boredom/distress/..., it shows something ike 2.34 happiness of boredom/distress/...
The Total unhappiness line stays also the same, it shows all unhappiness added together, not rounded.
The positive happiness stay as it is, cause its always integer.
The rounding only happens for the big number in the city screen, which count for the empire. For this case, its up to you, if you always round up, down or dependend on +/- 0,5 .
 
The addition of a weighted tech median doesnt need any problem to be an elegant solution

Solutions require problems, else they are not solutions...they are changes for changes sake. At this point in the project, we should not make changes "just because", but to solve outstanding issues.

G has shown a willingness to adjust aspects of the happiness system, but has asked that we showcase our concerns with real games from the latest patch. Every line of text made in this thread that doesn't do that is a complete waste of time. Sigh, probably including this text.
 
Solutions require problems, else they are not solutions...they are changes for changes sake. At this point in the project, we should not make changes "just because", but to solve outstanding issues.

G has shown a willingness to adjust aspects of the happiness system, but has asked that we showcase our concerns with real games from the latest patch. Every line of text made in this thread that doesn't do that is a complete waste of time. Sigh, probably including this text.
My question is, do you still believe its a rounding error of the global medians, which stayed the same, if the most increase of needs comes from a modifier?
Do you think its a rounding error, if my need modifier decrease by 50% after the conquest of polynesia. Which has nothing to do with medians?
I dont think we can solve problems, if we didnt identify, why those problems happened.
In this case I have relative low trust, the new version fixed the happiness jump problems.
 
Last edited:
I'll reiterate that people seem very keen to offer ideas but I'm seeing very little real data from 10-10. Go play.
I didn't have major happiness problems in previous versions and I expect that it would be even easier in this version. I proposed these calculation just because it makes more sense to me. I didn't realize that it's total rework of the system.
 
Top Bottom