Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Schmaven]

However it's done, there needs to be a simple, one-step way to dig a staircase across multiple z-levels from the surface.

Why not just use up/down stairs?

That only works underground though. 

[PatrikLundell]

I have battled "spell checking" that sabotages what's written, and even scrambles it again when I've corrected it, all of it silently so you have to scan the text for acts of sabotage.
I've definitely had cases where I've wanted Up/Down stairs in either or both ends because of planned future expansion.

While changing building to draw a 3D "blueprint" and tell the dorfs to go ahead and build it would be convenient, it would require a complete overhaul of the building logic, and that's not done in a week (plus all the bugs that would occur because of weird corner cases. The overseer designating digging or building next to a building site can have interesting effects on the ability to complete what was originally a reasonably straight forward task, for instance, not to mention dorfs who cancel their jobs for various reasons). It also clashes with the DF logic of having the overseer control what's built in terms of materials (but I agree this logic is relaxed when you define e.g. floor segments, as you don't know where the different materials will end up when you've selected 100 blocks of 5 different materials for a 10*10 section).

However it's done, there needs to be a simple, one-step way to dig a staircase across multiple z-levels from the surface.

Why not just use up/down stairs?

That only works underground though. 

No, you can use Up/Down staircases everywhere, as long as you don't mind having critters climb in through the hole at the bottom, and don't mind not being able to put a hatch over the top.

[Bumber]

No, you can use Up/Down staircases everywhere, as long as you don't mind having critters climb in through the hole at the bottom, and don't mind not being able to put a hatch over the top.

I'm pretty sure you can still use hatches on up/down stairs.

[Pillbo]

However it's done, there needs to be a simple, one-step way to dig a staircase across multiple z-levels from the surface.

Why not just use up/down stairs?

I thought that didn't work, but either way it's unintuitive to noobs, which is the point of this thread.  I know people often pick the downstair option when they are just starting and they can't figure out why the dwarves stopped digging right away.  It pisses people off.

No, you can use Up/Down staircases everywhere, as long as you don't mind having critters climb in through the hole at the bottom, and don't mind not being able to put a hatch over the top.

I'm pretty sure you can still use hatches on up/down stairs.

You can but this isn't a thread about how players solve problems with the way things work right now, it's a thread about what gives noobs trouble, and what can be done about it.  Noobs don't know your up/down stairs are leaving holes that can get covered with hatches.

Even if it's something as simple as a smarter 'Continuous staircase' option along with Up, Down and Up/Down. If you want noobs to give the game a chance I seriously think this is a big annoyance that comes up the first few minutes into starting a fort and it legitimately irritates people.

This is a problem whether or not veterans are used to it or prefer it this way.

[Putnam]

how would "continuous staircase" be different from up/down staircases?

[Pillbo]

However it's done, there needs to be a simple, one-step way to dig a staircase across multiple z-levels from the surface.

Why not just use up/down stairs?

I thought that didn't work, but either way it's unintuitive to noobs, which is the point of this thread.  I know people often pick the downstair option when they are just starting and they can't figure out why the dwarves stopped digging right away.  It pisses people off.

Ok just tested it to make sure Up/down staircase from the surface doesn't work. It won't let you designate a tile with that unless its a tile that can be completely mined out.

how would "continuous staircase" be different from up/down staircases?

U/D stairs can't be dug from the surface, a "continuous staircase" or whatever you want to call it would be a downstair from a surface level, U/D for middle levels and just Down for the lowest level designated.

Another option is to make the game understand that designating a U/D from a surface means dig a downstair instead of doing nothing.

Edit- typos

[RNGstrategist]

So like the previous thread I will go a bit into this. In my streams I am constantly letting people know to ask questions about ANYTHING and i will teach them the mechanic if they don't understand how or why i did something. Some of the points will be *features* that make the game less intuitive and others might just be bugs in disguise. That being said though i do not agree with some previous points/requests. Some previously mentioned fixes would require a major revamp to how the game actually works behind the scenes and i fear would be to difficult to fix without introducing new issues. Secondly the Raw difficulty. IF the devs are to make game mechanics just easier please do so on a toggle or slider if at all possible. Dwarf Fortress' main draw is it's complicated yet detailed ways. There have been far too many clones on steam through the years that tried to be Dwarf Fortress but easier. Too easy or simple and there wont be a defining feature.


