I didn't see this information anywhere else, so I'm starting a new thread for it.

The amount of hammers you earn from chopping a forest decrease the further the forest square is from your city. Cultural borders have no effect, its based on the city square. The following grid shows the number of hammers for each forest square positioned around your capitol. 8 squares out is the maximum distance you can still get hammers from a forest chop.

Production modifiers apply to forest chop values. For instance a city with a Heroic Epic will earn twice as many hammers from a forest chop when building a unit then otherwise. Leader trait bonuses modify the values as well. Whether you are playing epic, normal, or quick affects the values, and charts for each speed are posted below.

Base terrain does not change the forest value. Thus forest on a grassland, hill, plain, etc all gives the same number of hammers depending on distance.

savedfgsfgsdfg

Epic Length Chart

Thanks, much appreciated. It's mind boggling that someone didn't get this out sooner.

This is pretty easy to convert to a formula:

production bonus = FLOOR((speed factor) * (distance factor))

speed factor = 2/3 quick, 1 normal, 3/2 epic

distance factor = 30 - 5 * MAX(FLOOR(distance-3), 0)

Where distance is defined in the usual Firaxis sense, MAX(x,y)+1/2*MIN(x,y) or 3/4*(x+y)+1/4*ABS(x-y).

By the way, forest chop values also seem to be affected by the same (somewhat bogus) "current build overflow adjustments" as other production is.

It appears that the best squares to chop are 3 tiles from your city if your trying to keep trees in the radius for healthiness. You get the full chop value for the trees with no additional unhealthiness. It is also important that you get the most bang for your buck when chopping. That is, chop wonders when industrious, units if city has heroic epic. etc.

It is also important that you get the most bang for your buck when chopping. That is, chop wonders when industrious, units if city has heroic epic. etc.

No, it doesn't matter, because you get the same bonuses for your regular production and the chop production.

E.g., suppose you're building a wonder that costs 250 hammers, and you have a 50% industrious bonus and 100% resource bonus. Then you build a building that costs 80 hammers, with no bonus. If you chop 2 forests for the wonder, you get 2*30*2.5 = 150 toward the wonder, so you need to use 40 hammers (times 2.5 multiplier) to finish the wonder, and then 80 hammers to build the building, for 120 total. Alternatively, if you chop the 2 forests for the building, then you get 60 credit and need to put in another 20, and the wonder costs you 100 (times 2.5 multiplier), which is the same 120 total. So you get the same result whether you chop for one or the other.

Edit: This bug was fixed in patch 1.52!

Production bonuses can be abused to increase the value of forests. If you have 1 shield left on your +150% wonder and chop 4 forests, that's a 299 shield overrun that you can apply to any item you want.

Forests can be abused to extend the production bonus. If you have 1 shield left on your +150% wonder and chop 4 forests, that's a 299 shield overrun that you can apply to any item you want.

This isn't true, because there's an overflow correction that applies to the yield from chopping, just as to production in general. Look at the hammers you get from chopping when you have a bonus and have enough to complete the project, and you'll see that it's less than the formulas above.

It can be abused, but not to the extent that you state. And "overflow correction" can also work against you, most notably when the next project is something on which you would also have had a bonus.

Ok you're right - there's a 50% "overflow correction tax".

So in my example you have a 239-shield overrun for chopping 4*30 forest shields.

Ok you're right - there's a 50% "overflow correction tax".

I haven't checked it myself, but that could be right.

It's disappointing that they made such a botch of "overflow correction". It seems that they really tried to do the right thing, but just didn't ask the right people how to do it. It would have been no more work to just do it right.

The really frustrating situation is the reverse: when you have an overflow to a project with a large bonus, and you effectively lose most of the credit you should get.

In relation to overflow:
It's maximum seems to me to be limited to the amount the current item is worth. I.e. producing a warrior for 15 shields and chopping for 45 will result in a maximum overflow of 15.

