Ideas for 'Expanding' code functionality

Curated Projects Fetish Master
, ,
1

As more mods are being added to the game, I’ve noticed that a lot of the values kept on a character aren’t done in a way that allows for certain types of events.

For example:

The current way the body handles fat is to take a total value, and distribute it based on percentage values with hard caps on those percentages to prevent their combined total from exceeding 100%. While it works for the basic setup, there are some things it can’t do.

  • This system cannot be used to dynamically calculated added or lost fat if the values for the percentage distributions change as fat is gained/lost. If a percentage value changes, it affects not only the added/lost amount, but also what is already present in that organ/area.

  • None of the distribution values can exceed 33% without breaking the engine or requiring a mod/dev-hack to achieve.

This one’s actually a simple enough fix. Using a feature similar to how the game calculates for stretchmarks, you can have the total fat have a current and previous value stored to the character. As for the percentages, There’s a simple formula to check for the values to keep them in scale with one another.

(area) + (areas) + (etc) > 100

or, with the current genes:

(fat-chest) + (fat-waist) + (fat-hips) > 100

Using that as a check, if the total comes up over 100, the next step is to fix a problem when it happens. This would be done with a loop that uses a check something like this:

{(area) + (areas) + (etc) - 100} / (number of areas) =< 0

for now…

{(fat-chest) + (fat-waist) + (fat-hips) - 100} / 3 =< 0

The number of areas is important for later, as it allows this feature to be expanded when other organs and their fat content become implemented (such as butt, legs, arms, all that fun stuff). As long as this check is FALSE, you use that formula to make a number that gets applied to each of the fat values to scale them all down relative to one another.

Something like:

check = {(area) + (areas) + (etc) - 100} / (number of areas)
While (check >= 0) Do
{
red_val = check
new_area = (area * red_val) * (red_val / 100)
new_areas = (areas * red_val) * (red_val / 100)
new_etc = (etc * red_val) * (red_val / 100)
// add more values here when new fat placements are added

area = new_area
areas = new_areas
etc = new_etc
// see above comment

check = {(area) + (areas) + (etc) - 100} / (number of areas)
// make sure all formulas used have the full list of areas in them as well as the proper number to divide by
}

if (area + areas + etc < 100)
{
fat-left = 100 - (area + areas + etc)
}

From there, it can do the fat distribution by using the current and previous fat totals to add/subtract with the updated values. If it looks a little confusing without numbers, then here’s an example.

breasts = 54
waist = 30
hips = 40

check_over = (55) + (31) + (40)
// in this example, check_over = 126

