Refund wasted production as gold

[Thyrum]

Any wasted production, from for instance a partially completed wonder or obsolete units, will now be refunded as gold (in a 1:1 ratio). When obsolete units get replaced by their new version, this code should probably be updated.

I first added the gold refund code in validateInProgressConstructions, but this function is only called upon endTurn. Hence a refund for a wonder build elsewhere would occur after the relevant turn instead of before the turn. Hence the implementation is now put in validateConstructionQueue.

The current implementation does result in code duplication between validateInProgressConstructions and validateConstructionQueue. Any ideas on how to neatly remove this duplication are appreciated.

Another thing to consider would be a notification/popup explaining why the gold was added, but this probably clutters the interface too much.

Fixes #4047

[Thyrum]

Just noticed a quite big bug. This only accounts for constructions that were in your queue when they became obsolete, not for ones that you had already removed from your queue. I will fix this shortly, until then this will be a draft.

[Thyrum]

The code has now been updated. This did however require calling validateInProgressConstructions from constructIfEnough since constructIfEnough is called at the start of each turn. It might therefore be better to add a startTurn function which calls both constructIfEnough and validateInProgressConstructions.

[ravignir]

in civ5 all of the production invested into obsoleted units is transferred to progress towards their respective upgrades.

[Thyrum]

in civ5 all of the production invested into obsoleted units is transferred to progress towards their respective upgrades.

I am aware of this but decided not to implement this yet because the issue did not include this (and I still need to get a little more familiar with the codebase 🙃). It can always be added in a later pull request.

[SomeTroglodyte]

I'm not convinced the original game refunded you for a lost wonder race at all. I would be fully in favour of this if the refund ratio were moddable - then we could easily make it zero in the vanilla ruleset and thereby postpone the final decision while mods could do what they want...

Production for obsoleted units being preserved and applied to the successor units is IMHO a completely separate matter, as is production overflow - which Civ4 (four not five) definitely had, and Civ5 99.9% not.

[xlenstra]

I'm not convinced the original game refunded you for a lost wonder race at all.

Here is a link saying it's a 1-to-1 ratio:
https://gaming.stackexchange.com/questions/126105/how-to-calculate-gold-earned-from-a-wonder-if-another-civilization-finishes-firs

[...], as is production overflow - which Civ4 (four not five) definitely had, and Civ5 99.9% not.

Actually, according to this page of the civ 5 forums, this is an extensively documented mechanic:
https://forums.civfanatics.com/threads/hammer-overflow.419352/

[ravignir]

I've recorded all of the cases in vanilla civ5:

production.overflow.mp4

production.transfer.mp4

wonder.compensation.mp4

anyway, the topic on civfanatics linked by @xlenstra explains production overflow really well.

[SomeTroglodyte]

... and ravignir's input of course is beyond doubt. 👍

[ravignir]

Here is what happens when an obsoleted unit has no upgrade:
https://user-images.githubusercontent.com/30041793/120907153-8c1f8200-c65f-11eb-9340-4ca25a31626b.mp4

You get a regular production overflow and nothing more.

[Thyrum]

So if I understand it correctly, we have observed that in Civ 5:

• production spent on a wonder built elsewhere is converted into gold (with a 1:1 ratio, notified to the user via notification).
• production spent on a unit which has become obsolete is put into the upgraded version of the unit.
• all other 'overflow' production is stored separately (as overflow) and added to the production of the next turn. The overflow stored can be at most the current production income or cost of the last item (the one that caused overflow), whichever is greater.

I suggest these points get added to #663. I can implement the first two points quite easily and then have this branch merged. The third point can then be added in a later pull request.

[ravignir]

So if I understand it correctly, we have observed that in Civ 5:

* production spent on a wonder built elsewhere is converted into gold (with a 1:1 ratio, notified to the user via notification).

* production spent on a unit which has become obsolete is put into the upgraded version of the unit.

* all other 'lost' production is stored separately (as overflow) and added to the production of the next turn. The overflow stored can be at most the current production income or cost of the last item (the one that caused overflow), whichever is greater.

I suggest these points get added to #663. I can implement the first to points quite easily and then have this branch merged. The third point can then be added in a later pull request.

yes, notice the 12 production invested into scout in the last video is lost forever.

[yairm210]

