Print

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

[Maklak]

I used 2000 for att_sim because that is about as much as you'll ever gain from military training. It may be too high, but I definitely not too low. 5000 is too high. By choosing lower att_sim, the current attribute value is more important. By choosing higher att_sim, the cap becomes more important.
100 is pretty low even for civilians, but it does say the most about the attribute value in the near future, capped or not. 500 to 2000 are reasonable values, I think.
For 5000 the cap will weight in the most. If want to have some kind of slider between current attribute value and the cap, I'd sooner just change the att_sim value to whatever the user wants (self-explanatory enough) rather than use an arithmetic mean.

CTI is the first number in MENT_ATT_RATES and PHYS_ATT_RATES which are usually something along the lines of 500:4:5:4 The 500 is the CTI, the rest of them is for rust. This is why I used 500 as default. It is the default value. Since it is called "cost to improve", I assume the lower the better, but I'd have to run tests by setting it for agility to some low value, like 10 and observing military training. Very fast increase would mean I'm right, almost no increase would mean I'm not and this should be used instead:
att_sim = (att_sim * CTI) / 500;

Yes, the median is the middle value in these things: [200:800:900:1000:1100:1300:2000]

Also, the att_cap is affected by this tokens: MENT_ATT_CAP_PERC, PHYS_ATT_CAP_PERC 

I think when you say "lower cost the better" you mean  cost to improve attributes, such as 1:1 vs 5:1, which confuses me why we're dividing by 100 then multiplying.  Say my rate is 500%, so if the att_sim is 5000, shouldn't it be 5000/5 (i.e. 500%) but we're doing 5000 / 100 (to normalize 100% to 1) then MULTIPLYING by rate... therefore increasing sim.

I did no such thing. You're commenting about your own formula here.

> the uncommented one went higher with higher skill rates, which is exactly what you had typed.
No. I typed "assuming the lower cost the better". You assumed CTI works exactly like learning rates for skills, which I don't think it does. Maybe the simplest way to resolve it is to ask in the modding forum. 

regarding ATT_RATES: the first value (cost to improve) is indeed better the lower the value is. what happens in the background is that a counter is incremented up to the CTI and then the attribute is increased. i haven't tested it, but assuming it works like rust, the increase is only by 1 point each time the CTI maximum is reached. this is definitely different from skills, as the skill rate is modifying the amount of xp gained, while the CTI is basically just modifying a counter's limit.

This is what I thought, based on the name "cost to improve".

[splinterz]

regarding ATT_RATES: the first value (cost to improve) is indeed better the lower the value is. what happens in the background is that a counter is incremented up to the CTI and then the attribute is increased. i haven't tested it, but assuming it works like rust, the increase is only by 1 point each time the CTI maximum is reached. this is definitely different from skills, as the skill rate is modifying the amount of xp gained, while the CTI is basically just modifying a counter's limit.

[thistleknot]

if att_sim is based on theoretical max possible gain. why not set it to median (or on last raw value). actually. a good marker for possible gain would be the 3rd median quartile, ie (6th raw +5th raw )/2. as it would be 50% between the median nd max possible gain.  which would b about avg possible gain for that attribute (wait. since all values lower than median have a gain possible of median... that means median is weighted more used, i.e. at least 50% the 3rd median quartile would be the other 50%))

is it bad to have diff att_sim used for diff attributes? ie str vs agi (since they both have diff ranges of possible values they can gain).

if it is bad to change att_sim between attributes. then 2000 seems good

[Maklak]

> if att_sim is based on theoretical max possible gain. why not set it to median.
Or rather your mean based on bins, to make it caste-independent. Seems reasonable, at least for those attributes that you can gain fast.

> is it bad to have diff att_sim used for diff attributes? ie str vs agi
It is OK to have different att_sim for different attributes. Just have the same att_sim for the same attribute for all Dwarves.

