0001899: Game locks up for 30 min during seasonal temperature shift

Notes
(0006781) Logical2u (manager) 2010-05-16 08:33	Before I download the save, could you answer three questions? 1. If you have a military, does completely disbanding the military solve the crash? 2. If you have smelter, does disabling any melting jobs resolve the crash? 3. If you have a hospital zone, does deactivating the hospital zone and stopping your dwarves from receiving medical care (by deconstructing the beds they are resting in) stop the crash?

(0006788) ashta_ku (reporter) 2010-05-16 08:55	This is a pretty young fortress and doesn't yet have any military or hospital set up. With regard to the smelter, I checked and verified that no melting jobs are in progress, so I don't believe that is the culprit either I'm afraid.

(0006789) Logical2u (manager) 2010-05-16 08:58	Alright, I'm downloading the save now and will report back if I can find anything obvious. Thank you for the quick reply!

(0006790) Logical2u (manager) 2010-05-16 09:28	About when does it crash? My game locked up a little bit after the "Stud with gold" job finished, and it hasn't responded since then, but it hasn't crashed per say. (I have a suspicion that it might resolve itself eventually, much like the giant embark collapse I previously tested).

(0006791) ashta_ku (reporter) 2010-05-16 09:34	Hmmm, I was asuming that the frozen game was a crash event but maybe you are correct. I will load it up and let it set for an extended period of time to see if it sorts itself out. But yes, it was becoming non-responsible shortly after the stud with gold message. I will follow up if this resolves the issue. Thanks!

(0006794) ashta_ku (reporter) 2010-05-16 10:01	Followup: It took just short of half an hour, but the game came out of its stall. Thank you for pointing me in the right direction! Interestingly, the long non-response period seems to have corresponded with the end of a snow storm on the surface. I guess we can call this one resolved :)

(0006798) Footkerchief (manager) 2010-05-16 11:44	A thirty-minute lockup doesn't sound normal. This should probably get checked out by Toady.

(0007023) ashta_ku (reporter) 2010-05-19 14:51	Some additional information after a few more years in the fortress -the problem on occurs in winter, but does not appear to be always linked with snowstorms. -the problem always happenes only once a year -the problem still occurs in 31.04

(0007034) sloshmonger (reporter) 2010-05-19 19:27 edited on: 2010-05-19 19:28	I've noticed a measurable pause whenever a region temperature reaches the melt threshhold. My current fort is at a three-way regional intersection, and I get three noticeable pauses (22 Obsidian, 4 Granite & 7 Granite) that correspond with ice turning to water on each region. As I have a large body of water on the last region to melt, I have to make sure at the first pause that my dwarfs are exiting the ice or have high swimming. This pause is much less noticable if all the ice has been mined out in the large region.

(0007035) Logical2u (manager) 2010-05-19 19:58	Ah, so this might be a good test - does disabling temperature in the init settings resolve the lockup, ashta_ku? How about for your "pause", sloshmonger?

(0007114) ashta_ku (reporter) 2010-05-20 19:50	Turning temperature off prevented the pause from occuring at my fort.

(0010831) Lord_Dakstar (reporter) 2010-07-22 10:32 edited on: 2010-07-22 10:51	The pause is occuring due to the pathing updates due to the freeze/melt of water. Any map with significant amount of water that transitions has the same issue. The game isn't crashed, it's just busy recalculating its path maps due to EACH UNCOVERED WATER TILE CHANGING due to to its FREEZING. What is needed to fix this problem is a special step whenever the temperature crosses water's melt/frozen threshold: temporarily turn off pathing updates, change all water tiles to frozen (and mark them if needed so the code knows to recalculate its pathing map), and when no more water tiles are left to transition to frozen, then conduct the pathing map update, return to normal processing. It only needs to be done ONCE a season--- when outside water freezes. This would result in cold maps that have yearly freezing events to only having a small pause for the change, rather than 10 minute to 60 minute pauses while it calculates the change. Funnily enough, the reverse of the ice obstacles transitioning (MELTING) does not have this problem to such a notable degree (at least on the freezing maps I've played). The workaround you as a player can do (while leaving temperature option on) is to cover up your significant water sources on the map or drain it. Either works, as covered water doesn't freeze, and if the water isn't there, it cannot freeze. If you don't want to deal with the long pauses when the water freezes while you are covering it up on your map, temporarily turn off temperature, build your water covers, then go turn back on the temperature options. That should fix your problem on the map and allow you to enjoy the temperature option for the rest of your playing. Note: I think it is the freezing side of the cycle that causes the super long calculations. I might have that the wrong way around, as my last freezing map was a couple of games/fortresses ago. But the fix is still the same. It is the unnecessary calculating the machine is doing tile by tile due to the change in open/obstacle status when we know that during the seasonal FREEZING/MELT transition of the water on the map, we will most likely have many water tiles that change status, rather then this being a single change like the door being locked or unlocked, or a small number of tiles changing (such as a bridge changing states). So having the game suspend the path recalculating until all water tiles have been transitioned would skip all that unnecessary calculatons that just waste the players time--- we only need to recalculate the final map with all the water transitioned in this particular case.

