The C.A.N.S. (Cooperative Algebraic Node Sizing) Framework

[Feliks]

 

Hookmmerse is the biggest crap I have ever seen...

 

Why not use NiOverride? NetImmerse is pointless when it doesn't run fast, and when you want compatibility NiOverride is superior to draging scaling calls through a whole papyrus framework..

 

From what I understand NIOverride requires the mod author to use it instead of netimmerse, and that just hasn't happened for some mods? Or am I missing something.

 

If so, Hookmmerse helps me, as a user, to actually use those mods together (and has been for a while now).

 

 

See, the great thing about CANS is that if CANS uses NiOverride, other mods don't even need to worry about it, because they won't be calling node changes directly, only CANS should do that, or you end up with the exact conflicts CANS was created to prevent/solve.

[darkconsole]

 

 

Honestly arrays seemed like the best way to handle the pointers, but my knowledge is based mostly on other languages. The 128 limit came from the max array size, but that's really simple to work around, it just didn't seem like a pressing issue considering nothing actually talks to C.A.N.S. yet but I will be extending that in the next release. If you look through my code you'll notice there's some weird set up with the node size array too, that's all getting changed too to run from separate arrays with the extended limit as well.

Would you happen to know a good way around the magic effect's falling off the NPC's? 

 

Most of the suggestions I've seen so far are better ways to implement sizing, at least math is easy to code though.

 

 

the answer to the magic effect question: no. in untamed i ended up implementing a cherry bomb to check my nearby pack members to make sure they still had the effects on them, and if not, renew them. its ghetto as fuck but there wasn't much else to do.

 

[update] Soulgem Oven, in order to recalculate nearby NPC, the PC emits a cherry bomb aoe every 5 seconds. this aoe pings a script to every NPC valid to hit, and goes away rright after. it doesn't stay on like an ability script or anything. so it hits everyone around, each hit recalculate the actor it hits, and goes away.

 

for the array size: StorageUtil. it comes with sexlab, and as a standalone library called PapyrusUtil.  StorageUtil.FormListAdd and related functions for infinite savegame bloat, but without the bulk of jcontainers.

 

another technical dilemma you will face is temporary actors - for example hunters, vigilants of stendaar, etc, basically any npc without a real name. when the game deletes these actors two things can happen:

 

first your save data will basically be stranded in the middle of an island that has no pointers pointing at it anymore. the second problem is when the game deletes these actors, it will often reuse the form ids for new temporary actors later. basically a memory leak, where potentially you just keep stockpiling metadata that belongs to no one. but this next problem is way more hillarious.

 

i had this problem where you would meet a wolf, but spawn a whiterun guard a few hours alter when you tried to summon the wolf. i ended up having to engage a clever but unwise persistance hack to make sure the actors live for the length that their metadata i have stored away lives. but this problem means if you store metadata for a sexy hunter, there is a chance in a few hours that data is now pointing at a bear in the cave you just walked into.

 

there is actually a third thing that could happen. the game will crash upon attempting to access the lost/stale/unpointed data. its really hit and miss when it decides to go tits up about it.

[darkconsole]

i bring all this up to your attention because a while back ago someone started a thread with all the preggo mod authors attempting to devise a way where our bodyscales could work together in a way that made more visual sense than nio's multiplicative system.

 

the result of the chat was, nobody gave a fuck. i offered two solutions, one of which was to write the mod you are now writing. the response i got to that was "even if it existed we dont care enough to update because someone else wont care enough to update either"

 

so, you are basically attempting what i gave up on. i want to make sure you account for all the issues, not like, demotivate you.

[Expired6978]

i bring all this up to your attention because a while back ago someone started a thread with all the preggo mod authors attempting to devise a way where our bodyscales could work together in a way that made more visual sense than nio's multiplicative system.

 

the result of the chat was, nobody gave a fuck. i offered two solutions, one of which was to write the mod you are now writing. the response i got to that was "even if it existed we dont care enough to update because someone else wont care enough to update either"

 

so, you are basically attempting what i gave up on. i want to make sure you account for all the issues, not like, demotivate you.

That's because multiplicative is the only way that makes sense. You cant invert an average. It's a one-way computation. I can add a toggle to do averaging for scales if you really want, but it'll be hacky.

 

NetImmerse normally packs all the transforms into an NiTransform object, it includes scale, position, and rotation. All of the operations you do on this object have overloads for the operators, so I basically store all the modifications to the key as an NiTransform, then when it computes the result it just multiplies them all together.

 

