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

[darkconsole]

 

 

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.

 

 

reception from the mods that mattered was less than stellar. it was thought of, and more or less called dumb. i didn't have the mental stamina to work on my normal projects and one that would be an uphill battle.

[Deathmaw]

I would certainly like an additive option to be present.

Looking forward to seeing where this goes.

[dakirai]

This can result pretty good, nice job

[Feliks]

I would certainly like an additive option to be present.

Looking forward to seeing where this goes.

It is already present in the framework, I mention it in the OP, it just currently defaults to average because that was the off the cuff example when I started working on this.

[Kingslayer101]

Cant wait to get back home and use it with Fill her up, Milk Mod and Soulgemoven

[Feliks]

Cant wait to get back home and use it with Fill her up, Milk Mod and Soulgemoven

 

There're curebtly no compatibility patches (that I know of) so it won't actually do anything yet.

[Kingslayer101]

 

Cant wait to get back home and use it with Fill her up, Milk Mod and Soulgemoven

There're curebtly no compatibility patches (that I know of) so it won't actually do anything yet.

Aww bummer....

[Feliks]

 

 

Cant wait to get back home and use it with Fill her up, Milk Mod and Soulgemoven

There're curebtly no compatibility patches (that I know of) so it won't actually do anything yet.

Aww bummer....

 

 

Give me a few days to build the MCM and rebuild one or two features. Then it should be fairly straightforward to start building patches.

[Feliks]

 

 

 

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.

 

 

reception from the mods that mattered was less than stellar. it was thought of, and more or less called dumb. i didn't have the mental stamina to work on my normal projects and one that would be an uphill battle.

 

 

Luckily I'm nothing if not stubborn.

[Caliban44]

looking forward to the day that all of the node changing mods do not fight each other when they update my toons body

[jbezorg]

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.

It would be more efficient and less script laggy if there was one update cycle controlled by CANS rather than several mods each having a script running and updating CANS in their own cycle. You also risk a mod on a very fast cycle spamming CANS with node changes. CANS can communicate back to the dependent mods by sending mod events.

 

http://www.creationkit.com/RegisterForModEvent_-_Form

http://www.creationkit.com/SendModEvent

 

CANS would need 5 questions answered from each mod

• What actor?
• How much to add each cycle?
• How long should it be done? i.e. how many cycles to run?
• What node(s) to change?
• Receive a notification when CANS is finished?

cans.init(actor target, float rate, int cycles, int node, string hook = "")

I would avoid letting mods ask CANS to change a node's scale until a specific scale, volume, or any other dynamic value is reached. With several mods running at the same time and the dynamic values being constantly altered the target value may never be reached.

[Feliks]

 

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.

It would be more efficient and less script laggy if there was one update cycle controlled by CANS rather than several mods each having a script running and updating CANS in their own cycle. You also risk a mod on a very fast cycle spamming CANS with node changes. CANS can communicate back to the dependent mods by sending mod events.

 

http://www.creationkit.com/RegisterForModEvent_-_Form

http://www.creationkit.com/SendModEvent

 

CANS would need 5 questions answered from each mod

• What actor?
• How much to add each cycle?
• How long should it be done? i.e. how many cycles to run?
• What node(s) to change?
• Receive a notification when CANS is finished?

cans.init(actor target, float rate, int cycles, int node, string hook = "")

I would avoid letting mods ask CANS to change a node's scale until a specific scale, volume, or any other dynamic value is reached. With several mods running at the same time and the dynamic values being constantly altered the target value may never be reached.

 

 

That does sound like a much better way to look at it. I originally wrote the return functions to only bring out what the mod requesting was putting in, so that if they wanted to keep increasing until they were at a certain size they'd do that independent of what other mods were doing.

 

Good thing I'm currently rewriting large parts of the scripts anyways.

[Feliks]

Oh and well I'm here, if anyone's familiar with MCM code could you help me figure out why this code isn't working?

 

 