i did a quick bit of testing on the attribute rate gains with a woodcutter at 500 and 100 rates. the improvement counter gain was the same: +1 per 10 game steps while cutting trees. this resulted in a gain of 37 to the counter per tree the dwarf cut down. so at 500 it required 13.51 trees to increase strength by 1, while at 100 it only required 2.702 (or the expected 1/5 of 13.51).

This means I was right and (if you can get CTI for an attribute):
att_sim = (att_sim * 500) / CTI;    // Assume no one would set CTI to 0.
It will make the cap much more important for mods with improved learning rates for attributes.

[splinterz]

i did a quick bit of testing on the attribute rate gains with a woodcutter at 500 and 100 rates. the improvement counter gain was the same: +1 per 10 game steps while cutting trees. this resulted in a gain of 37 to the counter per tree the dwarf cut down. so at 500 it required 13.51 trees to increase strength by 1, while at 100 it only required 2.702 (or the expected 1/5 of 13.51).

[thistleknot]

Maklak:
quick pre correction
4500 is 99% 2250 is 85%《(see below)

Still on the fence about feeding the value back into the original bins.

I understand the concern of these values represent values after embark, but our frequency bin has a range of %s reserved for this area.

Yes, the values are newly generated.  But the frequency bins already account for max possible value.
Take strength of 4500 (vanilla) for example.  In our frequency distribution, that maps to 85%.
if we take a sim1 of 4500/5k, then that value comes out to be 90%.

Also, the sim approach has an att_cap included now that is inclusive of a dwarf's max possible gain, further allowing integration into our original % distribution scheme.

The frequency distribution we have setup already accounts for values that are generated after embark, we just try to fit it into our distribution scheme, whether values less than lowest raw are a certain %, and values above last raw are a new 98/7% range (i.e. a 14% range).

by mixing in a sim1/5k, we're basically introducing new values and saying their higher than a normal 4500 (which would be 85% vs 90%).

So by converting sim1 (actually sim3, modified) back to our frequency distribution, we are converting this new number back into a matching # in our frequency distribution, before averaging them

To be honest, I don't think it matter's so much, as we still get a value between 0 and 100, and the order is still preserved, but I think the value should be rescaled to match our distribution.  The max possible values will still be the same in both %, i.e. max for strength in our frequency bin is 4500, max generated with this sim3 approach I guess is 4500 (not sure since the question on att_sim posed below as to whether is should be be based on max possible gain, or average possible gain).

Anyways, I know it's confusing.  Two questions though.

1.
What to base att_sim on, avg, median gain, or max gain?

• anyways, I was talking with Splinterz, and what's best
  average potential gain for att_sim?
  median potential gain for att_sim?
  max potential gain for att_sim (basically last raw in an attribute)
  

2.
Merge ret result back into frequency bin?


here's code that uses median potential gain for att_sim

Spoiler (click to show/hide)

Code: [Select]

#include <iostream>
#include<stdio.h>
#include <math.h>

using namespace std;

int sim3 (int att, int initial, int median, int CTI, int att_sim)
{   //int att_cap = initial * 2;  // Actually:
    int att_cap = initial + ((initial > median) ? initial : median);
    att_cap = (att_cap > 5000) ? (5000) : (att_cap);  //caps at 5000

    // If att > att_cap, there can be no gain, except by interactions.
    if (att > att_cap)
       return att;

    //int att_sim = 5000; // Or whatever you think is prudent. This is where you can factor in attribute rates.
    att_sim = (att_sim / 100.0) * CTI;
    //att_sim = att_sim / (CTI/100);
    //att_sim = att_sim * 500.0 / CTI;
    int max_delta = (att_cap -att) > att_sim? att_sim : (att_cap -att); // min {att_sim, att_cap -att}
    long long ret = ((att + att + max_delta) * max_delta) / 2;   //  Or  att * max_delta + (max_delta * max_delta) / 2
    ret += (att_sim - max_delta) * att_cap;
    ret /= att_sim;   // Ret is now the average value for this attribute when you gain 2000 times in it and cap at some point.
    return (int)ret;
}

