- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
Difference between revisions of "v0.31 Talk:Activity zone"
Mason11987 (talk | contribs) |
|||
Line 6: | Line 6: | ||
--[[User:Altaree|Altaree]] 14:12, 9 April 2010 (UTC) | --[[User:Altaree|Altaree]] 14:12, 9 April 2010 (UTC) | ||
:When you are at the activity zone definition/selection state (right after hitting the Zones key from the main menu), you will see a key listed as "rectangle" (default "e") on the menu. Pressing that key toggles between three zone creation states: "rectangle" (the default, you set one corner of a rectangle and then the other), "flow" (you select a location and the area is "filled" with the activity zone, just like defining a room, and can be expanded and contracted the same way), and "floor flow" (not sure what the difference between it and "flow" is, anyone else done any testing?). I'm guessing zones don't become a simple property of the map squares where you defined the zone, like stock(p)iles and (d)esignations do. Instead the way you defined the zone is saved, and the area it occupies is re-calculated with every frame, after the zone menu is closed and play resumes. So a "flow-style" activity zone would be one that was originally defined using the "flow" method, and a large one could cause a performance hit at least, simply because its borders need to be recalculated from the definition every frame, which can get pretty complicated for some convoluted fortress designs. --[[Special:Contributions/66.190.120.90|66.190.120.90]] 15:45, 1 May 2010 (UTC) | :When you are at the activity zone definition/selection state (right after hitting the Zones key from the main menu), you will see a key listed as "rectangle" (default "e") on the menu. Pressing that key toggles between three zone creation states: "rectangle" (the default, you set one corner of a rectangle and then the other), "flow" (you select a location and the area is "filled" with the activity zone, just like defining a room, and can be expanded and contracted the same way), and "floor flow" (not sure what the difference between it and "flow" is, anyone else done any testing?). I'm guessing zones don't become a simple property of the map squares where you defined the zone, like stock(p)iles and (d)esignations do. Instead the way you defined the zone is saved, and the area it occupies is re-calculated with every frame, after the zone menu is closed and play resumes. So a "flow-style" activity zone would be one that was originally defined using the "flow" method, and a large one could cause a performance hit at least, simply because its borders need to be recalculated from the definition every frame, which can get pretty complicated for some convoluted fortress designs. --[[Special:Contributions/66.190.120.90|66.190.120.90]] 15:45, 1 May 2010 (UTC) | ||
+ | ::Flow will include but not pass through walls, floor flow will not include walls. I've had this crash several times, glad it's fixed. [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 11:52, 24 May 2010 (UTC) | ||
==Zone-canceling crash== | ==Zone-canceling crash== |
Revision as of 11:52, 24 May 2010
Flow-stylee activity zones?
Does anyone know what this comment in the 0.31.02 changelog at [1] means:
- fixed crash from doing a large flow-style activity zone
What is a flow-style activity zone? --Altaree 14:12, 9 April 2010 (UTC)
- When you are at the activity zone definition/selection state (right after hitting the Zones key from the main menu), you will see a key listed as "rectangle" (default "e") on the menu. Pressing that key toggles between three zone creation states: "rectangle" (the default, you set one corner of a rectangle and then the other), "flow" (you select a location and the area is "filled" with the activity zone, just like defining a room, and can be expanded and contracted the same way), and "floor flow" (not sure what the difference between it and "flow" is, anyone else done any testing?). I'm guessing zones don't become a simple property of the map squares where you defined the zone, like stock(p)iles and (d)esignations do. Instead the way you defined the zone is saved, and the area it occupies is re-calculated with every frame, after the zone menu is closed and play resumes. So a "flow-style" activity zone would be one that was originally defined using the "flow" method, and a large one could cause a performance hit at least, simply because its borders need to be recalculated from the definition every frame, which can get pretty complicated for some convoluted fortress designs. --66.190.120.90 15:45, 1 May 2010 (UTC)
Zone-canceling crash
It seems that whenever I cancel a zone while I am still placing it, the game crashes. It's pretty easily avoidable(finish building it, then delete it), but still annoying. Is this happening to anyone else?--Pvt. Miller 21:51, 15 April 2010 (UTC)
- I can confirm this, happens to me every time. It's a bummer.
Failure to dump items
I have a dozen clothing items on the ground marked for dumping that aren't being dumped. They're not on top of a stockpile, "gather refuse from outside" is turned ON, the items are not forbidden, I have a garbage dump zone AND refuse pile, and dwarves have refuse hauling enabled. I have many idlers. Stone from within my fortress gets dumped, but these clothing items do not. What gives? --208.81.12.34 14:12, 30 April 2010 (UTC)
Sounds like the items are owned. Owned items cannot be dumped. Only the owning dwarf can move them. View the item, and see if it lists an owner. If so, the only way to get them moved is to give the dwarf their own room (bedroom is good), and place a cabinet into that room. The dwarf will eventually grab up their discarded clothes and place them into the cabinet. --Darkstar 17:11, 5 May 2010 (UTC)
I have a similar problem, though the item in question is a random stone, and I have double-checked it is not owned.
Dwarves will also frequently drop food while carrying it somewhere to eat, and it can never be moved again if this happens. Apparently something in the ownership tags gets screwed up, so the food ends up owned by a null "nobody" dwarf that prevents removal of the food by any dwarf, including the one that dropped the food. My trade depot is currently full of miasma due to these unmovable dropped meals. Turning off all jobs except "refuse hauling" only leaves the dwarves that own the food standing around with "No Job." --Tatterdemalian 03:10, 24 May 2010 (UTC)