In relation to the forest chopping grid:
The main point of this graph (i.m.o.) is that you can chop pretty effective outside of your fat cross and still get very decent returns. I am already in the habit of chopping the 45 and 37 tiles outside of my fat cross first (assuming it's safe, which is in the HOF: Always ;))

Regarding overflow, I explained everything here (http://forums.civfanatics.com/showthread.php?t=141153).
(btw including chopping details; although without nice graphics. I thought it would be clear without)

Grids are much prettier than formulas. :D

Regarding overflow, I explained everything here (http://forums.civfanatics.com/showthread.php?t=141153).
(btw including chopping details; although without nice graphics. I thought it would be clear without)

Well, I'm not sure what to believe, not having checked any of this myself.

E.g., suppose I already have enough production on a wonder to finish it. I have +150% for that wonder from resource and industrious trait (i.e., s=1.5) and no general production bonus (i.e., g=0). I chop another forest that would normally send 30 hammers to that city. As I understand your formulas:

BP = 30 for the chop
NP = 0
P = 30*2.5 = 75
TO = 75
C = min(75*1.5/2.5, 30*1.5^2/2.5) = min(45, 27) = 27
O = 75-27 = 48.

On the other hand, DaveMcW (if I understand his post #10 correctly) claims to observe O=60 in this case.

I could set up a test myself. It does seem pretty clear that you can get more carryover than you should. It also seems that timing chops for the last turn when you're finishing a project with a high bonus, is going to be sometimes worthwhile.

It's certainly frustrating that they evidently went to some lengths to handle carryover in order to reduce micromanagement, but, they didn't ask the right people how to do it correctly.

C = min(75*1.5/2.5, 30*1.5^2/2.5) = min(45, 27) = 27
O = 75-27 = 48.
On the other hand, DaveMcW (if I understand his post #10 correctly) claims to observe O=60 in this case.
Admittedly I didn't test the special case of chopping overflow in detail, but I think that the base production in the formula should be the city's BP, not the 30 chop BP. So when maximizing overflow, it also depends on the city and tiles worked.
It's certainly frustrating that they evidently went to some lengths to handle carryover in order to reduce micromanagement, but, they didn't ask the right people how to do it correctly.
I don't see what "right people" they needed to "ask". It's pretty obvious how it should work: simply in the one and only fair way, which means that exactly the shields needed for a special bonus project get the bonus multipliers, and that no shields are lost. Everyone agrees about that.
The only issue where community opinions vary is whether to grant overflow production any special bonus multiplier of the next project.
And as I pointed out, Firaxis probably wanted to do it the right way, but unfortunately made a slight mistake in the formula and failed to fix it up to now.

And as I pointed out, Firaxis probably wanted to do it the right way, but unfortunately made a slight mistake in the formula and failed to fix it up to now.

Well the 'right people' in this case would be someone with
1) basic mathematical knowledge
2) knowledge of how the bonuses worked
3) knowledge of what they wanted the overflow to do
4) an ability to catch bugs in the code

The fact is Firaxis failed miserably on having the people in their organization that had all those skills/traits talking to each other well enough. Meaning that the overflow situation is either a programming bug (correct formula was known but not put in properly) or a design formula bug (correct effect was known but an improper formula was used).

Admittedly I didn't test the special case of chopping overflow in detail, but I think that the base production in the formula should be the city's BP, not the 30 chop BP. So when maximizing overflow, it also depends on the city and tiles worked.

I don't really understand this statement. When you chop a forest that generates more shields than the current project requires, the "overflow correction" is generated immediately as you chop. E.g., you chop a forest that would normally yield 75 hammers to a wonder with +150%, but it actually gives a smaller number.

It wouldn't make any sense at all to me if the amount of "overflow correction" applied to the forest chop depends on the base production of the city. This would mean, among other things, that going into the city, turning all of its citizens into specialists, completing the chop, and then changing them back, would allow you to affect the result that you get. That certainly wouldn't be good, and I hope it's not the case.

If you haven't tested it at all, then someone will have to do some tests to figure out how it does work.

I don't see what "right people" they needed to "ask". It's pretty obvious how it should work: simply in the one and only fair way, which means that exactly the shields needed for a special bonus project get the bonus multipliers, and that no shields are lost. Everyone agrees about that.
The only issue where community opinions vary is whether to grant overflow production any special bonus multiplier of the next project.
And as I pointed out, Firaxis probably wanted to do it the right way, but unfortunately made a slight mistake in the formula and failed to fix it up to now.

If it were so obvious how it should work, then they would have gotten it right. But there are many things that are obvious to me yet won't be obvious to someone who's never taken a single math class past high school.

And the biggest problem with the current system is not how the "overflow correction" is computed, but the fact that the subsequent project doesn't get any bonus multipliers. So, e.g., if you have a city that's building Knights, and it has Heroic Epic for +100%, then you get 1 Knight every two turns if you can get to 45 hammers/turn with the bonus, but if you only can get 44 hammers/turn then you do much worse, because each time you finish a Knight you lose several hammers to "overflow correction". This defeats the whole point of the new system which is supposed to let players not have to micromanage exactly how much production they generate. There's not really a matter of opinion here: there's one right way to do it.

Just wanted to bump this up as I needed to use it and had to scroll through 3 pages to find it... would be cool if this chop grid could be included in the Civ4 Reference Charts. Great tool by the way Ozzy :)

Grids are much prettier than formulas

Indeed they are, I was dazzled by the many colours:wow:.