Mechanics that are working as intended but haven't been experienced in quantity by developers
Werebeasts:
There are way too many of these. On stream alone i have been hit with low to mid hundreds of werewolves over hundreds of hours of play. In the same time i have been hit with 10-18 titans/legendary beasts, 0 vampires, and only tens of forgotten beasts. the were beast mechanic is annoying but makes sense. The only real problem is that you get sent were-beasts like it was a low level scrub. Due to their mechanics they can be more dangerous than rocs, dragons, etc. I get the need to make the game less monotonous but they happen way too much. I think in one of my streams i was in an evil biome next to a Necro tower with goblin neighbors. The elven blood rain made undead camels and i eventually got through. It was the were-(chameleon?,lizard?) that did my base in. I would legit happily stream a fort over a full map aquifer with evil biome rain and effects with nothing but goblins and necromancer to keep me company if it would mean i could get 1 base that didn't deal with were creatures. I am just so burnt out on them. maybe take some of their numbers and throw them at vampires or something. I've only ever seen 2 vampires in my ENTIRE time with dwarf fortress. Again it isn't necessarily a difficulty thing with were creatures but they shouldn't show up as often as my trade caravans do.

Loyalty Cascades:
Like were creatures this happens way too many times. These can happen with no input on your part and you have no recourse to fix them. best case scenario you have this situation where all your dwarves are just terrified of each other and will eventually starve to death running around your stockpile of food but somehow unable to grab any. This i feel is more a bug or symptom, of a different mechanic that is working right. just tone it down. There needs to be a global flag for enemy of the civilization when the dwarf goes crazy or is receiving justice, however temporary.


Mechanics that are not going to be understood by a new player
pathing restrictions:
The high/normal/low/restricted traffic designation. This works if you know what it is doing but does not work how someone new might take it. Currently Restricted only makes a square count as 25 squares for the purposes of path finding. It does not actually restrict travel to that area. If restricted were to be set to an unnecessarily high number by default it would work how new people would assume it works on early game. This would also solve a fair number of Ice complaints as you could now designate an area to avoid properly. If the coding doesnt allow this then a default map wide burrow should handle the same issue where the burrow could have the forbidden areas removed. This can be done in game right now manually but it would be meticulous every time especially for new players.

item claiming:
Correct me if I'm wrong but the entire game does everything backwards. A stockpile for seeds "looks" around for a seed and then requests a dwarf to pick it up and bring it to the dwarf. rather like a cat claiming a dwarf. I say this because if this isn't how it works then I personally don't understand the mechanics for claiming barrels. for example: I have 1 seed barrel and there is a loose seed on a dwarf's plate somewhere. A dwarf gets the command to put the seed in the barrel. Oh no! the dwarf chosen is across the map and 20 z levels down. Until that Dwarf grabs that seed and puts it in the barrel, the farm will not see the barrel when it does its request for a seed to be planted. Assuming i am right about how the mechanic works behind the scenes. The Barrel/bins/containers need to do 2 requests. a soft and a Hard. The soft request would be that the seed is brought to the barrels square like creating a temporary virtual stockpile. Since this is attributed to the temporary stockpile it doesn't lock out the barrel. Meanwhile the barrel is sending out its hard request for that stockpile, like a stockpile link. Once that temp stockpile shows the seed it puts out the hard request locking down the barrel. I know this would require an extra cleanup step to remove the stockpile and might create a situation where a dwarf carries the barrel away while the soft request is happening, but this is just a rough idea.

burrows:
Annoyingly pointless in emergencies. A burrow only determines where a dwarf can stand not where it can path. depending on how you set it up a dwarf can leave a burrow if its destination is also within the burrow. this happens mostly with disconnected burrows. A new player doing a civilian alert burrow will not know to make one core burrow as opposed to multiple regional areas for the burrow.

