Pop cap bugs after December patch

I think that the most likely culprit is that not all decimal numbers have an accurate binary representation. This inaccuracy (error) only compounds the more times you add up numbers.

For instance, you cannot represent the number 1.2 in binary (You would need infinite digits to do so); this is for the same reason why you cannot represent the number 1/3 in decimal (e.g., 0.333333...)

For example's sake, let's examine Volks. Each Volk model used to occupy 1.2 popcap per model (5 models = 6 popcap).

Normally, if we had 10 Volks models on the field, we would expect these models to take up 12 popcap.

However, 1.2 is a number that cannot be accurately represented in binary format. This means that 10 times 1.2 will NOT be equal to 12 (most likely it will be less).

POSSIBLE SOLUTIONS:

Moving the hard popcap to 101 might not be able to completely address the problem, but it might mitigate it for most practical effects.

For more longterm solutions, I would recommend the following two:

1. If Relic wants to revert to using decimals, they should only use decimals that have an accurate, finite digit representation in binary.

With a Popcap of 100, change all popcap costs to numbers divisible by 0.0625 (= 1/16). This will avoid the problems I outlined. If necessary, the rounding quantum can be made even finer.

2. As for a more elegant solution that completely avoids decimal numbers altogether, I will point you to this one:

I understand that non-integer popcap values can create a mess and introduce bugs (e.g., pershing call-in). However, I don't think that the system of only allowing integer values AND keeping the popcap to 100 is sustainable, because it doesn't give you enough wiggling space to balance the value.

- An infantry model cannot cost 3 popcap (or more); 18 popcap shocks would be too much
- Thus, you are only left with popcap values of 1 and 2
- Cheap infantry (pioneers) will get a popcap value of 1
- Elite infantry will get a popcap value of 2
- What value would you assign to stock infantry?

EASY FIX

1. Increase the population cap to 200 (or 400) and scale up all the values. With a popcap of 200:
- Cheap infantry costs 2 popcap
- Stock infantry costs 3 popcap
- Elite infantry costs 4 popcap

2. If you REALLY care about displaying a popcap of 100, then do the following:

- Your internal engine will do the scaling that I mentioned internally (only use integers)
- When it comes to displaying popcap values to the UI, divide everything by 2
- Consider outputting fractions (you will only have integers, or .5 numbers coming out, nothing weird)

This is way more reasonable than what we have now (sapper popcap = ranger popcap)

Is there a way to have from Relic to look at this post? (if possible, you can PM me for more info)

coh2 only started using decimal until WFA I believe.

before that the game has a "squad pop" upkeep, that is population attached to the squad itself.

for example, each conscript and each grenadier both cost 1 pop for each man, but the grenadier have a extra 2 pop upkeep attached to the squad itself for an total of 6.

this mean that a grenadier at 3 men would take up 5 pop, at 2 men would take up 4 pop, etc.

I am not sure why the game switched to decimal, but I think the decimal or squad pop setup are better than the new value we have currently.

I think a lot of those changes had to do with team weapons, (specifically the B-4 IIRC) which had really wonky pop cap on the weapon vs the crews. Likewise, the changes to entites merging with squads and recrewing also might've been involved in changing them to a more consistent (albeit imperfect) system.

Or just make total popcap 101 but display 100. Easy.

also this must fix problem.

http://www.coh2.org/topic/45956/pop-system-revision-poor-english-fixed/page/1#post_id453713

Relic are a fucking joke. Honestly I've never seen such incompetence before.

Do they test anything? Check anything?

Or just make total popcap 101 but display 100. Easy.

This would solve the problem.