Thanks a lot for a useful diagram, will help me a lot in the future.

eek

i think it's all change now with the new patch. a new grid may be required

BTW. I htink I just worked something out that has been confusing me for a while. I wondered how I was getting 40 hammers on a quick start, and now i know it was cos (e.g.) i was building a wonder with an industrious civ. So theoretically (though i never noticed) it is possible to get 60 hammers when u have appropriate resource hooked up.

Now the new patch will certainly requires some new grids... too bad.

The new standard grid should be 30,30,25,20,15,10,5. Compared to v1.52 which was 30,30,30,25,20,15,10,5. Scale by appropriate percentages for quick, epic, marathon. (And by 2/3 before Mathematics, and by 2/3 if outside cultural borders.)

There's another new patch and now we only get 20 hammers/sheilds for chops closest to our city

It looks like there's some funny rounding going on. One would expect a forest 3 tiles away, within the cultural borders, on epic speed, pre-Mathematics to be worth 25 hammers. (25*2/3*1.5) However it looks like, in game, they're rounding the result of 25*2/3 down to 16 and then when they multiply by 1.5 the result is only 24. Bug, or by design?

It looks like there's some funny rounding going on. One would expect a forest 3 tiles away, within the cultural borders, on epic speed, pre-Mathematics to be worth 25 hammers. (25*2/3*1.5) However it looks like, in game, they're rounding the result of 25*2/3 down to 16 and then when they multiply by 1.5 the result is only 24. Bug, or by design?

Or maybe it's 25*1.5 = 37.5, rounded down to 37, and then 2/3 of 37 is 24.7, rounded down to 24. It's not surprising that they are using integer arithmetic with fractions rounded down, as this happens many other places in the game too. I've heard that Firaxis avoids floating-point arithmetic because different systems might round differently, resulting in out-of-sync errors in multiplayer games. Of course, there are other ways to deal with rounding, but, it's not a big deal (in this case anyway).

I'm sure they didn't "design" it to be either 24 or 25. It just came out that way.

True, it's a product of how they do fractional math. Taking a look at the SDK, at each step of the formula they do something like:

iProduction *= getFeatureProductionModifier()+100
iProduction /= 100

Technically, I was correct with the order of operations. The order of operations followed in the code is (rounding at each step):

Get Base Forest production
Add extra production for current city project
Reduce Production by 5 for each tile past the second away from a city
Modify by Player's Production modifier (67% before mathematics)
Modify by Game Speed modifier

I was aware the game rounded all of it's arithmetic to the lowest integer, but I wasn't aware they did it for every interrim operation. It seems a tad unnecessary in this particular case, as there's little reason they couldn't just divide by some multiple of 100 at the end of the block of code. That would produce a more "accurate" result.

I was aware the game rounded all of it's arithmetic to the lowest integer, but I wasn't aware they did it for every interrim operation. It seems a tad unnecessary in this particular case, as there's little reason they couldn't just divide by some multiple of 100 at the end of the block of code. That would produce a more "accurate" result.

I think it's a little more complicated than that---if you "save up" too many multiples of 100 to divide by, you can get overflow, which would be worse than rounding errors. But I agree that you could do the calculation "exactly", without floating-point arithmetic. If it were me, I would probably do that. But it does add some complexity and thus some chance of new bugs.

Actually, I did a little more investigation, and I had the order of operations wrong. The full formula is as follows (again, flooring after each step).

Get base forest production (30).
Subtract 5 for every tile away from the nearest city > 2 (4 tiles away would = 20)
Multiply by the city's production modifier (1.25 if it has a forge)
Multiply by the player's forest production modifier (1.5 after mathematics)
Multiply by game speed modifier (1.5 for epic)
--- now the tricky ones that I didn't get before ---
Multiply by the BASE_FEATURE_PRODCUTION_PERCENT (0.67) - this is what they added to give forests a perceived base value of 20 hammers
If you're chopping a forest outside your borders, multiply by the DIFFERENT_TEAM_FEATURE_PRODUCTION_PERCENT (0.67)

What all of that results in is quite a lot of potential for rounding "errors". For instance, the most glaring example to me was, in an epic game (with mathematics), after chopping a forest right next to a city, I received only 44 hammers intead of the 45 I used to get. So, I ran through the math and came up with this:

30*1.5 = 45 (mathematics)
45*1.5 = 67.5 (epic)
67*.67 = 44.89 = 44 hammers. (BASE)

Say you had a city bonus of 100% (stone for the pyramids), now you'd get the full expected 90 hammers.

30*2.0 = 60 (stone)
60*1.5 = 90 (mathematics)
90*1.5 = 135 (epic)
135*.67 = 90.45 = 90 hammers. (BASE)