saving:
Admittedly this "complaint" is completely counter to what got me into the game to begin with. but saving and exiting need to possibly be separate. The game operates as if it were a iron man with the current manual save option, but the ability to have backups every month or season go counter to this. There should be 2 save options. One where backups are allowed and you can save whenever you want. or you are stuck to when the game saves and it tries to prevent save scumming. My friend introduced the game to me back in the day by loading it up and asking me to merely exit the game. i took me a non zero amount of time to figure out that save was also exit. (maybe just make save say save and exit)

Mechanics that need to just be modified for everyone's sanity
Civilian alert:
Doubling back on civilian alert mechanics. Civilian Dwarves should drop non owned held items immediately. Dwarves just dump whatever they are holding for a multitude of situations, but the moment you sound the alarm they decide that they really love that 30 ton boulder and wont let go. Its the civilian alert and the civilians are never alerted to their danger or act in anyway to not die.

Climbing Marksdwarves:
This is a combination of a multitude of issues.
1. Dwarves climb way too often. Whenever i do a "turtle" build like when i was attacked by the undead i routinely have to build and internal part of the wall to prevent my dwarves climbing out as well.
2. Marksdwarves have no ability to say do ranged and don't attempt melee. Like the uniform settings their should be one to tell ranged dwarves to not attempt melee unless already in melee range. Too often the dwarves will decide to melee and will climb over the wall to reach their enemies. One of my earlier bases on stream had my marksdwarves climb over my wall, hop off into my moat, and swim across. Once across 3 of them starting shooting their crossbows.
3. Fortification classification. Constructed fortifications act completely differently to carved fortifications, and this is not very clear. The carved one being called arrows slits or something would make this easier to identify. as it stands a new player could design around their dwarves ability or lack there of to get through a fortification only to discover that not all fortifications are the same.

The Menu dock on the right:
There are a fair number of players right now that play off of DF hack with TWBT. Even i had played with this for so long i forgot that vanilla DF scales the menu with the map. Even long time players may get surprised if this isn't fixed for steam. I zoom out to do a mini-map/full picture thing and zoom way in to see individual dwarves performing tasks like fighting the latest were-creature. The menu resizing with my play area drives me up a wall. please render the game separate from the menu so they scale differently. The way TWBT does this is actually pretty nice though it might need to be improved upon. With TWBT if i scroll my mouse in the play area the play area zooms in and out. If i go into a full screen menu like creature status and then scroll the wheel i resize the words, and thus the menu. Slightly unintuitive but preferred above the menu taking half my screen when i want to watch the combat up close.

Mechanic that works completely fine
fishing:
you don't fish 1 fish, clean it, and then fish the second fish in real life. This is an unrealistic method. In terms of pure game mechanics this would make fishing be utterly pointless. It would take far too long to collect any amount of fish, and the restriction of 1 dwarf to a workshop prevents you from having multiple fisher dwarves going at once as they would all wait for one at a time. The only 2 changes to the fishing industry would be: 1. don't have the 'play now' dwarf list have 1 dwarf who does both fishing and fish cleaning split those 2 up somehow and new players wont get confused. 2. make shells stack better. A legendary fisher dwarf left to his own devices will generate more shells than anything short of a quantum stockpile could handle.

[Putnam]

Mmh, save+quit as a single feature is in keeping with the Roguelike legacy that Dwarf Fortress... actually doesn't resemble in any regard that matters, so yeah, I'm not sure it needs to stay at all.

[wierd]

Barrels/bins:

The issue is that barrels get picked up.  Why does the dwarf need to pick up a huge barrel full of seeds, to go collect a single seed off a plate?  Complete nonsense.