int main()
{
    int ret = 5;
    int att;
    int rate;

    //int att_cap;  // Current attribute value and cap.
    int initial;
    int median;

    int att_sim;
    //att_sim is based on median possible gain, not sure if it should be based on average possible gain, or median possible gain, or max possible gain
    //formula is ((median*.5) + (((5th bin + 6th bin)/2) *.5)
    /*
        450:950:1150:1250:1350:1550:2250
        (1250*.5)+((1350+1550)/2)*.5
                  =1350
    */
    printf("input:\n current, initial, median, rate, att_sim\n\n");
    printf("output:\n current, initial, sim3\n\n");
    while (ret = scanf("%d %d %d %d %d", &att, &initial, &median, &rate, &att_sim) == 5)
    {
        printf("%d, %d, %d\n", att, initial, sim3(att, initial, median, rate, att_sim));
    }
    return 0;
}


[Maklak]

UGH, I find it extremely difficult to figure out what your post is about, but I'll try to clarify. Also, re-read my last post.

sim3 is supposed to simulate some time spent gaining an attribute, then tell you what was the average value for that attribute during that time. This much should be obvious from the trapezoid + rectangle formulas for ret. Anyway, what the sim3 returns, you need to treat as a predicted attribute value a few years ahead.

I don't know what any of this has to do with producing values for bins. I think taking this and accounting for vampires and other attribute-boosting interactions will suffice:
int att_cap = initial + ((initial > median) ? initial : median);

> I understand the concern of these values represent values after embark, but our frequency bin has a range of %s reserved for this area.
You mean the 1% assumed frequency for attributes above the maximum?

> Take strength of 4500 (vanilla) for example.  In our frequency distribution, that maps to 85%.
> if we take a sim1 of 4500/5k, then that value comes out to be 90%.
85% ow what? 90% of what. What does any of this have to do with anything? 

> Also, the sim approach has an att_cap included now that is inclusive of a dwarf's max possible gain, further allowing integration into our original % distribution scheme.
See above.

> The frequency distribution we have setup already accounts for values that are generated after embark, we just try to fit it into our distribution scheme, whether values less than lowest raw are a certain %, and values above last raw are a new 98/7% range (i.e. a 14% range).
  This looks like something from the way you construct bins. It has nothing to do with sim3 as far as I'm concerned.

> by mixing in a sim1/5k, we're basically introducing new values and saying their higher than a normal 4500 (which would be 85% vs 90%).
> So by converting sim1 (actually sim3, modified) back to our frequency distribution, we are converting this new number back into a matching # in our frequency distribution, before averaging them
Ah, I think I understand what you're trying to do now. You want to assume some attribute gain over time and modify the attribute bins accordingly. Well, for current population and a selected attribute you can calculate the average attribute gain so far:
sum = sum by all dwarves { ((att -initial)*CTI_for_his_caste*caste_frequency)/500 }
average = sum / number_of_dwarves.
Heck, you can even feed that to sim3, assuming you get a reasonable value (above 100).

> max for strength in our frequency bin is 4500
OK, but what about a very strong Dwarf becoming a vampire and having 5000 strength? This is not a hypothetical question. The FoE mod I play has "Power Armour Potion" - one use per dwarf, but boosts some attributes by 2000.

> max generated with this sim3 approach I guess is 4500
Unless att >= 4500, the value generated by sim3 will be <= 4500.

