Improved smooth_economy patch

[peter1138]

You have missed the point. If you leave the text out from the translated files, they will *automatically* use the English version. Thus, adding incorrect translations can only be wrong.

[gkirilov]

You don't have to hunt them. Just post a topic with the strings and someone may translate them in thier language.

[SirkoZ]

You have missed the point. If you leave the text out from the translated files, they will *automatically* use the English version. Thus, adding incorrect translations can only be wrong.

Oh - now you're talking my language.
I didn't know a fall-back to english version is implemented - very nice and practical indeed.

Thank you for your notice - I'll remove them immediately - from american too.

[SirkoZ]

Update for consistency with the trunk's changes (to r4781):

[misnomer]

Dragging this back up. My curiosity was piqued when my game didn't seem to be responding much with the mini integrated nightly. I've been looking through the code, and it seems fine, but there's one thing I've noticed.

Since you're using the same random number throughout ('r' being only generated once at the top, and CHANCE16I using this number unmodified as its "out of 65536" percentage), and are doing both the increase and decrease tests/effects in sequence, doesn't this mean that both their chances overlap? Like, if you get a low enough random number, you seem to be guaranteed to trigger both the increase and decrease. (I wrote out a long example explanation but it's a bit pointless. On average, though, the combined increase/decrease would, I think, work out to change new by + 1 - (5/64)*old.)

Anyhow, this doesn't really explain why my games don't seem to respond particularly to high production rates. Regardless - I'm just wondering, amongst other things, if this was the intended functionality? Assuming I've interpreted it correctly, of course. (Most of this is curiosity rather than criticism or anything, by the way. I was interested in refreshing my knowledge of C, and stuff.)

[SirkoZ]

Great questions/inquiry!

The main thing is to have the "influence" integer influence over the chance of increase/decrease. For CHANCE16I function, you can look at macros.h and the CHANCE_A and _B are 2 and 120, so if percent_transported is over 60%, then the chance of increasing is around 3%/month per industry, otherwise it's around 2% and it less than 60% transported, it's around 1%. At the same time, the chance for decrease has values in inverse order (1/2/3%) - the whole thing works like a scale (2 pot). If you press one down, the other goes up.
To summise - if percent_transported is higher than 60%, then increase chance is 3% and decrease chance is at the same time 1%. If it is 60%, both chances are 2% and if less than 60%, decrease is preferred (3%) and increase only 1% chance.
If they cancel each other out? I'd say no, but I'd rather say there's some "bleed-over". I mean - good chance with used industry can sometimes mean increase by a non-used industry.

I hope this is clear enough.

P.S.: With version 2.2, the RandomRange(old >> x) have 1 added, so the whole range of the production rate fraction is taken into account. E.g. RandomRange(256) means a random number out of 0-255, so I now use 256+1 to extend it to 0-256. This means more diverse increases/decreases.
Depending on how large production_rate is, accordingly will follow the changes - from 0-33%. Production_rate * 8 or * 9 gives you the total_production of industry per month.
Additionally - for those, who wouldn't like the production to change a lot, just change the value "configure smooth_economy" from 1 towards 10 - this multiplies the 2 and 120, so the "influence" integer has that much lesser influence on the chances (e.g. at 10: min: 1.583% medium: 1.7% and maximum: 1.75%).

I hope this mini "essay" helps.

[misnomer]

I understand all that, but what I'm saying is that by using the same "r" random value in both CHANCE16I calls (and since CHANCE16I doesn't generate a new random number), you're effectively saying that for a certain threshold, both the increase and decrease effects will definitely apply, at the same time.

It amounts to the chances being linked. So (assuming greater than 60% production and a prod_changes value of 1) there's a 1 in 120 chance that it will both increase and decrease at the same time, a 2 in 120 chance that it will increase only, and a 117 in 120 chance (i.e. the remainder) that nothing will happen. It's the other way round for less than 60% - a 1 in 120 chance of both increasing and decreasing simultaneously, and a 2 in 120 chance of decreasing. By your response it sounds like the 'chances' are supposed to be distinct and not linked like this. (Edit - to clarify, the "2" in "2 in 120" comes from the fact that 1 of the 3 of 120 triggers the opposite as well.)

