View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0006955 | Dwarf Fortress | Adventure Mode -- Buildings | public | 2014-07-10 10:05 | 2020-10-15 04:43 |
Reporter | Peeps | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | confirmed | Resolution | open | ||
Product Version | 0.40.01 | ||||
Summary | 0006955: Abandoned fortresses reconfigure when slept in / strange lighting | ||||
Description | I was exploring an abandoned fortress and got drowsy so I slept for a while; when I woke up I thought I had been moved to a different part of the fortress but after looking around I realized the entire layout had been re-generated. I haven't checked but I assume this will also happen whenever the fort is unloaded and reloaded by whatever means. Unrelated, but most of the magma forges I found were colored in shades of blue for some reason, as if it were nighttime. Even the lava I could see through holes in the floor was dark blue, I thought it was water but a quick [l]ook told me otherwise. The ones that looked normal didn't have any holes near them, so maybe the magma sea is classified as "outside" and since it was night the areas near the holes were dark. | ||||
Steps To Reproduce | Sleep in an NPC fortress, might not happen in inhabited ones but they need to be checked too. General unloading and reloading the map might cause it too. Find the level with the forges and look for ones with holes near them at night. | ||||
Tags | No tags attached. | ||||
|
It's not just abandoned fortresses, its occupied fortresses too. Reproducible in 40.11 |
|
I saw something similar happen to a populated fortress in 40.9. When I first arrived at the fortress, the square above-ground building was red and the depot was to the east of the central shaft. I went hunting in the desert and when I came back the building was black and the depot was to the north. The third time I arrived, it was back to red building and depot to the east. Recently, in 40.10, the entrance to a lair had moved from the east side of a hill to the west side after savescumming. Edit: Corrected version numbers. |
|
Here's a save for 40.11, it's an abandoned fortress. Just load up the save, wait an hour (or any length of time), and see that the stone color changes from white cryolite to dark grey hornblende, plus the trade depot items get scattered. It does happen to occupied fortresses, just not always I think. http://dffd.wimbli.com/file.php?id=9646 Also, the trade depot broke in that it just says 'nothing to pick up here' when I try to. |
|
Still in 40.12 and heres one of a worldgen fortress that is occupied (in the sense of being lived in, not occupied by an enemy army). It doesn't seem to happen to all worldgen fortresses, just some, no idea why. Wait or sleep any length of time and you'll see the material change from hornblende to lignite (same color), the open staircase get floored over and the dwarves at the trade depot will switch to the left side, along with scattered items. The spot the trade depot was previously won't register as having anything to pick up there. http://dffd.wimbli.com/file.php?id=9685 |
|
I may be able to add a bit to this. I visited a ruined fort with an adventurer, and experienced a reconfigure and teleport the first time I slept in it (but only the first time). Later, after evicting its uninvited guest, I reclaimed the fort. Some relevant oddities: 1) Armor and weapons that were left in the fort won't be used by military dwarves (they don't appear in list of items to assign specifics), but woodcutters will use the axes normally, and all items can be traded. 2) Clothing and armor that were in cabinets became large after reclaiming. I am least certain about this part; my adventurer was already well equipped when I came here, and I didn't thoroughly inspect the contents of most containers. These are the only large items I've seen in this world, though. The dwarf civ in question is isolated on an island and has never interacted with another civ. 3) An area of the fort that was disconnected from the rest of the fort when I visited with an adventurer now has a staircase leading to it. This is the strangest part; I spent a lot of time exploring this fort, so much that I had to leave three times to refill my waterskin. I was unable, in all that time, to find the forgotten beast that lived there. Finally, I downloaded dfhack and revealed, and found that it was in a disconnected part of the fort. I then used tiletypes to create a path to it. Now that I've reclaimed, the forgotten beast's corpse (vomit, actually) is in an area of the fort accessible by a staircase, and the changes I made with tiletypes appear to be gone. It's possible that the corpse "scattered" when I reclaimed, but it doesn't appear anything else did. It's also possible (though incredibly unlikely) that I just missed the staircase during my many passes through the fort, even after it was revealed and I was placing a staircase in the same room with dfhack. It is definitely not the one I placed. This is a post reclaim save: http://dffd.wimbli.com/file.php?id=9795 Unfortunately, I don't have one from the adventurer. Note the active military squad with an assigned uniform, and the unforbidden armor pieces in the depot and on the first activity level (F2 will zoom to it, iirc). They will equip armor and weapons created on site normally. If you wait a little while, the first caravan will arrive and you will see that the armor and weapons in the depot can be traded. |
|
Ziusudra posted at 0007940, describing another instance of this bug (with a save from 0.40.14). |
|
This bug is reproducible in 0.42.03. I've started in adventure mode in an underground fortress, went 2 levels up (still being underground), slept on a square with a bed. New area has been generated, sadly the staircases can also nowhere to be found :(. I've also found items that I dropped on a ground now being stuck in a wall. EDIT- Also, DF crashed when I tried saving the game while being next to the said items in the wall. |
|
With 0009432 resolved in 0.42.05 the changed layout for this one may be resolved, too. Someone can check the save files? Note that while checking 0009432 I experienced one initial layout switch after restoring the save file, but none after that. |
|
Some preliminary results. I had the time to check these two saves: http://dffd.wimbli.com/file.php?id=9646 (0006955:0030041) http://dffd.wimbli.com/file.php?id=9685 (0006955:0030157) Both do only one initial reconfiguration. Afterwards everything looks stable after multiple sleep/travel. Scattered items and unresponsive trade depot are happening, though. But these are covered by 0008350. When time allows I'll continue with the other saves. |
|
I'd like to point out other incidences of this happening: http://www.bay12forums.com/smf/index.php?topic=157383.0 0009685 What GoblinCookie appears to have deduced is that this may be one of those old problems of the seed generating a fortress differently depending on which direction you approach the fortress from, usually associated with some step in procedural generation not conforming neatly to the confines of the world map grid. (That is, past incidences have involved trees being generated in 5x5 grids, which would not fit neatly in the 48x48 map grids, so trees and ponds would generate differently in the same terrain depending on whether you embarked in a 3x4 or a 3x5 embark over mostly the same land.) Sites are offloaded, then regenerated upon quicktravel/sleep, so what's happening is that the site is regenerating differently because you generated a different chunk of map first this time you "looked" at that part of the map. This combines with 0009499 and 0009068 to create a problem where, if items are touched, they are saved by their location (which can change when the game regenerates the landscape) thus "teleporting items inside walls", and also destroying property rights due to item ownership somehow not being saved or only being saved through being inside of a shop or other site building that denotes ownership over items. |
|
TheJazziestCat posted a 0.47.04 save at 0011636. |
Date Modified | Username | Field | Change |
---|---|---|---|
2014-07-10 10:05 | Peeps | New Issue | |
2014-09-05 21:02 | smjjames | Note Added: 0029978 | |
2014-09-06 04:22 | Mopsy | Note Added: 0029983 | |
2014-09-06 07:38 | Mopsy | Note Edited: 0029983 | |
2014-09-06 07:39 | Mopsy | Note Edited: 0029983 | |
2014-09-06 07:40 | Mopsy | Note Edited: 0029983 | |
2014-09-08 13:51 | smjjames | Note Added: 0030041 | |
2014-09-08 13:53 | smjjames | Note Edited: 0030041 | |
2014-09-08 14:58 |
|
Assigned To | => user6 |
2014-09-08 14:58 |
|
Status | new => confirmed |
2014-09-08 14:59 |
|
Relationship added | related to 0003478 |
2014-09-12 22:30 | smjjames | Note Added: 0030157 | |
2014-09-26 12:14 | m-logik | Note Added: 0030385 | |
2014-11-21 04:24 | Mopsy | Note Added: 0031103 | |
2015-12-19 10:26 | jimmylobo | Note Added: 0034051 | |
2015-12-19 10:40 | jimmylobo | Note Edited: 0034051 | |
2016-01-23 05:57 | mkiever | Note Added: 0034523 | |
2016-02-09 06:07 | mkiever | Note Added: 0034624 | |
2016-04-09 21:20 | NW_Kohaku | Note Added: 0034990 | |
2016-04-09 21:21 | NW_Kohaku | Note Edited: 0034990 | |
2016-04-09 21:21 | NW_Kohaku | Note Edited: 0034990 | |
2017-11-22 15:27 |
|
Relationship added | has duplicate 0008871 |
2017-12-04 03:54 |
|
Relationship added | related to 0009499 |
2020-10-15 04:43 |
|
Note Added: 0040764 | |
2020-10-15 04:43 |
|
Sticky Issue | No => Yes |