0000018: Pathfinding fails to update after map changes

Notes
(0000021) warmist (reporter) 2010-04-01 15:22	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.

(0000042) ercdvs (reporter) 2010-04-01 17:37	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.

(0000146) st0rmforce (reporter) 2010-04-02 01:42	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.

(0000147) immibis (reporter) 2010-04-02 01:43	I had a similar problem when building a water tower above ground.

(0000235) Retro42 (reporter) 2010-04-02 11:02	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.

(0000283) axus (reporter) 2010-04-02 13:54 edited on: 2010-04-02 15:44	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...

(0000305) exottoyuhr (reporter) 2010-04-02 15:26 edited on: 2010-04-02 15:33	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.

(0000307) warmist (reporter) 2010-04-02 15:32	Saving and loading seems to help sometimes

(0000502) Kaguya (reporter) 2010-04-03 07:31 edited on: 2010-04-03 07:32	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)

(0000504) alphafalcon (reporter) 2010-04-03 07:39	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)

(0000588) burneddi (reporter) 2010-04-03 11:07	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".

(0000590) DoctorZuber (reporter) 2010-04-03 11:11	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.

(0000592) DoctorZuber (reporter) 2010-04-03 11:14	0000222 is the only one I've been able to partially confirm, pathing through mechanisms does have problems.

(0000684) ZeroGravitas (reporter) 2010-04-03 15:23	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.

(0000686) savanik (reporter) 2010-04-03 15:29 edited on: 2010-04-03 15:29	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.

(0000696) DoctorZuber (reporter) 2010-04-03 15:55	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.

(0000698) king doom (reporter) 2010-04-03 16:03 edited on: 2010-04-04 08:40	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 lxl 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.

(0000740) petitsourice (reporter) 2010-04-03 18:45	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.

(0000997) jeebussez (reporter) 2010-04-04 21:18	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.

(0000998) Wirrit (reporter) 2010-04-04 21:50	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.

(0001044) oliver (reporter) 2010-04-05 03:42	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.

(0001323) InsanityPrelude (reporter) 2010-04-05 20:23	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.

(0001410) Zeg (reporter) 2010-04-06 06:14 edited on: 2010-04-06 06:15	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.

(0001582) CaptainFailmore (reporter) 2010-04-06 14:27 edited on: 2010-04-06 14:29	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.

(0001595) Symmetry (reporter) 2010-04-06 14:59	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.

(0001600) KaelGotRice (reporter) 2010-04-06 15:14	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.

(0001621) felzix (reporter) 2010-04-06 17:37	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.

(0001683) Footkerchief (manager) 2010-04-06 22:48	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."

(0001758) Wirrit (reporter) 2010-04-07 09:25	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!

(0001833) DoctorZuber (reporter) 2010-04-07 13:24	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.

(0002251) savanik (reporter) 2010-04-08 21:11	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.

(0002368) martin (reporter) 2010-04-09 11:39	I can also confirm that locking a door resolves the issue, so hopefully that will lead to an easy fix.

(0002419) darkfred (reporter) 2010-04-09 13:50	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.

(0002681) teethering (reporter) 2010-04-10 17:49	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.

(0002767) Toady One (administrator) 2010-04-11 03:17 edited on: 2010-04-11 03:17	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.

(0002776) DoctorZuber (reporter) 2010-04-11 04:05 edited on: 2010-04-11 13:48	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.

(0002795) SirPenguin (reporter) 2010-04-11 07:24	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.

(0002798) user891 2010-04-11 07:43 edited on: 2010-04-11 08:24	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.

(0002832) darkfred (reporter) 2010-04-11 10:37	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.

(0002907) Toady One (administrator) 2010-04-11 17:11	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.

(0002909) Rafal99 (reporter) 2010-04-11 17:22	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.

(0002911) Markham (reporter) 2010-04-11 17:27	I didn't have this problem until I designated a multiple-level burrow. Removing the burrow fixed the pathing problems some dwarves were having.

(0002921) Rafal99 (reporter) 2010-04-11 17:46	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.

(0002922) ItchyBeard (reporter) 2010-04-11 18:04	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.

(0002924) Toaster (reporter) 2010-04-11 18:07	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.

(0002929) Toady One (administrator) 2010-04-11 18:21	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.