I had a look through the code it replaces, and I believe that what I'm talking about is the reason for the "r >> 16" expression (rather than just "r", as you have) in this line:

Code: Select all

if (CHANCE16I(20 + (i->pct_transported[j] * 20 >> 8), 1024, r >> 16))

Essentially, the previous code generated a 32 bit random number, used the rightmost 16 bits for the first CHANCE16I, and the leftmost 16 bits for the second - so you got (essentially) two random numbers out of one generation.

I think, anyhow.

[SirkoZ]

Indeed, 2 random numbers, but what good did that do (did you at all test the previous/default patch - the r >> 16 was supposed to increase the chance of increase, but failed miserably)?

I didn't just make this patch because I had nothing better to do. I've written it exclusively to actually drastically increase the quality of the game (as is with all of my patches), which it succeeded to do, based on players' comments.

Both chance_statements get evaluated, one after the other, and based on the influence_integer the higher chance prevails 2 out of 3 times if there is overlapping of the chances.

To be honest - I was asking myself both, if the chance_statements get overlapped and what's the bleed-over, but this scale principle really helps get the right results - the responsiveness, that default patch lacks...

[misnomer]

I'm still not completely sure that I've explained what I'm getting at properly, but it doesn't ultimately matter I guess. Indeed, the way it works now probably produces a stronger effect than if it used 2 random numbers. It's just that:

To summise - if percent_transported is higher than 60%, then increase chance is 3% and decrease chance is at the same time 1%. If it is 60%, both chances are 2% and if less than 60%, decrease is preferred (3%) and increase only 1% chance.

implies, to me, that you've intended the chances of either happening to be separate things (which they would be if you used r >> 16 in the second CHANCE16I), whereas from what I can see in the code it looks like they're linked (not just by the influence variable, but fundamentally - i.e. if a decrease is triggered with over 60% production, it will, by design, definitely also trigger an increase) as I explained above. I'm trying to clarify if this is what you intended?

if there is overlapping of the chances.

This is what I'm saying - there appears to be no 'if' about it. In the case of > 60%, you apparently can only either increase, increase AND decrease simultaneously or do nothing, and vice versa for < 60% (rather than the full gamut of increase, decrease, increase and decrease simultaneously and do nothing).

I'm also trying to establish if I've interpreted that right (and I should really add disclaimers all over these messages asking as much), as it's then difficult to explain why my games don't seem to display the behaviour that everyone else's do, but that might just be down to a weird installation - something I can verify once I get a compiler set up.

Also:

the r >> 16 was supposed to increase the chance of increase

Are you sure about that? Because to me, as I said, it looked simply like a way of generating two random numbers at once. Since CHANCE16I typecasts to a uint16 it cuts off half of the 32 bit random 'r' uint, so it bitshifts 16 to the right to get access to the other half the second time it uses it.

[SirkoZ]

I'm still not completely sure that I've explained what I'm getting at properly, but it doesn't ultimately matter I guess. Indeed, the way it works now probably produces a stronger effect than if it used 2 random numbers. It's just that:

To summise - if percent_transported is higher than 60%, then increase chance is 3% and decrease chance is at the same time 1%. If it is 60%, both chances are 2% and if less than 60%, decrease is preferred (3%) and increase only 1% chance.

implies, to me, that you've intended the chances of either happening to be separate things (which they would be if you used r >> 16 in the second CHANCE16I), whereas from what I can see in the code it looks like they're linked (not just by the influence variable, but fundamentally - i.e. if a decrease is triggered with over 60% production, it will, by design, definitely also trigger an increase) as I explained above. I'm trying to clarify if this is what you intended?

Why all the complicated questions?
I intended a quite simple patch, that is both, responsive to service and configurable and it works as I intended - after quite an amount of testing looks like the chances are not linked.