transform = t1 * t2 * t3 * ...

 

I would need to special case this to assume 1.0 for scale, then manually compute the average.

 

 

If you want an average you could actually manage that yourself if you wanted. NiOverride gives you access to all keys to a node, so you can get all the keys, make an average, then delete all the keys and make your merged average. This assumes the other mod isn't constantly setting the key value.

[Groovtama]

1. ninode are based of vectors, a scalar "a" for a vector "x" results in "a * x = y" a scalar b for the already scaled vector y is "b * y" => "b * (a * x)"

 

2. (b + a) * x would be a vector addition of two scaled vectors (a * x) + (b * x) which does not make sense.

 

if you don't want 5 mods scaling the breast node by 8 then put fucking guards in your mods or look if a mod already has its transform on the node, you can make a fucking blacklist with nio like this !NiOverride.HasTransform(actor, "modIdontliketoscalewith") then scale, else remove my scales.

 

and btw

 

(b * a) * x = (b + a) * x 

-> (b * a) = (b + a)

-> for what value v is (b * a) = (b + a)

-> (b * a) * v = (b + a)

-> v = (b + a)/(b * a)

for an extra scale transform with value v added to (b * a), (v * (b * (a *x))) will equal (b + a) * x, that works with an infinite number of values not just with two.

[chajapa]

holy shit... like.... MATHS!.... my brain hurts.

 

I'm watching this because I think it would be nice to have. I also looked at hookimmerse and even with my limited background decided it was a horrible hack that was GOING to break things.

 

