Queued shields are halved for unique units same as changing type

[jwrober]

Describe the bug
If you build a unique unit - Navy Troops in LTX as an example - and then continue to build Navy Troops in other cities the shields will store as you cannot actually build more than one unique unit. If you learn a tech (Amphibious Warfare) and want to build Marines with those stored shields, the client cuts the shored shields in half at swap same as if you were building a unit and changed to a city improvement.

NOTE: This could be a "feature" and not a "bug" per se, depending on how you are trying to exploit the game mechanics.

To Reproduce
Steps to reproduce the behavior:

1. Set many cities to build Navy Troops or another unique unit
2. Finish one of them in a city, but leave all the other cities still trying to complete the unit
3. Learn Amphib or another tech you want to use to build many units via build slots with the stored shields
4. Swap the construction to the new unit type (e.g. Marines)
5. Notice that you lost 50% of the stored shields for those cities that had more shields stored than the cost of a Marines unit. Those cities with fewer stored shields for one unit didn't have the 50% penalty.

Expected behavior
This is problematic on a couple of fronts:

1. This is clearly an exploit of the game engine mechanics
2. The "tax" if you want to call it that isn't evenly applied. It only happens if you have more shields than the cost of a single unit stored up.

There are a couple ways we could go about "fixing" this issue:

1. Change the code in a way that if you build a unique unit and the same unit is being built in other cities an "advisor" kicks in at TC and automatically changes construction to the best defensive unit available. This prevents the storage of the shields completely.
2. Enact some kind of unique-unit to regular-unit change in production tax just like we have already if you change prod between classes of items (e.g. you are building a unit and swap to a city improvement). For consistency, keep it at 50% just like the rest.

I personally like the first. This is an exploit we probably should look to eliminate.

Screenshots

vs

Platform and version (please complete the following information):

• OS: N/A - happens in all clients
• Freeciv21 version: v3.0 and v3.1-dev
• Ruleset/Longturn game (if applicable): LTX, but don't think this is ruleset dependent

Additional context
Add any other context about the problem here.

[jwrober]

https://github.com/longturn/freeciv21/blame/950ee4101d354d62a7be0ac913a9e7e1a7d2106e/common/city.cpp#L1832-L1837

[daavko]

This is not specific to unique units. It happens every time when you buy a unit and then don't end up building it for any reason. For example, buying Settlers in a size 1 city and then trying to change production to a different unit the next turn would produce the same result.

It's not tied to stored production being above or below the unit cost. I tried this in a 3.0 test game, and as long as you don't buy the unit you can't build, you can switch to anything else without any shield penalty.

[lmoureaux]

The exploit that we wanted try to prevent is:

1. Buying an unbuildable unit for cheap then switching to a more expensive one. Takes 2 turn but can save a lot of gold.

I'm not sure if it's an exploit, but we need to keep this in mind:

2. Storing shields to produce some other non-unique unit in the future. Disasters are already trying to discourage this.

I think that the following should not be penalized:

3. Buying a settler and waiting for the city to grow. Penalizing this would give a bad feeling to players who were expecting the city to grow but were hit by an epidemic.

From 3, it is clear that we only want to penalize when the player changes production. Force-changing production doesn't solve 1.

Technically this is already scriptable: Lua has a unit_cant_be_built signal, but unfortunately the API isn't rich enough to implement a "tax".

I think a penalty could apply to the shields that were bought. Maybe one loses half of them when changing production. This would still allow 2 while making 1 less attractive.