Issue History
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 15:52	muckypup	Issue Monitored: muckypup
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	View Revisions
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	View Revisions
2010-04-02 15:44	axus	Note Edited: 0000283	View Revisions
2010-04-03 05:28	warmist	Issue Monitored: warmist
2010-04-03 07:21	Kaguya	Issue Monitored: Kaguya
2010-04-03 07:21	Kaguya	Issue End Monitor: Kaguya
2010-04-03 07:31	Kaguya	Note Added: 0000502
2010-04-03 07:32	Kaguya	Note Edited: 0000502	View Revisions
2010-04-03 07:39	alphafalcon	Note Added: 0000504
2010-04-03 07:46	Footkerchief	Category	General => Pathfinding
2010-04-03 08:43	Footkerchief	Relationship added	has duplicate 0000062
2010-04-03 08:49	Footkerchief	Relationship added	parent of 0000070
2010-04-03 09:04	Footkerchief	Relationship added	has duplicate 0000164
2010-04-03 09:15	Footkerchief	Relationship added	has duplicate 0000104
2010-04-03 09:30	Footkerchief	Relationship added	has duplicate 0000128
2010-04-03 09:31	Footkerchief	Relationship added	parent of 0000166
2010-04-03 09:46	Footkerchief	Relationship added	has duplicate 0000137
2010-04-03 09:48	Footkerchief	Relationship added	parent of 0000140
2010-04-03 11:05	Footkerchief	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	Footkerchief	Relationship added	parent of 0000198
2010-04-03 11:14	DoctorZuber	Note Added: 0000592
2010-04-03 11:23	Footkerchief	Relationship added	parent of 0000225
2010-04-03 11:29	Footkerchief	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	View Revisions
2010-04-03 15:43	Footkerchief	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:36	chuzzum	Issue Monitored: chuzzum
2010-04-03 18:45	petitsourice	Note Added: 0000740
2010-04-03 19:38	Footkerchief	Relationship added	has duplicate 0000341
2010-04-03 20:01	Footkerchief	Relationship added	has duplicate 0000345
2010-04-03 20:04	Footkerchief	Relationship added	has duplicate 0000320
2010-04-03 20:37	Footkerchief	Relationship added	parent of 0000346
2010-04-04 08:39	king doom	Note Edited: 0000698	View Revisions
2010-04-04 08:39	king doom	Note Edited: 0000698	View Revisions
2010-04-04 08:40	king doom	Note Edited: 0000698	View Revisions
2010-04-04 13:44	Footkerchief	Relationship added	parent of 0000372
2010-04-04 13:44	Footkerchief	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 07:14	terrenblade	Issue Monitored: terrenblade
2010-04-05 13:15	Footkerchief	Relationship deleted	parent of 0000262
2010-04-05 20:04	Footkerchief	Relationship added	has duplicate 0000554
2010-04-05 20:23	InsanityPrelude	Note Added: 0001323
2010-04-05 22:20	Footkerchief	Relationship added	parent of 0000529
2010-04-05 23:02	Footkerchief	Relationship deleted	parent of 0000372
2010-04-06 06:14	Zeg	Note Added: 0001410
2010-04-06 06:15	Zeg	Note Edited: 0001410	View Revisions
2010-04-06 06:16	Zeg	Issue Monitored: Zeg
2010-04-06 09:04	Footkerchief	Relationship added	has duplicate 0000602
2010-04-06 10:19	Footkerchief	Relationship added	parent of 0000635
2010-04-06 10:50	Footkerchief	Relationship added	parent of 0000623
2010-04-06 12:46	Footkerchief	Sticky Issue	No => Yes
2010-04-06 12:49	Footkerchief	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	View Revisions
2010-04-06 14:59	Symmetry	Note Added: 0001595
2010-04-06 15:14	KaelGotRice	Note Added: 0001600
2010-04-06 17:34	felzix	Issue Monitored: felzix
2010-04-06 17:37	felzix	Note Added: 0001621
2010-04-06 18:30	Footkerchief	Relationship added	has duplicate 0000677
2010-04-06 22:41	Footkerchief	Relationship added	parent of 0000690
2010-04-06 22:47	Footkerchief	Severity	minor => major
2010-04-06 22:48	Footkerchief	Note Added: 0001683
2010-04-07 09:25	Wirrit	Note Added: 0001758
2010-04-07 10:44	Footkerchief	Relationship added	parent of 0000559
2010-04-07 13:24	DoctorZuber	Note Added: 0001833
2010-04-08 00:00	Symmetry	Issue Monitored: Symmetry
2010-04-08 00:19	Footkerchief	Relationship added	parent of 0000769
2010-04-08 00:21	Footkerchief	Relationship added	parent of 0000776
2010-04-08 14:16	Footkerchief	Relationship added	parent of 0000820
2010-04-08 21:11	savanik	Note Added: 0002251
2010-04-09 03:39	Khym Chanur	Issue Monitored: Khym Chanur
2010-04-09 08:57	jarvoll	Issue Monitored: jarvoll
2010-04-09 11:39	martin	Note Added: 0002368
2010-04-09 11:46	darkfred	Issue Monitored: darkfred
2010-04-09 13:50	darkfred	Note Added: 0002419
2010-04-09 17:39	Footkerchief	Relationship added	parent of 0000901
2010-04-10 12:08	mrdudeguy	Issue Monitored: mrdudeguy
2010-04-10 17:49	teethering	Note Added: 0002681
2010-04-10 17:53	teethering	Issue Monitored: teethering
2010-04-11 00:48	Footkerchief	Relationship added	parent of 0000984
2010-04-11 02:24	Footkerchief	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	View Revisions
2010-04-11 04:05	DoctorZuber	Note Added: 0002776
2010-04-11 04:06	DoctorZuber	Note Edited: 0002776	View Revisions
2010-04-11 07:19	bloodystump	Issue Monitored: bloodystump
2010-04-11 07:24	SirPenguin	Note Added: 0002795
2010-04-11 07:43	user891	Note Added: 0002798
2010-04-11 08:24	user891	Note Edited: 0002798	View Revisions
2010-04-11 10:09	Footkerchief	Relationship added	parent of 0000997
2010-04-11 10:19	Footkerchief	Relationship added	parent of 0001005
2010-04-11 10:37	darkfred	Note Added: 0002832
2010-04-11 13:48	DoctorZuber	Note Edited: 0002776	View Revisions
2010-04-11 15:56	Footkerchief	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-11 21:55	bloodystump	Issue End Monitor: bloodystump
2010-04-11 22:20	Khym Chanur	Issue End Monitor: Khym Chanur
2010-04-12 12:26	Footkerchief	Relationship replaced	related to 0000140
2010-04-12 12:27	Footkerchief	Relationship deleted	related to 0000235
2010-04-12 12:43	Footkerchief	Relationship added	parent of 0000103
2010-04-12 12:49	Footkerchief	Relationship replaced	related to 0000198
2010-04-12 12:49	Footkerchief	Relationship replaced	related to 0000690
2010-04-12 12:49	Footkerchief	Relationship replaced	related to 0000820
2010-04-12 12:49	Footkerchief	Relationship replaced	related to 0000997
2010-04-12 12:50	Footkerchief	Relationship deleted	related to 0000140
2010-04-12 12:50	Footkerchief	Relationship added	related to 0000140
2010-04-13 09:01	Footkerchief	Relationship replaced	has duplicate 0000198
2010-04-13 12:28	Footkerchief	Relationship added	has duplicate 0001095
2010-04-14 20:31	Footkerchief	Relationship added	has duplicate 0000816
2010-04-16 09:08	Footkerchief	Relationship added	has duplicate 0001217
2010-04-16 09:08	Footkerchief	Issue Monitored: Footkerchief
2010-04-16 13:57	warmist	Issue End Monitor: warmist
2010-04-18 19:09	Footkerchief	Relationship added	has duplicate 0001152
2010-04-20 19:34	Footkerchief	Relationship added	has duplicate 0001019
2010-04-26 17:27	Footkerchief	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-04-30 14:36	Logical2u	Issue Monitored: Griggs
2010-06-02 13:07	Footkerchief	Sticky Issue	Yes => No
2010-06-09 06:45	Toady One	Status	resolved => closed
2010-07-16 09:06	Footkerchief	Relationship added	has duplicate 0001858
2010-07-20 09:09	Footkerchief	Relationship added	has duplicate 0000662
2012-05-20 14:55	Footkerchief	Relationship replaced	has duplicate 0000690