Bay 12 Games Forum
Dwarf Fortress => DF Suggestions => Topic started by: Valdemar on April 05, 2010, 08:28:29 pm
-
Dwarf Foreman (or its most recent incarnations like Dwarf Manager and Dwarf Therapist) are considered by many to be absolutely essential tools for properly managing a fortress. This has been proposed many times, and currently ranks fairly high in the Eternal Suggestion Voting. But how can such a seemingly complicated feature be implemented?
I've thought about this problem, and coded up a fully functional prototype (http://www.pindi.us/files/df/foreman/foreman.html) of what this screen could look like in Javascript. It looks fairly similar to the new military screen, with the same general format as Dwarf Foreman/Manager/Therapist:
(http://www.pindi.us/files/df/foreman/foreman.png)
(this is just an image, follow the link above for the actual working version)
To be clear, this is not a utility, but a working prototype for what the integrated Dwarf Foreman could look like. I would suggest putting it under the Units screen with the hotkey "f".
Use the arrow keys to move around the screen. Shift + an arrow key will move 10 units in any direction. The full name, profession, and current labor column are displayed at the bottom, since each is highly abbreviated (especially the labors). The numbers indicate the relative skill levels, and the shaded in cells are enabled labors. I've fit almost all the labors on the one screen, though a second page will be required for the animal/hunting and medical labors. At the very right are the hauling professions; obviously there is no skill for these, but labors can still be easily toggled.
Press Enter in any cell to toggle the labor for the current dwarf. Shift-Enter will toggle the labor for all dwarves with the same custom profession as the currently selected dwarf. Control-Enter will toggle the entire labor group (the ones with the same color) for the selected dwarf; this is mostly intended for quickly turning hauling on and off.
Professions can be edited directly on this page with the y key. An underscore will pop up under the profession name at the bottom, and you can type and use backspace to edit the name. Press enter when you're done.
Another feature I put in that currently has no equivalent in normal Dwarf Fortress is editing the color of dwarves. It always annoys me when dwarves have a completely different color than their actual job, so you can press c to change the color of the current dwarf to that of the current labor. Ideally this would resort the list, but I haven't implemented that. If this goes contrary to DF design in some way, this need not actually be implemented.
Since one will probably have more dwarves than will fit, the screen will probably need to page in some way. Either automatically scrolling when you reach the bottom with the arrow keys or using + and - or / and * would work fine, though I haven't implemented that.
I hope this prototype will be a useful demonstration of what an integrated Dwarf Foreman could look like. I know I would be thrilled if something like this made it into Dwarf Fortress.
-
Brilliant, I love it.
Can't believe you coded a working version!
-
Great idea!
-
Great idea, but you're going to run out of space with double digit skill levels, so it'd also need horizontal paging, or better yet actual categories.
Still, I hope this gets implemented in some way.
-
It should also be moused controlled, so we can click on the grid to easily toggle labors.
-
This has always been my highest priority desired feature, and has always been one of my eternal voting selections. You've designed it almost exactly how I imagined it.
Great idea, but you're going to run out of space with double digit skill levels, so it'd also need horizontal paging, or better yet actual categories.
Still, I hope this gets implemented in some way.
Digits above 9 could blink, or be a different color.
-
Great idea, but you're going to run out of space with double digit skill levels, so it'd also need horizontal paging, or better yet actual categories.
Still, I hope this gets implemented in some way.
I have it using the letters A-E and L for Legendary once it runs out of numbers, so that no profession ever takes up more than one column. I've changed the random skill generator so it actually generates skills that high.
A second page for the columns will be needed to fit some of the other labors anyways. Collapsing the column headers by labor group could work, though it seems like it would become confusing and you'd lose the big overview you get with the grid. Collapsing the dwarf list by custom profession name like in Therapist would definitely be useful, though.
It should also be moused controlled, so we can click on the grid to easily toggle labors.
That would be great. I didn't want to go too far, since even though several screens in DF use the mouse, it's rare, which probably means it makes the coding more difficult for Toady. But if possible, it would definitely make the screen easier to use. Left click for toggling, right click to move the cursor, and Shift and Control click working like the modifiers for Enter would work well.
-
It would be rad if you could expand the profession names at the expense of the # of dwarves in the list. Like the tab button changes the view from 15 dwarves and 2 letter skill names to 5 dwarves and 12 letter skill names.
-
It would be more intuitive if the letter order were reversed so that A were Grand Master ________ and if E were Accomplished ________ because an B on a test is good, but a D is bad, if that makes any sense.
An awesome example nonetheless.
-
It would be more intuitive if the letter order were reversed so that A were Grand Master ________ and if E were Accomplished ________ because an B on a test is good, but a D is bad, if that makes any sense.
An awesome example nonetheless.
Ah yes, that makes much more sense. The letters now go E-A, with Legendary remaining L.
It would be rad if you could expand the profession names at the expense of the # of dwarves in the list. Like the tab button changes the view from 15 dwarves and 2 letter skill names to 5 dwarves and 12 letter skill names.
You can now press Tab to expand the profession abbreviations to 4 letters. It just cuts off the first two dwarves in the prototype; I wrote the display code really quickly and it would be a real hassle to shift them down. I'm not certain that it's much better this way, since it looks like a big jumble of letters until you concentrate on reading down, but it's certainly a good option to have.
-
What's wrong with it being in a separate window? I mean, it would be nice if it was bundled with the game, possibly even if it started with the game, but there's no reason it has to be *in* the same window as DF. In fact, it probably loses functionality doing that.
It would be pretty simple to write a script that started DF and Dwarf Therapist/Foreman/whatever with a single doubleclick. At which point there's no real need to merge the code.
Other ASCII games (eg, Angband) have multiple windows to display useful information so you can track information while using the main game. That those extra windows are controlled directly by the parent program isn't especially relevant - the fact that foreman is essentially separate is an advantage in the modern multi-core world, because it can run on a different core than DF.
Basically, what advantages are there to combining this program into the DF codebase that don't exist when running it separately?
-
What's wrong with it being in a separate window? I mean, it would be nice if it was bundled with the game, possibly even if it started with the game, but there's no reason it has to be *in* the same window as DF. In fact, it probably loses functionality doing that.
It would be pretty simple to write a script that started DF and Dwarf Therapist/Foreman/whatever with a single doubleclick. At which point there's no real need to merge the code.
Other ASCII games (eg, Angband) have multiple windows to display useful information so you can track information while using the main game. That those extra windows are controlled directly by the parent program isn't especially relevant - the fact that foreman is essentially separate is an advantage in the modern multi-core world, because it can run on a different core than DF.
Basically, what advantages are there to combining this program into the DF codebase that don't exist when running it separately?
The point is that we shouldn't have to rely on third-party utilities for such an important purpose. I'm sure we all agree that managing a large fortress without Foreman is a complete nightmare. While the separate-window utilities do work, we have to worry about them possibly corrupting memory or saves, and of course they need to be updated for every new version. And I personally far prefer to play DF full-screen on a widescreen monitor than in a window, so am forced to either play it in a window or constantly switch out. It also breaks immersion since the Foreman windows look so completely different from the DF UI.
My goal with this prototype was to demonstrate how the Foreman interface could be programmed using interface elements already in DF, which should present a minimum of hassle for Toady to code if he so chooses. It may be slightly less convenient than the third-party tools, but it's definitely good enough for me and I hope many others. You'll always be able to use the third-party utilities if you prefer them.
-
I'd be happy for an ingame foreman utility, even if it lost some functionality. It helps keep Toady independent, while the utilities are great things, it can cause all sorts of problems for the project if a new version does something to break one, forcing people to choose between the new version or the utility.
-
Basically, what advantages are there to combining this program into the DF codebase that don't exist when running it separately?
How about portability and ubiquity? It would run everywhere DF runs, because it would be part of the program. It's just absurd to say that it's important functionality, but shouldn't be part of the program.
-
Nice script!
This is quite similar to how I imagined Dwarf Foreman integrated into DF.
Nice feature to have would be sorting dwarves by specific skill. That way you can easily find these with highest level at certain skill, and enable the labor only for them.
-
The point is that we shouldn't have to rely on third-party utilities for such an important purpose. I'm sure we all agree that managing a large fortress without Foreman is a complete nightmare. While the separate-window utilities do work, we have to worry about them possibly corrupting memory or saves, and of course they need to be updated for every new version. And I personally far prefer to play DF full-screen on a widescreen monitor than in a window, so am forced to either play it in a window or constantly switch out. It also breaks immersion since the Foreman windows look so completely different from the DF UI.
Given Foreman already exists, it shouldn't be too hard for Toady to create hooks in DF that would let it access the information it needs (and then Foreman could be recoded to use those instead of memory hacking). This would be a positive change.
Foreman could always be coded to look like DF. It could even be coded to be platform independent. And once you slave DF and Foreman to a parent program or script that calls them both, they're basically the same program in any real sense, they just work in 2 windows.
The only thing this requires from Toady is he implements a way for another set of code to access the relevant data while DF is running, and to be able to make changes to that data while its running. This is far more likely than Toady incorporating Foreman into his code and updating it every version release (just another thing that can go wrong)
Basically, working as a mostly distinct set of code would seem to be an advantage. And being controlled by a separate developer would also seem to be an advantage because that developer can do his own bug fixing so foreman becomes functional faster in a new version. The only thing that prevents the real illusion that it is two programs right now are appearance and the memory hacking - only one of which requires Toady's assistance to fix.
I'm not sure what this mythical 'part of the program' thing means - a program is just a collection of code. If you write a script that starts DF and Foreman together, then you are essentially treating them as the same program. (Maybe this is a difference of perspective, but plenty of programs have multiple distinct components that are only unified as code by being called by the same parent script.)
-
:D This thread needs more attention! :D
So Valdemar, do you have an actual prototype DF v.31 with this implemented in the game? If yes, can you post a download link of it?
-
Of course he doesn't. I'd be really surprised if anyone but Toady, ThreeToe and Baughn had access to the relevant source code.
-
So Valdemar, do you have an actual prototype DF v.31 with this implemented in the game? If yes, can you post a download link of it?
Read the first post again.
What he did is a program in Javascript that immitates how that screen would look like in DF. There is nothing else except what you can see on that screen, you can use keys and see how stuff changes, but there is no actual dwarves, or any actual game logic there.
-
Given Foreman already exists, it shouldn't be too hard for Toady to create hooks in DF that would let it access the information it needs (and then Foreman could be recoded to use those instead of memory hacking). This would be a positive change.
Maybe I'm thinking of something else, but hasn't Toady often expressed apprehension about accommodating 3rd party interface tools? I seem to remember him saying that too much can change, and too much has to change from release to release that thinking about this now isn't practical. But I could be way off here.
-
Maybe I'm thinking of something else, but hasn't Toady often expressed apprehension about accommodating 3rd party interface tools? I seem to remember him saying that too much can change, and too much has to change from release to release that thinking about this now isn't practical. But I could be way off here.
Yes, he's expressed almost exactly that sentiment several times. Something like this suggestion that pulls the essential controls back inside the game would be great. Most people might still use the third party utilities, but they wouldn't be as necessary as they are at present. This is a gorgeous mockup, and it would be cool it it were added.
-
Excellent mock up.
Added this thread to the Eternal Voting item.
-
I don't find the two-letter abbreviation for the labor name at all readable -- the DF interface already has too many cryptic elements that require memorization. Otherwise, I'm all in favor. Toady has resisted concepts like this on the grounds that they're spreadsheet-like, but a) the healthcare screen is already a spreadsheet, b) it's a completely natural way to manage something like this, and c) the alternatives all suck.
Running the utility in a separate window would be gross, however -- it's aesthetically unappealing and doesn't work for people who like to play games in fullscreen.
-
I don't find the two-letter abbreviation for the labor name at all readable -- the DF interface already has too many cryptic elements that require memorization.
Agreed, but once I realized what I was looking at, it wasn't too bad.
Then again, this is the default 80x25 grid view, adding more grid height reduces the problem (once we can get non-map screens to resize usefully).
-
Running the utility in a separate window would be gross, however -- it's aesthetically unappealing and doesn't work for people who like to play games in fullscreen.
I'm not sure i follow, plenty of applications have multi-window displays, and this is generally a positive.
Further, the game's full-screen resolution is what, 800x600? My monitor hasn't been that small since 1993. If nothing else, people with two monitors can full screen and use a second window with no problem.
Some thinking about how multi-windowing the full screen could work as a full screen display. The main play area would be a 'window' or section of the screen in the upper left corner extending to somewhere near or beyond the center of the screen. Foreman could be on the right side from top to bottom, and some other useful utility could fill the lower left area that is still open. Possibly the current command layer could display there instead of on top of your map area, and you could issue commands without pausing the game. (so if you go to mine the mining designations menu pops up in the bottom 'window'.
This isn't too unlike how a game like Civ IV divides up its screen space - there is a main play area surrounded by other windows with useful information, game controls, and so on. And since DF's best resolution is far smaller than modern screens, it would seem the issue for 'full screen' users would be maintaining the illusion that the game is occupying the full screen. Or really, if DF + Foreman did occupy the full screen, of convincing the user that it really was all the game. (Foreman really is a part of the game if you're using it - pretending otherwise is like drawing lines in the sand).
Edit: Regarding Toady's willingness to create hooks for applications like Foreman: if he's unwilling to take a simple measure like making hooks, what makes you think he'll make the effort to fully incorporate it into the game? Making hooks is vastly easier, and will involve less tweaking on his part as the code develops. If he won't allow programs like foreman to hook into DF, he's certainly not going to try to implement Foreman himself.
-
Running the utility in a separate window would be gross, however -- it's aesthetically unappealing and doesn't work for people who like to play games in fullscreen.
I'm not sure i follow, plenty of applications have multi-window displays, and this is generally a positive.
Further, the game's full-screen resolution is what, 800x600? My monitor hasn't been that small since 1993. If nothing else, people with two monitors can full screen and use a second window with no problem.
Some thinking about how multi-windowing the full screen could work as a full screen display. The main play area would be a 'window' or section of the screen in the upper left corner extending to somewhere near or beyond the center of the screen. Foreman could be on the right side from top to bottom, and some other useful utility could fill the lower left area that is still open. Possibly the current command layer could display there instead of on top of your map area, and you could issue commands without pausing the game. (so if you go to mine the mining designations menu pops up in the bottom 'window'.
This isn't too unlike how a game like Civ IV divides up its screen space - there is a main play area surrounded by other windows with useful information, game controls, and so on. And since DF's best resolution is far smaller than modern screens, it would seem the issue for 'full screen' users would be maintaining the illusion that the game is occupying the full screen. Or really, if DF + Foreman did occupy the full screen, of convincing the user that it really was all the game. (Foreman really is a part of the game if you're using it - pretending otherwise is like drawing lines in the sand).
Edit: Regarding Toady's willingness to create hooks for applications like Foreman: if he's unwilling to take a simple measure like making hooks, what makes you think he'll make the effort to fully incorporate it into the game? Making hooks is vastly easier, and will involve less tweaking on his part as the code develops. If he won't allow programs like foreman to hook into DF, he's certainly not going to try to implement Foreman himself.
What you're proposing sounds like a complete interface overhaul with all the sub-windows. While it could work, it's something that would take a lot of coding.
My monitor is 1280x1024, and I have DF set to expand the grid to fill all of it. With 16x16 custom tiles, it's quite beautiful. As I've said before, if I want to use Foreman, I either need to set it to the far uglier windowed mode or constantly switch back and forth. Either ruins the immersion. Additionally, Foreman has the aforementioned problems of having to be constantly updated and possibly corrupting memory.
Toady has rejected the idea of hooks for custom interfaces because he feels that it takes the game out of his hands, a reasonable decision. But that's almost exactly what is happening right now without the hooks, with a huge number of people relying on Foreman. Toady adopting ideas from utilities into the core game is not unprecedented. Remember Regional Prospector, the utility that revealed magma/rivers/HFS on the region map? It was a practically essential tool for a while, until Toady rolled it (and more) into the core game with the Site Finder.
I don't find the two-letter abbreviation for the labor name at all readable -- the DF interface already has too many cryptic elements that require memorization.
Agreed, but once I realized what I was looking at, it wasn't too bad.
Then again, this is the default 80x25 grid view, adding more grid height reduces the problem (once we can get non-map screens to resize usefully).
Have you tried expanding the abbreviations with Tab? The four-letter abbreviations are more understandable, though it remain a bit difficult to read due to the vertical aspect. It shouldn't be too much of a problem though, since the full name of the professions are always shown in the the blue detail region. Along with the colors, one should be able to get used to them fairly quickly.
Some of the abbreviations could probably be better, though. I can't really judge what's easy to understand since I came up with them, so does anyone have any in particular they think should be changed?
-
Toady wants to maintain control over his project. I understand that desire, and fully support it.
I agree with most of the people here that I would not like it in a separate window, and I want it to be part of the same executable and written by the same programmer.
I've played a lot of Angband, and have never once used multiple windows. I prefer to play games like DF/Angband with one very large window, so I can see the maximum possible amount of the game world.
-
Toady wants to maintain control over his project. I understand that desire, and fully support it.
I agree with most of the people here that I would not like it in a separate window, and I want it to be part of the same executable and written by the same programmer.
I've played a lot of Angband, and have never once used multiple windows. I prefer to play games like DF/Angband with one very large window, so I can see the maximum possible amount of the game world.
How do you play Angband with only one window? Its painful. Having inventory and monster information in other windows is so much nicer.
I also don't recall being able to change the amount of 'world' you can see - but its been quite awhile since i've played Vanilla and they might have changed that aspect of display.
-
I also don't recall being able to change the amount of 'world' you can see - but its been quite awhile since i've played Vanilla and they might have changed that aspect of display.
In DF (don't know anything about Angband), you've been able to change the amount of world displayed using the [GRID] setting in init.txt for a long time now. It was definitely present in 40d, which was released over a year ago. It doesn't affect the menus, though.
-
I was about to suggest this myself, based on the health interface, but I see I was beaten to the punch by a superior example. Definitely in favour of something like this so I can manage my dwarfs more easily. I share the disdain for spreadsheets but in this case it is a necessary evil. (Mouse control to enable/disable labours would also be really, really nice.)
The only modification I would make to the original suggestion is to put it on the Status Menu next to Health, so: Z -> Labours, since that's a more logical place for 'overview' interfaces like this.
-
The only modification I would make to the original suggestion is to put it on the Status Menu next to Health, so: Z -> Labours, since that's a more logical place for 'overview' interfaces like this.
Linking into it from multiple places wouldn't necessarily be a bad idea either. It would be good if there was always a way "back" where you came from though if it had multiple linkages.
Added this thread to the Eternal Voting item.
This suggestion is now 15th highest in votes. I moved one of my votes over to it based on the mockup, which has sold me on the idea of merging this into the game.
-
Added this thread to the Eternal Voting item.
This suggestion is now 15th highest in votes. I moved one of my votes over to it based on the mockup, which has sold me on the idea of merging this into the game.
Added one of mine as well. Standing production orders--while something I wish to see completed--has enough votes to keep it in the spotlight.
-
This is good stuff, and quite intuitive as well. Would it be possible to have a marker for Legendary +5? It doesn't matter for a lot of professions, but unless item quality has had an overhaul then L+5 is one of the thresholds at which a certain quality of goods is guaranteed.
-
Highly confusing with the professions just saying "Mi" and whatnot, should be an option to expand the table so that it takes more space (and can be scrolled, of course).
I kinda like the idea of having 0-9 and then A-E and L for skills, but this will make things even more difficult to newcomers. Why not just expanding the table and using two digits?
-
Highly confusing with the professions just saying "Mi" and whatnot, should be an option to expand the table so that it takes more space (and can be scrolled, of course).
I kinda like the idea of having 0-9 and then A-E and L for skills, but this will make things even more difficult to newcomers. Why not just expanding the table and using two digits?
You can expand the labels vertically with Tab. Expanding horizontally would cause far less information to be displayed, defeating the purpose of the condensed view. New players probably aren't going to run into skills that high for a while anyway (though the new migrants can be very skilled), and the blue description allows one to see the full expansion of both the profession name and skill level, so the first time they see it they can just move the cursor over it and the full name will show up. Condensing the 15 skill levels into 9 digits by doubling up some of the mappings could solve this problem, at the loss of some precision.
This is good stuff, and quite intuitive as well. Would it be possible to have a marker for Legendary +5? It doesn't matter for a lot of professions, but unless item quality has had an overhaul then L+5 is one of the thresholds at which a certain quality of goods is guaranteed.
I'm not certain Toady would like that, since he seems to have already made the decision not to differentiate the skill levels above Legendary in the existing interface. But if he is, it would be a useful feature to have.
-
A dwarf foreman feature implemented like this would be incredibly useful to me. Seeing what jobs are enabled at a glance or two, and easily changing them? Great stuff.
As it is, I'm a forgetful, scatterbrained one, tending to forget what jobs I've set on what dwarves, inefficiently enabling bad job combinations on the same dwarf, not realizing what dwarves I don't have jobs set on, re-checking the same ones and skipping over others, etc. That is, this would be much easier, and more intuitive.
I can't think of much to add, other than possibly a shift+ctrl+enter, and being able to click and 'paint' on it with the mouse. I just really like what I'm seeing here.
Personally, I think this should be core functionality, not dependent on another program.
-
What about turning the grid on its side to make the labor labels easier to read? They seem more important to recognize quickly than the dwarves' names and occupations, most of the time.
-
I've always been a bit of a purist, so as to avoid becoming dependent on a third-party utility. I've heard good things about Dwarf Foreman, though, and I can see how this functionality would be most helpful for managing large numbers of dwarves. I wholeheartedly approve of this and it has one of my votes.
I'd prefer if it counted 0-9 A-E L since that's closer to the way hexadecimal works, but whatever.
-
That interface is so nice that I decided to use it in a tool I've just written: an improved "Dwarf Manager" for Dwarf Fortress v0.23.130.23a (since the only other available tool, Dwarf Foreman, could only assign labors based on custom professions and not actual dwarf names).
-
I like this, and I'm sure this point has already been mentioned in this thread, but I'll say it again just incase:
Why are we still designing interfaces to fit the old 80x25 grid? We're no longer bound to it, it should probably not be the default window size, and eventually Toady will rewrite all the 80x25 screensto scale, at least vertically, to custom window sizes. So following the old rules on new screens is just making more work for Toady when he eventually re-writes the interface.
We can safely assume an absolute minimum resolution of 1024x768, which I think comes out to a 128x64 DF window.
-
It's a fair guess that the prototype simply used an 80x25 display because it was convenient. When I implemented the same interface in my above-mentioned tool (now available here (http://dffd.wimbli.com/file.php?id=2248)), I coded it to automatically stretch to fill the entire window and to scroll the labor/skill list horizontally if it didn't all fit (coincidentally, the prototype is actually missing a bunch of columns - Health Care, the 5 Ranger skills, and possibly a few others), so it's probably not too big of a leap to assume that Toady would do the same thing if he were to implement such an interface.
-
... eventually Toady will rewrite all the 80x25 screensto scale, at least vertically, to custom window sizes. ...
Hence design for 80x25. You simply have to design for minimum window size. As long as design is stretchable, it is going to be just fine.
It's not as if making windows use extra screen if stretched is going to be huge problem because mostly it is just about longer lists, wider columns and apropriatelly displaced footer text.
-
Toady is reluctant, I think, to make the DF interface too spreadsheet-y... the health screen is a bit like a spreadsheet, but it's not something you need to use very often.
-
Toady is reluctant, I think, to make the DF interface too spreadsheet-y... the health screen is a bit like a spreadsheet, but it's not something you need to use very often.
He's going to have to get over it at some point. I don't think a game this complicated can reasonably be handled by one-dimensional interface elements.
-
We can safely assume an absolute minimum resolution of 1024x768, which I think comes out to a 128x64 DF window.
Hi. My screen's maximum resolution is 1024x600.
Assuming a minimum resolution of 1024x768 would also create difficulties with screens of that size, and make it only playable in full-screen mode, due to interference from the title bar and (possibly) taskbar.
It would be far better to assume that the minimum size for the game is what it is currently (a 80x25 character grid, which shouldn't make the game unplayable on any laptop, desktop, or netbook, as well as allowing people to read web-pages, such as the wiki, behind the game screen), but allow screens within it to be scaled up or centered as the grid is increased by the player, allowing more information to be shown on the screen at any single time. Default resolution could be (is?) an init option, of course, for those who couldn't stand the agony of resizing their window every time they open DF.
-
Toady is reluctant, I think, to make the DF interface too spreadsheet-y... the health screen is a bit like a spreadsheet, but it's not something you need to use very often.
Assigning jobs is begging for a grid if you want to have some form of oversight.
-
Toady is reluctant, I think, to make the DF interface too spreadsheet-y... the health screen is a bit like a spreadsheet, but it's not something you need to use very often.
He's going to have to get over it at some point. I don't think a game this complicated can reasonably be handled by one-dimensional interface elements.
Yup. Considering how much information DF throws at you, and how many objects you exert individual control over, avoiding spreadsheets is just denial.
-
Two complaints:
1) Two letter abbreviations are horribly small. Four letters would be a huge improvement at the cost of only a couple rows, adding far more convenience than sacrificed imo. Three letters at least.
2) That dark blue is murder on my eyes. Such dark colors on the black background should be avoided. Are they truly needed anyway? I think the purpose could better be served with alternating white and gray or such. I get why it is done, but DF's limited color display calls for too high a sacrifice in readability to go all-out with it. Having four letters would also reduce importance of having so many colors to tell everything apart.
Otherwise it seems about perfect. Something that, while not luxurious, makes a large fortress playable without a separate utility. More complexity can remain in the realm of third party tools, at least for now, but a basic skill and job spreadsheet is too important to leave completely out.
Why are we still designing interfaces to fit the old 80x25 grid?
We can safely assume an absolute minimum resolution of 1024x768, which I think comes out to a 128x64 DF window.
Not everyone uses the default tiles and fullscreen. A minimum width of 1280 is needed simply for 16x16 tiles. So while the default is small, that quickly changes if you want it to be pretty. The "absolute minimum" you think can be assumed is 2048 pixels wide with 16x16 tiles. Not even most brand new monitors can do that, and most people are probably using ones four years old or more.
-
What's wrong with it being in a separate window? I mean, it would be nice if it was bundled with the game, possibly even if it started with the game, but there's no reason it has to be *in* the same window as DF. In fact, it probably loses functionality doing that.
It would be pretty simple to write a script that started DF and Dwarf Therapist/Foreman/whatever with a single doubleclick. At which point there's no real need to merge the code.
Other ASCII games (eg, Angband) have multiple windows to display useful information so you can track information while using the main game. That those extra windows are controlled directly by the parent program isn't especially relevant - the fact that foreman is essentially separate is an advantage in the modern multi-core world, because it can run on a different core than DF.
Basically, what advantages are there to combining this program into the DF codebase that don't exist when running it separately?
The problem for me at least is that DF has no well defined external API. Every time a new version of DF arrives the external utilites break. After substantial messing arround I got Dwarf Therapist running on 0.31.12 but I couldn't get it running with 0.31.13 or 0.31.14 yet to try with .16
If its part of the core game then it will Just work on every new version without any messing arround or memory remapping.
-
No it won't just magically work, it will mean more work for Toady every time he changes something. While I think this is convenient to have, I firmly believe that it's in our best interest to not have Toady waste his time on implementing and maintaining stuff like this that can be done by others with memory hacks.
-
After trying to play the new DF without Therapist, i've changed my votes on the eternal suggestion thread, as i've realized how much i depend on an external 3rd party utility to be able to organize my dwarves. - I believe an integrated foreman / therapist would aid playing DF without needing any 3rd party utilities, much more than fixing farming (which is currently above it on the list, and is easily mod-able).
Alternatively, is there any way to see if that dwarf who just died was my only butcher, without a)this suggestion being implemented. b) working DT, c) hitting u,selecting a dwarf, hitting c , scrolling to farming/related and checking in that sub-menu?
-
I believe an integrated foreman / therapist would aid playing DF without needing any 3rd party utilities, much more than fixing farming (which is currently above it on the list, and is easily mod-able).
If you think the farming suggestions are easily moddable, you haven't read the thread (http://www.bay12forums.com/smf/index.php?topic=76007.msg1920005#msg1920005).
Anyway, even as someone who is probably the single greatest proponent of the farming overhaul, I do agree that interface issues are probably more pressing as a concern right now. There's only so much Toady can ignore on the interface or bug-squishing front before the userbase just plain starts to revolt, and there have been times when it wasn't just the game getting ugly. (And, I will point out, I went out of my way to talk about how to handle the interface for the farming suggestion just to try to head off some problems.)
-
It would be more intuitive if the letter order were reversed so that A were Grand Master ________ and if E were Accomplished ________ because an B on a test is good, but a D is bad, if that makes any sense.
An awesome example nonetheless.
Using letters from A to E (actually to F) is the convention for people using hexadecimal, which many DF players do. It's a common convention for HTML coders and graphic artists to denote colors and is also used in some cases in more serious coding. It is probably easier to have the game display the value in hex, as it is stored in binary, than it is to switch the values.
-
After trying to play the new DF without Therapist, i've changed my votes on the eternal suggestion thread, as i've realized how much i depend on an external 3rd party utility to be able to organize my dwarves. - I believe an integrated foreman / therapist would aid playing DF without needing any 3rd party utilities, much more than fixing farming (which is currently above it on the list, and is easily mod-able).
Alternatively, is there any way to see if that dwarf who just died was my only butcher, without a)this suggestion being implemented. b) working DT, c) hitting u,selecting a dwarf, hitting c , scrolling to farming/related and checking in that sub-menu?
I'd personally prefer an API, that way all of the external utilities could be updated much more easily without Toady having to do the work to update them individually. I love Dwarf Therapist, I also love DFHack, Other people love Soundsense and Stonesense. an API would allow all of these to update more easily, quickly, and reliably, without Toady having to spend time updating each feature, he'd just have to make sure the API was still functional in the new version.
-
I'd personally prefer an API, that way all of the external utilities could be updated much more easily without Toady having to do the work to update them individually. I love Dwarf Therapist, I also love DFHack, Other people love Soundsense and Stonesense. an API would allow all of these to update more easily, quickly, and reliably, without Toady having to spend time updating each feature, he'd just have to make sure the API was still functional in the new version.
Unfortunately, that's been discussed ad nauseam, and Toady simply doesn't want to make an API because he doesn't want to make sure it was still functional.
Or at least, that's the way it was a year ago when I last saw him talk about it.
-
I'd personally prefer an API, that way all of the external utilities could be updated much more easily without Toady having to do the work to update them individually. I love Dwarf Therapist, I also love DFHack, Other people love Soundsense and Stonesense. an API would allow all of these to update more easily, quickly, and reliably, without Toady having to spend time updating each feature, he'd just have to make sure the API was still functional in the new version.
Unfortunately, that's been discussed ad nauseam, and Toady simply doesn't want to make an API because he doesn't want to make sure it was still functional.
Or at least, that's the way it was a year ago when I last saw him talk about it.
Certainly. My point is that maintaining an API is less work than maintaining an integrated labor management tool. Now if Toady enjoys creating a labor management tool that would be different, but considering he hasn't done so yet I doubt he enjoys it.
-
Minor necro-bump, but I think it's worth it: using some exciting new functionality within DFHack, I have successfully implemented a working version of this labor editor within Dwarf Fortress itself. Build the latest DFHack sources (from my fork on github), then enter the (u)nits list and press the (l)abors key.
-
Hmm. I haven't and shan't try this out, but I wonder what the purpose of this is, Quietust. I've been a long time supporter of some labour management within the game, but I have doubts as to how positive this proof of concept really can be.
- I don't like the way DF Foreman (or this Javascript) works in the first place, the layout is cluttered and gives too much information - it's design seriously needs a more intelligent and intuitive overhaul regarding the way job allocation works in real life.
- If and when Toady does get round to it at the very least this is going to confuse some players.
- What are you hoping to achieve by this? Pressuring Toady into including it in the game? Forking DF in a just-legal manner again?
- If you just wanted to do an in-game proof of concept, why not just show it to Toady?
- I honestly don't know how others feel about this, but this kind of "internal" DF-UI modification is seriously dubious IMO and could threaten the legitimacy of DF hack if it continues/went much further.
Hey, I could be overreacting, but I'd like to know a bit more about your motivations & hopes for this.
-
He's letting us know for those of us who want the functionality of DT in the interface but either don't like DT on principle or want it all in one window. I don't care, because I don't use DT (or DFhack, for that matter), but some do care.
-
It would be more intuitive if the letter order were reversed so that A were Grand Master ________ and if E were Accomplished ________ because an B on a test is good, but a D is bad, if that makes any sense.
An awesome example nonetheless.
Ah yes, that makes much more sense. The letters now go E-A, with Legendary remaining L.
It would be rad if you could expand the profession names at the expense of the # of dwarves in the list. Like the tab button changes the view from 15 dwarves and 2 letter skill names to 5 dwarves and 12 letter skill names.
You can now press Tab to expand the profession abbreviations to 4 letters. It just cuts off the first two dwarves in the prototype; I wrote the display code really quickly and it would be a real hassle to shift them down. I'm not certain that it's much better this way, since it looks like a big jumble of letters until you concentrate on reading down, but it's certainly a good option to have.
Actually, why not make legendary the icon thing for masterwork products?
-
My understanding from what Toady wrote re: APIs was that he didn't want to make them because then when he changed the API (as he would be guaranteed to do), people wouldn't use the new version of DF because their cool toys don't work with it. Reading between the lines, Toady doesn't particularly like DF Hack et al. but he tolerates them because there's not much else he can do, plus he's not the sort of person to obfusticate the memory just to stop it.
From that, I can see how it would benefit Toady to add Dwarf Foreman and stuff into the game, but given that we have existing utilities to do it right now, I see no reason why Toady should duplicate effort, especially since I think that the interface of Dwarf Therapist is far better than it could be if it was integrated into Dwarf Fortress. Also, having it separate allows for it to be continually developed alongside all of Toady's work, instead of giving him something else to do on top of everything else.
Right now, in Dwarf Therapist, I can sort by dwarves in several different ways, and then look at a glance what they are assigned to do and what their skills are, as well as if they are idle or not, the windows interface is particularly suited to this.
-
Sockless pretty much said everything I was thinking.
While it would not be amiss if DT was re skinned to fit in with the game a little better overall I would consider this low priority.
-
My understanding from what Toady wrote re: APIs was that he didn't want to make them because then when he changed the API (as he would be guaranteed to do), people wouldn't use the new version of DF because their cool toys don't work with it. Reading between the lines, Toady doesn't particularly like DF Hack et al. but he tolerates them because there's not much else he can do, plus he's not the sort of person to obfusticate the memory just to stop it.
From that, I can see how it would benefit Toady to add Dwarf Foreman and stuff into the game, but given that we have existing utilities to do it right now, I see no reason why Toady should duplicate effort, especially since I think that the interface of Dwarf Therapist is far better than it could be if it was integrated into Dwarf Fortress. Also, having it separate allows for it to be continually developed alongside all of Toady's work, instead of giving him something else to do on top of everything else.
Right now, in Dwarf Therapist, I can sort by dwarves in several different ways, and then look at a glance what they are assigned to do and what their skills are, as well as if they are idle or not, the windows interface is particularly suited to this.
Question: how is what Therapist does better than what DFhack does? You seem to change your mind mid-post, first saying how bad memory hacking is, then saying that everybody should use therapist.
-
I assume sockless is referring to DFhack's other tools.
-
I assume sockless is referring to DFhack's other tools.
Okay, so the cool toy that he uses that needs to be updated before he'll use the new DF version is fine while ones he doesn't use are bad? Allright.
-
Looks fantastic. Hopefully Toady will merge it.
-
This is awesome, props to the OP for some cutting edge DF interface design. I'd love so much to see this in the game...
-
This is awesome, props to the OP for some cutting edge DF interface design. I'd love so much to see this in the game...
Ah, but you CAN see it ingame, using the next version of DFhack.
-
What you talk about is so interesting.