Suggestion: Seed barrels contain bags. Rather than send the whole effin barrel off with the dwarf, have the dwarf take a bag out of the barrel, of the appropriate seed type, to go do the seed collecting. That leaves the dwarf with a container in their hands to carry multiple seeds (such as collecting at a farmer's workshop after a threshing session, or at a distillery after an aggressive brewing session), while leaving the barrel (and other sacks of seeds) alone in the stockpile.  That enables farms to still operate, and serves to lock a container for the task, at the same time.

Bins: Short of hauling to a depot for trading or transporting it to a new stockpile, there is precisely ZERO reason for a dwarf to pick up a bin and walk off with it. ZERO REASON.  If a dwarf needs to transport many bars at once to the stockpile, or FROM the stockpile, use a wheelbarrow instead. (This message brought to you by Dwarven Chiropractic Clinics LLC. Remember to practice safe lifting!)

[Shonai_Dweller]

I've only ever seen dwarves pick up bins when they're taking the whole thing to the trade depot. Barrels also? When do dwarves start carrying barrels about? Not happening in the current version of the game. Did it ever?

[PatrikLundell]

Suggestion: Scrap the barrel/bin locking. This would save this forum a lot of questions and make life easier for newbies and veterans alike, as well as make bins generally useful instead of being a newbie trap with a very marginal practical use.

As far as I understand, the locking of a barrel/bin for access is an attempt at simulating that you can only access the container one person at a time. However, in real life people won't cancel their shopping because they had to wait for a moment while someone else took a frozen pizza out of the freezer, but would just wait for a moment. The time you'd have to wait is typically too short to be noticed at the fortress accelerated time scale, and so there is no point modelling it (unless you want bug reports of the type "sometimes, but inconsistently, my dorfs put things in/take things out of containers and then just stands there staring at it before moving away".
It looks like this change would be a simple case of disabling/removing over complicated code, but it's quite possible there's some technical reason behind the mechanism, making a change harder to implement than it seems.

Of course, you still need to cancel jobs to access containers if the containers are moved (it was somewhat amusing to see wall builders chasing a hauler to get a block in a bin when the hauler carried the bin back to the feeding stockpile to replace a block that had been taken out of the bin, before that bug was fixed). Apart from moving it to the trade depot for sale, I'd also consider moving a container with its contents to a linked stockpile to be a valid action (countering wierd's opinion).
Moving a container into a minecart would be a sensible action if the container would be released from the source stockpile's ownership, but that's a different issue, and minecart usage is probably not a top priority newbie issue.

@RNGStrategist:
- Weres: I don't see them often, although slightly more often than (semi)megabeasts and titans. FB's however, appears in their dozens over a reasonably normal length fortress with the standard 3 caverns.

- Pathing restrictions are near useless. Not only don't they work as you'd expect, they also fail to affect locations used for building (standing out in the evil rain rather than under the roof, for instance), and they don't have any effect at all on non residents.

- Job allocation: Jobs are posted (generated by stockpiles, for instance) and dorfs looking for a job takes posted jobs based on crude priority and distance considerations.

- Burrows: These are extremely important, at least the civ alert ones. However, they do not work the way you'd expect, which causes a lot of trouble. Changing path finding so burrows would work as you'd expect them to do would probably be expensive in FPS terms, though.

- Fishing: I'd have no problem with a fisherdorf fishing a pile of fish, hauling it back and then cleaning the batch (assuming that can be done before the fish goes bad), but I don't think it would be trivial to implement. However, a fisher/fish cleaner job combo on a dorf should handle the fishing and processing in a reasonable manner (assuming the workshop is available, of course, the building of which should be a higher priority task than fishing [don't know if that's an issue]).
I wouldn't have a fisher among the starting 7 as default, and I definitely wouldn't allocate a second dorf to fish handling: the starting 7 are far too few to be fully specialized to a single task, and 2 of them set on fishing is definitely not balanced.

@Shonai_Dweller (posted while I typed): I've got one historical example of non depot bin hauling above (which isn't barrel hauling, of course). Seed bags in barrels was supposed to be a worse pain than it is now once upon a time, although I don't recall the details.

[wierd]

Part of the reason why containers get locked for task, is because of job item loss/consumption.

See for instance, the historic bee keeper bug.  Dwarves would stand around indefinitely looking for a hive that had been consumed by another bee keeper, and never cancel the job. This was because the hive objects were not locked for task, and so the same hive would get earmarked by multiple bee keepers.

The idea with seed sacks is that when people carry seeds, they tend to carry whole sacks of seeds, rather than individual seeds. To keep dwarves from all trying to grab the same bag (the same way the beekeeper bug did), the bag gets locked for task.