State ModWeightSlide0

Int zCount

Event OnSliderOpenST()

SetSliderDialogStartValue(CANS.MasterWeightList[zCount])

SetSliderDialogDefaultValue(1.0)

SetSliderDialogRange(0.1, 2.0)

SetSliderDialogInterval(0.1)

EndEvent

Event OnSliderAcceptST(Float weight)

CANS.MasterWeightList[zCount] = weight

SetSliderOptionValueST(CANS.MasterWeightList[zCount])

EndEvent

Event OnDefaultST()

CANS.MasterWeightList[zCount] = 1.0

SetSliderOptionValueST(CANS.MasterWeightList[zCount])

EndEvent

Event OnHighlightST(

zCount = 0

SetInfoText("Set the weighting of " + CANS.MasterModlist[zCount])

EndEvent

EndState

 

It's a state for a specific option, but no matter what i do the compiler returns.

 

C:\...\CANS\Release\Scripts\Source\CANS_MCM.psc(819,5): missing FUNCTION at 'zCount'

C:\...\CANS\Release\Scripts\Source\CANS_MCM.psc(819,11): mismatched input '\\r\\n' expecting LPAREN

The zCount variable is important here since there are 64 instances of nearly identical options that should dynamically order themselves and point to certain data depending on what mods are working with C.A.N.S. and I really didn't want to write unique code for each of them (especially considering I'm going to have to increase it in the future) so zCount would allow me to effectively copy and paste instead. I get the feeling I'm going to need to write the index out for each of them though.

[Caliban44]

can you redo post to not show white i can not read the code snippet you posted

[Feliks]

can you redo post to not show white i can not read the code snippet you posted

Threw it in a quote instead of a code box. No idea why the code box is tossing up that stark white line coloring.

 

Edit: Whatever. I just changed the 64 instances to contain the pure index instead of a variable workaround. Took more work, but probably not as much time as I put into trying to get zCount to work.

[Feliks]

Status update: MCM is mostly finished. A few things I'll go back to change, add, or rework in future releases, but for now it's done. Got to fix a few functions, add some new math, and improve a few features and the next version will be up. Upgrading to NiO in either this coming release or the one after depending on time, and storageutil incorporation will be in the release following that. After that the only glaring issue left to face should be the fact that magic effects tend to fall off of actors, so I need to find a better way to point CANS to specific actors. 

 

In one of these releases the volumetric mode will be added. This will be the last time (theoretically) CANS patches would need to be modified. It will come with a completely alternate way of handling sizes and a new way of handling updates. At this point I am unsure of whether or not I want to also implement this new method for scale related methods. 

 

Stay tuned.

 

Also, if anyone knows their way around paint.net and wants to volunteer to create a title image for the MCM default page I'd be in eternally grateful.

[Severyx]

Amazing progress! I was pleasantly surprised to see so much constructive modders discussion after hearing about how this idea fell through in the past. Hats off to you, Feliks. You're making this community proud.

[MorePrinniesDood]

Watching this with interest.

[TechBaNe]

When you update the implementation section of the OP, could you also include a bit about where each code snippet goes (does it go all together in one script, or is it dispersed across several objects/effects/actors/etc.?) so that those of us that are complete scripting noobs can also get this thing working? I'm learning how to do papyrus scripting, but I'vs only started this month, and reading that section left me scratching my head.

[Feliks]

When you update the implementation section of the OP, could you also include a bit about where each code snippet goes (does it go all together in one script, or is it dispersed across several objects/effects/actors/etc.?) so that those of us that are complete scripting noobs can also get this thing working? I'm learning how to do papyrus scripting, but I'vs only started this month, and reading that section left me scratching my head.

Yeah no problem mate. If you need any help there feel free to ask me, I want to be helpful in this forum, in as many ways as I can.

[Feliks]