This looks good - I have no comments at all on the existing code!
I do have another addition, though - if the user is getting refunded, the user notification (could not continue work on []) should also contain "Excess Production converted to [] Gold", in both the notification itself and the translation line in template.properties

[SomeTroglodyte]

The overflow stored can be at most...

Didn't I read a -1 somewhere?

Otherwise 👍. I could only add the reminder - If it's not too much hassle then allowing mods to change the behaviours implemented for this might be nice.

[Thyrum]

I have implemented both gold refund for wonders and changing obsolete units into their upgraded form (if available). The relevant notifications can be seen in the screenshots below. I currently only alert users of the unit production transfer if the relevant unit was queued. I have chosen to do it this way since you probably don't care for the production swap if the unit wasn't queued.

The civlopedia should probably also be updated to reflect the changes made.


(note the last screenshot has a comma in the notification, not a dot)

[SomeTroglodyte]

Time to optimize the wording (not nitpicking, if this weren't so good I woudn't bother)? I feel the notifications are a bit long (I can already see the issues from people with 640x360 @ 72dpi screens) and 'has been obsolete' doesn't sound quite perfect... So, just thinking & feel free to ignore:

• Could not continue work on [wonder], excess production converted to [goldAmount] gold = hmm - if it's guaranteed you'll be getting the "[wonder] has been built by those other meanies" note right alongside, might "Excess production for [wonder] converted to [goldAmount] gold = " suffice?
• [oldUnit] has been obsolete and production will be changed to [newUnit] in [cityName]! = ... ... "[cityName] changed production from [oldUnit] to [newUnit]"? Maybe people are clever enought to guess - or learn - that the reason is obsoletion? Also: If N cities have these - maybe a single message "[count] cities..." with a LocationAction cycling through all of them? Just to save screen 'real estate'?

[avdstaaij]

So if I understand it correctly, we have observed that in Civ 5:
(...)

• all other 'lost' production is stored separately (as overflow) and added to the production of the next turn. The overflow stored can be at most the current production income or cost of the last item (the one that caused overflow), whichever is greater.

Minor note: I'm fairly sure that production put into a building that you then rush-buy is not refunded in any way.

[Thyrum]

I feel the notifications are a bit long

I totally agree but couldn't think of a shorter wording at that time. I will shorten the wording to your suggestions.

[...] and 'has been obsolete' doesn't sound quite perfect

I agree but the existing notification for removing obsolete constructions was

[construction] has been obsolete and will be removed from construction queue in [cityName]!

thus I used this wording in order to be more uniform. I would personally prefer to change the old and new notification to

[construction] has become obsolete and will be removed from construction queue in [cityName]!
[cityName] changed production from [oldUnit] to [newUnit]

[SomeTroglodyte]

Sorry for accidentally hitting the green pill instead of the white one.

[Thyrum]

The notifications have now been shortened to what's below. Should I also just change the has been obsolete to has become obsolete in all .properties language files? Or do we maybe want to reword it entirely (because it is quite a long notification)?

[construction] has been obsolete and will be removed from construction queue in [cityName]! = 
[construction] has been obsolete and will be removed from construction queue in [amount] cities! = 
[cityName] changed production from [oldUnit] to [newUnit] = 
[amount] cities changed production from [oldUnit] to [newUnit] = 
Excess production for [wonder] converted to [goldAmount] gold = 

[yairm210]

"has become obsolete"
Also if you want to make it shorter,

[construction] has become obsolete and was removed from the queue in [cityName] =

[ravignir]

So if I understand it correctly, we have observed that in Civ 5:
(...)

• all other 'lost' production is stored separately (as overflow) and added to the production of the next turn. The overflow stored can be at most the current production income or cost of the last item (the one that caused overflow), whichever is greater.

Minor note: I'm fairly sure that production put into a building that you then rush-buy is not refunded in any way.

yup, it is not.

[Thyrum]

Rewording of been obsolete -> become obsolete has been added. I think we are ready to merge.

[ajustsomebody]

happy to see this resolved

[Thyrum]

For completeness sake, this is yet to be implemented and will require a different pull request:

all other 'overflow' production is stored separately (as overflow) and added to the production of the next turn. The overflow stored can be at most the current production income or cost of the last item (the one that caused overflow), whichever is greater.