if there is overlapping of the chances.

This is what I'm saying - there appears to be no 'if' about it. In the case of > 60%, you apparently can only either increase, increase AND decrease simultaneously or do nothing, and vice versa for < 60% (rather than the full gamut of increase, decrease, increase and decrease simultaneously and do nothing).

Not at all. Testing shows chances behave as NOT_linked and increases/decreases occur according to the influence. End of story.
The only valid question is the bleed_over - what amount is affects the non_used industries - I'd say the right amount...

Also:

the r >> 16 was supposed to increase the chance of increase

Are you sure about that? Because to me, as I said, it looked simply like a way of generating two random numbers at once. Since CHANCE16I typecasts to a uint16 it cuts off half of the 32 bit random 'r' uint, so it bitshifts 16 to the right to get access to the other half the second time it uses it.

Where are you getting all these? Stop fantasizing - play the game and enjoy it!
If increases are too seldom, just increase the influence numbers already.
The real question is what is right vs. what will work.

[misnomer]

I'm looking at what the code is saying. From what the code says, you do indeed get "roughly" the right behaviour, but I don't think it's quite the behaviour you intended, is all. From the code, it looks as if 2 of 120 times it'll produce a pure increase, and 1 of 120 times it will (most likely, depending on the values that RandomRange produces) produce a relatively tiny decrease.

Testing won't show exactly what it's doing, as the chances of things happening are so small that it's impossible to judge exactly what's going on. In particular, the difference between what I think is happening and what you probably intend to happen is about 1% (although, the amount of decrease with high production might give it away... maybe not, though), which would be impossible to judge. I'm just working through this logically, and

End of story.

it doesn't sound like you're interested in that, which is a shame.

Where are you getting all these? Stop fantasizing - play the game and enjoy it!

I enjoy coding! And I'm fairly convinced about that r >> 16 thing. I could even draw you a diagram if you'd like.

[SirkoZ]

Well - OK - I'll play along - forget the end of story bit...it's really getting late here...
However I have quite a few r4562M and r4593M mini_IN save-games, all with intended behaviour show through productions and I and many others can't really complain. Again picture it as a scale.

Don't say "produce a tiny decrease" - the amount largely depends on production_rate.

Just understand, that the 1 and 3% things work nicely and the main fault was the RandomRange(old >> x) bit because it didn't take into account all the numbers from that fraction - I changed that with 2.2 to RandomRange((old >> x) + 1).

[misnomer]

Okay. I'll make it explicit.

For > 60% production, prod_changes set to 1:

CHANCE16I always gets called with first (3, 120, r), and second with (1, 120, r). CHANCE16I is defined as

Code: Select all

#define CHANCE16I(a,b,v) ((uint16)(v) <= (uint16)((65536 * a) / b))