(0021456) Toady One (administrator) 2012-03-14 03:56	My understanding is that I fixed the main cause of ice-lag for 34.01.

Issue History
Date Modified	Username	Field	Change
2010-05-16 08:25	ashta_ku	New Issue
2010-05-16 08:33	Logical2u	Note Added: 0006781
2010-05-16 08:34	Logical2u	Issue Monitored: Logical2u
2010-05-16 08:48	Logical2u	Tag Attached: AWAITING UPDATE
2010-05-16 08:48	Logical2u	Issue End Monitor: Logical2u
2010-05-16 08:55	ashta_ku	Note Added: 0006788
2010-05-16 08:58	Logical2u	Note Added: 0006789
2010-05-16 08:58	Logical2u	Tag Detached: AWAITING UPDATE
2010-05-16 09:28	Logical2u	Note Added: 0006790
2010-05-16 09:34	ashta_ku	Note Added: 0006791
2010-05-16 10:01	ashta_ku	Note Added: 0006794
2010-05-16 11:44	Footkerchief	Note Added: 0006798
2010-05-16 11:45	Footkerchief	Summary	Reproducible crash - cause unclear => Game becomes unresponsive for 30 min, possibly related to end of snow storm
2010-05-19 14:51	ashta_ku	Note Added: 0007023
2010-05-19 19:27	sloshmonger	Note Added: 0007034
2010-05-19 19:28	sloshmonger	Note Edited: 0007034	View Revisions
2010-05-19 19:58	Logical2u	Note Added: 0007035
2010-05-20 19:50	ashta_ku	Note Added: 0007114
2010-06-16 05:46	Logical2u	Relationship added	parent of 0002352
2010-06-29 07:38	Footkerchief	Category	Technical => Technical -- General
2010-06-30 17:21	Khym Chanur	Issue Monitored: Khym Chanur
2010-07-22 09:43	Jinalealia	Issue Monitored: Jinalealia
2010-07-22 10:32	Lord_Dakstar	Note Added: 0010831
2010-07-22 10:33	Lord_Dakstar	Note Edited: 0010831	View Revisions
2010-07-22 10:34	Lord_Dakstar	Note Edited: 0010831	View Revisions
2010-07-22 10:38	Lord_Dakstar	Note Edited: 0010831	View Revisions
2010-07-22 10:44	Lord_Dakstar	Note Edited: 0010831	View Revisions
2010-07-22 10:46	Lord_Dakstar	Note Edited: 0010831	View Revisions
2010-07-22 10:48	Lord_Dakstar	Note Edited: 0010831	View Revisions
2010-07-22 10:51	Lord_Dakstar	Note Edited: 0010831	View Revisions
2010-07-22 11:32	Footkerchief	Summary	Game becomes unresponsive for 30 min, possibly related to end of snow storm => Game locks up for 30 min during seasonal temperature shift
2010-08-20 23:35	Dwarfu	Relationship added	has duplicate 0003079
2010-11-28 12:48	Footkerchief	Relationship added	related to 0003750
2010-12-23 10:14	Footkerchief	Relationship added	related to 0002063
2011-02-06 10:32	Dwarfu	Relationship added	related to 0002296
2011-03-30 13:37	Footkerchief	Relationship added	has duplicate 0001462
2011-03-30 13:39	Footkerchief	Relationship added	related to 0002195
2011-08-20 06:06	Logical2u	Relationship added	parent of 0004845
2012-02-13 12:01	Footkerchief	Tag Attached: Fixed in 0.31.26?
2012-02-14 05:12	Footkerchief	Tag Renamed	Fixed in 0.31.26? => Fixed in 0.34.01?
2012-02-25 13:00	Footkerchief	Relationship replaced	has duplicate 0002352
2012-02-25 13:00	Footkerchief	Issue Monitored: KTaipan
2012-02-25 13:00	Footkerchief	Issue Monitored: plynxis
2012-02-25 13:00	Footkerchief	Issue Monitored: btbonval
2012-02-25 13:00	Footkerchief	Issue Monitored: Kogut
2012-02-26 11:49	Buglist	Issue Monitored: Buglist
2012-03-14 03:55	Toady One	Relationship replaced	related to 0004845
2012-03-14 03:56	Toady One	Note Added: 0021456
2012-03-14 03:56	Toady One	Status	new => resolved
2012-03-14 03:56	Toady One	Fixed in Version	=> 0.34.01
2012-03-14 03:56	Toady One	Resolution	open => fixed
2012-03-14 03:56	Toady One	Assigned To	=> Toady One
2012-03-14 03:56	Toady One	Tag Detached: Fixed in 0.34.01?
2012-03-15 15:35	Buglist	Issue End Monitor: Buglist
2012-03-17 23:49	Kogut	Issue End Monitor: Kogut
2014-01-20 18:57	Footkerchief	Relationship added	has duplicate 0004587