To me, this makes more sense, realworld mechanics wise--

A dwarf takes a sack of appropriate seeds for his task, to the task site, then sets it down near the work site, which then releases it from task. (The dwarf selected for this task is determined by the granular chunk of fortress issuing the task, and a ranking "election" of dwarves with appropriate labor enabled, distance to target seed bag at time of election, and speed + strength scores of possible haulers.  The fastest, strongest, and closest dwarf is selected to carry the bag which will service the other job tasks generated within that granular fortress chunk.)*
Dwarves near that task site, with tasks that need seeds of that type, will target the seeds in that sack with preference, will not move the sack, and instead take seeds out until either all the tasks in that granular region of proximity are satisfied, or the sack runs out of seeds, whichever happens first.  Then a new job to return the sack to a stockpile (or barrel, if it still contains seeds) is issued.

Something similar should be done with fuel, ore, and bar use, vis-a-vis how much material should be taken to the job site. It is inefficient and silly to have the operator run all over the damn place every time.  It makes much more sense to look at the manager queue list, (or building queues), and then have the operator go on a single raw material run, and move everything to the workshop before beginning.  EG, if you have "make iron bars" on endless repeat, then calculate what the available number of iron ore boulders is, look for the closest aggregate group of such boulders is, and then calculate the load capacity of the wheelbarrow. Load the wheelbarrow with the maximum number of ore boulders (either available in that locality chunk, or that the wheelbarrow can hold, whichever is less), then haul them all at once to the work site.  If the smelter requires fuel, have them evaluate how much ore they just collected, and have them collect that much fuel, and transport it to the worksite, then have them do the production run.

For both, dwarves should select the highest density source of material, in the shortest distance, then take it to the job site.

*

Spoiler: logical flow for this problem (click to show/hide)

Job is first(reset at season change, and when bag exhausted) of this kind issued in this chunk? (True/false)
   True-> Begin election
   False-> Is Target Container inside work area chunk? (True/False)
        True->Container contains untasked seeds suitable for task? (True/False)
            True->Select seed and lock for task, perform task
            False-> Unselect sack, reset JobFirst, postpone job until next iteration.
        False-> Wait for container free from task_lock in area chunk; postpone job issue until next iteration

Election:
 Select case (containers with work item)
   Select subcase (Containers closest (path distance) to work site chunk)
     Select subcase (Container with most task material inside)

Select case (Dwarves with labor enabled)
  Select subcase (Dwarves closest to target [shortest path] container, from current position)
    Select subcase (Dwarves in upper deviation for speed attribute)
      Select subcase (Dwarf with highest strength attribute)

Lock [chosen container] for hauling task by [selected dwarf], with order to drop off container in target chunk.

[iceball3]

Talking about DFHack, Threetoe or Toad, have you seen the ingame interface dfhack adds to the units list?
With DFHack installed (you will probably need to go back to the currently released version of dwarf fortress to do this), you go to (u)nits and then press "l" (lowercase L) you'll come across an interface like this:

This has to be one of the most useful interfaces for managing dwarves I've come across, and it's by and large *most of the DFHackfeatures implemented into a very aesthetic ingame interface. The most extremely useful part about this is being able to take a glance at which dwarves have what labors, and at what skill level, and being able to sort the list and toggle labors with very little effort and interface diving.
Perhaps you could talk to the DFHack developers for more information on how designed this, and implemented the various features?
The interface is very well designed, i feel like the paradigm it was designed under could also help give other interfaces a fresh coat of functionality and ease-of-use.

[wierd]

DFhack is open source.

Not sure what license it is;  Toady has ZERO interest in opening his source. If DFHack is GPL, he cannot lift the code, and retain code control.  He would have to ask the developers of DFHack to release under a more permissive license, like BSD.

If it is already under a permissive license, toady can just lift it, and incorporate.

[Putnam]

It's zlib, which would fully allows for that sort of thing.

Also, both of 'em have mentioned an aversion to spreadsheet-type UIs, preferring to straight up destroy the current jobs system and replace it with something else over having that. Considering the way stress interacts with it, I think that's fair.