Print

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

[Impaler[WrG]]

Got the Icon suggestion in, but accidentally listed it as a Bug, so I figured I'd add a real bug too just for good measures, grid views that have been deleted are still listed and selecting them can cause a crash.

[chmod]

Got the Icon suggestion in, but accidentally listed it as a Bug, so I figured I'd add a real bug too just for good measures, grid views that have been deleted are still listed and selecting them can cause a crash.

Yep I see that one too. Did you see what I did with your icons in the other thread?

[lodester]

I'm against using a dwarf-icon tileset for the activity. It's too busy, not everyone uses the same tileset, and from a user-interface perspective simpler shapes are better for decision support and acclimation.
Sure, everyone would eventually know the tiny spec of yellow on the dwarf posed just so means "idle", but it's counterintuitive and i feel logically its just messy. You're not representing a dwarf in that column, you're representing an activity. It would make more sense to put something like this in the Dwarf Detail modal - personification belongs in there and that I feel is the right place for a graphic like this. Look at Urist McSleepybotom, sleeping away. In there you could use a larger graphic with greater detail and definition that makes the activity very obvious.

I very much prefer the simpler object icons like red dot for idle. Quick, simple, efficient. A shopping cart for hauling is just brilliant, imo.

Normally I want DT to get in, help with decisions, and get back to the game. With enhancements to traits, likes/dislikes, and skills this will grow in to a more rpg-support kind of role but untimately I see it as effective decision support. Keep it simple.

Of course, the ultimate concession would be for mod should to code the ability for the user to select their pairs of icons-to-activities. Sorry buddy .

-my $0.02

[ChocoHearts]

[img]

Well, say I know I need a stack or ten of booze. I want to sort my dorfs in DT by brewer skill, and assign the one with the highest skill to do nothing but brew.

Ok, I commit changes, hop back into DF... and wouldn't you know it, he's on break, and will be for the rest of the season. Then my dorfs get mad 'cause they don't have any booze, and before you know it, tantrums.

So... yeah, I want to know what all my dorfs are doing without having to switch back and forth between game and DT.

You win! I have tried to implement a best of both worlds. For those of us who just want to sort by idlers and make them do stuff, the new job column is a regular sized (16px) column with icons for the job type. And since it uses icons for job groups, those of you who want to see what they're doing can see a general icon in the column, and hover over it for a full description. I have also included the full description in the dwarf details dock window.

I love it! Though I see what lodester is saying - I honestly wouldn't mind just an idle/working column, with the current job listed in the details pane.

In fact, thinking about it, that makes more sense. We can always get rid of the column if we're not using it, right?

[chmod]

Newest Linux build is up. Please try it out! http://code.google.com/p/dwarftherapist/wiki/LinuxVersion

[Zavior]

Could grouping by squad be possible? Maybe even forming squads through dt? Would help tremendously with crosstraining the recruits

[Shurhaian]

Gave Linux R296 a try, and it worked all right so far! I did find a quibble about the options screen which I put in the Issues page. I didn't give it very exhaustive testing - this is a mature fortress with very little shuffling of labour needed - but it loaded, ran, and closed without causing a hangup; I'll try it soonish on a younger fortress.

[chmod]

Could grouping by squad be possible? Maybe even forming squads through dt? Would help tremendously with crosstraining the recruits

Not without a lot more work. I just don't understand how the squads are stored. It appears each dwarf has a squad name stored in their structure just in case they ever end up leading a squad. I think I have found a pointer to the squad leader, but I don't know if I'm barking up the wrong tree. I agree it would be very nice to build up the squad levels from inside DT. You can always open up a new ticket and other folks can vote for it by talking about it a lot

Gave Linux R296 a try, and it worked all right so far! I did find a quibble about the options screen which I put in the Issues page. I didn't give it very exhaustive testing - this is a mature fortress with very little shuffling of labour needed - but it loaded, ran, and closed without causing a hangup; I'll try it soonish on a younger fortress.

That is amazingly good to hear! The string writing thing will not be solved any time soon. The only reason it works on windows is because of some weirdness that MSVC does to std::string instances. It gives you a free 16 bytes to put in regardless of string size. GCC does no such thing. So for Linux if you gave each dwarf a nickname in game of at least 16 characters, the game would reserve memory for those strings, then DT could overwrite from there, but it can't do the original allocation. I know it's a bummer, but hey! native DT on linux!

[Shurhaian]

Bummer about the string entry and such, but that wasn't what I was talking about. I put in issue 126 - splitting Grid Colors from the other Grid Options, so that the Options screen is small enough to fit on my 1024x768 screen.

(Ed) I see now that that's already been fixed for next build. Score.

I'd also like to voice my support for suggestion 31. Given that my most common task to toggle is hauling, which is all the way over to the right, not being able to see who I'm highlighting to change can be a bit vexing - and on my machine, DT is sluggish enough about mouseovers/right-click menus that identifying the dwarves with such means is a bit inconvenient.

[chmod]