> What to base att_sim on, avg, median gain, or max gain?
Keep in mind that really big gains in attributes, exceeding a thousand, are rare. They only really happen for military ponies. Gaining 4000 or 5000 in an attribute never ever happens, so be a realist here. I think this should either be some arbitrary value for each attribute or something based on the "average median" for all castes. (I'm not kidding, take medians for all castes and get their arithmetic average, based on caste frequencies.)

> Merge ret result back into frequency bin?
It might work with caution and knowing exactly what you do, but looking at your mathematical recklessness so far, don't bother or you will get it wrong.

Your program still uses the wrong formula for factoring in CTI, as proven by Splinterz and explained by me. The correct one is this:
att_sim = (att_sim * 500) / CTI;

[thistleknot]

mk
i get my math right in the end thru trial and error

when i said i wanted to feed the value back into the frequency bin.
i meant take ret and instead of divide by 5000 to get a percent
run it through our already established formula for deriving percents based on value.  because our formula already accounts for values above the 7th raw. i.e. 85% to 99% is 7th raw to 7th raw * 2 (or the 200% perc token value)

i was proposing a att_sim based on median *.5 and 3rd median quartile*.5
agil would b 975
str would be 1375

[Maklak]

Ugh, remind me, what do you need to do with the attributes again and why? I think displaying them is already handled, so now you want something to decide which dwarf has better attributes for a job and to do that you want to factor in potential attribute gain over time, yes?

> i get my math right in the end thru trial and error
I don't like the sound of that, but I sometimes do this myself.

> when i said i wanted to feed the value back into the frequency bin.
> i meant take ret and instead of divide by 5000 to get a percent
I don't divide ret by 5000, so you probably mean "take the average value of this attribute for this Dwarf after some gains and compare it to the highest possible value for that attribute".

> run it through our already established formula for deriving percents based on value.  because our formula already accounts for values above the 7th raw. i.e. 85% to 99% is 7th raw to 7th raw * 2 (or the 200% perc token value)
OK, I guess, but what exactly do you want to accomplish?

> i was proposing a att_sim based on median *.5 and 3rd median quartile*.5
> agil would b 975
> str would be 1375
I don't know why you need quartiles for this, but most any value around a thousand should work. Just keep these in mind:
* Sensible values are in the <100, 2500> range.
* The att_sim for an attribute, before factoring in CTI, must be the same for all Dwarves.

I still think that taking an old fort and looking at attribute gains there (att -initial) would be a good way to make an informed guess on good att_sim values. They would be good for agility, strength, endurance and so on, OK for things like memory and creativity and negative for musicality.

[thistleknot]

MK:
First, I'd like to say, that most of these posts are from my phone.  Right now I'm at a PC, so I have some time to explain in more detail, but sometimes I try to hit on specific points as quickly as possible which seems to only add to your confusion.

Ugh, remind me, what do you need to do with the attributes again and why? I think displaying them is already handled, so now you want something to decide which dwarf has better attributes for a job and to do that you want to factor in potential attribute gain over time, yes?

I want to create a weighted average, for attributes , similar to how skills are using (sim1 normalized to a % value) with (current % method using frequency bins, see as formerly described here or just see below).

Wo when I said

i wanted to feed the value back into the frequency bin.

I meant take your sim3 approach, and put the # back into the formula as described below.

Example for finding % based on an attribute's frequency bin.
The formula uses 98/7 vs 98/6% for each frequency bin, as we've created a new bin for the values past the 7th raw.

Strength:
450:950:1150:1250:1350:1550:2250
There are 6 bin frequencies, we add a 7th by doubling the last value (2250-4500)

98/7=14% per frequency bin.

<450 = <1%
450-950 = 1 - 15%
950-1150 = 15 - 29%
1150-1250 =  29 - 43%
1250-1350 =  43 - 57%
1350-1550 =  57% - 71%
1550 - 2250 = 71% - 85%
2250 - 4500 = 85% - 99%
>4500 = 99%+

Spoiler (click to show/hide)

Note: There is talk of changing the 98/7 to something lower like 90/7 to give values <lowest bin (450 in this case) a larger percent, although not by much, since dwarf's can rust away to 0 attributes).

The 4500 is derived from the max possible value a dwarf can have (if he started with the max possible initial value, which is defined in the raw's as 2250)  I.e. 2250 x 2 = 4500.

ATT_Sim: (median*.5) + (3rd quartile median*.5)
I just realized I may be wrong about this.
If half the dwarf's have a max gain value of median (because initial embark value is below median)
and the other half have a max value of initial embark value x 2.
Then the halfway point would be median no?  If so, then disregard the spoiler which describes what I was trying to do with 3rd quartile and just use median.

Spoiler (click to show/hide)

  I proposed this, as half the dwarf's of any given attribute will have a potential gain above/below this amount.  As dwarf's below the median value (50% of dwarf's) will have a possible gain of median (i.e. median * .5).
  The other half of dwarf's will have initial values above median (i.e. 50%).  So I need to find the 3rd quartile median, as this is the halfway point of this group.  Which is the ((5th raw value) + (6th raw value)) /2.
  So what I proposed was to base att_sim for any given attribute on this derived value, which falls within 900-2000 generally.  Which I described as the median potential gain for any given dwarf.
  I propose this instead of median, as only half the dwarf's will actually have this value, the other half will have a value somewhere between median and max, so I derived the 3rd quartile median.

I'll calculate ++ for example

++
Focus, Spatial Sense
700:1200:1400:1500:1600:1800:2500
Median/Att_sim
=(1500*.5)+((1600+1800)/2)*.5
=1600

All the other attributes were lower
+ was 1375 I believe
- was 975

Code: [Select]

I still think that taking an old fort and looking at attribute gains there (att -initial) would be a good way to make an informed guess on good att_sim values. They would be good for agility, strength, endurance and so on, OK for things like memory and creativity and negative for musicality. Originally DT used to use statistics and the current population to derive %s from.  However, since we've deviated from that and tried to hard code everything (see above frequency bin as reference), we were hoping to derive an att_sim based on the raws of an attribute.

So the question I was proposing earlier.
Would it be better to use
  median of an attribute's possible gain,
  average of an attribute's possible gain (would certainly be higher than median),  Useful for finding the middle value for att_sim based on any embark dwarf.
  max of an attribute's possible gain (i.e. 7th raw value)

The average of an attribute's possible gain could be derived by

Spoiler (click to show/hide)

Column 1: Frequency Range
Column 2: Avg Range
Column 3: Avg Gain for that Range| Gain = (Range<Median) ? Median : Range   
Column 4: Column 3 * (1/6)

700-1200   950   1500   250
1200-1400   1300   1500   250
1400-1500   1450   1500   250
1500-1600   1550   1550   258.3333333
1600-1800   1700   1700   283.3333333
1800-2500   2150   2150   358.3333333

Last column is avg Gain for that range * 1/6
sum of last column is
1650

[thistleknot]

this pic should work for a day or two, but here's some methods involving including the median as att_sim

 (pic won't be up forver)
http://i50.tinypic.com/o5artj.jpg

thanks to splinterz

so the distribution only slightly changes using median as the att_sim.  So I recommended Splinterz use either the avg potential gain (as described in post above), or max possible gain (i.e. 7th bin).

actually, looking how the ordering isn't changed, differences between median based vs 2000 just seems to grow/shrink with edge cases.  After comparing the differences between an att_sim of 900 vs 2000, the ordering between the 2 does not change.    So I don't think worrying about the att_sim value really has much of an effect on anything, especially the order (i.e. ranking)
http://i45.tinypic.com/9powon.jpg (agility) 2000 vs 900 att_sim

So Idk, maybe try max possible value, and see if the ranking differences is more profound (see ranking differences in next picture)

here's a picture showing the order differences (i.e. rank) of agility (2nd sheet)
left is regular rank compared with att_sim
the right is regular rank compared with att_sim averaged back with the non att_sim derived percent (i.e. original)
http://i46.tinypic.com/141oyg6.jpg
a regular 1-77, and the second is att_sim= 2000

So it shows the order is slightly different (may not even need averaging, but I'd still prefer it), and only gives slight boosts to dwarf's who have a higher potential gain than those without.  I.e. a few cases.

ranking diff of attribute rating vs sim_rating
29/75

when averaged back with rating
11/75

ranking diff
http://i47.tinypic.com/4gkkmu.jpg

histogram diff
http://i49.tinypic.com/25ip74j.jpg

[Sutremaine]

Can we have an option to sort dwarves by age? It's kind of a niche use, but if you're trying to get dwarves to socialise and marry they have to be fairly close in age (and also not be siblings or parents. Cousins and aunts/uncles may be fine though).

[thistleknot]

Can we have an option to sort dwarves by age? It's kind of a niche use, but if you're trying to get dwarves to socialise and marry they have to be fairly close in age (and also not be siblings or parents. Cousins and aunts/uncles may be fine though).

what state do you live in

[Maklak]

All this talk about attributes makes my head hurt, but I'll try to answer as best as I can.

sim3 gives you the predicted average attribute value during some some hypothethical gain. If you don't hit a cap, it returns "att + att_sim/2" (the formulas it uses do exactly this, except are more complex to handle the second part. After you hit the cap, value returned by sim3 is between "(att_cap+att)/2" and  "att_cap". It increases with att_sim at the speed of "x/(1+x)" (If you really want me to, I can derive the formula for this).
If you don't cap for attribute, then sorting by sim3 is pretty much sorting by att + att_sim/2 and since att_sim is the same for all dwarves, it is the same as sorting by att. I argued with you to get this property. This is why for reasonably low (resembling actual potential to gain for most attributes, like creativity) att_sim, the order doesn't change much and getting att_sim right is not that important.
If some Dwarves start capping out on the attribute because att_sim is big, the caps come into play and those with higher caps can come ahead of those with higher attributes, but lower caps.

Now, why do you need the bins for attributes anyway? For ranking them for the labour optimizer? You said you wanted weighted averages for attributes, but why do you need them in the first place? Unless I understand your motivation and the reasoning behind it, I'm stumbling in the dark here.

> The formula uses 98/7 vs 98/6% for each frequency bin, as we've created a new bin for the values past the 7th raw.
Assuming that 1/7 of each attribute will go above their maximums is rather arbitrary, but I have no suggestions here. 
You also need to account for the fact that some interactions (Vampirism in Vanilla, Power Armour Training in FoE) can raise attributes above this value and possibly even above 5000.

> Note: There is talk of changing the 98/7 to something lower like 90/7 to give values <lowest bin (450 in this case) a larger percent, although not by much, since dwarf's can rust away to 0 attributes).
Attribute rust is quite slow, even for things that aren't ever used, like musicality. I've seen less than 50 point drop over 4 years. I'd say starting really low and rusting below the lowest value for migrants is pretty rare, unless you play for tens of years. It has to be accounted for in some way of course.
For most attributes I counteract the rust by setting a lot of labours not influencing quality for my haulers. They will sometimes butcher an animal or smelt some ore and not rust.

> Then the halfway point would be median no?
Lol, yes. Surprisingly enough the median is... median. That's why I told you that it might be a good idea to compute the "average median" for all castes.
I understand your (median + 3rd_quartile)/2 idea. Yes, this would be the average potential for attribute gain for a dwarf, but again, you would want to average it for all castes. 

> > I still think that taking an old fort and looking at attribute gains there (att -initial) would be a good way to make an informed guess on good att_sim values. They would be good for agility, strength, endurance and so on, OK for things like memory and creativity and negative for musicality.
This is not about current population. This is about assessment of how much each attribute can rust or increase over the course of normal gameplay. I still think it would be very educational in regard to attribute gain to take a 200+ dwarf fort with 10+ years of history and at least 10 multiple legendary champions and for each attribute dump:
max { att - initial }  // maximum gain
min { att - initial }  // worst rust
I'm pretty sure this would shed a lot of light over what att_sim values to choose for each attribute. For example if median is 1000 and maximum gain was around 300, you can pretty much assume dwarves will never cap and simply sort them by current values for that attribute. It is only strength, agility, endurance, toughness, willpower, focus, kinesthethic sense and spatial sense that ever increase by enough to make caps relevant. Well, unless someone mods some attributes to be abysmally low.

> Would it be better to use: median of an attribute's possible gain, [...]
Doesn't matter much in my opinion. All of those are pretty close and pretty high. I'd say try to go for realistic (and different for different attributes) values of att_sim and almost never cap, except in rare circumstances.

> The average of an attribute's possible gain could be derived by [...]
Correct, but as I said, realistic gains would be even better (from an old fort).
I don't even know where to look for it in DT code, but once you can get to att and initial, doing a loop over dwarves and writing the results to a file or log or whatever is maybe 50 lines of extra throwaway code.

> I can't do much with those graphs. They have no labels for x or y, no data sets. I don't even know what I'm looking at. I can only assume you took some attribute, made about 70 values increasing from min to max for it, then fed that and the median to sim3. Maybe you even cross the median around value number 45. If this is the case, then well, it looks as I would expect it to.
Speaking of graphs, those things are ugly. Even in something as crude as Excel you can use lines instead of bars, add more horizontal lines and put dataset values on x.

> actually, looking how the ordering isn't changed, differences between median based vs 2000 just seems to grow/shrink with edge cases.
Working as intended, right?

> So Idk, maybe try max possible value, and see if the ranking differences is more profound
For att_sim up to the median, sim3 ordering is very similar to ordering by current attribute value. For att_sim of 2000 or more, caps become important as well. Since you will hardly ever cap an attribute in Fortress Mode, realistic att_sim are below a thousand. Minor differences in att_sim aren't important, but it still should be the same for all dwarves (well, you could argue that this depends on speed and therefore isn't the same, but let's not go there).

> So it shows the order is slightly different (may not even need averaging, but I'd still prefer it), and only gives slight boosts to dwarf's who have a higher potential gain than those without.  I.e. a few cases.
I have no explanation for irregularities, unless you didn't use att == initial.
Since you will almost never cap an attribute anyway (I think I never did), I'd say the current attribute value is more important than the cap.

> here's a histogram of the ranking shift (just with att_sim 2000)
Results of sim3 depend on both att and initial. Were they different? Which one did you sort by? If they were different and you sorted by initial, that would explain the irregularities. If you sorted by att or att and initial were the same, there shouldn't be any irregularities and there is a (small) error, either on my or on your part.

sim3 is not some tool that will solve your problems with attributes. All it does is simulate attribute gain and return the average attribute value during that time. You could rewrite sim3 with a loop like this (but this is not a smart way to do it):

Code: [Select]

input: att, initial, att_sim, CTI, median
// CTI, att_sim, yada yada.
att_cap = initial + max {initial, median}
int sum = 0;
for (int i=0; i<att_sim; i++)
{ sum += att;
   att++;
   att = min {att, att_cap}
}
sum /= att_sim;
return sum;

[thistleknot]

mk

now, why do you need the bins for attributes anyway? For ranking them for the labour optimizer? You said you wanted weighted averages for attributes, but why do you need them in the first place? Unless I understand your motivation and the reasoning behind it, I'm stumbling in the dark here.

because we want to match the raw values between attributes to each other in terms of percents.

i.e.
strength
450:950:1150:1250:1350:1550:2250

agility
150:600:800:900:1000:1100:1500

we want 450 strength's percent to equal 150 agility's percent
same for the rest of the attribute's raw values.
so 2250 strength = 1500 agility in terms of percent

okay, I think I understand now about attributes and att_sim.  I guess median value is the highest we need to go to then (mainly because they'll hardly ever cap, or possible even hit that much gain).  Sorry I didn't post the sheet that I gen'ed the numbers off of.  I could later if your interested.

The sheet was sorted by attributes rating (or you could say highest attribute value to lowest attribute).

I believe splinterz modded sim3 to not use initial, and instead use the ingame memory value for att_cap that was already derived ingame.