Hey y'all, update here. I just spent two hours tearing down and rewriting ~1000 lines of code across a few features. And then wrote most of the math operations for the actual calculations. Now there's some copying and pasting and replacing to do. 

 

Highest value only is done.

Additive is done.

Categorical and individual weights through the MCM are done.

Modification of the registration script to account for categories is done.

Expansion of the framework (up to 128 mods on up to 256 actors(will expand actors if anyone thinks it needs to be done, mods will be expanded at some point when there's more than about a dozen)) is done (but still in arrays).

Moving to NiO is done.

 

I've got a quick question for anyone math inclined though as I've been putting off working this out (and plan to continue doing so until most of the rest of the code is done).

For weighted averages, how should I do that exactly? Right now it allows for user defined weights by mod or by category, but how should I actually implement that into the code?

At the moment it does this

(individual weighted average)

 

Loop through Mods

     A += ModX * ModXweight

     B+= ModXweight

EndLoop

C = A/B

(check to see if it overreaches max limit (if set))

(apply size C)

 

but I did some (admittedly half-assed) tests and found that this might not solve the problems in an average, and in a few cases actually made it worse. Now, this is better implemented in categories, where each group of mods can effect each group of nodes (belly, breast, butt) do a different extent, but I'm not sure if the problem is solved there either.

 

If anyone's got any feedback on that particular issue I'd love to hear it, otherwise I'll leave it as is for now and get back to it in a bit.

 

 

EDIT: Now that I think about it I'm also going to look into a categorical cap instead of weights for a future release. So pregnancy mods can increase the belly up to X or the breasts ad infinitum, and milking mods can increase the butt to Z but not the belly or something. Honestly the beast methods currently are Additive and highest only. 

[chajapa]

Personal perspective as a user.... I tend to try to keep things simple

 

You start getting into averaging and weighted result calculations and unless the interface to all the math mumbo-jumbo is EXTREMELY simple, people are generally going to bypass that option and just go for either Additive (Cummulative?) or highest.

 

Example:

You have a pregnancy mod (Let's say Sould Gem Oven), Fill Her Up (cum inflation), and Estrus Chaurus. The Max you want your belly to get (a slider in MCM for this) is 6.5.

 

You get laid and have some cum inflation from Fill her Up. Since pregnancy belly value is lower than inflated value, inflation subsides until it gets DOWN to the value of the belly node being requested by SGO. FHU deflation events continue to happen but belly size won't go below highest request which at this point is SGO.

 

Pregnancy progresses... SGO wants belly at 3.5 at this stage. You get fucked by a horse and Fill Her Up is either going to inflate you PAST the 3.5 value (if you've selected Additive) or it will do nothing (if you've selected highest value wins) since the value it would set is lower than SGO's current 3.5.

 

Continue on, dungeon explorer and.... what's that clicking noise?

DAMMIT! Chaurus spit... tentacle attack and.... by the Nines you've got EGGS in you!

 

Still not going to see any evidence of that until and unless EC+ requests a belly scale higher than SGO... OR.... you birth those soul gems only to watch your belly grow AGAIN due to the eggs..... 

 

So... point of all this...

It's ALREADY not simple! 

But the VISUAL effects can still be kept simple by using additive or highest wins.

And 99.9% of the users will be overjoyed to have the control you're offering and will be thrilled with the choices of either an additive result or a "highest wins" result.

I think going into massive computations for weighted results could be interesting, but I think it falls into the "diminishing returns" category and will take far more effort to implement, and be more complex to maintain and adjust, than it's worth.

 

Again.... just opinion.

 

And if, as a MODDER, I could use simple code insertions to request node scale changes to a "central controller" framework, it would be LOVELY.

[Feliks]

Roger that chajapa. That's basically the gist of it as is. Update should be up in a few hours with a fixed implementation post and whatnot. Simple development ahoy.

[Caliban44]

i have only one question.....

 

where are the patches?

[TechBaNe]

i have only one question.....

 

where are the patches?

There are no publicly available patches yet.