Game is played from year 05 to year 08 on DF 0.47.03 This bug makes Dwarf Fortress totally unplayable. Digging for magma is a digging job for 100 levels, so it will take 100 game reloads. To dig it clear, takes 40 game saves and reloads. Dwarves stop digging after breaking out stone in the first line of the dig. It removes the bug, but try to dig a channel 40x10. After a longer while, some Dwarves will try to break out by jumping over the new constructed wall. Watch Dwarves glued to positions next to the newly constructed wall. Wait for merchants to pack their stuff and leave trade depot. Floyd-Warshall parallel algorithm, for finding all points-pairs shortest distances, which is using GPU, solves the re-computing all paths issue under 1 second, when terrain changes for any whatsoever reason. My guess is, that the Dijkstra path-finding algorithm for sake of efficiency was badly optimized or is badly implemented for largest embarks. Though, I could load an older game-save and simply block access to my Trade Depot for all caravans for ever. I am considering killing the caravan and starting war with humans, because this bug makes continuous building and continuous digging impossible without frenzy of reloads. So I suspect the caravan is the guilty party. The bug, in my game, starts after Human Caravan in summer of 3rd year old embark is packing and leaving the Trading Depot. Player is being spammed with "can't give water" and "item for eating is inaccessible". Dwarves become idle standing for long time, despite need to sleep, drink or eat. It applies both to constructing jobs and digging. The issue still exists on largest embarks in 0.47.03 with large surface bunker-construction. Note that DF loads this as having random seeds, but the world was generated with the empty string as all seeds.ĮDIT 2: The *_FREQUENCY, MINERAL_SCARCITY, settings do not have any effect on this bug.ĮDIT 5: A pocket region with reproduces the issue seeing where the tipping point is. The worldgen parameters are at the bottom of this note I'll continue trying to reduce the testcase.ĮDIT: That was more text than expected here are the _differences_ vs. Attempting 17x17 and 257x257 worlds with otherwise baseline parameters using simple worldgen did not reproduce the issue, but using the same worldgen parameters as I originally encountered the issue in to generate a completely vanilla world (no tileset, no DFHack) did reproduce it. Many thanks to lethosor for helping me debug this on IRCįurther testing has revealed that there's at least some influence from worldgen parameters. Watch dwarves get trapped optionally use gui/pathable to inspect the floored tiles. The broken pathfinding groups can be fixed by saving and loading, however the issue will recur with any subsequent construction or excavation.ģ. This occurs regardless of where in the embark the construction is performed (tested at the center and all four corners), where in the world map the embark is performed (tested two locations, one north-east-ish and one south-west-ish, on a 257x257 map), and does not occur on a 2x2 or 2x16 embark. In a likely-related issue, newly dug (d-d) tiles receive a unique pathfinding group ID per tile, though surrounding tiles are unaffected. This isolates them from the rest of the map, breaking pathfinding. On a 16x16 embark, any constructed wall or floor will cause its own tile and all directly adjacent tiles to become part of pathfinding group 1 (as tested with dfhack's gui/pathable). Main | My View | View Issues | Change Log | RoadmapĠ010838: Constructed floors and walls, as well as digging, break pathfinding on 16x16 embarks Anonymous | Login | Signup for a new account
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |