Print

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

[NW_Kohaku]

I think people would be surprised how much is currently possible with DFHack. One ambitious person with a lot of free time could probably redo most of the whole interface. We know how to directly paint tiles to the screen, create new viewscreens, listen for keyboard input, etc. People have added search buttons to existing viewscreens before. Quietust even made a simplified version of Dwarf Therapist in-game.

Not that DFHack hasn't been anything but a godsend, of course, but there are good reasons not to rely upon it exclusively to solve the problems of interface.  (And thanks, by the way...)

DFHack can cause major crash bugs, and because some people are so dependent upon its features, it creates basically two nested programs (one of which is a nested batch of collaborative scripts, any one of whom can cause problems, but which has no single overseer for quality assurance,) with players incapable of distinguishing which one's bugs are causing their problems. 

Compound this with the data invisibility problem, and you wind up with only the tiny handful of players with said necessary skill to both program and know the game enough to read the hacked memory to find errors are the only ones who can actually reliably hunt bugs as Toady programs the game.  Quietust, in particular, seems to be spotting far more than his fair share of causes of major problems. 

In all, we really need Toady to actually think about adding ways to actually see and check his own code when it is in operation, and creating ways for players to actually have some of that window open, as well, so that they can understand when things go wrong, and report bugs, as well. 

There's also, frankly, the performance issue, where you're asking for multiple layers of interface to be overlaid on top of one another, when DF is already inexplicably a game that relies heavily upon the CPU to render graphics to the point that lowering graphic framerate is offered as advice for raising performance framerate. 

I get that DFHack makes great features available, but when someone can make a third-party interface that replicates the functions of Dwarf Therapist ENTIRELY IN-GAME USING IN-GAME ASSETS, then it's basically as close to a slap in the face as a programmer can get.  Since it's literally already coded out for him, it just begs the question why Toady can't just sheepishly accept it and copy that code?

OK, so Toady doesn't want to work with other people, but if we literally write out a step-by-step lesson for how to do something, have it entirely play-tested and bug-checked for him, and set it out for him on a silver platter, and he still doesn't take it...

[expwnent]

DFHack can cause bugs but it's fairly stable. Stable enough for most users. It's true that it's sometimes unclear whether it's a DFHack bug or a DF bug. That's a drawback and there isn't much we can do about it.

I have literally never seen Quietust be wrong about anything, which scares me a little. He's probably a robot from the future. In any case, it's a pre-existing issue that few people can help Toady debug, but without memory hacking, zero people can help except for Threetoe if he's a programmer.

I agree more transparency would help so that we can increase the number of people who can help.

Graphical stuff is an insignificant performance drain. Most of it happens when the game is paused anyway.

I get that DFHack makes great features available, but when someone can make a third-party interface that replicates the functions of Dwarf Therapist ENTIRELY IN-GAME USING IN-GAME ASSETS, then it's basically as close to a slap in the face as a programmer can get.  Since it's literally already coded out for him, it just begs the question why Toady can't just sheepishly accept it and copy that code?

Hehe I guess I never thought of it that way. In the same category, I implemented digging invaders but I'm not aware of anyone who uses it, despite how high it is on the eternal suggestions voting.

Here's how I see it: as players we have relatively little influence on what Toady works on. He does great stuff but he's going to focus on whatever he wants to do. As DFHackers we can add certain features, and cannot add other features. The best thing for the players is for Toady to work on the stuff he can do that we can't and for us to do the stuff that he doesn't want to, and for raw modders to take advantage of DFHack stuff to enhance their mods.

I think I have the necessary skill to redo most of the interface but I don't know where to start with the actual interface design. I've seen several suggestions posts talking about interface improvements, but I haven't seen any concrete suggestions of what should replace it, at least not enough for me to take it and run with it. I've gotten used to DF's interface to the point where I don't remember what was counter-intuitive so it's sort of "too late" for me.

[lethosor]

DFHack can cause major crash bugs, and because some people are so dependent upon its features, it creates basically two nested programs (one of which is a nested batch of collaborative scripts, any one of whom can cause problems, but which has no single overseer for quality assurance,) with players incapable of distinguishing which one's bugs are causing their problems.

We do try to test plugins and scripts, although this is a little harder with scripts due to a lack of compile-time checking. Packs also tend to distribute their own scripts, which we have no control over. Please don't hesitate to report issues on the Github issue tracker or in the thread. (TwbT can cause a large portion of crashes, so if a crash occurs when you're not interacting with a specific DFHack tool, try disabling that first.)

I get that DFHack makes great features available, but when someone can make a third-party interface that replicates the functions of Dwarf Therapist ENTIRELY IN-GAME USING IN-GAME ASSETS, then it's basically as close to a slap in the face as a programmer can get.  Since it's literally already coded out for him, it just begs the question why Toady can't just sheepishly accept it and copy that code?

DFHack and DF use different names for a lot of things, so merging it in and allowing people to contribute to it (which they would, since it's been open-source for so long) would be difficult for all parties involved.

[NW_Kohaku]

I think I have the necessary skill to redo most of the interface but I don't know where to start with the actual interface design. I've seen several suggestions posts talking about interface improvements, but I haven't seen any concrete suggestions of what should replace it, at least not enough for me to take it and run with it. I've gotten used to DF's interface to the point where I don't remember what was counter-intuitive so it's sort of "too late" for me.

Technically, isn't that what Stonesense is?  I know that Gnomoria basically built their whole game off of Stonesense. (To the point that they actually share some graphics, although that may be due to sharing some of their source...) As an interface goes, Gnomoria isn't bad at all. 

(In fact, the game also has a decently-designed "bootstrapping phase" where you start out with a "crude workshop" that is necessary for building required tools for starting other workshops.  This forces a progression of workshops, where wood and stone-working workshops come first.  Making it so you just plain can't build extraneous workshops until the basics are built helps prevent new player sandbox paralysis, so there's more to interface design than just raw GUI layout.)

Anyway, it depends on what you want to try accomplishing with it, but using Stonesense as a starting point wouldn't be a bad place to start, and I know that there was someone who was trying to make Stonesense actually playable...  The fact that you bypass the whole flaw of one-tile-one-icon is a huge plus, as it lets you display things like current job over a dwarf, what the dwarf is wearing, and also lets you do things like show conversation bubbles when a dwarf is talking rather than just having them sit there in the meeting hall invisibly gaining conversation skill exp.  With some work, you could even show when a dwarf is getting specific thoughts, such as showing some sort of red line of sight and an anger sign when a dwarf sees some cloud of flies and they hate flies. 

[NW_Kohaku]

DFHack can cause major crash bugs, and because some people are so dependent upon its features, it creates basically two nested programs (one of which is a nested batch of collaborative scripts, any one of whom can cause problems, but which has no single overseer for quality assurance,) with players incapable of distinguishing which one's bugs are causing their problems.

We do try to test plugins and scripts, although this is a little harder with scripts due to a lack of compile-time checking. Packs also tend to distribute their own scripts, which we have no control over. Please don't hesitate to report issues on the Github issue tracker or in the thread. (TwbT can cause a large portion of crashes, so if a crash occurs when you're not interacting with a specific DFHack tool, try disabling that first.)

The bigger problem is not knowing what's causing a problem.  I have some crash bugs, but I can't tell what is causing them.  Every time I try to shut something off, or do something differently, I find that I keep getting similar bugs.

For now, all I know is that going up and down z levels in certain information-gathering modes (like "q" or "v", although I had one in "i"...) can occasionally cause crashes, and I frequently get crashes during saves on the "cleaning up" part of the save process.

Worse, I've seen some fights on the wiki about people saying that such-and-such is how you do something, and not mentioning it's only available via DFHack plugin because they didn't know it was a plugin.  When you have people who never use vanilla DF, they have trouble telling where DFHack ends, and vanilla begins...

[expwnent]

Worse, I've seen some fights on the wiki about people saying that such-and-such is how you do something, and not mentioning it's only available via DFHack plugin because they didn't know it was a plugin.  When you have people who never use vanilla DF, they have trouble telling where DFHack ends, and vanilla begins...

That's certainly a problem but I see no way around it. There will always be a large section of the userbase who refuses to read any documentation.

I'm more interested in less ambitious user interface overhauls. Just using the existing in-game stuff with different menu design, adding more search buttons, categorizing things better, etc.

I particularly like the idea of showing the current job of a dwarf visually somehow. I'll think about whether there's a way to do something like that with DFHack in a somewhat user-friendly way.

Upgrading workshops are already possible. Ask Roses about it. We'd just need to replace the existing workshops with a sort of tech tree and it would work like Gnomoria. I think Meph has an extensive tech tree for Masterwork (at least before he started it over). Regular old raw modding can accomplish that: you need a certain building to make a blueprint for another, etc. Lua scripting can let you upgrade a building in-place. Sandbox paralysis is certainly an issue.

[Vattic]

I get that DFHack makes great features available, but when someone can make a third-party interface that replicates the functions of Dwarf Therapist ENTIRELY IN-GAME USING IN-GAME ASSETS, then it's basically as close to a slap in the face as a programmer can get.  Since it's literally already coded out for him, it just begs the question why Toady can't just sheepishly accept it and copy that code?

OK, so Toady doesn't want to work with other people, but if we literally write out a step-by-step lesson for how to do something, have it entirely play-tested and bug-checked for him, and set it out for him on a silver platter, and he still doesn't take it...

Even if he didn't mind working with other programmers I doubt he'd include the custom job management screen you mention.

Generally, we'd prefer to stay away from spreadsheets or a numbers-oriented priotization for specific labors on the labor list. We'd rather see the labor list removed entirely in many circumstances, depending on fortress citizen status, but that'll have to wait until starting scenarios are completed.

Have to say I'd be disappointed if the only interface available was isometric like Gnomoria; I found having tiles invisible to the player and the underground caverns to be confusing because of Escher like depth illusions (there has been talk of this difficulty in the Stonesense thread too). While the UI is much better designed in general I found some aspects fiddly, especially navigating the nested menus by mouse (why I've argued for keeping keyboard shortcuts even if they need to be more regular and logical).

[NW_Kohaku]

Well, I think that the move to workshop zones instead of buildings would offer more of a chance for this, as you can move towards requiring built tools, the way that Gnomoria does it, rather than 1 boulder = anything and everything.  The bigger problem I have with that system, however, is the potential for a sudden flood of stockpile-list-drowning tool types, and a need for greater organization.  (Yes, I appreciate search terms in the menu, but it's a pain to have to punch through them every single time I have to revisit the screen.)

Which brings up another thing: Cursor Memory.  Can't we have a way to remember where we were in the units screen or stocks screen?  I have to hesitate to wonder if it's really worth it to zoom in on where a given item in the stocks screen is, because I know I have to search for that type of item again if I'm looking for where every single wheelbarrow has gone off to...

But anyway, if we're talking about links between different modes of information-gathering and decision-making, obvious culprits are the military screen and anything having to do with animals.  Animals, in particular, require that you just memorize the order of the animals' appearance on the list, because there is no other distinguishing feature you can find when you want to train or pasture some, and butcher others.  You just have a list of 30 turkey hens all listed as "turkey hen", and no idea which one is in a pasture on a nest box, and which one is just running around free.  To see the specific stats of a given turkey on the detail view, you need to exit (and lose your place in) the units screen, and even then, you don't get enough information without just using DFHack, anyway. 

For that matter, just plain having a capacity to nickname animals would be a huge help.  "Egglayer turkey 04" is fine enough to label a turkey, while, due to the difference in adulthood and max size, you might say something like "butcher timber 1062" on another turkey. 

Also, one thing that's just the bane of my existence in this version is inexplicable job cancellation messages.  Jobs about stockpiling keep being canceled because of the job item being lost or moved, and I have NO IDEA what's creating the problem, because the announcements screen only zooms in on the area where the DWARF was when they canceled the job.  There is no indication what item they were going for, so I have no way of solving the problem.  Worse, I keep having job cancelations with my clothesweavers saying they're out of cloth when I have 70 cloth in the stockpile, apparently because someone just keeps moving all the bins or something...

One of the things I really loved in Gnomoria was the fact that, if you ordered a new steel spear, and you were out of steel, rather than just spitting out one more cancellation message among 500 others that get spammed a second, it just plain orders a new bar of steel be forged to complete that order, and the steel spear order is suspended until the steel bar is ready for being made into a spearhead. 

While we're on topic, if you could actually add in sound effects, that would be great.  In Gnomoria, things like shield blocks, dodges, hits to armor, and hits that pierce flesh are all different sound effects, and it helps give a sense of how a battle is going without having to read combat reports every 0.2 seconds.  Sound effects for different events could also take some of the load off of visual representation, such as an "ahhh!" sound for getting a happy thought looking at something. 


However, I think the most critical issue of interface (one I've harped on to some length in some of the previous rants I've linked to within this thread,) is the fact that critical data is invisible to the player.

Players keep running into problems where their dwarves go into tantrum spirals because of problems they don't understand.  Thoughts exist, but most players don't camp in the thoughts screens of dwarves, especially as you start to get over a hundred dwarves.  (Again, a reason why dwarven migration should be far, far slower...) When they finally do look it up, it's mostly just talk about being horrified by one thing or another, and a bajillion messages about how friggin' INTERESTING every random door is.  Not a specific door, just "a door".  No zoom-in here. 

The big problem is that everything in this game needs to be visually identifiable for players to really understand it.  Players understand minecarts and fluids and even to some extent combat (although they have to read the reports to get the blow-by-blow, they understand where they are standing, and what is dead).  Players do not understand conversations, social relations, thoughts and mood until it has hit critical stages, and general problems dwarves have with why they are picking one job over another. 

That last one is especially critical when Toady wants to move away from enabled and disabled labors to dwarves-choose-jobs.  Why does a dwarf choose one job over another?  WHO KNOWS! What can we do about it? APPARENTLY NOTHING!  Sure, there's going to be an elite few that get how to make this work, and build elaborate systems to exploit the subtle quirks of the system for maximum efficiency, the way that we used to control which side of a wall dwarves stood on by ordering suspended wall construction where we didn't want them to stand, but most players wind up walling a few dwarves into a closed-off space, and have no idea why. 

Adding in this tavern stuff, with musicians whose actions we can't see, visitors whose thoughts we can't see, but whose happiness we need to ensure so that we get more paying customers, and all sorts of other invisible data problems all add up to a major problem going on. 

In The Sims, we can see what a character is thinking - not through some details view that requires dropping all else from the screen to focus on just that one character - but just because a bubble pops out of their head saying "I wanna go to the bathroom".  And frankly, OF COURSE they do that, because understanding what your sim is doing, AND WHY, is critical to playing the game.

DF needs to have this capacity to show when a dwarf is playing or listening to music if this is going to be some sort of important aspect of gameplay.  We need to know why a dwarf is doing one thing, and not another thing when both choices are available to them, and what we can do to influence that decision in the future, and do so natively in the game, not only if you search and read up some obscure forum post where SCIENCE was done. 

We need to be able to see when a dwarf gets unhappy because they saw some swarm of flies because there's a rotting untreated leather in the stockpile so we can remedy that, rather than just see problems occuring, but having no idea WHY.  We need to be able to see the relationships, and what they do, or they're just some invisible bar filling up to a marriage that you can't even distinguish from being single except for when straight dwarves randomly spawn more babies.  If we have these taverns, we need to see what parts of the tavern are working well at satisfying customers or what parts of dining halls dwarves love, and which ones are annoying dwarves.  Armok forbid we start getting advanced social structures or factions within a fortress or thieves that pose as fortress members, and we have no means of telling what's happening or why.

Interface, and showing what's actually happening as it happens, not just when a player randomly chases a cause down after the disaster has already occurred is critical to letting dwarves become more than just the smiley faced automatons that blithely do whatever they are ordered without questioning orders, because we have no means of seeing when it is they are questioning orders. 

[NW_Kohaku]

Even if he didn't mind working with other programmers I doubt he'd include the custom job management screen you mention.

Generally, we'd prefer to stay away from spreadsheets or a numbers-oriented priotization for specific labors on the labor list. We'd rather see the labor list removed entirely in many circumstances, depending on fortress citizen status, but that'll have to wait until starting scenarios are completed.

Isn't that like saying "I'd prefer to stay away from an Interface that works"?  Because it's not something about presentation, it's about how the game was built in the first place that requires specific types of data to be in the game in the first place. 

Toady built a game where you need to be able to compare dwarves to see which one is best suited for a task, or where, when a job isn't being done, you need to see how many dwarves are assigned to that task, who is available to be shifted over to that task, and what consequences there would be for assigning those labors to them. 

He built a spreadsheet-based labor screen by building a game that requires a spreadsheet-based labor screen to actually manage.  And if he doesn't like that, well, HE'S BUILT THE WRONG GAME, THEN.  This is a simple failure to think the consequences of his design through, and it shows through every fracture in this broken and failed interface of his. 

He built a system for, say, bee hives, where you need to be able to set half the hives to be split and the other half to be gathered.  There's no reason to do otherwise.  There's a button to control that, and you just have to manually make sure it's half.  It's not ideal, but it's fairly functional, and all the buttons are explained on the menu, itself, which is fairly good, and probably one of the better uses of interface Toady has performed. 

Nest boxes, on the other hand, require that players somehow manually forbid dwarves from collecting fertilized eggs, which is a massive chore, and a failure to foresee how these nest boxes will be used, especially when you have something like bee hives with a perfectly good system for designating whether a nest box's eggs should be forbidden AUTOMATICALLY or not. You can't see whether turkeys are gay or not because he didn't bother to think through the need for that interface.  You can't see which turkeys are fat or muscular on the screen where you butcher them after explicitly making a system which rewards selecting for fatter, more muscular livestock because he didn't bother to think that one through.  You have the game that requires keeping track of when a turkey was born for maximum butchery, but no means of actually tracking that information, because he didn't bother thinking it through.  We only needed those features when he built the game so that we'd have to use those features.  He BUILT the problem to which those interface features are the only, obvious solutions.

That's where all this comes from: He didn't bother to think it through.  And it turns what would be a game that could curb-stomp Minecraft into some tiny indie thing only programmers play because only programmers can figure out how anything works and can manually change it to properly run. 

Have to say I'd be disappointed if the only interface available was isometric like Gnomoria; I found having tiles invisible to the player and the underground caverns to be confusing because of Escher like depth illusions (there has been talk of this difficulty in the Stonesense thread too). While the UI is much better designed in general I found some aspects fiddly, especially navigating the nested menus by mouse (why I've argued for keeping keyboard shortcuts even if they need to be more regular and logical).

You can use a button to make walls shorter in Gnomoria, which is a help.  You can also try to set the "slice" of the world down to just 1, which also stops depth illusions.  (I also find need of this with TWBT...)

And yes, you can use keyboard shortcuts in Gnomoria, as well, which I do with a custom key layout so that U is a ramp up, J is a ramp down, I is stairs up, K is stairs down, L is build floor, O is build wall, : is replace floor, P is replace wall, etc. etc.  I don't use the number buttons in Gnomoria at all except to use delete, which is just plain 5.

But yes, that scheme works specifically because I made it, and I made it all at once, so it follows a specific logic pattern, and I know what it does.

[expwnent]

Which brings up another thing: Cursor Memory.  Can't we have a way to remember where we were in the units screen or stocks screen?  I have to hesitate to wonder if it's really worth it to zoom in on where a given item in the stocks screen is, because I know I have to search for that type of item again if I'm looking for where every single wheelbarrow has gone off to...

That is completely possible with DFHack and would be quite nice. I'll add that to my list. There's already "tweak stable-cursor" for the map cursor. It won't always be possible for menu items, especially if new units/items are created or old ones are destroyed, but something is better than nothing.

But anyway, if we're talking about links between different modes of information-gathering and decision-making, obvious culprits are the military screen and anything having to do with animals.  Animals, in particular, require that you just memorize the order of the animals' appearance on the list, because there is no other distinguishing feature you can find when you want to train or pasture some, and butcher others.  You just have a list of 30 turkey hens all listed as "turkey hen", and no idea which one is in a pasture on a nest box, and which one is just running around free.  To see the specific stats of a given turkey on the detail view, you need to exit (and lose your place in) the units screen, and even then, you don't get enough information without just using DFHack, anyway.

I agree, and this is also possible to fix graphically with DFHack. I have no problem just showing the exact weight, or at least a few significant digits based on the skill of your most-skilled dwarf. I had always thought that you could go directly to the unit viewer from the animals menu but I just tried it and that doesn't work. That would help at least a little.

For that matter, just plain having a capacity to nickname animals would be a huge help.  "Egglayer turkey 04" is fine enough to label a turkey, while, due to the difference in adulthood and max size, you might say something like "butcher timber 1062" on another turkey.

That would be handy. Nicknaming them isn't hard but I don't know whether it would show up in useful places in the UI without extra tweaking.

Also, one thing that's just the bane of my existence in this version is inexplicable job cancellation messages.  Jobs about stockpiling keep being canceled because of the job item being lost or moved, and I have NO IDEA what's creating the problem, because the announcements screen only zooms in on the area where the DWARF was when they canceled the job.  There is no indication what item they were going for, so I have no way of solving the problem.  Worse, I keep having job cancelations with my clothesweavers saying they're out of cloth when I have 70 cloth in the stockpile, apparently because someone just keeps moving all the bins or something...

Difficult to fix, but maybe possible. It would involve searching through the entire list of jobs every time there's a job cancellation announcement, but on a frame-by-frame basis this is pretty rare so it shouldn't be too bad for performance.

One of the things I really loved in Gnomoria was the fact that, if you ordered a new steel spear, and you were out of steel, rather than just spitting out one more cancellation message among 500 others that get spammed a second, it just plain orders a new bar of steel be forged to complete that order, and the steel spear order is suspended until the steel bar is ready for being made into a spearhead.

Possible, but not 100% clear how to generalize. What if the components also have prerequisites? What if there are multiple ways of producing the ingredient item and they have different trade-offs (prefer magma forges over fuel-powered forges probably)? Would players want the game to completely automate going through an elaborate long tech tree in some mod in order to produce a top-tier blueprint, or would they want to do it themselves? What if they don't have any of the right kind of ore? One of angavrilov's old ideas was to combine one of the automining plugins with workflow and mine out ore as you need it. That might help.

While we're on topic, if you could actually add in sound effects, that would be great.  In Gnomoria, things like shield blocks, dodges, hits to armor, and hits that pierce flesh are all different sound effects, and it helps give a sense of how a battle is going without having to read combat reports every 0.2 seconds.  Sound effects for different events could also take some of the load off of visual representation, such as an "ahhh!" sound for getting a happy thought looking at
something.

Soundsense did this for a while but it may or may not work anymore. It would require finding free sound effects or making them, which is nontrivial.

However, I think the most critical issue of interface (one I've harped on to some length in some of the previous rants I've linked to within this thread,) is the fact that critical data is invisible to the player.

Players keep running into problems where their dwarves go into tantrum spirals because of problems they don't understand.  Thoughts exist, but most players don't camp in the thoughts screens of dwarves, especially as you start to get over a hundred dwarves.  (Again, a reason why dwarven migration should be far, far slower...) When they finally do look it up, it's mostly just talk about being horrified by one thing or another, and a bajillion messages about how friggin' INTERESTING every random door is.  Not a specific door, just "a door".  No zoom-in here.

The big problem is that everything in this game needs to be visually identifiable for players to really understand it.  Players understand minecarts and fluids and even to some extent combat (although they have to read the reports to get the blow-by-blow, they understand where they are standing, and what is dead).  Players do not understand conversations, social relations, thoughts and mood until it has hit critical stages, and general problems dwarves have with why they are picking one job over another.

I generally agree. There is the question of how much information should be available to the player. The player should certainly never be punished for something they couldn't reasonably have known about.

I agree migration should be slower. If you have fewer dwarves the game runs faster and each dwarf matters more and there's less micromanagement. I always keep my forts small.

That last one is especially critical when Toady wants to move away from enabled and disabled labors to dwarves-choose-jobs.  Why does a dwarf choose one job over another?  WHO KNOWS! What can we do about it? APPARENTLY NOTHING!  Sure, there's going to be an elite few that get how to make this work, and build elaborate systems to exploit the subtle quirks of the system for maximum efficiency, the way that we used to control which side of a wall dwarves stood on by ordering suspended wall construction where we didn't want them to stand, but most players wind up walling a few dwarves into a closed-off space, and have no idea why.

Dwarves don't look for jobs, jobs look for dwarves. There are a few exceptions with mining but that's basically how it works. It's more or less random and hard to control, as you say. This would be difficult to fix. Manual control is possible but a bad idea to rely on because that's a LOT of micromanagement. DFHack's autolabor does very advanced things to maximize efficiency that I'm reading about. It's an improvement but not a perfect solution.

Adding in this tavern stuff, with musicians whose actions we can't see, visitors whose thoughts we can't see, but whose happiness we need to ensure so that we get more paying customers, and all sorts of other invisible data problems all add up to a major problem going on. 

In The Sims, we can see what a character is thinking - not through some details view that requires dropping all else from the screen to focus on just that one character - but just because a bubble pops out of their head saying "I wanna go to the bathroom".  And frankly, OF COURSE they do that, because understanding what your sim is doing, AND WHY, is critical to playing the game.

DF needs to have this capacity to show when a dwarf is playing or listening to music if this is going to be some sort of important aspect of gameplay.  We need to know why a dwarf is doing one thing, and not another thing when both choices are available to them, and what we can do to influence that decision in the future, and do so natively in the game, not only if you search and read up some obscure forum post where SCIENCE was done. 

We need to be able to see when a dwarf gets unhappy because they saw some swarm of flies because there's a rotting untreated leather in the stockpile so we can remedy that, rather than just see problems occuring, but having no idea WHY.  We need to be able to see the relationships, and what they do, or they're just some invisible bar filling up to a marriage that you can't even distinguish from being single except for when straight dwarves randomly spawn more babies.  If we have these taverns, we need to see what parts of the tavern are working well at satisfying customers or what parts of dining halls dwarves love, and which ones are annoying dwarves.  Armok forbid we start getting advanced social structures or factions within a fortress or thieves that pose as fortress members, and we have no means of telling what's happening or why.

I agree completely. I'm not completely certain what the best way to present that information is but I agree it should be available. Toady's plan is probably to expand the nobles and have a "public relations" or "morale officer" who can tell you about who's upset and why, like the bookkeeper manages item counts. I personally kind of like spreadsheets. Just replacing the wall of text of recent thoughts with a table describing lots of useful information at a glance would be a step in the right direction.

Interface, and showing what's actually happening as it happens, not just when a player randomly chases a cause down after the disaster has already occurred is critical to letting dwarves become more than just the smiley faced automatons that blithely do whatever they are ordered without questioning orders, because we have no means of seeing when it is they are questioning orders.

Sounds would help, as you said. DFHack could monitor thoughts and let the player know when a lot of one type of unhappy thought are happening or when a dwarf is getting too stressed out. Not clear what the best answer is though.

(reading next post)

[expwnent]

Even if he didn't mind working with other programmers I doubt he'd include the custom job management screen you mention.

Generally, we'd prefer to stay away from spreadsheets or a numbers-oriented priotization for specific labors on the labor list. We'd rather see the labor list removed entirely in many circumstances, depending on fortress citizen status, but that'll have to wait until starting scenarios are completed.

Isn't that like saying "I'd prefer to stay away from an Interface that works"?  Because it's not something about presentation, it's about how the game was built in the first place that requires specific types of data to be in the game in the first place. 

Toady built a game where you need to be able to compare dwarves to see which one is best suited for a task, or where, when a job isn't being done, you need to see how many dwarves are assigned to that task, who is available to be shifted over to that task, and what consequences there would be for assigning those labors to them. 

He built a spreadsheet-based labor screen by building a game that requires a spreadsheet-based labor screen to actually manage.  And if he doesn't like that, well, HE'S BUILT THE WRONG GAME, THEN.  This is a simple failure to think the consequences of his design through, and it shows through every fracture in this broken and failed interface of his. 

I also have no problem with spreadsheets. They accurately display a large amount of useful information and it's easy to navigate to what you need.

He built a system for, say, bee hives, where you need to be able to set half the hives to be split and the other half to be gathered.  There's no reason to do otherwise.  There's a button to control that, and you just have to manually make sure it's half.  It's not ideal, but it's fairly functional, and all the buttons are explained on the menu, itself, which is fairly good, and probably one of the better uses of interface Toady has performed. 

Nest boxes, on the other hand, require that players somehow manually forbid dwarves from collecting fertilized eggs, which is a massive chore, and a failure to foresee how these nest boxes will be used, especially when you have something like bee hives with a perfectly good system for designating whether a nest box's eggs should be forbidden AUTOMATICALLY or not. You can't see whether turkeys are gay or not because he didn't bother to think through the need for that interface.  You can't see which turkeys are fat or muscular on the screen where you butcher them after explicitly making a system which rewards selecting for fatter, more muscular livestock because he didn't bother to think that one through.  You have the game that requires keeping track of when a turkey was born for maximum butchery, but no means of actually tracking that information, because he didn't bother thinking it through.  We only needed those features when he built the game so that we'd have to use those features.  He BUILT the problem to which those interface features are the only, obvious solutions.

I think I can fix most of those examples with DFHack.

That's where all this comes from: He didn't bother to think it through.  And it turns what would be a game that could curb-stomp Minecraft into some tiny indie thing only programmers play because only programmers can figure out how anything works and can manually change it to properly run. 

I wouldn't go that far, but it could absolutely be more user-friendly and it could improve in the ways you've said.

I like keyboard shortcuts. They take longer to learn but once you learn them you can navigate MUCH faster than you can with a mouse.

[expwnent]

PS: I think it's more an issue of priorities than not thinking it through. He's more interested in the game itself and its mechanics than the user interface, so that's what he spends most of his time on.

[NW_Kohaku]

I wouldn't go that far, but it could absolutely be more user-friendly and it could improve in the ways you've said.

PS: I think it's more an issue of priorities than not thinking it through. He's more interested in the game itself and its mechanics than the user interface, so that's what he spends most of his time on.

Well, it's more an outburst of frustration at seeing that quote than anything else. (I was actually about to edit them back to tamer language...)

I get that he wants to make the simulation and all, he doesn't let anyone actually UNDERSTAND what's going on, not even himself, when he doesn't even include the capacity to recognize that his growing eyebrows are now 6 feet long because they never stop growing or fall out.  And only Quietust found out about it because he was reading the game memory in a memory hack. 

There's no point to a game where you can't figure out what happened or why, or even know something even happened at all.  Eyelash growth was ultimately just taken out because they simply didn't matter at all. 

This should be something like putting your shoes on.  It's just something you do when you prepare to go outside, not something where you wonder why your socks are wet once you're halfway to the store.  Before you add a feature to the game, you ask what it's ramifications upon gameplay will be, and how players will understand what's happening. 

[Salmeuk]

There's quite a bit of hyperbole being thrown around, I'd just like to remind you that Dwarf Fortress is currently in development and certain things (like 6 ft eyelashes and suicidal birds) are to be expected. Could you explain to me how the bugs in DF are indicative of outright incompetence? You portray Toady as being unable to "think anything through" and reliant on circular reasoning, despite failing to understand his focus or vision. Getting so very frustrated at things that are bound to change isn't very productive, and I will reiterate that Vanilla DF is playable, and to me it is as playable as I'd expect from a game at it's stage of production.


I did like that idea of showing what dwarf is doing which job. Like a thought bubble that hovers nearby their sprite when you hold down a key, displaying another symbol for the kind of job being performed.

I was under the impression that if dwarfs are listening to music, they will be dancing along with it. Perhaps they can sit in still contemplation, but I bet the new dances are going to be remarkably interesting.

Calling it now, someone will program a song generator based off of the in-game descriptions.

Spoiler (click to show/hide)

I'm not a programmer, what am I doing here. . .?

[NW_Kohaku]

One of the things I really loved in Gnomoria was the fact that, if you ordered a new steel spear, and you were out of steel, rather than just spitting out one more cancellation message among 500 others that get spammed a second, it just plain orders a new bar of steel be forged to complete that order, and the steel spear order is suspended until the steel bar is ready for being made into a spearhead.

Possible, but not 100% clear how to generalize. What if the components also have prerequisites? What if there are multiple ways of producing the ingredient item and they have different trade-offs (prefer magma forges over fuel-powered forges probably)? Would players want the game to completely automate going through an elaborate long tech tree in some mod in order to produce a top-tier blueprint, or would they want to do it themselves? What if they don't have any of the right kind of ore? One of angavrilov's old ideas was to combine one of the automining plugins with workflow and mine out ore as you need it. That might help.

Gnomoria doesn't auto-mine ore, but as for the rest, there are multi-phase workflow components, far more than DF has, in fact.  (Making a spear requires making steel into a spearhead, and then combining it with a haft, which is made from a stick, which is made from a plank, which is made from a log, which is made by chopping down a tree.) Gnomoria has a system of drop-down menus per reagent, and what happens when an intermediate material is not available is that it checks for a job making that material, and just waits for that to be complete before un-suspending the job.  If you want specific materials to be used, you can set that on the finish product job, and it trickles through to the intermediate product jobs if applicable. 

It can still ask players to be a little micromanage-y for some jobs, however, as torso armor requires metal plates, leather straps, and cloth padding to be built, and the material quality of each one matters, so your steel breastplate should be built with ogre leather straps for maximum durability.  (Armor degrades with hits until they fall apart into recoverable but useless materials like metal plates. Ogre leather is better than bear leather, which is better than domestic animal leather.)  Hence, you need to make sure there are ogre leather straps coming through the production chain. 

Still, there's a "build to ___" function available in the base game, which means you can just tell your workers to always keep 8 ogre leather straps on hand. 

That last one is especially critical when Toady wants to move away from enabled and disabled labors to dwarves-choose-jobs.  Why does a dwarf choose one job over another?  WHO KNOWS! What can we do about it? APPARENTLY NOTHING!  Sure, there's going to be an elite few that get how to make this work, and build elaborate systems to exploit the subtle quirks of the system for maximum efficiency, the way that we used to control which side of a wall dwarves stood on by ordering suspended wall construction where we didn't want them to stand, but most players wind up walling a few dwarves into a closed-off space, and have no idea why.

Dwarves don't look for jobs, jobs look for dwarves. There are a few exceptions with mining but that's basically how it works. It's more or less random and hard to control, as you say. This would be difficult to fix. Manual control is possible but a bad idea to rely on because that's a LOT of micromanagement. DFHack's autolabor does very advanced things to maximize efficiency that I'm reading about. It's an improvement but not a perfect solution.

I'm more referring to what Toady is trying to do in the future, at least as I understand it.  In what he's said, he wants to obviate the whole labor system where you choose dwarves to accept tasks, and let dwarves have more autonomy to pick for themselves. (THE HORROR! THE HORROR!)

From what I understand, the new system will be something more dwarves-choose-the-jobs, and to an extent, this is basically just required, because we've got a system now where you need to check for things that are difficult to see (like whether someone likes helping people or not) before you can assign them a labor (such as doctor or nurse), because otherwise, they refuse to do the labor, or you have dwarves that have great skills, but poor attribute matching to their chosen jobs. 

In effect, this is an understandable fix to a problem of making all these personality traits and attributes that are difficult to see a part of what make ideal labor assignments, and it does so by functionally automating the process, rather than having a micromanagement-heavy optimization problem that simply having the Interface show you these stats would do.  As such, as far as that is concerned, it's actually a very good solution to the problem, since optimization problems SHOULD be automated whenever possible, as they tend to be boring gameplay.

The thing is, it's also a bit of a leap into the unknown, and if we don't have any control over who does what, it opens the potential for serious problems, the likes of which we may be forced into crazy methods like forcing burrows all the time for individual dwarves to fix, which may be more micromanagement than it solves.

I agree completely. I'm not completely certain what the best way to present that information is but I agree it should be available. Toady's plan is probably to expand the nobles and have a "public relations" or "morale officer" who can tell you about who's upset and why, like the bookkeeper manages item counts. I personally kind of like spreadsheets. Just replacing the wall of text of recent thoughts with a table describing lots of useful information at a glance would be a step in the right direction.

I had a suggestion a little while ago on a similar topic.  Making comments boxes in-game where dwarves tell you individual thoughts or complaints makes an in-game way for random blurbs of in-game thoughts or events to pop up to player attention without having to force the player to go hunting them down. 

Currently, the problem is that you have to know there IS a problem, and have a clue where it is before you even start to hunt it down.  This usually means you've had your first tantrum before you even know there's a morale problem.  Even then, you may not find a good explanation of WHY they're mad, especially if it's built up of multiple events that may even have fallen off the

A feature where you just periodically get dwarves telling you some arbitrary number of things about your fort and what they think (which can be made passive and background for those who don't want to deal) lets the game actively notify players of general problems.

There's the announcement system, sure, but the game's systems are basically afflicted with autism.  Events are only the most minor details, never the whole picture.  You don't engrave the battle of the Knives of Slashing, you engrave the one swing of an axe that Urist McWarrior did to Tog Gobboguy that cut the goblin's arm off.  You have cancellations, but those cancellations never tell you what problem actually caused the cancellation.  That's something that needs fixing in general, but this is something that at least makes the random thoughts of dwarves actually something proactively handed to the player, rather than something players have to occasionally bother to remember to look into.