Most improvement flags where it makes sense work cumulatively. However, there are still exceptions such as
+1 Ship Movement and
+2 Ship Movement. A special case is the
Treasury earns 5% given to "Wall Street", but is limited to a
maximum earning of
50 gold. In practice, this means that if you have one "Wall Street", you only need to keep
1000 gold in your treasury to maximize this effect. If you had two "Wall Streets",
5% becomes
10% and you only need to keep
500 gold in your treasury to maximize this effect. My point is that I find the
50 gold maximum earnings limitation to be
OVERLY STRICT. As it stands, using this flag for multiple improvements is practically pointless and I'd like to change that. Therefore, I would suggest three things:
1) The option to
set your own maximum earnings. (Possibility of removing it entirely via the -1 value, the default being 50.)
2) The option to
set your own interest percentage. (The default being 5%.)
3) The option to
increase this limit for each additional "Wall Street" built. (Which means that if the default value for 1 "Wall Street" is 50, for 2 is 100, for 3 is 150, etc.)
Points
1) and
2) shouldn't be too difficult in my opinion, since it should be a rewrite of one number in one place in the code.
I consider point
3) to be more challenging, so if it turns out to be something considerably more complicated, I would be perfectly happy with implementing points
1) and
2).
This further I assume is more something that would be done or expanded in the future using LUA, but I could be wrong. The "Wall Street" principle is simply
the MORE money you have, the MORE you make. That's why I thought of expanding the economic complexity to include the following:
a) Add a bit of code to implement a possible
INVERSE principle of
the MORE money you have, the LESS you make. Which I also think shouldn't be a big deal, just tweak the equation for calculating earnings a bit, with it reaching maximum efficiency with a treasury at 0 gold and zero efficiency with a treasury over 1000 gold under current conditions of 5% interest and maximum earnings at 50 gold.
b) Add a bit of code to implement the principle of
VARIABILITY/INSTABILITY of earnings depending on the
SINE function. The adjustable value of the maximum earnings would actually mean the maximum amplitude of the function. Next, we would need to specify the second parameter and that is the period of the function. So under current conditions, the
amplitude is 50 gold with the
period set to 10000 gold:
- the treasury would earn 0 gold on 0 gold,
- the treasury would earn +50 gold on 2500 gold,
- the treasury would earn 0 gold on 5000 gold,
- the treasury would earn -50 gold on 7500 gold,
- the treasury would earn 0 gold on 10000 gold,
- the treasury would earn +50 gold on 12500 gold,
- the treasury would earn 0 gold on 15000 gold,
- the treasury would earn -50 gold on 17500 gold,
- the treasury would earn 0 gold on 20000 gold, etc.
c) Same as for
b), but for
COSINE. So under current conditions, the
amplitude is 50 gold with the
period set to 10000 gold:
- the treasury would earn +50 gold on 0 gold,
- the treasury would earn 0 gold on 2500 gold,
- the treasury would earn -50 gold on 5000 gold,
- the treasury would earn 0 gold on 7500 gold,
- the treasury would earn +50 gold on 10000 gold,
- the treasury would earn 0 gold on 12500 gold,
- the treasury would earn -50 gold on 15000 gold,
- the treasury would earn 0 gold on 17500 gold,
- the treasury would earn +50 gold on 20000 gold, etc.
d) If something like Sine/Cosine is too complicated, a function alternating linear increase and linear decrease would suffice for case
b)/c).
Just for the record, all of the cases mentioned (growth,
a) regression,
b) sine,
c) cosine,
d) linear inc & dec) would still be triggered by the "
Treasury earns 5%" flag, and only in the config file would you be told which "
economic model" to use for which improvement instead of the standard growth.
This wouldn't be easy but it wouldn't be all that difficult either. The original logic for the doubling happiness effect isn't practical to modify. However it's inside of a relatively small function that could be entirely rewritten. That function's purpose is to sum the happiness from all buildings in a given city and it does that in a very straight forward manner.
If you're still actively keeping your list with suggestions, I hope you'll add it.
I think the hard part here would be knowing when to recompute city economies because a building may have been added or lost due to some weird rule. For example, if you want a wonder that adds an building to only enemy cities, it would be simple to modify the has_improvement function to check for that but you'd also have to make sure to recompute city happiness whenever wars started or ended to make sure the building appears when it's supposed to.
Isn't this something that's actually already partially happening? When war breaks out, it is common to lose active trades such as resources of luxury for money, which will inherently affect happiness in cities. In fact, the very act of war at the beginning will affect the happiness in cities and you don't even need to have an active trade to lose. I mean, I'm assuming that the game is already doing some checks the moment the diplomatic status between civilizations changes. Likewise, checks are made due to the change of ownership, becoming obsolete, or destruction of the city in which the wonder is located or to which the free improvement is given. So recalculations of the city economy also happen during such situations. I'm not quite sure what kind of WEIRD RULES you're referring to? For example, if barbarians took over a city, they are perhaps at war with everyone all the time. Or is the problem whether things happen when you're ON or OFF your turn?
Other than that, modifying has_improvement to consider additional conditions is no more difficult than programming those conditions anywhere else. E.g., if you want buildings to appear based on the surrounding terrain, the traits of the civ that owns the city, the distance to some other city, etc., that would all be pretty easy.
If it's that pretty easy, I'm surprised it hasn't been implemented yet. This is definitely not the first time I've heard of being dependent on the surrounding terrain or traits. Conditions with distance would be interesting again in relation to Allied/Hostile/Own cities.
I'm not sure what's going on here. The function to sum happiness from buildings doesn't directly limit unhappiness to that content citizen number, so it doesn't look like the developers programmed that specific rule you describe. I can see that the content citizens from difficulty does contribute to the happiness computation one level higher but I'd have to study the recompute_happiness method to figure out exactly what it's doing because it's surprisingly complicated.
I was wondering if maybe this could be a similar problem to calculating the overall culture in a city, where the order of improvements matters, and therefore improvements giving negative culture should be after improvements giving positive culture, so that everything is counted correctly, since the growth of culture in a city cannot be negative. (By the way, could something be done about the possibility of a declining culture?)
However, this is probably not the case. I tried adding unhappiness for a few basic improvements and the order in which either the happy or unhappy improvements were built didn't play a role and the results were correct, except of course those that fell below the
number of citizens born content. It was also interesting to note that as the number of unhappy improvements increased, the explanatory notes "
Some improvements in this city are annoying" and "
Some improvements in another city are annoying" in "
Unhappiness Causes" kept increasing, so this part of the code obviously records something well, it's just not interpreted correctly on the citizens of the city.
I think there's no doubt that something isn't working quite right here probably because it hasn't been properly tested. If I had to guess, I'd say it would have to do with some constraint on natural numbers, since city size can't be non-positive. I think it's definitely something worth revisiting at some point if not now. But I don't really know how many other people have experience with this problem and how much demand there is to solve it? (Hello, anyone?)