So, if r = 546 (after being typecast to 16 bits - the leftmost bits could contain anything and it wouldn't matter, so long as the rightmost 16 bits equalled 546 (0000001000100010 in binary) for this example), the first call simplifies to (546 <= 1638) which is TRUE. The second call simplifies to (546 <= 546) which is also TRUE. (You can see why I picked this number, now.) So if r <= 546, it will trigger both. Hopefully you can see, now, that triggering the second alone (in this case) is impossible - it will always have triggered the first, too. This doesn't mean that you'll get two events (an increase followed by a decrease, for example) - just that the overall change will be the net of an increase and a decrease, most likely resulting in a small decrease (but it could produce either given the RandomRange functions).

If it's less than 60% production it's just the other way round, with the first call being (1, 120, r) and the second (3, 120, r) - any r <= 546 will trigger the increase and the decrease. In both these cases, if r is between 546 and 1638 it'll trigger the increase (in the case of > 60%) or the decrease (< 60%) only, and above 1638 it won't do anything.

So you're not really getting a 3% chance of increase and a 1% chance of decrease, both of which could happen at any time - it's more like a 2% chance of increase and a 1% (non-overlapping) chance of some randomised change that could either be an increase or a decrease. I'm fairly sure that if you used r >> 16 on the second call to CHANCE16I it would produce two disconnected possibilities as intended - first a chance to increase, then a chance to decrease, both acting separately.

[misnomer]

By the way, I'm sorry to be a pain - this is just what first caught my eye as I began looking into the code.

Edit - and I'm not saying you should necessarily change your code, as it's probably more consistently responsive as it is already, it's just I don't think it's working quite as it seems to have been intended. ('Intended' in terms of the code, not the outcome! As it does roughly the same thing, just in a different way.)

[SirkoZ]

No no it's ok - things have to be clear - interesting indeed - I never really cared too much about that r...

Anyhow - taking the possible overlapping into account - if we have the r32(right part) and r32(left part - after r>>16) - there is 50/50 percent chance one or the other will be appropriate i.e. less than equal to the result of ax2^16/b, right?
Example:
r32=98000000 - for the first part comes 23680 and for the second 1495
r32=17000 - first: 17000 and second one is 0...
Somewhat unbalanced, wouldn't you say?

I think it would be more aprropriate to use 16-bit r and the same for both parts...however I'll try the r>>16 method with v2.1 and 2.2 today...

[SirkoZ]

You know what? After the testing of both r >> 16 (with uint32 r) and r (with uint16), I'm sticking with your suggested change - it works more as I intended with the new+=/-= "fractions".

Thank you very much for your persistent inquiries.

/updating to 2.3...

[SirkoZ]

Here is the latest - 2.5 - improved increases/decreases (bigger production, smaller increase, larger decrease). For source r5095. Starting chance now 2 in 100 instead of 2 in 120.

[SirkoZ]

Here's the distribution of industries after a non-used (0 services built) run of a 256x512 tropic map from 1950-2054 with r4810 OTTD patched with 2.4 of sz_improved_smooth_economy, responsiveness set to highest (1):
Number of producing industries: 76.
From those:
_1 or _1.3% at ~300 units per month,
_1 or _1.3% at ~250 units per month,
_5 or _6.6% at ~200 units per month,
10 or 13.2% at ~150 units per month,
31 or 40.8% at ~100 units per month,
_5 or _6.6% at ~_75 units per month,
17 or 22.4% at ~_50 units per month,
_6 or _7.9% at ~_25 units per month.

Increases will occur with service even if one produced 8 or 9 units/month, so no worries there.

And also results for least responsive (to service) setting - 10.
The decreases (because of <60% transported) don't express themselves so much) somewhat same result would come out of the default patch...
Here are they - again - same size map, tropic, 1950-2054 - no service built - # of producing industries = 68:
_1 or _1.5% at ~1000 units per month,
_2 or _2.9% at ~_700 units per month,
_1 or _1.5% at ~_600 units per month,
_7 or 10.3% at ~_500 units per month,
_7 or 10.3% at ~_400 units per month,
_7 or 10.3% at ~_350 units per month,
_4 or _5.9% at ~_300 units per month,
11 or 16.2% at ~_250 units per month,
_9 or 13.2% at ~_200 units per month,
10 or 14.7% at ~_150 units per month,
_8 or 11.8% at ~_100 units per month,
_1 or _1.5% at ~__75 units per month.

[SirkoZ]

Again new version - responsive setting has been amplified, default is now 5...
Test - 1 coal mine 160/180, map 256x512, 4 13-waggon Lev3 'Pegasus' trains - to keep station ratings (with company statue) at 93%, time - August 1954 - January 2000.
1.) Setting 1 - least responsive - production in 2000: 248/279,
2.) Setting 5 - default setting - prod. in 2000: 520/585,
3.) Setting 10 - most responsive - prod. in 2000: 1312/1476.

Now also for mini-IN branch (r5147).

[SirkoZ]

A bit of change - increase percentige is also somewhat affected by the percent_transported...
In r5478 NS has been used in the settings.c instead of 0 under SDT_VAR for better savegame compatibility... Comments are welcome...