View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000018 | Dwarf Fortress | Pathfinding | public | 2010-04-01 14:42 | 2010-06-09 06:45 |
| Reporter | DoctorZuber | Assigned To | Toady One | ||
| Priority | normal | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Platform | PC | OS | Windows Vista | ||
| Fixed in Version | 0.31.03 | ||||
| Summary | 0000018: Pathfinding fails to update after map changes | ||||
| Description | Had several problems already with dwarves unable to path to areas that should be pathable, or unable to place structures because it was unable to find path to the needed resources. More information needed. | ||||
| Tags | pathfinding | ||||
| related to | 0000820 | closed | Arriving caravan that has no access to depot totally grinds the game to dust. | |
| related to | 0000140 | resolved | Toady One | Miner cancels mine, and the designation. |
| parent of | 0000070 | closed | Toady One | Negative distance for building materials |
| parent of | 0000176 | closed | Toady One | Pathfinding not working properly with grates and ramps |
| parent of | 0000225 | closed | Toady One | Cannot find path to build bug |
| parent of | 0000317 | closed | Toady One | Constructing staircases causes pathing problems. |
| parent of | 0000346 | closed | Toady One | Recently cut wood logs not usable |
| parent of | 0000529 | closed | Toady One | Yet another way to break pathfinding, this time with a rock. |
| parent of | 0000635 | closed | Toady One | Removing a construction and replacing it with a different one sometimes fails to list the closest stone |
| parent of | 0000623 | closed | Toady One | Cannot build constructions over empty spaces (INCLUDES SAVE) |
| parent of | 0000559 | closed | Toady One | Miners won't mine some squares (at first) |
| parent of | 0000769 | closed | Toady One | Dwarves cannot dump items through doors. |
| parent of | 0000776 | closed | Toady One | Butcher cancels Butcher an Animal: Could not find path. |
| parent of | 0000901 | closed | Toady One | Cutting off access to outside areas causes lag and buggy pathfinding. |
| parent of | 0000984 | closed | Toady One | Dwarves path to suspended constructions, get stuck |
| parent of | 0000990 | closed | Toady One | I tracked down the source of the pathfinding/job item misplaced bug |
| parent of | 0001005 | closed | Toady One | Bridge over a pit by only entrance to fort breaks pathfinding |
| parent of | 0000103 | closed | Toady One | Dwarfs get stuck in buildings |
| has duplicate | 0000062 | closed | Cannot make wooden crossbows | |
| has duplicate | 0000164 | closed | Pathfinding issues | |
| has duplicate | 0000104 | closed | No access to building material issue | |
| has duplicate | 0000128 | closed | Dwarves sometimes do not start new jobs anymore | |
| has duplicate | 0000137 | closed | Path finding seems to break completely | |
| has duplicate | 0000198 | closed | Trader runs around in circles, never reaches depot | |
| has duplicate | 0000341 | closed | Miners descending z-levels by using ramps are unable to path back up. | |
| has duplicate | 0000345 | closed | Pathfinding updates too slowly | |
| has duplicate | 0000320 | closed | Dwarves complain about pathing through stairs | |
| has duplicate | 0000554 | closed | Mining designations ignored | |
| has duplicate | 0000602 | closed | Pathfinding fail, sometimes dwarfs cant find a "way out" | |
| has duplicate | 0000677 | closed | miner stops following job orders. | |
| has duplicate | 0000690 | resolved | Stuck Miner: magma channel | |
| has duplicate | 0000997 | closed | Miner decides to be stuck, problem with stairs | |
| has duplicate | 0001095 | closed | Sporadic lack of access near constructions | |
| has duplicate | 0000816 | closed | Smelter will not allow smelting jobs to be queued: Needs ore and/or fuel. | |
| has duplicate | 0001217 | closed | Dwarves refuse to dig. | |
| has duplicate | 0001152 | closed | Placing door freezes dwarf in place | |
| has duplicate | 0001019 | closed | Dwarves also get stuck on stairs | |
| has duplicate | 0001651 | closed | Logical2u | Building Constructions, Other Labors Will Result In Idling When Finished - Ocean Biome? |
| has duplicate | 0001858 | resolved | Dwarves cant seem to find path right | |
| has duplicate | 0000662 | resolved | Cancels cut gem: needs rough gem (gem exists) |
|
|
Repricated with setting: r wwwwwww w w ... wwwwwww (w- wall, r-ramp) Well basicaly a walled in depot and ramp to go up. Up there when trying to build anything it shows that there is no access but only to east,west and south walls. North builds ok. |
|
|
Adding to this, i created a down stairway on z level 1, and a proper connecting up stairway on zlevel -1. The dwarves build it going down, and i eventually sealed the area with a floodgate. dwarves were unable to use the existing stairway to get out or in to mine further. Creating a new path, then walling it back up seemed to fix the problem. |
|
|
I had a similar problem Kitting out a floor for bedrooms, A load of dwarfs were putting in doors. They then couldn't find a way back up the staircase, even though there was nothing between it and them. There were about 5 dwarfs on that floor and they all got "lost" at the same time. Tunnelling out a square fixed it. |
|
|
I had a similar problem when building a water tower above ground. |
|
|
Easily replicated. Built a fort, dug a straight 10z stairway down and started fleshing out my outpost. No issues until now. As soon as I start building a wall(just one side to start, not enclosed) around my entrance pathing goes nuts and most dwarves go to No Job and all progress slows down considerably. Note: Easy to spot with Fisherdwarves. They went from "Fishing" to "No Job" almost at the same time. |
|
|
I had a problem with a miner that would hang out not mining a place very close by. He was one tile northwest of a ramp. I set the ramps to be removed, and being adjacent to them, he did that, once all the ramps were gone he went back to normal. Also, guys tend to get stuck next to constructed walls. Hmm, also happens with statues! weird... |
|
|
Dig a tunnel one Z-level down from the ground, then dig a channel above it, thus: #..# #..# #..# ,,,, ,--, ,,,, and the dwarves will not go past the open space on any Z-level. I noticed this when digging skylights for a fort. Update: I can confirm that saving and loading solves the problem. |
|
|
Saving and loading seems to help sometimes |
|
|
http://i39.tinypic.com/2vvkrhz.png The marked tiles could not be dug at all (Could not find path), nor could any of the walls in the screenshot that would've breached into the cavern itself, while all other interior walls could be dug out. The only other entrance to the cavern would've been the scout tunnel I dug earlier, but it's atleast 10 z-levels from the bottom, thus not a valid route either. Saving and loading didn't help, but I managed to detour this with two ways: 1) Digging one z-level below, then digging a ramp up into the cavern (even then there was few cancellations due to no path). Digging stairs up to the cavern didn't work. 2) Simply digging right, to the exact same cavern. The wall could be breached from there. And once there was a hole there, the miners could dig out the marked tiles, by walking around in the cavern. Didn't try removing ramps and replacing them with stairs, however. The save is now long gone so I can't test it out. What I did try, was to dig the scout tunnel down to the cavern, but it failed too once I was placing the last part of stairs to the cavern floor (Could not find path) |
|
|
http://www.bay12games.com/dwarves/mantisbt/view.php?id=166 seems to be at least related if not the same problem. Apologies for duplicating (searched for the wrong keywords it seems) |
|
|
I think I know what causes this: There seems to be a system that caches paths to save processor power. This is hinted by the following experiment: Dig a long, narrow hallway, with only one exit. Build a wall somewhere in the center, and make sure the dwarf builds it so that he gets stuck behind the wall. Then remove the wall. He will still think that the wall is there (although it is not), and thus refuse to move out of the hallway, and will stay there until he starves to death. Now that the dwarf is stuck there, save your game, and then load it back up. He will happily move out of the aisle. I bet this is because saving and loading resets this "path caching". |
|
|
I think there's more than one pathing issue going on, although your case for caching does sound plausible seeing as some of the issues can be resolved by a save/load. |
|
|
0000222 is the only one I've been able to partially confirm, pathing through mechanisms does have problems. |
|
|
Actually, I think this should be kicked up to major importance. Routine breaks in pathing ruin Fortress mode entirely, and it seems to come up quite a lot. |
|
|
Ran into an oddity this morning. Don't know how reproduceable it is, so will document fully here. Loaded game. In the freshly-loaded game, I have a corridor and room that looks like this: #..# #..######### #..#.......# #..#.......# #..#.......# #..#.......# #..........# #..#.......# #..#.......# #..######### #..# [Editor's note: I hate proportional fonts! paste in notepad to see properly - VERY simple design] In the room there was a bunch of waste stone that I designated to be dumped. As there was no stone in the doorway, I designated a door to be built immediately. 1. A swarm of dwarves departs for the dump jobs. 2. A long dwarf grab a door and slaps it in the open space. 3. IMMEDIATELY all the dwarves who had just picked up stones 'cancels Dump: Drop-off Inaccessible' 4. Followed by 'cancels Drink: Could not find path.' 5. The pathing issues continued until I designated the door to be deconstructed. Immediately after being *designated* everyone resumed normal pathing. *The door had not been removed yet.* 6. The door was then deconstructed as normal and stored in the stockpile. 7. Was able to reliably reproduce this issue by fully deconstructing the door and building a new one there. 8. Was able to eliminate the pathing issue by designating for deconstructing, letting a single tick elapse, then stopping the removal. 9. Was *still* able to reliably reproduce this issue by fully deconstructing the door and building a new one there. |
|
|
I think I agree with this caching theory. Changing the path by digging a new path and walling off the old path seems to create problems consistently. I am fairly certain it is not the only pathing problem however. |
|
|
dig a five by five room, build a wall across half of it, making sure the dwarves have access to the bottom half of the room (closest to the bottom of the screen) ------ l*****l l*****l l------l l*****l l**x**l l*****l ------ * = empty stone floor. x = up/down stair. l and _ are the walls. Tell the dwarves to remove the constructed wall, and they will cancel the task because they cannot get to the top of the room and remove it from there, even though they can directly acces the wall from the bottom of the room. |
|
|
I have had numerous path issues as well: * = hallway _ = open pit (dig a channel, then go underneath and get rid of the up ramp) X = desired location of a floodgate to cable up a Mechanism to a lever D = dwarf ****X****** * ****** * ****** *_*****D In this case the job to attach the floodgate to a lever fails and is canceled because the dwarf cant find a path to the gate. I experimented and added a floor over the pit and then of course the dwarf went 'behind' the gate and installed the mechanism. In another case I have had dwarves fail to find a path to build a workshop. |
|
|
My dorfs don't want to cross the river to start mining or chopping trees, despite a large bridge and many floors covering the gap. |
|
|
How I ran across the problem : (1) Take large, flat area. Designate a large, solid rectangle to be Channeled by your miners. One or more of them will probably get stuck on a ramp. (2) Dug an up-down stairway. On the levels above it (above ground), I -constructed- up-down stairways. Dwarves treated the path as partially invalid -- leading to a situation where dwarves could get into my tower with ease, but could not thenceforth escape. Might be hard to reproduce. As reported by others, however; I find the problem fixes itself when I save/load the game. ... However, as my population rises, I need to do this more and more frequently. Large-population forts become problematic. |
|
|
Here's how I reproduced pathing problems where valid paths get lost until reload: 1. Embark on a flat site with lots of picks 2. Set everyone to mining 3. Designating the border of a large square to be channelled (i.e. you're digging a moat) Watch as idlers drops to 0, then gradually comes back up to 7 as dwarfs get stuck. I usually only get about 1/3 of a 50x50 moat done before everyone has stopped. Then save/reload and watch them all wake up again. |
|
|
I was trying to dig down to a cluster of gems in the caverns via staircases in a pillar of rock. At the bottom, the miners would consistently cancel it with a message of "Could not find path" even though there was nothing there that should have been blocking them from carving the staircase. |
|
|
If this is going to be the bug repot that all the duplicates get refered too, should it really not be a major, not a minor? As I mentioned in the forum post, easy enough to get reproducable pathing errors. I found I imediatly started getting problems as soon as I tried to seal off part of the map. Originally, I had a locked door at my fort entrance and noticed the problem seemed to go away when it was unlocked. So I replaced it by just a plain wall, thinking it was a problem with trying to path through locked doors, but the problem persisted. Also confirmed that channels have the same effect. The actual effect is that the tiles around any construction site or dig site act like a sealed space when the construction is completed or the square dug out. This includes workshops. Dwarves will still try and path through this 'zone' but will cancel their job with the inaccessable message. Dwarves in the 'zone' can only access materials within it (if you try and build a wall, you can see the available materials change as you move the cursor over the zone), but will still send job cancelation messages as they try to path to items outside it. |
|
|
Seconding the 'cache' observation, with some added notes: This problem will, after a time, resolve itself. Dwarfs will eventually find new paths to use and relearn the map, but a considerable span of seconds to minutes might pass before this happens. The heuristic map used by the game to build pathways is apparently updated in real time (as per the door experiment) at least part of the time, but other times paths are built and rebuilt very slowly, such as with the wall experiments above. The dwarfs won't even consider other paths to be available, almost as though the whole map is set to restricted-level traffic by default. Assuming that this theory is correct, it brings to light three problems that the people in this thread (and myself) have observed. One, doors shouldn't appear to be impassible. In fact, unless they're locked, they shouldn't have any impact on an existing path at all. Two, the game builds new paths far too slowly now. The gap between 'thinking' and dwarfs actually using pathways was noticeable in the old release but usually quite brief; but now the wait is problematic, and sometimes indefinite. Finally, some events apparently don't update the heuristic map in real time, if they update it at all. Wall removal and other deconstruction events should immediately open up paths that were previously obstructed - something that happens when the game is restarted (thus rebuilding the working heuristic map) or after an often lengthy wait time of path rebuilding. With the total overhaul path-finding got in this release, issues like this can be expected. |
|
|
I've seen this using the "pillar of up/down staircases then channel" technique to hollow out large areas. In my experience this is trivial to reproduce with multiple miners working at once in this way. I'd also echo the request by Zeg that this be major, it's actually a game breaking bug even if it does have the lengthy workaround of restarting. |
|
|
Just wanted to add too that I get pathfinding bugs a lot near stockpiles, a dwarf having just grabbed or dropped something at stockpiles will "dance" back and forth with no job until they finally break out of it for some reason. Don't know if there's anything else I can do to test further to help out. |
|
|
Just wanted to say that I'm seeing this issue, too. Severity should definitely be higher since this has broken fortress mode for me and apparently lots of others. I'm running dwarf fortress with wine on Linux. |
|
|
I updated the severity field, but people shouldn't put too much stock in that anyway -- I don't know how much attention Toady will pay to it unless it says "crash." |
|
|
For what it's worth, here's a corresponding thread in the bug forum -- http://www.bay12games.com/forum/index.php?topic=52003.0 Interestingly, one of the people in the thread suggests locking and unlocking a door -- and says that kick-starts pathing, just as effectively as a save/load does. And, several others piped up saying that method worked. Temporary workarounds for the win! |
|
|
I seem to have found one reliable way to get a dwarf stuck using a burrow I listed it out as a new topic in 0000733 to describe it fully. |
|
|
o.O! I can verify that the locking/unlocking door works. Actually, I can verify that /locking/, specifically, works. Unlocking does not appear to do anything. Second: I have a reliable reproduction with very interesting behavior! 1. Dig your first burrow downwards, quarters, etc. 2. Dig a channel filled with water, so it is impassable. 3. Build a drawbridge across it and hook it up to a lever. 4. Attempt to build a wall next to the moat. Wall production proceeds fine. 5. Pull the lever and raise the drawbridge. PATHING ISSUES! 6. Pull the lever and lower the drawbridge. No pathing issues. 7. Repeat 5-6 indefinitely. It seems to have something to do with a path *existing* that can reach the outside of the map. |
|
|
I can also confirm that locking a door resolves the issue, so hopefully that will lead to an easy fix. |
|
|
Door trick works for me. BUT.... ...the trick does not make the game actually playable. On all 3 of my fortresses this only fixes the problem for around 40 seconds. I don't know what I am doing differently than those who seem to be able to play, but mining is impossible for me. When mining inside the fortress dwarves can only do 4 blocks or so apiece before stopping again. OTOH they can mine large areas outside with no ill effect for perhaps 5 minutes. |
|
|
This is a very severe problem on my map. But I found that saving and then continuing the save gets the dwarves going, so if you're having severe issues like I am this might help you. But you will need to do this quite often unfortunately. |
|
|
I tried the channel/wall reproducibility methods from this thread and from 0000070 as well, using the released 0.31.02 zip, and I can't get anything bad to happen. Obviously something is going on, but I'm having trouble getting it to show up. |
|
|
I have a crazy theory. I'm beginning to think that some of our pathfinding bugs may not actually be pathfinding bugs at all. in 0000733 I found a reliable way to get dwarves "stuck" by assigning them to a burrow mid-task. I however, don't think this is actually a bug in burrows so much as a flaw in the new dwarven work ethic (0000008) which many of us have been complaining about. This new behavior is not allowing the burrow to interrupt an assigned task which results in the dwarf finishing his task and then sitting down to take a nap wherever he happens to be. While the burrow is an easy way to illustrate this, it's quite possible this occurs when other jobs try to interrupt a task as well. if that is the case, it could explain a lot of our problems. |
|
|
This sounds like an impossible bug to really get to you, Toady, because it seems that saving and loading fixes it. As such, uploading a save doesn't have much of a use. Please see my report here - 0000891 for a save with a similar yet probably slightly different problem. It has to do with new HFS becoming eternally stuck in a 1 tile hallway. I imagine it's related to all the pathing bug woes. |
|
|
Toady, whatever pathfinding code is being called the instant a door becomes locked is the code we want to run whenever the rest of the map changes, especially regarding constructions and digging. It should not run 30 seconds later, like it seems to be doing now. Also, has anyone noticed if the Alt key is bound to something? I switch from the game often but am hoping I'm not making things worse somehow with my alt-tab combination. |
|
|
I think one of the key components for reproducibility is that you do the digging near the dwarven idle traffic areas. It seems to be worst when you are doing a complex pattern of mining right near the meeting area. Only takes seconds to re-break each time. I have a fortress based on a pattern of interconnecting X's with diagonal shafts, the dining room in the center. It rebreaks after 4 tiles are mined from the ends of any spoke. also, perhaps it is a timing problem with scheduling the updates to pathfinding. Many of the posters have mentioned that they had very fast machines. I for one have about the fastest i7 based machine available. |
|
|
Psithief, I can't run that code at every change or the game would grind to a halt. There are other functions that handle situations like digging that run faster, and they are working here in the situations I've tried. There's obviously some situation or configuration that is messing things up, but I haven't seen it yet. |
|
|
Try building a long (like 20 tiles or so) wall. Every time a dwarf finishes one tile of it, it gets stuck next to it. There seem to be some updates every few moments that unstuck all dwarves. But they only happen every 5 minutes or so (at least in my 20-30 FPS game), while my dwarves are idle during that time. This makes every above-ground construction a real pain to build. |
|
|
I didn't have this problem until I designated a multiple-level burrow. Removing the burrow fixed the pathing problems some dwarves were having. |
|
|
It doesn't seem to be related. I tried deleting all burrows. Then observed a few dwarves building a wall. They have like 50% chance of getting stuck next to the wall every time they build it. |
|
|
I've witnessed a variety of pathfinding bugs over the course of maybe 20 forts, but also can't pin down a specific cause. The following should be considered somewhat anecdotal until I can pin down a way to replicate the problem (I've been trying to avoid it, not replicate it). The big problem I've had (which this comment relates to) manifests as a dwarf constructing one piece of a construction and then getting 'confused'. The same thing Rafal is talking about I think. The dwarf will sit still until pathing updates, apparently not being able to path _anywhere_ at all (he will even go to sleep on the spot even if a bed is 10 squares away). He will be listed as No Job. He will cancel constructing other bits of construction because he can't reach them. You sometimes get job cancellation spam when the problem starts to occur (cannot reach site). I tend to play on completely flat embarks (usually 3x3 or 4x4), often making only minimal forays into the caverns below. On some of these embarks, the pathing problems manifest. On some of them, they don't. This is with pretty much the same castle design (an above ground fort - big square of walls) every time. The problems seem to manifest more frequently on larger embarks. The problems seem to manifest more if you start doing things underground. The problems seem to manifest more if you construct updown stairs or ramps, especially if you're building them downwards. Again, all very anecdotal - but I've made a lot of forts. Could it somehow be related to some underground features (even if the caverns have not been breached?). That might explain why it occurs immediately on some maps but not on others. Once the problem starts occurring on a map, that game is basically a write-off from that point on. It doesn't 'fix' itself later - you can only mitigate the problem using door locking/unlocking or save/reload. |
|
|
I have seen pathing bugs (Once when I got miners stuck, another when I built a workshop in a frequently used hallway) and I have yet to designate a burrow in my fort. I don't think it's burrow related. |
|
|
I've addressed what should be the main cause of these problems (see comments in 0000070), but I doubt I've handled every single pathing issue that's been reported. It's difficult to say what I should do with those reports now. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-04-01 14:42 | DoctorZuber | New Issue | |
| 2010-04-01 15:22 | warmist | Note Added: 0000021 | |
| 2010-04-01 17:37 | ercdvs | Note Added: 0000042 | |
| 2010-04-02 01:42 | st0rmforce | Note Added: 0000146 | |
| 2010-04-02 01:43 | immibis | Note Added: 0000147 | |
| 2010-04-02 05:52 | Todestool | Tag Attached: pathfinding | |
| 2010-04-02 11:02 | Retro42 | Note Added: 0000235 | |
| 2010-04-02 13:54 | axus | Note Added: 0000283 | |
| 2010-04-02 15:15 | axus | Note Edited: 0000283 | |
| 2010-04-02 15:26 | exottoyuhr | Note Added: 0000305 | |
| 2010-04-02 15:32 | warmist | Note Added: 0000307 | |
| 2010-04-02 15:33 | exottoyuhr | Note Edited: 0000305 | |
| 2010-04-02 15:44 | axus | Note Edited: 0000283 | |
| 2010-04-03 07:31 | Kaguya | Note Added: 0000502 | |
| 2010-04-03 07:32 | Kaguya | Note Edited: 0000502 | |
| 2010-04-03 07:39 | alphafalcon | Note Added: 0000504 | |
| 2010-04-03 07:46 |
|
Category | General => Pathfinding |
| 2010-04-03 08:43 |
|
Relationship added | has duplicate 0000062 |
| 2010-04-03 08:49 |
|
Relationship added | parent of 0000070 |
| 2010-04-03 09:04 |
|
Relationship added | has duplicate 0000164 |
| 2010-04-03 09:15 |
|
Relationship added | has duplicate 0000104 |
| 2010-04-03 09:30 |
|
Relationship added | has duplicate 0000128 |
| 2010-04-03 09:31 |
|
Relationship added | parent of 0000166 |
| 2010-04-03 09:46 |
|
Relationship added | has duplicate 0000137 |
| 2010-04-03 09:48 |
|
Relationship added | parent of 0000140 |
| 2010-04-03 11:05 |
|
Relationship added | parent of 0000176 |
| 2010-04-03 11:07 | burneddi | Note Added: 0000588 | |
| 2010-04-03 11:11 | DoctorZuber | Note Added: 0000590 | |
| 2010-04-03 11:12 |
|
Relationship added | parent of 0000198 |
| 2010-04-03 11:14 | DoctorZuber | Note Added: 0000592 | |
| 2010-04-03 11:23 |
|
Relationship added | parent of 0000225 |
| 2010-04-03 11:29 |
|
Relationship added | related to 0000235 |
| 2010-04-03 15:23 | ZeroGravitas | Note Added: 0000684 | |
| 2010-04-03 15:29 | savanik | Note Added: 0000686 | |
| 2010-04-03 15:29 | savanik | Note Edited: 0000686 | |
| 2010-04-03 15:43 |
|
Relationship added | parent of 0000317 |
| 2010-04-03 15:55 | DoctorZuber | Note Added: 0000696 | |
| 2010-04-03 16:03 | king doom | Note Added: 0000698 | |
| 2010-04-03 18:45 | petitsourice | Note Added: 0000740 | |
| 2010-04-03 19:38 |
|
Relationship added | has duplicate 0000341 |
| 2010-04-03 20:01 |
|
Relationship added | has duplicate 0000345 |
| 2010-04-03 20:04 |
|
Relationship added | has duplicate 0000320 |
| 2010-04-03 20:37 |
|
Relationship added | parent of 0000346 |
| 2010-04-04 08:39 | king doom | Note Edited: 0000698 | |
| 2010-04-04 08:39 | king doom | Note Edited: 0000698 | |
| 2010-04-04 08:40 | king doom | Note Edited: 0000698 | |
| 2010-04-04 13:44 |
|
Relationship added | parent of 0000372 |
| 2010-04-04 13:44 |
|
Relationship added | parent of 0000262 |
| 2010-04-04 21:18 | jeebussez | Note Added: 0000997 | |
| 2010-04-04 21:50 | Wirrit | Note Added: 0000998 | |
| 2010-04-05 03:42 | oliver | Note Added: 0001044 | |
| 2010-04-05 13:15 |
|
Relationship deleted | parent of 0000262 |
| 2010-04-05 20:04 |
|
Relationship added | has duplicate 0000554 |
| 2010-04-05 20:23 | InsanityPrelude | Note Added: 0001323 | |
| 2010-04-05 22:20 |
|
Relationship added | parent of 0000529 |
| 2010-04-05 23:02 |
|
Relationship deleted | parent of 0000372 |
| 2010-04-06 06:14 | Zeg | Note Added: 0001410 | |
| 2010-04-06 06:15 | Zeg | Note Edited: 0001410 | |
| 2010-04-06 09:04 |
|
Relationship added | has duplicate 0000602 |
| 2010-04-06 10:19 |
|
Relationship added | parent of 0000635 |
| 2010-04-06 10:50 |
|
Relationship added | parent of 0000623 |
| 2010-04-06 12:46 |
|
Sticky Issue | No => Yes |
| 2010-04-06 12:49 |
|
Summary | Pathing issues? => Pathfinding fails to update after map changes |
| 2010-04-06 14:27 | CaptainFailmore | Note Added: 0001582 | |
| 2010-04-06 14:29 | CaptainFailmore | Note Edited: 0001582 | |
| 2010-04-06 14:59 | Symmetry | Note Added: 0001595 | |
| 2010-04-06 15:14 | KaelGotRice | Note Added: 0001600 | |
| 2010-04-06 17:37 | felzix | Note Added: 0001621 | |
| 2010-04-06 18:30 |
|
Relationship added | has duplicate 0000677 |
| 2010-04-06 22:41 |
|
Relationship added | parent of 0000690 |
| 2010-04-06 22:47 |
|
Severity | minor => major |
| 2010-04-06 22:48 |
|
Note Added: 0001683 | |
| 2010-04-07 09:25 | Wirrit | Note Added: 0001758 | |
| 2010-04-07 10:44 |
|
Relationship added | parent of 0000559 |
| 2010-04-07 13:24 | DoctorZuber | Note Added: 0001833 | |
| 2010-04-08 00:19 |
|
Relationship added | parent of 0000769 |
| 2010-04-08 00:21 |
|
Relationship added | parent of 0000776 |
| 2010-04-08 14:16 |
|
Relationship added | parent of 0000820 |
| 2010-04-08 21:11 | savanik | Note Added: 0002251 | |
| 2010-04-09 11:39 | martin | Note Added: 0002368 | |
| 2010-04-09 13:50 | darkfred | Note Added: 0002419 | |
| 2010-04-09 17:39 |
|
Relationship added | parent of 0000901 |
| 2010-04-10 17:49 | teethering | Note Added: 0002681 | |
| 2010-04-11 00:48 |
|
Relationship added | parent of 0000984 |
| 2010-04-11 02:24 |
|
Relationship added | parent of 0000990 |
| 2010-04-11 03:17 | Toady One | Note Added: 0002767 | |
| 2010-04-11 03:17 | Toady One | Assigned To | => Toady One |
| 2010-04-11 03:17 | Toady One | Status | new => acknowledged |
| 2010-04-11 03:17 | Toady One | Note Edited: 0002767 | |
| 2010-04-11 04:05 | DoctorZuber | Note Added: 0002776 | |
| 2010-04-11 04:06 | DoctorZuber | Note Edited: 0002776 | |
| 2010-04-11 07:24 | SirPenguin | Note Added: 0002795 | |
| 2010-04-11 07:43 |
|
Note Added: 0002798 | |
| 2010-04-11 08:24 |
|
Note Edited: 0002798 | |
| 2010-04-11 10:09 |
|
Relationship added | parent of 0000997 |
| 2010-04-11 10:19 |
|
Relationship added | parent of 0001005 |
| 2010-04-11 10:37 | darkfred | Note Added: 0002832 | |
| 2010-04-11 13:48 | DoctorZuber | Note Edited: 0002776 | |
| 2010-04-11 15:56 |
|
Relationship deleted | parent of 0000166 |
| 2010-04-11 17:11 | Toady One | Note Added: 0002907 | |
| 2010-04-11 17:22 | Rafal99 | Note Added: 0002909 | |
| 2010-04-11 17:27 | Markham | Note Added: 0002911 | |
| 2010-04-11 17:46 | Rafal99 | Note Added: 0002921 | |
| 2010-04-11 18:04 | ItchyBeard | Note Added: 0002922 | |
| 2010-04-11 18:07 | Toaster | Note Added: 0002924 | |
| 2010-04-11 18:21 | Toady One | Note Added: 0002929 | |
| 2010-04-11 18:21 | Toady One | Status | acknowledged => resolved |
| 2010-04-11 18:21 | Toady One | Fixed in Version | => 0.31.03 |
| 2010-04-11 18:21 | Toady One | Resolution | open => fixed |
| 2010-04-12 12:26 |
|
Relationship replaced | related to 0000140 |
| 2010-04-12 12:27 |
|
Relationship deleted | related to 0000235 |
| 2010-04-12 12:43 |
|
Relationship added | parent of 0000103 |
| 2010-04-12 12:49 |
|
Relationship replaced | related to 0000198 |
| 2010-04-12 12:49 |
|
Relationship replaced | related to 0000690 |
| 2010-04-12 12:49 |
|
Relationship replaced | related to 0000820 |
| 2010-04-12 12:49 |
|
Relationship replaced | related to 0000997 |
| 2010-04-12 12:50 |
|
Relationship deleted | related to 0000140 |
| 2010-04-12 12:50 |
|
Relationship added | related to 0000140 |
| 2010-04-13 09:01 |
|
Relationship replaced | has duplicate 0000198 |
| 2010-04-13 12:28 |
|
Relationship added | has duplicate 0001095 |
| 2010-04-14 20:31 |
|
Relationship added | has duplicate 0000816 |
| 2010-04-16 09:08 |
|
Relationship added | has duplicate 0001217 |
| 2010-04-18 19:09 |
|
Relationship added | has duplicate 0001152 |
| 2010-04-20 19:34 |
|
Relationship added | has duplicate 0001019 |
| 2010-04-26 17:27 |
|
Relationship replaced | has duplicate 0000997 |
| 2010-04-30 06:16 | Logical2u | Relationship added | related to 0001651 |
| 2010-04-30 14:36 | Logical2u | Relationship replaced | has duplicate 0001651 |
| 2010-06-02 13:07 |
|
Sticky Issue | Yes => No |
| 2010-06-09 06:45 | Toady One | Status | resolved => closed |
| 2010-07-16 09:06 |
|
Relationship added | has duplicate 0001858 |
| 2010-07-20 09:09 |
|
Relationship added | has duplicate 0000662 |
| 2012-05-20 14:55 |
|
Relationship replaced | has duplicate 0000690 |