That 100% bonus really turned out to be a 105% bonus.

Interestingly, there's also a variable in the formula that's not currently being used that can mitigate the reduced hammer value based upon city population. For instance, cities with 5 population could potentially receive full chop value before mathematics.

@malekithe: Good job. I really wonder, after reading all this, if it would be better to modify accordingly the values for base chop (from 30 to 20) and BASE_FEATURE_PRODUCTION_PERCENT (from 0.67 to 1). Don't you think that the result would be the same, but with one rounding less?

I am pretty sure that this 1 lost hammer (45 to 44) wasn't intented, but rather a bug. For example, in normal speed there is no lost hammer in this case.

Atreas, the problem with changing the base value of a chop from 30 to 20 is that it breaks the first operation of subtracting 5 per tile distance > 2. To tell the truth, I can't come up with a good fix for this that doesn't involve an SDK-based mod. The best I could do without touching the code would be to modify the game speed modifiers and restore the BASE modifier to 1.00. I'd propose something like Quick = .45 Normal = .67 Epic = 1.00 Marathon = 2.00. That would produce nearly identical results on Normal, Quick and Marathon, but Epic would be fairly close to "exact".

A better fix, to me, would be to go in and change the order of operations to be a bit more logical. I would combine the Math Bonus with the base bonus such that they "cancel out" most of the time. I would make it the first modifier I applied. I'd then apply the game speed modifier combined with the outside-cultural-radius modifier (which cancel out on epic). Lastly, I'd apply the city's production bonus.

@malekithe: Right. You can't fix it unless you delve into the code. For my part, I will probably play a few games with the given settings and then make the change I stated and also change the distance factor from 5 to 4. That creates almost identical values with the intented, unless you chop too far from the city (which I almost never do, especially after the new patch).

I just hate it when I see (for one more time) that they didn't manage to find a formula that balances for all game speeds. After all, epic isn't the most unpopular game speed (I could say exactly the opposite is true).

I just hate it when I see (for one more time) that they didn't manage to find a formula that balances for all game speeds. After all, epic isn't the most unpopular game speed (I could say exactly the opposite is true).

This seems like complete nonsense. You surely can't believe that one hammer more or less has any significant effect on game balance.

The turn a normal worker spends moving onto a forest is 50% more valuable than the turn an epic worker spends.
This is clearly unfair to normal workers, so epic deserves to be nerfed a lot more than 1 hammer! ;)

This seems like complete nonsense. You surely can't believe that one hammer more or less has any significant effect on game balance.
You are certainly more clever than me, of course, so you can find things "complete nonsense" or not. I have similar habbits, I admit, but generally I try to be more polite.

Can you find a good reason why even 1 hammer should be taken or given according to game speed? Can you find me a good reason why fast workers are better in normal speed than in Marathon? If it isn't intented, then it's bad balancing. PERIOD.

Can you find a good reason why even 1 hammer should be taken or given according to game speed?

It keeps the code simpler and requires fewer changes, thus reducing the probability that the patch might be released with a really serious bug that would affect many people, as opposed to a trivial "bug" that hardly matters.

But, if it were me, I would have written the code differently. That's not the point. The question is not whether you or I would do it one way or another---when we design and publish our own games, we can do them however we like. The question here is whether it matters, one way or another, to the players.

If it isn't intented, then it's bad balancing. PERIOD.

There are lots of things in the game that aren't "intended" but still have no effect on balance. They are just immaterial.

@DaviddesJ: I don't disagree with you about the importance, but about the expression you used. I would even like more DaveMCW note about having a chopping penalty in faster speeds - but I just don't like to make a +/-1 rounding when it could be avoided.

As you might note, I am not talking about the code but about the values of parameters - as a programmer, I know very well what it means to change a formula and what it means to change a bit the parameters. So, let's just say that the "complete nonsense" phrase didn't ever existed :).

So, let's just say that the "complete nonsense" phrase didn't ever existed :).

The rounding is not a balance problem. If we can start with your claim of a balance problem and make that posting retroactively not exist, then everything that followed it will disappear, too.

If we can start with your claim of a balance problem and make that posting retroactively not exist, then everything that followed it will disappear, too.
What are you saying? The problem, in case you didn't notice it (which is obvious by your writtings) is in your MANNERS.

You have the right to disagree (I disagree with all your sayings, for example) - but "complete nonsense" is quite heavy an expression, at least in the place where I was born.

What are you saying?

I'm saying that I think the root of the problem is your original (mis)statement.

I'm not going to engage in an argument about whether or not you like how I express my opinions. If you want to discuss Civ4, feel free. If you want to argue about the best way to discuss Civ4, you can argue with yourself.