Bummer about the string entry and such, but that wasn't what I was talking about. I put in issue 126 - splitting Grid Colors from the other Grid Options, so that the Options screen is small enough to fit on my 1024x768 screen.

(Ed) I see now that that's already been fixed for next build. Score.

Yeah I live for the easy requests, that was like a 2-line change Looks better IMO too!

I'd also like to voice my support for suggestion 31. Given that my most common task to toggle is hauling, which is all the way over to the right, not being able to see who I'm highlighting to change can be a bit vexing - and on my machine, DT is sluggish enough about mouseovers/right-click menus that identifying the dwarves with such means is a bit inconvenient.

That has been sitting in my inbox for a few months now. It's going to be a huge pain the ass to solve. First off the labor column headers are actual table headers at the OS level. The dwarf names though are actual data cells. If I made them part of a vertical header this would just work, however then grouping would break. It wouldn't look so hot to have nested vertical columns, plus it's not even possible without writing a whole ton of custom drawing code.

In the interest of staying cross-platform, I have avoided as much custom drawing as I can (except inside cells). This might be possible by overloading the scroll behavior to not scroll but instead hide/unhide columns. So you would lose smooth scrolling, but the first column would never go out of view. You could still move a scroll bar horizontally, it would just be jerkier. Probably not do-able until issue 96 is done (http://code.google.com/p/dwarftherapist/issues/detail?id=96)



In other news: I just started a new poll in general discussion about what features DT needs next:

Vote over there!
http://www.bay12games.com/forum/index.php?topic=43252.0

[Saber Cherry]

I'd also like to voice my support for suggestion 31. Given that my most common task to toggle is hauling, which is all the way over to the right, not being able to see who I'm highlighting to change can be a bit vexing - and on my machine, DT is sluggish enough about mouseovers/right-click menus that identifying the dwarves with such means is a bit inconvenient.

That has been sitting in my inbox for a few months now. It's going to be a huge pain the ass to solve. First off the labor column headers are actual table headers at the OS level. The dwarf names though are actual data cells. If I made them part of a vertical header this would just work, however then grouping would break. It wouldn't look so hot to have nested vertical columns, plus it's not even possible without writing a whole ton of custom drawing code.

An easy - not perfect, but easy - way to solve it would be to duplicate the dwarf name column on both the far left AND far right side.

[chmod]

I'd also like to voice my support for suggestion 31. Given that my most common task to toggle is hauling, which is all the way over to the right, not being able to see who I'm highlighting to change can be a bit vexing - and on my machine, DT is sluggish enough about mouseovers/right-click menus that identifying the dwarves with such means is a bit inconvenient.

That has been sitting in my inbox for a few months now. It's going to be a huge pain the ass to solve. First off the labor column headers are actual table headers at the OS level. The dwarf names though are actual data cells. If I made them part of a vertical header this would just work, however then grouping would break. It wouldn't look so hot to have nested vertical columns, plus it's not even possible without writing a whole ton of custom drawing code.

An easy - not perfect, but easy - way to solve it would be to duplicate the dwarf name column on both the far left AND far right side.

Heh, why didn't I think of that? Simple > Complicated.

[HammerHand]

Is it also not possible for the name column to be still, and not move horizontally when the rest of the columns are?

Or... is that what all that technical jargon like "custom drawing code" effectively boiled down to?

The far left and right side is a perfectly good solution, of course, but the more intuitive and eye-catching one would be for the names to simply stay where they are when you scroll across your labors.  In this way, if a player has a particularly long labor view, the names are still perfectly visible while editing labors in the center.  On the other hand, beggars can't be choosers, and I'd be happy with the simple, effective solution instead of a complicated but elegant one.

[chmod]

Is it also not possible for the name column to be still, and not move horizontally when the rest of the columns are?

Or... is that what all that technical jargon like "custom drawing code" effectively boiled down to?

The far left and right side is a perfectly good solution, of course, but the more intuitive and eye-catching one would be for the names to simply stay where they are when you scroll across your labors.  In this way, if a player has a particularly long labor view, the names are still perfectly visible while editing labors in the center.  On the other hand, beggars can't be choosers, and I'd be happy with the simple, effective solution instead of a complicated but elegant one.

Yeah, unfortunately what you're describing as the elegant solution involves a lot of custom drawing code. Since the dwarf names are no different than a "Bowyer" cell for example. The headers at the top are actual headers though, not table cells. And since it's a tree (due to grouping) and not a table, it gets weird. Not that it can't be done, it would just involve a Whole Lot Of Coding(tm).

I would really like to get that working, there are just more pressing issues. There remains the possibility of splitting these big views into more tabs in the mean time.

[Shades]

Would it be easier to have two tables, that just happened to have the same height rows. The first containing just names, without a scroll bar or any framing really and with vertical position was actually linked to the scroll of the other table.

As long as the vertical position and the order of elements in the trees are the same for both tables it should just work (tm).

Should give the same visual result as having the first column fixed and not moving horizontally, I caveat this with not having looked at the code so not sure how easy this would be to do.