Print

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

[Deon]

I am not sure about "gigantic wolves", brobably it's their 125 length with 125 height/broadness combined or something like this. It's easy to check: make all values of a set the same number and see what it says.

[Zurai]

Would [BODY_APPEARANCE_MODIFIER:BROADNESS:75:75:75:75:75:75:125]
hold a different meaning than
[BODY_APPEARANCE_MODIFIER:BROADNESS:3:3:3:3:3:3:5] (a simplified proportion)?

The scale here is in percent, so it's not just a proportion. In the second example, you will have always extremely thin creatures.

This is not true. After extensive testing and debugging with a personal mod, I discovered that not only are the numbers relative, the position matters. I was trying to determine which direction LENGTH and THICKNESS scaled (ie, is 0 long or short?) and, assuming the same thing you did above, I set a test to 5:5:5:5:5:5:10. Result? Nothing. In other words, average.

After another hour or so spent testing, I was able to determine that the 4th/center value sets the average value and all the others are relative to that value. So, an entry of 5:5:5:100:5:5:5 will return "very short" 6/7 and nothing at all 1/7 of the time, while an entry of 5:5:5:5:5:5:100 will return nothing at all 6/7 the time and "extremely long" 1/7 the time.

I also discovered an oddity with the TL_COLOR_MODIFIER tag. It's supposed to use a weighted average, but it doesn't appear to use the numbers for weights, but rather the position in the list. Items closer to the front of the list are orders of magnitude more likely to appear than items at the end of the list, even if the item at the front has a weight of 1 and the item at the rear has a weight of 10000. The more items there are in the list, the more obvious the difference becomes. Get a long enough list and you'll never, ever see the colors in the second half of the list.

If I had to guess, the TL_COLOR_MODIFIER thing is a bug. I'd guess it's totaling the weights cumulatively; in other words, the first item in the list gets its weight added to the weight of every other item in the list, whereas the final item only gets its own weight.

[Greiger]

This is not true. After extensive testing and debugging with a personal mod, I discovered that not only are the numbers relative, the position matters. I was trying to determine which direction LENGTH and THICKNESS scaled (ie, is 0 long or short?) and, assuming the same thing you did above, I set a test to 5:5:5:5:5:5:10. Result? Nothing. In other words, average.

I had noticed something like that as well.  But I didn't want to mention it until somebody else confirmed. With

Code: [Select]

[SET_BP_GROUP:BY_CATEGORY:HORN]
[BP_APPEARANCE_MODIFIER:LENGTH:10:20:40:50:60:80:90]
[APP_MOD_IMPORTANCE:700]
[APP_MOD_NOUN:horns:PLURAL]I still get members of the caste with "long" or "very long" horns.  Even though the idea was for the particular caste to always list as short.  So maybe it bases the length on the median values or something?  I'm not certain. 

But if it actually modifies the size of the affected bodypart (like it does with body size like broadness)using really low numbers might cause the bodypart to be something like 5% of the size listed in the raws.  So I would still use the % scale when possible.

I also discovered an oddity with the TL_COLOR_MODIFIER tag. It's supposed to use a weighted average, but it doesn't appear to use the numbers for weights, but rather the position in the list. Items closer to the front of the list are orders of magnitude more likely to appear than items at the end of the list, even if the item at the front has a weight of 1 and the item at the rear has a weight of 10000. The more items there are in the list, the more obvious the difference becomes. Get a long enough list and you'll never, ever see the colors in the second half of the list.

Again I seem to be able to confirm this. From the same creature,

Code: [Select]

[SET_TL_GROUP:BY_CATEGORY:ALL:SCALE]
[TL_COLOR_MODIFIER:GREEN:1:DARK_GREEN:1:JADE:1:EMERALD:1]
[TLCM_NOUN:scales:PLURAL] The Green coloration seems to happen in 50% of all members of the caste.  With Dark_green happening in the others.  I have yet to see one with the jade or emerald scale coloration.

[Naros]

I'm wondering how PHYS_RATES_RANGE PHYS_ATT_CAP_PERC work with PHYS_ATT_RANGE.

Say if I wanted to have strong creatures who increase their abilities faster than usual, who do not suffer skillrust and who can improve themselves a lot ( 500% of whatever stat they started out with?), would this be how to do it? :

   

Code: [Select]

[PHYS_ATT_RANGE:STRENGTH:700:1200:1400:1500:1600:1800:2500]             ++
[PHYS_ATT_RATES:STRENGTH:700:NONE:NONE:NONE]
[PHYS_ATT_CAP_PERC:STRENGTH:500]


[soul4hdwn]

I'm wondering how PHYS_RATES_RANGE PHYS_ATT_CAP_PERC work with PHYS_ATT_RANGE.

Say if I wanted to have strong creatures who increase their abilities faster than usual, who do not suffer skillrust and who can improve themselves a lot ( 500% of whatever stat they started out with?), would this be how to do it? :

   

Code: [Select]

[PHYS_ATT_RANGE:STRENGTH:700:1200:1400:1500:1600:1800:2500]             ++
[PHYS_ATT_RATES:STRENGTH:700:NONE:NONE:NONE]
[PHYS_ATT_CAP_PERC:STRENGTH:500]


i don't know what CAP_PERC does but it is the first number in RATES that does what you ask. currently the creature's strength attribute will max out at 7 times greater than what it started on.

[Naros]

No, rates is what controls the speed at which abilities are gained. The default is 500.
cap_perc is the max, in this case 5 times what it started on. The default is 200.

Or atleast so the documentation tells me.
Are you sure?

[soul4hdwn]

No, rates is what controls the speed at which abilities are gained. The default is 500.
cap_perc is the max, in this case 5 times what it started on. The default is 200.

Or atleast so the documentation tells me.
Are you sure?

i'm wrong yay, here: http://www.bay12forums.com/smf/index.php?topic=52902.msg1135181#msg1135181

edit: info is in first part of topic in first post and a bit down the page by toady

[Zurai]

If I had to guess, the TL_COLOR_MODIFIER thing is a bug. I'd guess it's totaling the weights cumulatively; in other words, the first item in the list gets its weight added to the weight of every other item in the list, whereas the final item only gets its own weight.

Just an update: I did some more testing, and this is almost certainly not how it works. I had a string of 16 colors, all but the last of which had a weight of 1, while the last had a weight of 32,000+. That should have produced an almost even distribution of the 16 colors, if my above hypothesis was correct. Unfortunately, only the first 5 colors showed up in a test of over 100 subjects in arena mode, which is statistically very improbable even for that small a sample size.

So really, I have no clue how this actually functions behind the screen, except that it's not as advertised and as far as I can tell the weights are utterly meaningless.

I wonder if it accepts weights of 0? Hmm...