Profile of Mr.Smith

Tommy squads have a chance to drop their upgraded weapons (Bren, PIAT), even if there are enough men to pick up the dropped weapon.

This bug has a very noticeable knock-on effect on balance. Please fix

Reproduction steps

In order to prepare for the bug to manifest
- Take a Tommy squad
- Give the Tommy squad 1 PIAT from a weapon rack
- Attain vet3 with that squad
- Kill off a few models, until the Tommy squad has 3 models left

You will notice that: 2 Tommies carry scoped Enfield rifles (the vet3 bonus), and 1 Tommy squad carries a PIAT.

Now, this is how you trigger the bug
- Take a sniper and kill the Tommy that carries the PIAT (e.g., approach from an angle that only the PIAT-carrying model is visible to the sniper)

Bug manifestations

There are two outcomes possible, both of which are a bug:
1) The Tommy Squad will drop the PIAT. This is despite the fact that the squad has enough space to carry the piat

2) The Tommy Squad will not drop the PIAT. However, they will also not be able to use the PIAT until they are reinforced (the PIAT icon will not be visible on the squad).
This becomes a problem since the upgraded weapons are superior to the vet3 weapons that Tommies get for free.

Of course, you can repeat as necessary, so that you get both manifestations of the same bug. Both bugs are _extremely_ annoying and limit the unit's performance.

The cause

At Vet3, Tommies get access to 2 scoped Enfield rifles (which replace their standard Enfield rifles). These rifles have a slot size of 0 (thus, still allowing the Tommy Squad to access weapon upgrades).

The problem is that scoped Enfields do count as special weapons when it comes to occupying a model's carrying capacity. Thus, the PIAT will not have a chance to transfer to a model that carries the scoped Enfield.

Possible fixes

The most thorough fix would be fix #1. This might require a bit more effort to implement, though.

I am also proposing 2 band-aid solutions. (Personally, I prefer #2 to #3). Either of these fixes should be effortless to implement.

The idea is that you could implement one band-aid solution for the next patch/hotfix. This will buy you time to work on the more-longterm/consistent solution (#1).

1) Implement some weapon-carrying priorities.

There will be 3 kind of weapon priorities:
- Highest priority: Minesweepers
- Middle priority: dropable weapons (e.g., PIAT)
- Lowest priority: Non-dropable weapons (e.g., scoped Enfield, g43)

This means that when a higher priority weapon drops, it immediately transfers to a squad member carrying a lower-priority weapon. If no such squad member exists, then, and only then, does the drop chance take place.

CoH2 seems to have already 2 weapon priorities in place: Minesweepers vs everything else. What I am suggesting is to extend the weapon prioritization system to 3 classes.

This would be the best solution by far. It would also prevent this bug from ever resurfacing in the future.

2) Only give Tommies 1 scoped Enfield at vet3, but with upgraded stats

Let's say that the DPS of scoped enfield is A, and that the DPS of a standard enfield is B, initially the squad DPS would increase by:

2 x (A - B)

Thus, the new DPS of the scoped enfield could be:
- B + 2 x (A - B) = 2x A - B

The bug will still be there, but it will be a bit less noticeable
(With 2 upgrades weapons, you need to drop down to 3 models for the bug to happen).

3) Give Tommies the Soviet Union Guard Rifles treatment

Guards Rifle infantry used to have a similar issue (since they were carrying 4 guns). They tended to drop weapons all over the battlefield.

Some ~1 year ago (?), it was decided that guards would have a lower weapon-drop rate than other squads. Nobody has ever complained about Guards Rifle weapon pinatas since.

Note that this bug will NOT address bug manifestation #2, which means that the Tommy squad will be using an inferior, baseline weapon, although an upgraded weapon is available.


Other units affected by the same bug

- USF Airborne Pathfinders
- (edited to add) Axis infantry upgraded with g43
- (26 Dec, edited to add): possibly PPSH Conscripts and Guards too?

(possibly also) USF Recon I&R Pathfinders

The Bug / Reproduction Steps

For this you need:
- 1 Tommy squad (UKF Infantry Section)
- 1 Decrewed Vickers MG, which you will recrew

Normally, when you recrew weapons, the weapon teams take the stats (and reinforcement cost) of the recrewing unit. However, in this case:

- Tommies' reinforcement cost is 28 per model (changed on October 29 patch)
- Vickers' reinforcement cost is 35 per model (this is the cost per model prior to the October 29 patch)

The reinforcement cost of Vickers should have been 28 per model.

The Cause

The October 29 patch intended to decrease the reinforcement cost of Tommies. The way this was implemented was by tweaking a reinforcement cost modifier (I don't remember the name).

For each squad type, there is a reinforcement cost modifier attribute that determines the relative price of reinforcing missing models in the squad (as opposed to buying a new squad). Each squad and support weapon type has a separate attribute

For nearly all squads, this attribute is equal to 0.5 (i.e., you are only paying 50% of the cost to reinforce the missing model).

For Tommy squads, this attribute is equal to 0.4 (i.e., you are paying 40% of the price to reinforce Tommies).

The problem is that the value of this modifier does not transfer into recrewed team weapons. Thus, Tommies have a 50% cost modifier when recrewing a team weapon (35 MP per model)

Potential fix

A more consistent way to implement the Tommies' reinforcement cost would be the following. There is an attribute called squad_member_count. This attribute does NOT change the actual size of the squad, but is only used for reinforcement cost calculations).

- Revert reinforcement cost modifier from 0.4 to 0.5
- Instead, change squad_member_count from 4 to 5

This fix is inspired from the recently-introduced reinforcement cost bug for Rear Echelons (3 December):
http://www.coh2.org/topic/45638/rip-rear-echelon-c

Other units affected by the bug

This affects all support teams (AT guns, MGs, you name it)

Over the past few months several units have received similar tweaking in their reinforcement cost modifier. In the changelog, this is referred to as "reinforcement cost reduced by 10%" (it's actually 20% if you do the math).

Invariably, all of these units are "elite" 4-men squads with a high MP creation cost. This definitely includes:
- Panzergrenadiers
- Obersoldaten
- Fallschimjaggers

There might be more units though!
(just look in your files for units with reinforcement cost modifier = 0.4)

•  
  

  4

  VS

  RtN.The Phalanx Midconflict Dick Smith ★

  ╬OKH╬Keigo Lawrence of Arabia [ƒocus]™隆美尔

  Double Firefly Rampage

  by: pigsoup map: Essen Steelworks

  6

  -

wasn't really sure What I thought of Fireflies until this game.

Firefly is definitely fine in 3v3+. Unique and fun, too.

That video is a great example of how to use a Firefly:
Show Spoiler

If you want to unlock the Firefly's potential to the fullest remember the following:

- Tulips can travel through shotblockers; use them how you would use a pak43
- Tulips explode when they reach the maximum distance, which you can use to neutralize pak43 if you are absolutely desperate
- Brits already have a doctrinal ability to increase units' ROF; it's called command vehicle

I also used to think that Firefly was terrible. THis is because, just like everyone else in this thread, I was trying to use it as a Jackson. However, for all the reasons that Jadame has already explained in this thread:

- Brits don't need a Jackson; you can use Comet to fill in that role to some degree
- In teamgames, Allies don't need another Jackson (USF is there for that)
- Again, in teamgames, Allies need a way to gun down serious threats: exposed command tanks, Elephants, JTs and JPIVs. The Firefly is the only allied unit/ability that can fulfill that role.

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)

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)