It just seems so odd to me that we have this environment where we are manipulating the size of body parts, but no central control for the scaling. As a non-programmer, but wearing a project manager hat (retired.... don't want a job, thank you... heheheh).... it's like the central controller should have come first and anything wanting to change a scale sends the request to the controller and the controller is the only thing actually making scale changes. Which is what it looks like this is trying to do or... be... but with the number of mods existing, already doing this scaling individually without regard for what another mod may be doing (yes, I know there are exceptions) I think you're in for a tough road here.

 

Getting mod authors on board, even after you finalize something that WORKS.... could be tough.

[mangalo]

(b * a) * x = (b + a) * x

 

What

 

You're saying that (2*3)*4 = (2+3)*4

[Feliks]

holy shit... like.... MATHS!.... my brain hurts.

 

I'm watching this because I think it would be nice to have. I also looked at hookimmerse and even with my limited background decided it was a horrible hack that was GOING to break things.

 

It just seems so odd to me that we have this environment where we are manipulating the size of body parts, but no central control for the scaling. As a non-programmer, but wearing a project manager hat (retired.... don't want a job, thank you... heheheh).... it's like the central controller should have come first and anything wanting to change a scale sends the request to the controller and the controller is the only thing actually making scale changes. Which is what it looks like this is trying to do or... be... but with the number of mods existing, already doing this scaling individually without regard for what another mod may be doing (yes, I know there are exceptions) I think you're in for a tough road here.

 

Getting mod authors on board, even after you finalize something that WORKS.... could be tough.

 

Noted.

 

 

i bring all this up to your attention because a while back ago someone started a thread with all the preggo mod authors attempting to devise a way where our bodyscales could work together in a way that made more visual sense than nio's multiplicative system.

 

the result of the chat was, nobody gave a fuck. i offered two solutions, one of which was to write the mod you are now writing. the response i got to that was "even if it existed we dont care enough to update because someone else wont care enough to update either"

 

so, you are basically attempting what i gave up on. i want to make sure you account for all the issues, not like, demotivate you.

That's because multiplicative is the only way that makes sense. You cant invert an average. It's a one-way computation. I can add a toggle to do averaging for scales if you really want, but it'll be hacky.

 

NetImmerse normally packs all the transforms into an NiTransform object, it includes scale, position, and rotation. All of the operations you do on this object have overloads for the operators, so I basically store all the modifications to the key as an NiTransform, then when it computes the result it just multiplies them all together.

 

transform = t1 * t2 * t3 * ...

 

I would need to special case this to assume 1.0 for scale, then manually compute the average.

 

 

If you want an average you could actually manage that yourself if you wanted. NiOverride gives you access to all keys to a node, so you can get all the keys, make an average, then delete all the keys and make your merged average. This assumes the other mod isn't constantly setting the key value.

 

 

I will take that approach into account, the issue with relying entirely on that is (as far as I can tell) most mods do not rely on NiO but NetImmerse. Either way, CANS will effectively just be a collection of ways to calculate the new unified modification size.

 

i bring all this up to your attention because a while back ago someone started a thread with all the preggo mod authors attempting to devise a way where our bodyscales could work together in a way that made more visual sense than nio's multiplicative system.

 

the result of the chat was, nobody gave a fuck. i offered two solutions, one of which was to write the mod you are now writing. the response i got to that was "even if it existed we dont care enough to update because someone else wont care enough to update either"

 

so, you are basically attempting what i gave up on. i want to make sure you account for all the issues, not like, demotivate you.

 

Noted.

 

 

 

 

Honestly arrays seemed like the best way to handle the pointers, but my knowledge is based mostly on other languages. The 128 limit came from the max array size, but that's really simple to work around, it just didn't seem like a pressing issue considering nothing actually talks to C.A.N.S. yet but I will be extending that in the next release. If you look through my code you'll notice there's some weird set up with the node size array too, that's all getting changed too to run from separate arrays with the extended limit as well.

Would you happen to know a good way around the magic effect's falling off the NPC's? 

 

Most of the suggestions I've seen so far are better ways to implement sizing, at least math is easy to code though.

 

 

the answer to the magic effect question: no. in untamed i ended up implementing a cherry bomb to check my nearby pack members to make sure they still had the effects on them, and if not, renew them. its ghetto as fuck but there wasn't much else to do.

 

[update] Soulgem Oven, in order to recalculate nearby NPC, the PC emits a cherry bomb aoe every 5 seconds. this aoe pings a script to every NPC valid to hit, and goes away rright after. it doesn't stay on like an ability script or anything. so it hits everyone around, each hit recalculate the actor it hits, and goes away.

 

for the array size: StorageUtil. it comes with sexlab, and as a standalone library called PapyrusUtil.  StorageUtil.FormListAdd and related functions for infinite savegame bloat, but without the bulk of jcontainers.

 

another technical dilemma you will face is temporary actors - for example hunters, vigilants of stendaar, etc, basically any npc without a real name. when the game deletes these actors two things can happen:

 

first your save data will basically be stranded in the middle of an island that has no pointers pointing at it anymore. the second problem is when the game deletes these actors, it will often reuse the form ids for new temporary actors later. basically a memory leak, where potentially you just keep stockpiling metadata that belongs to no one. but this next problem is way more hillarious.

 

i had this problem where you would meet a wolf, but spawn a whiterun guard a few hours alter when you tried to summon the wolf. i ended up having to engage a clever but unwise persistance hack to make sure the actors live for the length that their metadata i have stored away lives. but this problem means if you store metadata for a sexy hunter, there is a chance in a few hours that data is now pointing at a bear in the cave you just walked into.

 

there is actually a third thing that could happen. the game will crash upon attempting to access the lost/stale/unpointed data. its really hit and miss when it decides to go tits up about it.

 

 

See the reason Magic Effects seemed like the way to go was that if some mods only affected the player or certain NPC's the placeholder scale (of 1.0) wouldn't throw off the final calculations for actors not actually affected. 

[Groovtama]

 

(b * a) * x = (b + a) * x

 

What

 

You're saying that (2*3)*4 = (2+3)*4

No I am not saying fucking numbers mean other fucking numbers, if you have problems with understanding the first line of that whole thing than don't post.

 

I say there exists a value v where "v*(2*3)*4 = (2+3)*4" the first line is to show that the vectors do not matter because they nullify each other because they are on both sides...

[jbezorg]

I would do additive rather than average. Preggers for 6 months + chaurus eggs is going to be bigger than just preggers for 6 months.
 
 
A more accurate way to calculate the addition to scale is by added volume. When you scale up a node you are increasing dimensions on the X,Y and Z axis. Scale is a multiplier of the X,Y and Z dimensions. Just to keep things simple and since the increase on the X,Y and Z axis are proportional we can use a sphere for our volume calculation and we can arbitrarily say at scale 1.0 the radius of the belly is 1.0 and breast is 0.5.
 
Volume of a sphere = 4/3πr³
 
Belly

• Volume = 4.1887902047864 @ scale of 1.0
• Volume = 113.09733552923 @ scale of 3.0
• Volume = 904.77868423386 @ scale of 6.0

Breast (single)

• Volume = 0.5235987755983 @ scale of 1.0
• Volume = 14.137166941154 @ scale of 3.0
• Volume = 113.09733552923 @ scale of 6.0

 

Mods would then tell CANS "I am adding/subtracting X volume at every interval". CANS can then calculate the volume at the interval and then adjust scale based on the current volume.

 

r = ( V / (4/3π) )^^1/3

 

where "r" would convert back to scale.

 

Belly scale = r/1.0

Breast scale = r/0.5

[darkconsole]

personally, i would still rather go with a min/max clamp and "biggest value wins" system.

 

mod a says "i want 100% belly"

mod b says "i want 42% belly"

 

player sees 100% belly which they may have defined in mcm to be "6.5" they now know at least 1 of their mods is ready to do something. showing me 142% or 71% doesn't tell me shit about what i need to do to play my game.

 

mod a says "alright back to 0% belly for me"

 

player now sees 42% belly, and they know none of their mods are ready.

 

when you start muliplying values you get crazy huge stacking results. when you start adding, you get unlinear stacking crazy results because of the scale value. when you start averaging, you don't get a fair representation that anything is remotely done and needs attention.

 

this leaves, largest value wins, mods define a percentage, which is mathed between the user defined min and max clamp values.

 

at the end of the day we dont need boobs showing that i have 10 mods installed and all 10 mods need milking. we need every bodynode to be a progress bar.

[Feliks]

personally, i would still rather go with a min/max clamp and "biggest value wins" system.

 

mod a says "i want 100% belly"

mod b says "i want 42% belly"

 

player sees 100% belly which they may have defined in mcm to be "6.5" they now know at least 1 of their mods is ready to do something. showing me 142% or 71% doesn't tell me shit about what i need to do to play my game.

 

mod a says "alright back to 0% belly for me"

 

player now sees 42% belly, and they know none of their mods are ready.

 

when you start muliplying values you get crazy huge stacking results. when you start adding, you get unlinear stacking crazy results because of the scale value. when you start averaging, you don't get a fair representation that anything is remotely done and needs attention.

 

this leaves, largest value wins, mods define a percentage, which is mathed between the user defined min and max clamp values.

 

at the end of the day we dont need boobs showing that i have 10 mods installed and all 10 mods need milking. we need every bodynode to be a progress bar.

 

Yeah that's definitely looking like one of the better solutions at this point.

 

I would do additive rather than average. Preggers for 6 months + chaurus eggs is going to be bigger than just preggers for 6 months.

 

 

A more accurate way to calculate the addition to scale is by added volume. When you scale up a node you are increasing dimensions on the X,Y and Z axis. Scale is a multiplier of the X,Y and Z dimensions. Just to keep things simple and since the increase on the X,Y and Z axis are proportional we can use a sphere for our volume calculation and we can arbitrarily say at scale 1.0 the radius of the belly is 1.0 and breast is 0.5.

 

Volume of a sphere = 4/3πr³

 

Belly

• Volume = 4.1887902047864 @ scale of 1.0
• Volume = 113.09733552923 @ scale of 3.0
• Volume = 904.77868423386 @ scale of 6.0

Breast (single)

• Volume = 0.5235987755983 @ scale of 1.0
• Volume = 14.137166941154 @ scale of 3.0
• Volume = 113.09733552923 @ scale of 6.0

 

Mods would then tell CANS "I am adding/subtracting X volume at every interval". CANS can then calculate the volume at the interval and then adjust scale based on the current volume.

 

r = ( V / (4/3π) )^^1/3

 

where "r" would convert back to scale.

 

Belly scale = r/1.0

Breast scale = r/0.5

 

I'm gonna be honest, I didn't even think about volume until now, and looking at those numbers I can say that additive could cause some insanely large body parts. A volumetric approach is a neat idea, but also kinda difficult to get the people making the patches or mods in on i'd think. Once I get a bit more of CANS figured out, I'll take a stab at a volume based version. 

 

 

Ya know, it's funny. I was honestly expecting mostly apathy until this mod actually worked with some other mods. This is much better.

 

Edit: Another thing I'd like to point about C.A.N.S. here is that besides just making existing mods cooperate, it was also intended to make new mods playing with the nodes easier to make work, because there'd be no need to check for the nodes or run the NiO (or NetImmerse) functions yourself, CANS'd do it all.

[xxdjdjxx]

At this point I'm kind of more interested in the underlying maths than any gameplay implications this mod may have

[IronRose]

 

Another thing I'd like to point about C.A.N.S. here is that besides just making existing mods cooperate, it was also intended to make new mods playing with the nodes easier to make work, because there'd be no need to check for the nodes or run the NiO (or NetImmerse) functions yourself, CANS'd do it all.

 

 

I think that's the part of this mod I find most exciting, is the idea that node manipulation suddenly becomes something easy to add to a mod. Want a mod that makes the Dovakhin have a huge belly when he eats too much cheese? Just send the request to C.A.N.S. to grow the stomach node. Want a mod that makes the character waste away due to horrible starvation? Just send the request to C.A.N.S. to shrink all body nodes.

 

Hopefully C.A.N.S. will not just make the existing mods "play nice", it will make it easier for people to write new mods that alter the character.

[darkconsole]

 

 

Another thing I'd like to point about C.A.N.S. here is that besides just making existing mods cooperate, it was also intended to make new mods playing with the nodes easier to make work, because there'd be no need to check for the nodes or run the NiO (or NetImmerse) functions yourself, CANS'd do it all.

 

 

I think that's the part of this mod I find most exciting, is the idea that node manipulation suddenly becomes something easy to add to a mod. Want a mod that makes the Dovakhin have a huge belly when he eats too much cheese? Just send the request to C.A.N.S. to grow the stomach node. Want a mod that makes the character waste away due to horrible starvation? Just send the request to C.A.N.S. to shrink all body nodes.

 

Hopefully C.A.N.S. will not just make the existing mods "play nice", it will make it easier for people to write new mods that alter the character.

 

 

i really regret not having my irc logging on now. i went on a rant about this yesterday arguing with groov about why we need this. its an argument we have been having every other month for over a year now, lol.

 

 

Hopefully C.A.N.S. will not just make the existing mods "play nice", it will make it easier for people to write new mods that alter the character.

 

 

this exactly. mods need to just fire and forget their size requests. let the framework negotiate what to do with the values and handle error checking.

 

so, with the soon release of sexlab 1.6 i am probably going to have to start Soulgem Oven 3 soon, which is a prime opportunity to get some live testing done for something like this.

[jbezorg]

 

I would do additive rather than average. Preggers for 6 months + chaurus eggs is going to be bigger than just preggers for 6 months.

 

 

A more accurate way to calculate the addition to scale is by added volume. When you scale up a node you are increasing dimensions on the X,Y and Z axis. Scale is a multiplier of the X,Y and Z dimensions. Just to keep things simple and since the increase on the X,Y and Z axis are proportional we can use a sphere for our volume calculation and we can arbitrarily say at scale 1.0 the radius of the belly is 1.0 and breast is 0.5.

 

Volume of a sphere = 4/3πr³

 

Belly

• Volume = 4.1887902047864 @ scale of 1.0
• Volume = 113.09733552923 @ scale of 3.0
• Volume = 904.77868423386 @ scale of 6.0

Breast (single)

• Volume = 0.5235987755983 @ scale of 1.0
• Volume = 14.137166941154 @ scale of 3.0
• Volume = 113.09733552923 @ scale of 6.0

Mods would then tell CANS "I am adding/subtracting X volume at every interval". CANS can then calculate the volume at the interval and then adjust scale based on the current volume.

 

r = ( V / (4/3π) )^^1/3

 

where "r" would convert back to scale.

 

Belly scale = r/1.0

Breast scale = r/0.5

 

 

I'm gonna be honest, I didn't even think about volume until now, and looking at those numbers I can say that additive could cause some insanely large body parts. A volumetric approach is a neat idea, but also kinda difficult to get the people making the patches or mods in on i'd think. Once I get a bit more of CANS figured out, I'll take a stab at a volume based version.

 

Actually the opposite. The increase in the node scale would exponentially get smaller and smaller each time the same volume was added.

 

For a belly to go from a scale of 1.0 to 3.0 the volume added is 108.9085453244436. To get from 3.0 to 6.0 the volume that must be added is 791.68134870463

 

Really huge body parts would require insane amounts of volume added.

 

But I do agree with min/max caps.

[Feliks]

 

 

 

 

I would do additive rather than average. Preggers for 6 months + chaurus eggs is going to be bigger than just preggers for 6 months.

 

 

A more accurate way to calculate the addition to scale is by added volume. When you scale up a node you are increasing dimensions on the X,Y and Z axis. Scale is a multiplier of the X,Y and Z dimensions. Just to keep things simple and since the increase on the X,Y and Z axis are proportional we can use a sphere for our volume calculation and we can arbitrarily say at scale 1.0 the radius of the belly is 1.0 and breast is 0.5.

 

Volume of a sphere = 4/3πr³

 

Belly

• Volume = 4.1887902047864 @ scale of 1.0
• Volume = 113.09733552923 @ scale of 3.0
• Volume = 904.77868423386 @ scale of 6.0

Breast (single)

• Volume = 0.5235987755983 @ scale of 1.0
• Volume = 14.137166941154 @ scale of 3.0
• Volume = 113.09733552923 @ scale of 6.0

Mods would then tell CANS "I am adding/subtracting X volume at every interval". CANS can then calculate the volume at the interval and then adjust scale based on the current volume.

 

r = ( V / (4/3π) )^^1/3

 

where "r" would convert back to scale.

 

Belly scale = r/1.0

Breast scale = r/0.5

 

 

 

 

I'm gonna be honest, I didn't even think about volume until now, and looking at those numbers I can say that additive could cause some insanely large body parts. A volumetric approach is a neat idea, but also kinda difficult to get the people making the patches or mods in on i'd think. Once I get a bit more of CANS figured out, I'll take a stab at a volume based version.

 

Actually the opposite. The increase in the node scale would exponentially get smaller and smaller each time the same volume was added.

 

For a belly to go from a scale of 1.0 to 3.0 the volume added is 108.9085453244436. To get from 3.0 to 6.0 the volume that must be added is 791.68134870463

 

Really huge body parts would require insane amounts of volume added.

 

But I do agree with min/max caps.

 

 

I meant that an additive scale could cause some insane volumes really quickly, not additive volume. 

[MeMe]

I was skeptical of this at first, to be honest, but you have the right sort of attitude that you may pull it off. Good luck.

 

I agree that the square root of the sum of squares would be a wonderful default averaging method. Secondary, optional methods should probably also include just using the highest value (for clearer visual cues) and additive (if you don't care about nodes potentially growing huge, it's very intuitive.)

 

The real problem is that this is rather late in Skyrim's life to start a framework. Manually patching all the nodescaling mods yourself is one way to do it, I guess?

 

There really needs to be a thread where modders list the lessons learned from Skyrim modding that should be kept in mind for Fallout 4 modding, including mods and frameworks that should be made as soon as possible for maximum adoption. Having a nodescaling framework in FO4 early on would be great too, though my personal dream mod (which never got made for some reason??) is a framework that runs all the ModEvents registered to it on every nearby person and creature every so often (customizable of course.) Imagine if all the invisible cloaking effects from all the mods that want to check or affect nearby people got consolidated into one customizable package.

[Feliks]

I was skeptical of this at first, to be honest, but you have the right sort of attitude that you may pull it off. Good luck.

 

I agree that the square root of the sum of squares would be a wonderful default averaging method. Secondary, optional methods should probably also include just using the highest value (for clearer visual cues) and additive (if you don't care about nodes potentially growing huge, it's very intuitive.)

 

The real problem is that this is rather late in Skyrim's life to start a framework. Manually patching all the nodescaling mods yourself is one way to do it, I guess?

 

There really needs to be a thread where modders list the lessons learned from Skyrim modding that should be kept in mind for Fallout 4 modding, including mods and frameworks that should be made as soon as possible for maximum adoption. Having a nodescaling framework in FO4 early on would be great too, though my personal dream mod (which never got made for some reason??) is a framework that runs all the ModEvents registered to it on every nearby person and creature every so often (customizable of course.) Imagine if all the invisible cloaking effects from all the mods that want to check or affect nearby people got consolidated into one customizable package.

 

I'm gonna take that first part as a complement. Thank you.

 

Currently it's gonna default to just using the highest value, within the mins and maxes set.

 

Also, what do you mean late in Skyrim's life? I understand that Fallout 4 is coming soon, and that Skyrim's going to have been around for 4 years when that happens (FO4, 4 years... Half life 4 confirmed) but I don't think that means much. Look at New Vegas, there's still stuff going on there. And New Vegas was never as versatile as Skyrim. FO:4 might  take a few authors from Skyrim, but for the most part I think it'll keep going.

[Monoman1]

+ they are pretty different games. 

Looking forward to this mod as it matures and mods get integrated. 

It is sorely needed. To many good mods changing nodes everywhere

[jbezorg]

I meant that an additive scale could cause some insane volumes really quickly, not additive volume.

Ah, definitely.

 

That's the problem with CANS letting mods specify change in scale. Additive doesn't work without risking insane size. Average doesn't work. The only real option is to ignore mods and sort out what mods to ignore in what combination. Or let users select mods to ignore. Or you have to create some sort of weighting algorithm. Then what happens when a character gives birth? Size jumps to the next biggest? Don't know if Estrus Charus still does it but scale was also gradually reduced each egg laying cycle. Estrus Charus (if it still works that way) and other mods will need a Framework call to change & update a value outside the normal update cycle.

 

I honestly think working with volume would be easier for you. You can skip deciding if you are going to ignore mods, if some/all/none of them are going to be ignored and/or if they will have a weight for each mod and come up with a weighting algorithm. A modder only has to worry about +/- voulum per CANS interval.

[bimbochoas]

ok my question is why hasn't anyone thought of this type of mod before in the past???

[Feliks]

 

I meant that an additive scale could cause some insane volumes really quickly, not additive volume.

Ah, definitely.

 

That's the problem with CANS letting mods specify change in scale. Additive doesn't work without risking insane size. Average doesn't work. The only real option is to ignore mods and sort out what mods to ignore in what combination. Or let users select mods to ignore. Or you have to create some sort of weighting algorithm. Then what happens when a character gives birth? Size jumps to the next biggest? Don't know if Estrus Charus still does it but scale was also gradually reduced each egg laying cycle. Estrus Charus (if it still works that way) and other mods will need a Framework call to change & update a value outside the normal update cycle.

 

I honestly think working with volume would be easier for you. You can skip deciding if you are going to ignore mods, if some/all/none of them are going to be ignored and/or if they will have a weight for each mod and come up with a weighting algorithm. A modder only has to worry about +/- voulum per CANS interval.

 

 

Looks like I'll have to look into a volumetric approach too. Quick question though, what did you mean by the "normal update cycle?" At the moment, CANS doesn't do anything perdiodically (it will be an option soon though, as long as I can come up with some kind of justification) it just updates whenever it gets a new size update request from another mod. It doesn't monitor the values itself. I actually thought about adding a page to the MCM with toggles for the mods in case players wanted to turn certain ones off. You think that's a good idea? I've actually got the MCM script open in another window right now.

 

ok my question is why hasn't anyone thought of this type of mod before in the past???

From what I can tell people have, but no one actually made it.

[snarfies]

 

 

Hookmmerse is the biggest crap I have ever seen...

 

Why not use NiOverride? NetImmerse is pointless when it doesn't run fast, and when you want compatibility NiOverride is superior to draging scaling calls through a whole papyrus framework..

 

From what I understand NIOverride requires the mod author to use it instead of netimmerse, and that just hasn't happened for some mods? Or am I missing something.

 

If so, Hookmmerse helps me, as a user, to actually use those mods together (and has been for a while now).

 

You miss the fact that Hookmmerse manipulates other people scripts to replace Netimmerse function calls with hookimmerse, and in some cases breaks them, because the Hookmmerse functions do not behave like netimmerse functions do.

 

 

So how do I, as an end-user, and not a modder, implement your preferred solution?

 

Hookmmerse may do "bad things," but from my perspective as an end-user, it works, and is very easy to implement.

[Groovtama]

 

 

 

Hookmmerse is the biggest crap I have ever seen...

 

Why not use NiOverride? NetImmerse is pointless when it doesn't run fast, and when you want compatibility NiOverride is superior to draging scaling calls through a whole papyrus framework..

 

From what I understand NIOverride requires the mod author to use it instead of netimmerse, and that just hasn't happened for some mods? Or am I missing something.

 

If so, Hookmmerse helps me, as a user, to actually use those mods together (and has been for a while now).

 

You miss the fact that Hookmmerse manipulates other people scripts to replace Netimmerse function calls with hookimmerse, and in some cases breaks them, because the Hookmmerse functions do not behave like netimmerse functions do.

 

 

So how do I, as an end-user, and not a modder, implement your preferred solution?

 

Hookmmerse may do "bad things," but from my perspective as an end-user, it works, and is very easy to implement.

 

You do not, you install the mod it sould work with the others, users should not need to do a hacky workaround.