Print

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

[feelotraveller]

while there's no column for body size (yet), you can right click on the first column (with the names) and sort by body size, which should help.

Oh wow, fantastic!  I had no idea that was there.   

Just spent a few hours playing around with the grid views.  It's really nice to be able to customise the views/information.  This is how my roles tab ended up looking, at least for now.



I was planning on going through the roles and customising them a bit in the nearish future.  Any tips on what (not) to do to keep some balance between them?

The spread of figures in the above image is quite small (58 max, 44 min, disregarding the figures influenced by skills).  I realise that it is a complicated matter of statistics and scaling to come up with a set of figures which are useful.  Barring another solution would it be possible for users to scale the distribution (either scalar or some geometric expansion)?  Much easier for simple heads like mine to pick the gaps and proportions if the spread was say 20 to 90 (i.e. 5x linear).  Or to put it another way 1% difference (easily hidden on the spreadsheet) is currently so large that I feel like I should be looking at the unrounded figure on each and every occasion.

[splinterz]

while there's no column for body size (yet), you can right click on the first column (with the names) and sort by body size, which should help.

Oh wow, fantastic!  I had no idea that was there.   

Just spent a few hours playing around with the grid views.  It's really nice to be able to customise the views/information.  This is how my roles tab ended up looking, at least for now.

Spoiler (click to show/hide)

I was planning on going through the roles and customising them a bit in the nearish future.  Any tips on what (not) to do to keep some balance between them?

The spread of figures in the above image is quite small (58 max, 44 min, disregarding the figures influenced by skills).  I realise that it is a complicated matter of statistics and scaling to come up with a set of figures which are useful.  Barring another solution would it be possible for users to scale the distribution (either scalar or some geometric expansion)?  Much easier for simple heads like mine to pick the gaps and proportions if the spread was say 20 to 90 (i.e. 5x linear).  Or to put it another way 1% difference (easily hidden on the spreadsheet) is currently so large that I feel like I should be looking at the unrounded figure on each and every occasion.

yeah the default roles view also needs to be retooled to match the labor views..

traits have been removed from the default roles since 40.x since it was unknown what they might be affecting now. for military it's more obvious with things like bravery, violence, discipline, etc. but otherwise the default roles could really use some work in general. there are still some missing for spinner and shearer i think.

the roles have already been updated in the dev version to give better numbers in the display.

[Pink Photon]

