From 894e52031914bd69d74c8e20830f0ed67a14f0e6 Mon Sep 17 00:00:00 2001 From: Yair Morgenstern Date: Tue, 26 Jan 2021 22:34:38 +0200 Subject: [PATCH] More concurrency problems avoided by creating a second cityStats to run the values on This should also help speed things up, since we don't need to run the update() again to revert it! --- core/src/com/unciv/logic/city/CityConstructions.kt | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/core/src/com/unciv/logic/city/CityConstructions.kt b/core/src/com/unciv/logic/city/CityConstructions.kt index ecd152f0ab..166a1e3d25 100644 --- a/core/src/com/unciv/logic/city/CityConstructions.kt +++ b/core/src/com/unciv/logic/city/CityConstructions.kt @@ -208,13 +208,15 @@ class CityConstructions { We don't want to change our current construction queue - what if we have an empty queue, this can affect the city if we run it on another thread like in ConstructionsTable - So we run the numbers for the other construction + ALSO apparently if we run on the actual cityStats from another thread, + we get all sorts of fun concurrency problems when accessing various parts of the cityStats. + SO, we create an entirely new CityStats and iterate there - problem solve! */ - + val cityStats = CityStats() + cityStats.cityInfo = cityInfo val construction = cityInfo.cityConstructions.getConstruction(constructionName) - cityInfo.cityStats.update(construction) - cityStatsForConstruction = cityInfo.cityStats.currentCityStats - // revert! - cityInfo.cityStats.update() + cityStats.update(construction) + cityStatsForConstruction = cityStats.currentCityStats } val production = cityStatsForConstruction.production.roundToInt()