[1.4] Issues with EconomicStimulus / CulturalFestival

Firstly, the tooltips for the two are wrong - they still indicate just a +5% bonus.  Given the now variable nature of the stimulus/festival, either correct this with the formulae used, or simply eliminate it.

 

Secondly, the values seem *VERY* step-function. I'd have to look at the code, but it *roughly* appears that the formula is something like "SOCIAL production / 10" dropping all fractions, times 5%. AKA:  (SocProd DIV 10) * 0.05

Social production:  

0-9:   NO benefit from the festival/stimulus

10-19:  +5%

20-29: +10%

30-39: +15%

 

That's terrible.  It should be a much smoother gradient. (Social Production DIV 2) * 0.01 as a bonus , is a far, far, far better idea.

 

 

8,263 views 7 replies
Reply #1 Top


Social production:

...
End of quote

That's interesting. In v1.3.x and earlier, projects round up, and I don't see any changes to the projects aside from increasing the bonus from 5% per 10 manufacturing to 10% per 10 manufacturing listed in the changelog.


Secondly, the values seem *VERY* step-function.
End of quote

The projects have always more or less been step functions; the model, at least in 1.3.x and earlier, was ceiling(socialManufacturing / 10)*projectBonus. From what you're saying, it's now floor(socialManufacturing / 10)*projectBonus, which makes economic stimulus and research projects into even more of a trap than they already are.


Given the now variable nature of the stimulus/festival,
End of quote

The projects having a variable bonus is nothing new. It was like that in 1.3.x, 1.2.x. 1.1.x, 1.0.x, and as far back into the betas as the +X% output per 10 manufacturing project model existed, and even further back into the beta and alpha with the +0.25 output per manufacturing projects.

Reply #2 Top


That's terrible. It should be a much smoother gradient. (Social Production DIV 2) * 0.01 as a bonus , is a far, far, far better idea.
End of quote

TBH i am ok with as is but i do like your idea better.  Totally agree with the need to fix the tool tips. You would think it would be a QA check, function change-Yes > tool tip updated?

Reply #3 Top

OK, after further experimentation, I was partially wrong.

 

The function for them now appears to be:

SP=social production

 

If SP > 0

0.05 * (1 + FLOOR((SP -10)/10))

 

That is:

0.1-9.9:  +5%

10 - 19.9: +10%

20-29.9: +15%

etc.

 

 

I still vote that it should be the simple:  CEIL(SP) * 0.01   or perhaps 0.05 + CEIL(SP/2) * 0.01

Reply #4 Top

Quoting trims2u, reply 3

That is:

0.1-9.9: +5%

10 - 19.9: +10%

20-29.9: +15%
End of trims2u's quote

These points do not match the function provided. 1 + FLOOR((SP - 10) / 10) =

1 when 0 <= SP < 20

x, 10x <= SP < 10x + 10 where x is an integer greater than 1

You can see this with a quick test with SP on (10, 20); for example, with SP = 15: 15 - 10 = 5, 5 / 10 = 0.5, floor(0.5) = 0, 1 + 0 = 1 => bonus at SP = 15 is 5%. The intervals provided are consistent with 1 + FLOOR(SP / 10). If the intervals are closed above and open below (as I recall them being the last time I checked, though I haven't updated to 1.4 and my memory could be faulty) rather than closed below and open above as your intervals are, then it'd be consistent with CEIL(SP / 10). But for being open above and closed below, the intervals and associated bonuses provided could also be consistent with 1 + CEIL((SP - 10) / 10), though since that's the same as CEIL(SP / 10) it'd be a bit of an odd choice.

Reply #5 Top

I'll recheck a formula.

But the observed values are as I (restated):  the bonus increments when you hit a multiple of 10.


Preferentially, I use DIV (integer division), so it appears to look like:

 

(1+ (SP DIV 10)) * 5%  when SP > 0

 

They should still change it to be a smoother gradient than the pretty harsh step function it is now.

 

Reply #6 Top

They've always been step functions, as Joe notes. It's a bit weird that they are tbh, since the XML structure allows it to be set to a step of 1 manu with no issues. 

 

To change it, go to game/planetaryprojectdefs.xml, change every instance of <ManufacturingPerBonus> to 1, and then divide every <Value> entry by 10. This will make the bonus map directly to social production.

Reply #7 Top

Quoting naselus, reply 6

since the XML structure allows it to be set to a step of 1 manu with no issues.
End of naselus's quote

The XML actually permits the divisor to be set to any number with no more than three digits following the decimal point which is less than or equal to (2^31 - 1)/1000. There are no issues during gameplay that I am aware of from setting the divisor to 0.001 manufacturing per bonus increment (assuming you've adjusted the bonus increment to account for the fact that you've multiplied the manufacturing output by 1000, anyways; an interesting side-note is that it appears that the game knows the manufacturing output down to at least the thousandths place).

I suspect that the variables in the project XML files are handled by the game as signed 32-bit integers, with the game treating the integer as the number of thousandths in the number that you wish to represent.

Quoting naselus, reply 6

To change it, go to game/planetaryprojectdefs.xml, change every instance of to 1, and then divide every entry by 10. This will make the bonus map directly to social production.
End of naselus's quote

It won't quite make the bonus map directly to the social production; some rounding is performed after dividing the social manufacturing by the divisor set in the project file and before multiplying by the bonus. It does make the steps in the staircase function much smaller and so produces a smoother function.