I would like it so that the tooltip does not display social skills. Would it be possible to add that in (or is it hiding somewhere I haven't found yet)?

[splinterz]

I would like it so that the tooltip does not display social skills. Would it be possible to add that in (or is it hiding somewhere I haven't found yet)?

the best you can do is set the minimum level of skills to display in the tooltip. i'll make a note about the social skills.

[feelotraveller]

traits have been removed from the default roles since 40.x since it was unknown what they might be affecting now. for military it's more obvious with things like bravery, violence, discipline, etc. but otherwise the default roles could really use some work in general. there are still some missing for spinner and shearer i think.

the roles have already been updated in the dev version to give better numbers in the display.

Looking forward to the new version.    

That traits is missing is fine, better nothing than something misleading until their mechanics are somewhat understood.

I added custom roles for shearer, spinner, glazer, waxworker, presser, beekeeper and potter basically whatever I needed to map the labours to the roles. (No hauler roles... yet.   Used only default DT preferences.

(Edit: revised and incorporated into a set of custom roles.  http://dffd.wimbli.com/file.php?id=9661)

I was thinking of taking a pass through all the roles but I'm worried that without a basic understanding of how the weightings are used in calculating the final suitability that it will do more harm than good at least in terms of cross-role comparison. 

Is adding a lot (and what is too many?) preferences a bad idea?  Should I be aiming to standardise the number of attributes or total skill weight (i.e. setting each of two skills to 0.5 rather than 1 when they are both relevant) or should the goal be to have to total potential weight the same across attributes/skills/preferences?  Or does none of this matter?

Finally when you say the roles have already been updated in the development version (unreleased I assume?) does that mean the roles themselves or only the suitability calculations deriving from them?  I ask because if it is the former I probably should wait for the next release...

[thistleknot]

I didn't quite catch all your questions on weights...

but the way the #'s are normalized is:

at least these conditions are true:

all values are normalized
to:

max = ~100%

>median = 50%+

average ~50%

the one thing that is different between values is...

with preferences and skills...

min is ~<50%

where-as with traits and attributes

min is ~0%.

That is due to the way preferences and skills are skewed.  They have a lot of null values basically, so almost the entire set of values are null.  So we fix the null value by making it a neutral ~<50% value, and the >median values are 50%+ to 100%.

So... hopefully that clarifies how the %'s are derived to give you an idea on weights.

So an entire set of attributes (comparative to each and every other attribute within the dwarfs x attribute matrix) are scaled from 0% (if attribute or trait; otherwise ~<50% for preferences and skills) to 100% respectively, same for traits, skills, and preferences.

So within each "aspect" or "domain" or "category"... whatever one wishes to call: traits, skills, preferences, and attributes.  We have an average of .5 across each aspect; and each value within said aspect is directly comparable to each other.

So... it extends the comparative dimension of the problem to 4 dimensions, with each "plane"/aspect being 1 dimension (aka all attributes compared to each other).  So each dimension lines up at a .5 mean, where above .5 is >Median values.

Therefore, when you set weights, the weights work with a range of values from 0 to 100% for each "plane"

God, I hope that makes sense.

PS:
If you want to see how each aspect individually does it's "Rating", you can disable all the other aspect's [global] weights

As to my strategy with weights.  I always treat each "aspect" as a sum total of 1.  So each weight within that aspect, I try to ensure a sum of 1 with all total weights.  It's completely arbitrary, because it's all based on ratio's between the weights.  However, what I do within this "sum of 1" (because ultimately, that's how weighted averages work, they reduce each weight to a contributing %) is create sub-groups.  Say I'm making a melee combat role.  I would segment skills into "groups" where the group tries to represent a certain % of the total, therefore each individual weight would be some value below 1 (aka 100%).

You shouldn't have to reduce anything in relation to each other.  Everything set to 1 (out of say 11 weights) would mean each weight is 1/11th.

Say, if you have 3 weights...

.5 and .5 and 1
sum = 2

Then
.5 = 25% (.5/2)
.5 = 25% (.5/2)
1 = 50% (1/2)

[feelotraveller]

Thanks Thistleknot.  Mostly understood - answers my basic questions and good tip to play around with the 'independent variables'.

Part of the problem which was impeding my admittedly more global attempt at understanding the figures is that the preferences calculation is not working properly at the moment.  As far as I can tell from quick testing, at most one preference is counted and this gives the full weighting to the preferences component in the overall total.  (Assuming that any further preference is ignored I now understand why the spear preference was not showing, damn you bucklers.)  I guess the positive side is that only one preference is also used for reducing suitability.

As an example of cross-role comparison difficulties (which is the deeper question I'm asking, mainly myself) take the example of the default carpenter role and a custom stone hauler role which has only a preference for wheelbarrows as its weighting.  Imagine a dwarf with preferences for wheelbarrows and beds and standard stats otherwise.  They are going to look like an excellent candidate for a stone hauler but only a reasonable pick for a carpenter.  Okay it's a joke example, I always need stone haulers!

As an addendum I noted that preferences for Donkeys are not having any effect at all even when their preference is the sole element of a role.

[thistleknot]

Screenshots of pref issues?


I did a lot of testing of preferences around v23 to ensure we set it up right. The system I'd a bit hard to explain but it counts matches as either 1 for single (non group) matches and 1 +.1/ea for group matches.

That in turn is converted into 50%+ values

The method we use is rankecdf and it basically gives a proportional cumulative % based non the values frequency within the dataset. Prefs have approx 99% of their non null values as 1 match.  So... It makes a 1 pref match for a role be a high %. But there is still room above this % for the matches such as 2 or 3.1 etc.

[agpen]

I'm having an issue with custom profession names.  Custom profession names set within DF show up fine in DT, and all other DT features seem to be working correctly, but setting a custom profession name via DT just doesn't work.  It shows in the change queue, but post-commit they still have their existing profession name both in DF and DT.  Tested across multiple worlds and saves to make sure it wasn't just the one.

Any ideas for troubleshooting this issue?


DT 25 and DF 40.10, from Beautato's LNP, on Mint 17 x64

[splinterz]

Screenshots of pref issues


J did a lot of testing of preferences around v23 to ensure we set it up right. The system I'd a bit hard to explain but it counts matches as either 1 for single (non group) matches and 1 +.1/ea for group matches.

That in turn is converted into 50%+ values

The method we use is rankecdf and it basically gives a proportional cumulative % based non the values frequency within the dataset. Prefs have approx 99% of their non null values as 1 match.  So... It makes a 1 pref match for a role be a high %. But there is still room above this % for the matches such as 2 or 3.1 etc.

no, it's broken, see the posts/explanation above about the speardwarf. dropping the zeros can result in an equal rating for a different number of matches.

[feelotraveller]

A proposal for preferences.

Exclude preferences from the numerical calculation for roles.  Instead have a positive preference match trigger a highlighted box (yellow or purple, by default?) for the appropriate dwarf/role.  Preferences could then be added in whatever detail to a role without effecting the calculation but when present they would draw attention to themselves graphically.  (A complementary suggestion would be to include a new filter to select dwarfs who have a preference match by role.  So filter by preferences --> Mason, for example.)

Having thought around the issue a little it occurred to me that preferences are different from attributes, skills and traits in that they are highly situational.  E.g. an armoursmith with a preference for steel is a great thing unless your site happens to lack flux, or again a shearer with a preference for sheep is a good thing unless you're breeding alpacas, and so on.

Comments?

[thistleknot]

I had a similar idea for [making them similar to] moodable skills but... Why? Its already calculated into roles well (roles fit the situational bill, as in only those preferences that are associated with a role are counted, and non matches are not counted, we spent a lot of time trying to figure it out btw.  Because preferences are on a per role basis for purposes of role calculations). 

99% of preferences are only a single match, so more often than not.  Preferences only have 1 match, but with your setup, any dwarf who meets multiple pref's would be ignored, and to make matters worse, it wouldn't be incorporate into the role optimizer.  Which apparently has the affect of increasing dwarf happiness.

The [speardwarf] bug isn't related to the way the % is derived but in that its not reading a pref specifically to count it. (correct me if I'm wrong)

[feelotraveller]

Why?  Because with the current setup there is a lot of bad information.  The example of the shearer (prefs for alpacas, llamas and sheep)... any of these add to apparent suitability of a dwarf and yet suitability really depends on which animals there are (or will be) to be shorn on a given map.  Okay trivial example but how about a dwarf with a preference for bismuth bronze are they really as good a choice for a smith role as a dwarf with a preference for iron (or copper, or steel)? 

(If I understand it correctly the speardwarf above gets full weighting in all melee roles because of their preference for bucklers and then the spear preference adds no further weight.)

Okay it is a choice of mine to prefer no information (numerically) to a mix of good and bad information, but I really doubt anyone desires the latter for any automated labour allocation.  Which leaves the problem that preferences still need a major rework.  (I think that there are inherent problems with giving preferences numerical values, you are welcome to prove me wrong by producing a weighting system for preferences which does not suffer the bad information dilemma.  Conceptually it is how you go from the set of all possible preferences, for a given role, to those that are relevant - or could become relevant - at a given time and place.)  My suggestion was an attempt to bypass this more significant task but admittedly it comes from my desire to use Dwarf Therapist as a tool to make labour choices rather than as a tool to automate labour allocation.

But I would be happy to see my proposal implemented as an optional checkbox which would set the weight of preferences in the numerical calculation to zero and trigger a highlight box on roles where a preference is present (or I would even be happy enough to set my preference weights to zero manually in all my roles, as long as they still get checked for matches to trigger a highlight... but a toggle might be nicer so people can alternate views).  Then I can check out my smith or shearer candidate(s) for myself to see if their preference is relevant.

p.s. I don't get the comment about dwarfs with multiple preferences being ignored.  In my proposal, and as it works in DT currently the check is made for preference yes or no.  Multiple preferences make no difference.  My proposal is slightly better (assuming you are playing manually enough to look for yourself) in that if you look at the dwarf highlighted to have preferences you can see for yourself how many, and what kind, they have.

[thistleknot]

A dwarf w bismuth and spear prefs and a match for both would return a higher # than a dwarf w just a spear match.

You can compare yourself how preferences look.  Just disable all weights but preferences.

You'll see a lot of say 78%'s, then you'll see a few that are higher than 78%.  Those #'s that are higher, are #'s that have more than one match.

Originally the matches were all just "binary", either a 1 or a 0.  A group match, such as metals was 1, and an individual match was a 1.

However, we realized that "group" matches, such as for "metals", when a dwarf has multiple matches for metals.  That we don't wish to value each successive match as another 1, it was opted to go with a fractional value, that fraction of additional successive group matches is .1 for each successive match.

Example:
Metal matches:
2 matches =
1.1

Single Matches:
2 matches = 2

combined
2 + 1.1 = 3.1

btw, 3.1 would be a really high number, and is very rare; but whoever had such a setup would have their % be near 99.99

I was proposing that group matches be a value less than 1 [say .7 to .9], and approach 1 as more [group] matches are achieved (to keep group matches as always <=1), but that idea was shot down.

[feelotraveller]

A dwarf w bismuth and spear prefs and aatch for both would return a higher # than a dwarf w just a spear match.

Well, no.

I just double checked by adding nickel to the speardwarf role.  Stakud (my problematic speardwarf from the last couple of pages) a nickel-lover does not see any change in their suitability for the speardwarf role and neither do any of my other dwarfs.  Their suitabilities remain exactly the same as the default speardwarf role.

But you don't have to take my word for it.  Feel free to download the savegame/region (40.10) from a couple of seconds after embark https://dl.dropboxusercontent.com/u/14105530/region1.rar and look for yourself.  Or check it out with a similar custom role adjustment in one of your own games.

In fact this is exactly the problem which initially caused me to post.  Since Stakud has a preference for bucklers as well as spears she ends up being shown as equally suitable for all melee roles (since bucklers count for all of them).  Have a look at the snapshot on the previous page, disregarding the figure for axedwarf since I spent skill points there at embark.

More deeply though it would be problematic (in my opinion at least) for a dwarf with a preference for bismuth bronze to have a higher suitability since in the vast majority of cases they will not be equipped with bismuth bronze.  This is the problem of situational relevance.  Yes in the odd situation I will equip them with bismuth bronze so in some respects (all possible worlds scenario) they should be shown as more suitable.  But in most cases I'm not going to have the ability and/or desire to equip them with bismuth bronze so in these cases (a large set of given worlds) their increased suitability is spurious and can actually cause bad labour assignations (whether done by me or an automated system).

But wait, there is yet more, if you read now the offer also comes with the bonus problem of qualitative differences.  I was making a joke out of it above but it is clear (to me at least) that in most circumstances a dwarf with bed and wheelbarrow preferences is better off being a carpenter than a stone hauler (I'm assuming a custom stone hauler role with only the preference for wheelbarrows, which seems credible if not very useful).  This is since the stone hauler will potentially be more happy but the carpenter will also produce enhanced quality beds.  These beds are more valuable, but wait there is more, they also tend enhance room quality, and as a special offer if you read now, they also tend to be admired as fine pieces of furniture more.  So that's two extra ways you can improve the happiness of your fortress.