while (check_over) > 100
{
check_redo = {(check_over) - 100} / 3
// in this example, check_redo = 8

new_breasts = (55 * 8) *(8 / 100)
new_waist = (31 * 8) * (8 / 100)
new_hips = (40 * 8) * (8 / 100)
// in order, the new values are: 35.2, 19.84, and 25.6

breasts = (35.2)
waist = (19.84)
hips = (25.6)
// numbers would be replaced by the names for new_breasts, new_waist , and new_hips in the actual code

check_over = {(35.2) + (19.84) + (25.6)
// total comes up to 80.64 before subtraction of 100, loop ends
// may consider hard capping the decimals to prevent loop running infinitely.
}

if check_over < 100
{
left_fat = 100 - {(25.2) + (19.84) + (25.6)}
// in this example, fat_left = 19.36
}

// Results:
// breasts = 35.2
// waist = 19.84
// hips = 25.6
// left_fat = 19.36

Okay, so it’s imperfect what with the leftover value being kind of large, but it does reduce the allotted total below 100 without messing up the non-remainder values’ relative to one another which was the primary issue. At this point, the calculations can carry out about the same way they used to, but instead of the engine redistributing all of the person’s fat, it just takes the difference of the current from previous volumes and adds/subtracts that result.

fat_mod = fat_now - fat_then

fat_breasts = fat_breasts + (breasts / 100) * fat_mod
fat_waist = fat_waist + (waist / 100) * fat_mod
fat_hips = fat_hips + (hips / 100) * fat_mod
fat_left = fat_left + (left_fat / 100) * fat_mod

So, if the numbers before calculation are are:

fat_breasts = 275
fat_waist = 250
fat_hips = 375
fat_left = 100
calorie_add = 200
// this is fetched by adding the result of the calorie conversion to fat_then, pretty much the same way it has been
// if it wasn’t for wanting the potential to lose fat, just using calorie_add and fat_total would’ve worked

fat_then = (275) + (250) + (375) + (100)
// in this example, the total is 1000

fat_now = fat_then + calorie_add
// in this example, the total is 1200

fat_mod = (1200) - (1000)
// in this example, the total is 200

// This will be using the percentages from the previous example
fat_breasts = (275) + (35.2 / 100) * (200)
fat_waist = (250) + (19.84 / 100) * (200)
fat_hips = (375) + (25.6 / 100) * (200)
fat_left = (100) + (19.36 / 100) * (200)

// this system’s results are:
// fat_breasts = 345.4
// fat_waist = 289.68
// fat_hips = 426.2
// fat_left = 138.72

//old system’s results would be:
// fat_breasts = 422.4
// fat_waist = 238.08
// fat_hips = 307.2
// fat_left = 232.32

With this in place, the engine would only use the 200 units worth with the new percentages instead of the full 1200. To make this system play nice with mods like the ‘Watermelon Special’ body mod, just have the event set the previous volume to 0 for both the total and individual area values when it recalculates the fat distribution to replicate how the old system handled fat distribution.

This next bit could be used as a model to handle fat distribution just so the system doesn’t go through all of the motions every time an hour goes by when the proxy hasn’t had a change in their fat totals.

if (fat_mod != 0)
{
// do all the stuff for check_ over

// do fat_recalc for each organ
}

This is just one step, as it might help to move all the fat calculations into their own organ, if just to minimize the amount of code that needs to be added.

There’s more I had in mind for overhauls/additions to the base system, but that’ll be in another post.

2

I think the biggest problem you’ll run into is one of performance. abdomen.recalc_fat gets called every hour of in game time and including a while loop in your calculations could give a performance hit. I’m not against the idea at all. In fact I’d say give it a try and see how it works out. it is definitely a problem that needs addressing and maybe this is a way to do that.

3

Fat distribution subsystem currently not good by design. At the times of adding it, I been tired with fixing some other parts of code, and as I can see now, I did it somewhat a lame way. As I can see now, it’s need a redesign, not just the tweaking. Sorry for this.

4

Risking being a total ass, I’d like to ask something about the game/mods. Are there other ways atm. to keep proxies’ asses clean than deleting their colons? (A very efficient method that one, no doubt. Just appears a bit suspicious to me, because… pressures might get unbearable finally!) There must be potent reasons why the colons get dirty - even I can imagine some - and I realize I am actually quite stupid getting agitated about a minor thing like that. Also it is not a big deal to wipe a few dozen butts every now and then, a little bit repetitive and quite time-consuming though. I’d very much like to learn about ‘an automate ass-wipe’ or something in case they are available in some mod or by some (preferably simple) tweak I could myself easily insert in the game. Constant wiping was the reason I stopped playing this great game a few years back. It still baffles me why the proxies couldn’t clean their colons themselves.
Sorry in case I left this awkward question in wrong place. Even more sorry if I happened to leave some bad ideas to folks here. Basically just curious about delicate matters, you see.

5

[quote=“tsap, post:4, topic:812”]Risking being a total ass, I’d like to ask something about the game/mods. Are there other ways atm. to keep proxies’ asses clean than deleting their colons? (A very efficient method that one, no doubt. Just appears a bit suspicious to me, because… pressures might get unbearable finally!) There must be potent reasons why the colons get dirty - even I can imagine some - and I realize I am actually quite stupid getting agitated about a minor thing like that. Also it is not a big deal to wipe a few dozen butts every now and then, a little bit repetitive and quite time-consuming though. I’d very much like to learn about ‘an automate ass-wipe’ or something in case they are available in some mod or by some (preferably simple) tweak I could myself easily insert in the game. Constant wiping was the reason I stopped playing this great game a few years back. It still baffles me why the proxies couldn’t clean their colons themselves.
Sorry in case I left this awkward question in wrong place. Even more sorry if I happened to leave some bad ideas to folks here. Basically just curious about delicate matters, you see.[/quote]

I honestly just remove the description line for colon stuff for my personal use. The only place the stat is checked is in the brothel i think when doing anal sex with a customer. I never do that so it doesn’t bother me. It should be easy to just replace the conditions for that specific event with just “0”(meaning it would always return false).

6

After trying to implement the new fat distribution system, I realized it may require more restructuring of the organ script and perhaps some tampering with the genes’ built-in script portion that I don’t feel comfortable testing at this time…

Given how complex some creatures may become as the game develops, the engine should allow one to set priority for which organs recalculate first when the clock advances. This would help ensure that values are updated in the correct order, even if a template loads the organs in a different sequence than normal. It could also save lines in the “organ_recalc” codes by having the requisite actions happen on a higher priority than the recalc that needs the information from it. The actions and next-hour script do help in this regard, but there may eventually be a situation where a modder tries to make a new creature (or parts for one), but its values come up incorrect because it calculated a given organ before recalculating the intended organ(s)/modification(s) first or some similar oversight brought on by a yet-unknown bug in sorting organs under the current system.

If there’s a simple way to avoid this with the current engine it would be worth adding that to a tutorial posts around here.


In lieu of this, I decided to try something completely unrelated, but still somewhat useful:

Support for hair(/fur?) consistency and hair/eye shades.

Currently the hair consistency has 4 ranges, straight, wavy, curly, and frizzy. The shades have 3 values for darker shades, 3 values for lighter shades, plus a blank value for a neutral shade (not lighter or darker than average). The genes work the same way those for hair/eye color do, and allow for custom text values the same way that the colors for Vicky and Belanika do. This opens up for things like custom values for certain effects like greased/gelled hair via a salon or some-such (and glowing eyes for the supernatural, perhaps?) if the mods or main game ever implement it. I plan to expand the shades another value in each direction (totaling 8+1), but couldn't find a decent way to describe "hair/eyes so dark one only sees its color when light reflects off of them" in somewhere under 4 or 5 words with the color at the end.

I have it functional in my current work-space for the Agency-generated proxies, just need to tweak the genes/description as mentioned above and redo a portion of the script so it checks for the blank, ''neutral' entry's response instead of its numerical value. The only real hurdle for this mod would be setting up the genes in question for all the pre-established NPCs, if only because of minor disagreements on what choices would be made.

I'll probably also add eye shapes before releasing this, but I figured it was worth announcing it for now. Suggestions for wording as well as the NPCs' descriptors are also welcome and appreciated.

For now, I don't plan on doing similar for skin color/shade because that'll require a more dynamic approach to ensure that not only the templates check correctly, but that the genes themselves assign base color for the correct description file (it's still bound to get messy with cross-breeding). This will be an issue more when other races are added, particularly those like demons and elf-variants or those with fur/scales.

(Meta Note: a scripting guide [i]within the game's Dev Mode[/i] could prove a fun little project for the community. It wouldn't need to be much more than a series of events/templates crammed into the already existing Debug menu. Perhaps adding pictures of the in-game text at a later point.)
7

Does the engine not support lists or arrays or other collection? Because that would seem to be the better, more scalable, more maintainable solution here: just put all the organs/values/areas in an array/list/map/whatever, and iterate over them all, however many there are, in a loop, instead of forcing yourself or other future modders to hardcode new values in all the places.

check = {(area) + (areas) + (etc) - 100} / (number of areas) While (check >= 0) Do { red_val = check new_area = (area * red_val) * (red_val / 100)

I see where you’re coming from with this, but I think there’s a more direct way to do it, that does not require the while loop, or the confusing red_val^2 thing you’ve going on there.

To get the actual total of all the areas back to 100, you just need to multiply it by a scaling factor
total = (area1 + area2 + … + area_n)
100 = total * (100/total)

Therefore, to fix the scaling of the individual values, you’d also multiply each of them by the same scaling factor
new_area = area * (100/total)
Just watch the floating value precision, or rounding.

The number of areas is important for later, as it allows this feature to be expanded when other organs and their fat content become implemented (such as butt, legs, arms, all that fun stuff).
Arms and legs and butts and fun stuff? Dude, I'm begging, would you please consider doing an actual clothing system? That supports sizes and possibly even bursting?
8

Does the engine not support lists or arrays or other collection? Because that would seem to be the better, more scalable, more maintainable solution here: just put all the organs/values/areas in an array/list/map/whatever, and iterate over them all, however many there are, in a loop, instead of forcing yourself or other future modders to hardcode new values in all the places.

check = {(area) + (areas) + (etc) - 100} / (number of areas) While (check >= 0) Do { red_val = check new_area = (area * red_val) * (red_val / 100)

I see where you’re coming from with this, but I think there’s a more direct way to do it, that does not require the while loop, or the confusing red_val^2 thing you’ve going on there.

To get the actual total of all the areas back to 100, you just need to multiply it by a scaling factor
total = (area1 + area2 + … + area_n)
100 = total * (100/total)

Therefore, to fix the scaling of the individual values, you’d also multiply each of them by the same scaling factor
new_area = area * (100/total)
Just watch the floating value precision, or rounding.

The number of areas is important for later, as it allows this feature to be expanded when other organs and their fat content become implemented (such as butt, legs, arms, all that fun stuff).
Arms and legs and butts and fun stuff? Dude, I'm begging, would you please consider doing an actual clothing system? That supports sizes and possibly even bursting?[/quote]

Adding a clothing system would be a ton of work. Just saying.

9

Oh yeah, potentially a ridiculous amount, depending on how it’s implemented and how detailed. I didn’t mean to suggest otherwise; I just thought I’d toss out a hopeful request, since it sounded like s/he is already planning to track size & fatness of limbs, etc. :slight_smile:

10

Oh yeah, potentially a ridiculous amount, depending on how it’s implemented and how detailed. I didn’t mean to suggest otherwise; I just thought I’d toss out a hopeful request, since it sounded like s/he is already planning to track size & fatness of limbs, etc. :)[/quote]

I’ve thought about doing it myself, but decided against it because of limitations in the scripting system and the time involvement it would take

11

[quote=“docarrol, post:7, topic:812”][quote=“Lurch_004, post:1, topic:812”]check = {(area) + (areas) + (etc) - 100} / (number of areas)
While (check >= 0) Do
{
red_val = check
new_area = (area * red_val) * (red_val / 100)[/quote]

I see where you’re coming from with this, but I think there’s a more direct way to do it, that does not require the while loop, or the confusing red_val^2 thing you’ve going on there.

To get the actual total of all the areas back to 100, you just need to multiply it by a scaling factor
total = (area1 + area2 + … + area_n)
100 = total * (100/total)

Therefore, to fix the scaling of the individual values, you’d also multiply each of them by the same scaling factor
new_area = area * (100/total)
Just watch the floating value precision, or rounding.[/quote]

I like the elegance of this in terms of how little needs to be done, but testing it as given (using the example numbers because lazy) actually resulted in larger numbers, not smaller ones. Flipping the total and 100 in the second formula gets a result closer to what you were intending.

For reference, none of the values were rounded up.

total = (55 + 31 + 40) //area_1, area_2, and area_3 from example //total = 126 red_val = 126 * (100 / 126) //red_val ~ 79.365079365079365079365079365079 //red_val ~ 79.365 for this test.

//formula is area_# * (100 / red_val)

new_area_1 = 55 * (100 / 79.365)
//new_area_1 = 69.3

new_area_2 = 31 * (100 / 79.365)
//new_area_1 = 39.06

new_area_2 = 40 * (100 / 79.365)
//new_area_1 = 50.4

//formula is area_# * (red_val / 100)

new_area_1 = 55 * (79.365 / 100)
//new_area_1 = 43.65

new_area_2 = 31 * (79.365 / 100)
//new_area_2 = 24.603

new_area_2 = 40 * (79.365 / 100)
//new_area_3 = 31.746

total = (43.65 + 24.603 + 31.746)
//total = 100.017

It works, but the loop looks like it will need to iterate again. This version would also still need the addition of code when other body parts are factored in via mods/updates. I remember there being mention of support for a list system in the more recent base builds of the game, but h.coder didn’t really elaborate too much on what they can and can’t support at this time.


I noticed something when using the ProxyGen mod that I wanted to try and mess with. Its current setup runs it as a series of events, but that causes a problem. Depending on how many times you re-roll a character, a player can advance the game clock before the game has technically begun.

Having said that, I wanted to try turning that mod into an Interaction event similar to the sex/battle systems. It could use flags to set whether the player has specified a value for a given trait as well as the trait in question, then 'clear' once all the choice flags are "true".

Another idea I was toying with was how to split the legs from the body for code/calculation purposes. This does two things. The first would be to allow for the much awaited butt(/thigh) implementation, the second is to allow for non-human lower halves such as serpentine or tauric bodies.

I have a few bits of information at this time, but nowhere near assembled in a way that I could test it yet.


I added an age descriptor to the appearance mod I've been working on, but I feel like I should ask if the getAge() command has a modifier that can be tacked on to it to give the result in years instead of hours. The workaround I'm using now added a few lines of code to the human_body organ that probably aren't really needed.
12

[quote=“Lurch_004, post:11, topic:812”][quote=“docarrol, post:7, topic:812”][quote=“Lurch_004, post:1, topic:812”]check = {(area) + (areas) + (etc) - 100} / (number of areas)
While (check >= 0) Do
{
red_val = check
new_area = (area * red_val) * (red_val / 100)[/quote]

I see where you’re coming from with this, but I think there’s a more direct way to do it, that does not require the while loop, or the confusing red_val^2 thing you’ve going on there.

To get the actual total of all the areas back to 100, you just need to multiply it by a scaling factor
total = (area1 + area2 + … + area_n)
100 = total * (100/total)

Therefore, to fix the scaling of the individual values, you’d also multiply each of them by the same scaling factor
new_area = area * (100/total)
Just watch the floating value precision, or rounding.[/quote]

I like the elegance of this in terms of how little needs to be done, but testing it as given (using the example numbers because lazy) actually resulted in larger numbers, not smaller ones. Flipping the total and 100 in the second formula gets a result closer to what you were intending.

For reference, none of the values were rounded up.

total = (55 + 31 + 40) //area_1, area_2, and area_3 from example //total = 126 red_val = 126 * (100 / 126) //red_val ~ 79.365079365079365079365079365079 //red_val ~ 79.365 for this test.

//formula is area_# * (100 / red_val)

new_area_1 = 55 * (100 / 79.365)
//new_area_1 = 69.3

new_area_2 = 31 * (100 / 79.365)
//new_area_1 = 39.06

new_area_2 = 40 * (100 / 79.365)
//new_area_1 = 50.4

//formula is area_# * (red_val / 100)

new_area_1 = 55 * (79.365 / 100)
//new_area_1 = 43.65

new_area_2 = 31 * (79.365 / 100)
//new_area_2 = 24.603

new_area_2 = 40 * (79.365 / 100)
//new_area_3 = 31.746

total = (43.65 + 24.603 + 31.746)
//total = 100.017

It works, but the loop looks like it will need to iterate again. This version would also still need the addition of code when other body parts are factored in via mods/updates. I remember there being mention of support for a list system in the more recent base builds of the game, but h.coder didn’t really elaborate too much on what they can and can’t support at this time.


I noticed something when using the ProxyGen mod that I wanted to try and mess with. Its current setup runs it as a series of events, but that causes a problem. Depending on how many times you re-roll a character, a player can advance the game clock before the game has technically begun.

Having said that, I wanted to try turning that mod into an Interaction event similar to the sex/battle systems. It could use flags to set whether the player has specified a value for a given trait as well as the trait in question, then 'clear' once all the choice flags are "true".

Another idea I was toying with was how to split the legs from the body for code/calculation purposes. This does two things. The first would be to allow for the much awaited butt(/thigh) implementation, the second is to allow for non-human lower halves such as serpentine or tauric bodies.

I have a few bits of information at this time, but nowhere near assembled in a way that I could test it yet.


I added an age descriptor to the appearance mod I've been working on, but I feel like I should ask if the getAge() command has a modifier that can be tacked on to it to give the result in years instead of hours. The workaround I'm using now added a few lines of code to the human_body organ that probably aren't really needed.[/quote]

Nice ideas. I don't have much to comment on them atm
13

[quote=“Lurch_004, post:11, topic:812”][quote=“docarrol, post:7, topic:812”]To get the actual total of all the areas back to 100, you just need to multiply it by a scaling factor
total = (area1 + area2 + … + area_n)
100 = total * (100/total)

Therefore, to fix the scaling of the individual values, you’d also multiply each of them by the same scaling factor
new_area = area * (100/total)
Just watch the floating value precision, or rounding.[/quote]

I like the elegance of this in terms of how little needs to be done, but testing it as given (using the example numbers because lazy) actually resulted in larger numbers, not smaller ones. Flipping the total and 100 in the second formula gets a result closer to what you were intending.

For reference, none of the values were rounded up.[/quote]
Oh? That’s strange, let me double check my thinking; it was late when I wrote that, I could easily have done something dumb there.

So algebraically, that should be:
100 = total * (100/total) = 100 * (total/total) = 100 * 1 = 100
So the scaling factor is (100/total)

And
(a + b + c + …) * (100/total) = (a * 100/total) + (b * 100/total) + (c * 100/total) + …

But let’s try it with real numbers

total = (55 + 31 + 40) = 126

total * (100/total) = 126 * (100 / 126) = 126 * 0.7936507937 = 100.0

I think you multiplied by 100 in that last step, instead of by total. That’s why you were seeing 79.365… at that point.

total * (100/total) = (55 + 31 + 40) * (100/126) = (55 * 100/126) + (31 * 100/126) + (40 * 100/126)
55 * (100/126) ~ 43.6507936508
31 * (100/126) ~ 24.6031746032
40 * (100/126) ~ 31.746031746

And in this part, you were using (100 / 79.365), instead of (100 / 126), so that’s why your numbers were getting bigger rather than smaller

Then as a cross-check of the results
43.6507936508 + 24.6031746032 + 31.746031746 ~ 100
Which is what we were looking for. Victory!

But normally, I wouldn’t carry that many places past the decimal point, as those extra digits are meaningless, and more than even a modern computer can carry around without floating point rounding errors. In general practice, you might consider rounding to 1 or two decimal places, as a last step after any series or calculations, for anything that doesn’t require the extra precision. (but only as a last step, or you’ll definitely be throwing rounding errors in the middle of your calculations, and besides there’s no point in doing the extra work of rounding twice).

You should double check my math here, but I think with those two changes it should be working as intended.

As for the rest of it: Good luck! Sounds like you have some interesting ideas, I’ll be waiting to see how it works out :slight_smile:

14

After trying to read that formula and frying my brain a bit at in a vain attempt to sort the redundancy out, I plugged it all into a spreadsheet to see if it’d work. So long as the numbers are all handled by the same system, your solution works without need of iteration. Mine actually gets pretty loopy and seems to result in over-the-top inflation of the value after a certain threshold. At this point, the only gripe I have with it is that you’d need to factor in the value meant to account for excess when performing the iteration if one intends to preserve it, because the total for that method results in a clean 100 so long as a floating error doesn’t occur.


I fiddled with the height gene and body organ and have the base framework for the legs complete. The torso and legs now have their own individual heights that keep within the generators' ranges from when they were a single total height; the edits to the organ just make the engine add the heights together to ensure that none of the script checks for height need to be edited. Needless to say, the change to the organ and genes will destroy compatibility, but that comes in time.

The next step will be to adjust how the engine calculates the base weights for the respective halves and get them slightly under the current values. This will allow room for the butt organ's weight to be added without affecting what the average player will see.
15

I guess I must have misread your first post then, because I thought that’s what you were trying to get: The new percentages of each or the individual areas, when an arbitrary amount has been added to one or more, which violated the 100% requirement of H.Coder’s engine. The sum of all the renormalized percentages had better add up to 100% again after, or I set up the equations wrong.

But if that’s not what you were going for, you’ll have to dumb it down and explain it to me again, and I’ll see if I can rejigger my formula to do that, instead.

16

The goal was actually to derive a number I could use to “math at” the individual values so they’d come up to 100 or less when totaled. The total reaching 100 was more a secondary objective than a primary one. Having them come up to 100 total exactly defeats the point of having the leftover value if this script runs every hour. The whole point of that value is to distribute whatever isn’t assigned to any given area by the other values.

So again: I was trying to derive a formula that results in a number I can apply to individual values to bring their new total to 100 or lower.


More spreadsheet sorcery has resulted in a complex weight calculator, which even goes so far as to reverse-calculate values for a subject if just the age, height, and gender are known. It's still terribly inefficient, but it has yielded otherwise promising results such as reverse-calculating the middle-range for ankle and wrist circumference as well as several other values that could prove useful. I'm not sure whether I should just implement 1 of the 16 other formulas I got functional in the spreadsheet, or make a mish-mash of those that give a value close to the one the engine uses already.
17

[quote=“Lurch_004, post:16, topic:812”]The goal was actually to derive a number I could use to “math at” the individual values so they’d come up to 100 or less when totaled. The total reaching 100 was more a secondary objective than a primary one. Having them come up to 100 total exactly defeats the point of having the leftover value if this script runs every hour. The whole point of that value is to distribute whatever isn’t assigned to any given area by the other values.

So again: I was trying to derive a formula that results in a number I can apply to individual values to bring their new total to 100 or lower.[/quote]
If all you want is a number smaller than

newArea1 = area1 * (100/total)

is giving you, then you can use

newArea1 = area1 * (100/(total + x))

Or

newArea1 = area1 * (100/(total * x))

where “x” is any positive value greater than 0. You can use the same “x” for all areas or set them individually if you want, although if you do use the same one for all areas, that gives you just one “knob to turn” to control the scaling of all of them at once. The bigger you make “x”, the smaller the resulting new value.

But I guess I’m still not quite following your explanation of what you’re doing and why. Let me try again:

I think what you’re saying is that you’re getting some leftover value where

total = area1 + area2 + area3 + ... leftover = total - 100
And you want to distribute a chunk of that “leftover” amount to each of the individual areas, in a way that’s proportional to the amount being added to each area? Or you’re looking to find how much of the “leftover” belongs to each area?

If that’s correct then I think what you’re asking for is

[code]newArea1 = (area1 * (100/total)
area1_leftover = leftover * (area1 * (100/total))

newArea2 = (area2 * (100/total)
area2_leftover = leftover * (area2 * (100/total))

etc.
[/code]

More spreadsheet sorcery has resulted in a complex weight calculator, which even goes so far as to reverse-calculate values for a subject if just the age, height, and gender are known. It's still terribly inefficient, but it has yielded otherwise promising results such as reverse-calculating the middle-range for ankle and wrist circumference as well as several other values that could prove useful. I'm not sure whether I should just implement 1 of the 16 other formulas I got functional in the spreadsheet, or make a mish-mash of those that give a value close to the one the engine uses already.
You should always do what fits your vision best, but personally, I try and minimize the number of different ways of doing things, as it makes debugging, maintainance, and future updates so much easier in the future when you only have to change one thing in one place, instead of 16 things in 16 places, or even 1 thing in 16 places. So the [url=https://en.wikipedia.org/wiki/KISS_principle]KISS Principle[/url] is a way of life ;)
18

I will try those soon, docarrol.


In the meantime, I finished the calculator spreadsheet I mentioned earlier.

To use it, simply pick the gender from the drop-down menu in the wider dark orange cell then give it whatever numbers you happen to have in the ones below it. The more values you have, the more accurate the results become.

The cells with the orange numbers under the "Estimates" column can be used if you don't have a number to put in the dark orange cells, but be aware that they are guesses and trying to get them all to match up will drag your results off-course. Also note that these will only be averages, so there's a margin of error to be had if you dislike a result. It's best to just fiddle with the values you were missing until the estimates stop changing.

I hope someone finds this useful for improving the engine, or maybe even just getting more complex data for a character you had planned.