Jump to content

Recommended Posts

6 hours ago, Ed86 said:

why dont you try explaining a bit simplier, like 2+2=4 lmao

also im not sure milk mass should be reduced, 1 milk is 1 milk at 0 and 100 lvl

100 is just a slider, you can go into billions and then fall into negatives when you run out of digits

also im not sure simple calculation should be replaced by this abomination, papyrus is slow already

... well

lets say we have 0.1 scale per milk

0 milk   » scale 1 » 1 volume

10 milk » scale 2 » 8 volume

30 milk » scale 4 » 64 volume

...

Spoiler

plot.png.240fb0fb3cbbd238f72eb7751f75090f.png

thats a linear relation of milk to scale.

but the volume/mass represented by the visual scale rises exponentially.

What we/I want is a linear relation of milk to volume (so 1 milk will really always have the same mass/volume)

 

The Problem I want to solve is that for a certain amount of milk the scale increase is to low and then it gets too high

Namely 1 milk will increase the scale almost unnoticeable (dependent on how big your default boobs are) when you are at level 0 and have no other milk.

And 1 milk at a high level where the breast scale already is high (in graph above 4.something) will have a bigger and bigger impact on visual scale

Spoiler

evidence.gif.716e9c1dd9de75ad213f67759eee7390.gif

left:   effective size 1.0; 1.4 - barely a difference

right: effective size 5.0; 5.4 - very much noticeable

ps:

don't worry about the runtime (I think.. how slow exactly are we speaking?). at the precision we need this (0.01 or 0.001) this should be quite fast.

 

pps:

I've just read a bit here: https://www.creationkit.com/fallout4/index.php?title=Performance_(Papyrus)#Function_Size

and made some minor optimizations based on that:

Spoiler

def cbrt(n, precision) {
    if(precision <= 0) return 0 // no infinite loop please!
    return cbrt1(n, precision)
}

def cbrt1(n, precision) {
  def start = 0, end = n, m, p
    
    //binary search
    while true {
      m = (start+end)/2
      p = m*m*m
      if(abs(n-p) < precision)
      	return round(1/precision * m) * precision
        // or ditch the rounding if it costs too much ...
                     
      if (p > n) {
        end = m
      }else {
        start = m
      }
    }
}
  
def abs(d) {
  if (d < 0)
  	return -d
  return d
}

def round(double n) {
  if (n - n as int < 0.5
      return n as int
  return (n as int)+1
}

 

ppps:

infinite loop for 0 < n < 1 ...  got to think of something for that... 

... otherwise < 20 iterations at 0.01 precision .. is that bad for papyrus?

Link to comment
11 hours ago, cubucus said:

... well

lets say we have 0.1 scale per milk

0 milk   » scale 1 » 1 volume

10 milk » scale 2 » 8 volume

30 milk » scale 4 » 64 volume

...

  Hide contents

plot.png.240fb0fb3cbbd238f72eb7751f75090f.png

thats a linear relation of milk to scale.

but the volume/mass represented by the visual scale rises exponentially.

What we/I want is a linear relation of milk to volume (so 1 milk will really always have the same mass/volume)

 

The Problem I want to solve is that for a certain amount of milk the scale increase is to low and then it gets too high

Namely 1 milk will increase the scale almost unnoticeable (dependent on how big your default boobs are) when you are at level 0 and have no other milk.

And 1 milk at a high level where the breast scale already is high (in graph above 4.something) will have a bigger and bigger impact on visual scale

  Reveal hidden contents

ps:

don't worry about the runtime (I think.. how slow exactly are we speaking?). at the precision we need this (0.01 or 0.001) this should be quite fast.

 

pps:

I've just read a bit here: https://www.creationkit.com/fallout4/index.php?title=Performance_(Papyrus)#Function_Size

and made some minor optimizations based on that:

  Reveal hidden contents

ppps:

infinite loop for 0 < n < 1 ...  got to think of something for that... 

... otherwise < 20 iterations at 0.01 precision .. is that bad for papyrus?

okay.......... so Amount represents milk, which is always fixed .01

and Volume represents maxmilk amount (2+ maidlevel)*2, and simply speaking you want something like maxmilk = 1+maidlevel, so max breast size with milk in it would be linear

or Volume represents breast size from level, which is always fixed

?

 

i know that its slow and less stuff you do is better, coz when you add more mods it slows even more, and when there mods with errors shit hit the fan fast

Link to comment
7 hours ago, Ed86 said:

okay.......... so Amount represents milk, which is always fixed .01

and Volume represents maxmilk amount (2+ maidlevel)*2, and simply speaking you want something like maxmilk = 1+maidlevel, so max breast size with milk in it would be linear

or Volume represents breast size from level, which is always fixed

?

Ok, I try with another graph. It's what I think how your mod is working.

For simplicity I'm going to ignore the maid level.

Spoiler

plot2.png.042dd0fe2d3ed47d3aa4889e44c05a26.pngHorizontal axis is the amount of milk

1 Milk equals 0.1 scale

 

Blue line is the current relation of milk to scale.

So we get an effective breast size of 1.5 at 5 milk and 2 at 10 milk.

Vertical axis is the effective breast size (scale)

 

Red line shows what the volume increase is for that amount of milk

(vertical axis = volume)

 

Green line is what the blue line should be in order to make 1 milk always have the same mass

(so red line becomes linear)

 

 

 

Use this expression in wolfram alpha to generate this graph:

plot 1+a and 1+a^3 and 1+Re(a^(1/3)) where a = 1x/10 from x = 0 to 11

But well, ...

if papyrus is really that bad I think we just have to live with exponential visual mass increase. :/

It just bugs me that at first breast are like not growing at all and then exploding later on. (I think this is what you meant with milk production getting out of hand in the mod description)

If you're inflating a balloon it grows fast first and slower the bigger it gets because your breath isn't magically increasing the more often you blow...

Link to comment
9 minutes ago, cubucus said:

Ok, I try with another graph. It's what I think how your mod is working.

For simplicity I'm going to ignore the maid level.

  Hide contents

plot2.png.042dd0fe2d3ed47d3aa4889e44c05a26.pngHorizontal axis is the amount of milk

1 Milk equals 0.1 scale

 

Blue line is the current relation of milk to scale.

So we get an effective breast size of 1.5 at 5 milk and 2 at 10 milk.

Vertical axis is the effective breast size (scale)

 

Red line shows what the volume increase is for that amount of milk

(vertical axis = volume)

 

Green line is what the blue line should be in order to make 1 milk always have the same mass

(so red line becomes linear)

 

 

 

Use this expression in wolfram alpha to generate this graph:

plot 1+a and 1+a^3 and 1+Re(a^(1/3)) where a = 1x/10 from x = 0 to 11

But well, ...

if papyrus is really that bad I think we just have to live with exponential visual mass increase. :/

It just bugs me that at first breast are like not growing at all and then exploding later on. (I think this is what you meant with milk production getting out of hand in the mod description)

If you're inflating a balloon it grows fast first and slower the bigger it gets because your breath isn't magically increasing the more often you blow...

This makes so much sense. I hope that the mod can be adjusted like that without killing papyrus so the volume increases more realistically... I noticed something was odd when I tested the scaling. great job so far, cubucus!

 

EDIT: in case Ed decides to make another update I offer to fix up some of the dialogues (typos, phrasing etc.)...if that is wanted by the author ofc

Link to comment
2 hours ago, cubucus said:

Ok, I try with another graph. It's what I think how your mod is working.

For simplicity I'm going to ignore the maid level.

  Reveal hidden contents

But well, ...

if papyrus is really that bad I think we just have to live with exponential visual mass increase. :/

It just bugs me that at first breast are like not growing at all and then exploding later on. (I think this is what you meant with milk production getting out of hand in the mod description)

If you're inflating a balloon it grows fast first and slower the bigger it gets because your breath isn't magically increasing the more often you blow...

okay......... soo.....

        CurrentSize = BreastBase + Math.pow(( MilkCnt * MaidBoobIncr ) + ( MaidLevel + ( MaidTimesMilked / (( MaidLevel + 1 ) * TimesMilkedMult ))) * MaidBoobPerLvl, (1/3))
?

1 hour ago, Hermestris said:

This makes so much sense. I hope that the mod can be adjusted like that without killing papyrus so the volume increases more realistically... I noticed something was odd when I tested the scaling. great job so far, cubucus!

 

EDIT: in case Ed decides to make another update I offer to fix up some of the dialogues (typos, phrasing etc.)...if that is wanted by the author ofc

send ur stuff

MilkQUEST.zip

Link to comment
4 hours ago, Ed86 said:

okay......... soo.....

        CurrentSize = BreastBase + Math.pow(( MilkCnt * MaidBoobIncr ) + ( MaidLevel + ( MaidTimesMilked / (( MaidLevel + 1 ) * TimesMilkedMult ))) * MaidBoobPerLvl, (1/3))
?

Yes

Though I don't know what "TimesMilkedMult" is and how "BreastBaseMod" fits in

Link to comment
On 11/22/2018 at 9:53 PM, cubucus said:

ppps:

infinite loop for 0 < n < 1 ...  got to think of something for that...

Ok. made an implementation of this algorithm from wikipedia.

Spoiler

// p is precision or error margin - needs to be > 0
// 0.1 is more than accurate enough
// maybe 0.2 with rounding 0.01
def cbrt(a, p) {
    def x = a / 3;
    return cbrt1(a, (2 * x + a / (x * x)) / 3, 1.0, p);
}

def cbrt1(a, x, dx, p) {
    while (abs(dx) > p) {
      dx = (a / (x * x) - x) / 3;
      x += dx;
    }
    return x;
}

def abs(n) {
    if n >= 0
    	return n
    else
    	return -n
}

def round(n) {
    if n - (n as int) < 0.5
    	return n as int
    else
    	return n as int + 1
}

// p is decimal '0.0..1' to which point should be rounded
def round(n, p) {
    return round((1 / p) * n) * p;
}

 

We'll probably going to have a hard time finding anything better (maybe there is some optimization magic that I don't know of, but still)

input range is also safe for what realistically could ever be reached in game.

 

If it really happens to have a noticeable impact on performance you could still add this as an option in MCM so one could turn it of to save performance.

But otherwise as long as there is the capacity for this it'll be worth it i think.

 

Link to comment
7 hours ago, cubucus said:

Ok. made an implementation of this algorithm from wikipedia.

  Reveal hidden contents

We'll probably going to have a hard time finding anything better (maybe there is some optimization magic that I don't know of, but still)

input range is also safe for what realistically could ever be reached in game.

 

If it really happens to have a noticeable impact on performance you could still add this as an option in MCM so one could turn it of to save performance.

But otherwise as long as there is the capacity for this it'll be worth it i think.

 

*sigh* the issue is not in MME its game engine/skse/nioverride

im not really interested implementing(or understanding) all that precision nonsense!

 

all that stuff should be fixed by 1-2 lines of code, if not, then its not worth it

 

you can try explaining in xls

as far as i understand, issue is in C12 and "immersive fix" is in D12

Book1.xlsx

Link to comment
On 11/25/2018 at 9:44 AM, Ed86 said:

you can try explaining in xls

here you go Book2.xlsx

On 11/25/2018 at 9:44 AM, Ed86 said:

*sigh* the issue is not in MME its game engine/skse/nioverride

im not really interested implementing(or understanding) all that precision nonsense!

that is ... unfortunate.

Is it the math or what the variable 'precision' means in the code? (that is just a means to stop the algorithm so it doesn't compute longer than we need it to)

...

On 11/25/2018 at 9:44 AM, Ed86 said:

all that stuff should be fixed by 1-2 lines of code, if not, then its not worth it

...?

This led me to ask google how slow papyrus really is.

Found this reddit, which led me here, and that is where I found this ?

so no need for my custom code. just do 

// boob potion addition
BaseSize + BaseMod + pow(milk*milkIncr + maidLvl*maidBoobPerLvl, 0.33333334)

// or

// boob potion scaling
(BaseSize + pow(milk*milkIncr + maidLvl*maidBoobPerLvl, 0.33333334))*(1+BaseSizeMod)

like in the xls

depending on what you prefer (I prefer the latter with scaling)

(edit: maybe the first variant (addition) is enough - tried to visualize the difference in 3d program and it looks like the plain addition of 'BaseSizeMod' already makes a big enough difference)

 

and as 'pow' is a "non-delayed Native Function" we should be totally fine.

(and if that kind of function call is still too slow my code can easily be modified to eliminate any function calls)

 

edit: for the lol'z:

def a = milk*milkIncr + maidLvl*maidBoobPerLvl
def x = 0.0
if a != 0 { // cbrt(0) is 0 - or use 'a > 0' if you want to ignore negative values
	def dx = 1.0	
	x = a/3
	
 	 while (dx > 0.1) {
		dx = (a / (x * x) - x) / 3
		x += dx
		if dx < 0 {
			dx = -dx
    	   	}
  	}
}
currentSize = baseSize + baseMod + x

 

Link to comment
On 11/25/2018 at 9:25 PM, cubucus said:

here you go Book2.xlsx

that is ... unfortunate.

Is it the math or what the variable 'precision' means in the code? (that is just a means to stop the algorithm so it doesn't compute longer than we need it to)

...

...?

This led me to ask google how slow papyrus really is.

Found this reddit, which led me here, and that is where I found this ?

so no need for my custom code. just do 


// boob potion addition
BaseSize + BaseMod + pow(milk*milkIncr + maidLvl*maidBoobPerLvl, 0.33333334)

// or

// boob potion scaling
(BaseSize + pow(milk*milkIncr + maidLvl*maidBoobPerLvl, 0.33333334))*(1+BaseSizeMod)

like in the xls

depending on what you prefer (I prefer the latter with scaling)

(edit: maybe the first variant (addition) is enough - tried to visualize the difference in 3d program and it looks like the plain addition of 'BaseSizeMod' already makes a big enough difference)

 

and as 'pow' is a "non-delayed Native Function" we should be totally fine.

(and if that kind of function call is still too slow my code can easily be modified to eliminate any function calls)

 

edit: for the lol'z:


def a = milk*milkIncr + maidLvl*maidBoobPerLvl
def x = 0.0
if a != 0 { // cbrt(0) is 0 - or use 'a > 0' if you want to ignore negative values
	def dx = 1.0	
	x = a/3
	
 	 while (dx > 0.1) {
		dx = (a / (x * x) - x) / 3
		x += dx
		if dx < 0 {
			dx = -dx
    	   	}
  	}
}
currentSize = baseSize + baseMod + x

 

:/ ur xls calulations are all mess

 

 

here, boob scaling version

 

Scripts.7z

Link to comment
44 minutes ago, Hermestris said:

nice. If I want to use these can I just update the mod by simpley putting this in the loadorder? or do I need to deactivate the mod in mcm, make a new safe and all that....?

overwrite existing scripts

Link to comment
1 hour ago, Ed86 said:

:/ ur xls calulations are all mess

??

First row (A) has the just the labels

then every other row (B to F) each is a different set of values for the calculation(s) (G and H are left empty for you to play with different values)

the lines 7,8 and 9 contain the results of the calculations using the values (lines 1 to 6) in their respective rows.

...

so you're also gradually increasing breast size by percentage to the next level with MaidTimesMilked and TimesMilkedMult? 

Missed that before...

here is the revised version (just for 'fun'): Book2.1.xlsx

3 hours ago, Ed86 said:

here, boob scaling version

 

Scripts.7z

:D

 

OK... 

MilkQUEST.psc:

1088		...
1089		CurrentSize = ( MilkCnt * MaidBoobIncr ) + ( MaidLevel + ( MaidTimesMilked / (( MaidLevel + 1 ) * TimesMilkedMult ))) * MaidBoobPerLvl ; so this is original formula without 'BreastBase' (which included 'BreastBaseMod' at that point
1090		CurrentSize = Math.pow( CurrentSize, (1/3)) ; YES!
1091		CurrentSize = (BreastBase-BreastBaseMod + CurrentSize)*(1+BreastBaseMod) ; ->*
1092		...

*Well .. yes. I didn't know the exact formula you where using and though using 'BreastBaseMod' was a good way to scale the end result.

I'm not sure about that anymore.

As 'BreastBaseMod' is used by the Breast Potions I think we shouldn't touch/use that here. Instead it looks like 'BreastBase' can only be changed through MCM in the debug menu, right?

Then I think it would be best to make that the scaling option for when the new fix doesn't make the breasts large enough for some players.

(It is redundant to the breast scaling in RaceMenu anyway - if it really doesn't have any other functionality that is of course)

==>

1088		...
1089		CurrentSize = ( MilkCnt * MaidBoobIncr ) + ( MaidLevel + ( MaidTimesMilked / (( MaidLevel + 1 ) * TimesMilkedMult ))) * MaidBoobPerLvl
1090		CurrentSize = Math.pow( CurrentSize, (1/3))*(BreastBase-BreastBaseMod)
1091		...
1092		...

 

Link to comment
1 hour ago, Ed86 said:

overwrite existing scripts

strange .. looks like the maid level and milk amount don't have any effect on the size anymore ... but it should work just fine.. they are included in the formula

and the initial size for new milk maid is already 2.00

the only things affecting the size are just BreastBase and BreastBaseMod ??? that's impossible! ?

 

effectively size is now

(1+BaseSize)*(1+BaseMod)

... I'm confused

Link to comment
25 minutes ago, cubucus said:

strange .. looks like the maid level and milk amount don't have any effect on the size anymore ... but it should work just fine.. they are included in the formula

and the initial size for new milk maid is already 2.00

the only things affecting the size are just BreastBase and BreastBaseMod ??? that's impossible! ?

 

effectively size is now

(1+BaseSize)*(1+BaseMod)

... I'm confused

I had the same experience. The default boob size was much bigger, but despite increase in milk no scaling happened.

Link to comment
1 hour ago, cubucus said:

effectively size is now

(1+BaseSize)*(1+BaseMod)

that sounds like line 1091

 

does 'Math.pow(anything, 0<something<1)' return 1 by any chance?  (would mean that Math.pow treats 'something' as equal to 0 -> x^0 = 1 ... Bethesda you lazy bunch! ?)

that would mean we have to use my custom cube-root code after all.

 

ok then we have to write it like this:

CurrentSize = ( MilkCnt * MaidBoobIncr ) + ( MaidLevel + ( MaidTimesMilked / (( MaidLevel + 1 ) * TimesMilkedMult ))) * MaidBoobPerLvl
float x = 0.0
if CurrentSize != 0
	float dx = 1.0
	x = CurrentSize/3
	
	while dx > 0.1
		dx = (CurrentSize / (x*x) - x) / 3
		x += dx
		if dx < 0
			dx = -dx
		endif
	endwhile
endif
CurrentSize = BrestBase + x*(BreastBase-BreastBaseMod)

 

Link to comment
10 hours ago, cubucus said:

??

First row (A) has the just the labels

then every other row (B to F) each is a different set of values for the calculation(s) (G and H are left empty for you to play with different values)

the lines 7,8 and 9 contain the results of the calculations using the values (lines 1 to 6) in their respective rows.

...

coz all values are different, hard to make any sense

 

Scripts.7z

Link to comment
44 minutes ago, Ed86 said:

Scripts.7z

IT WORKS!

 

... just that I didn't catch that you removed the line before the calculation where you added BaseMod to BaseSize (BreastBase += BreastBaseMod) ?

Otherwise it now works as expected.

 

fix:

1105		;debug.notification(CurrentSize)
1106		CurrentSize = BreastBase + x*(BreastBase-BreastBaseMod)
1107		;CurrentSize = (BreastBase+BreastBaseMod + CurrentSize)*(1+BreastBaseMod)

to

1106		CurrentSize = BreastBase + x*BreastBase + BreastBaseMod
or
1106		CurrentSize = 1 + x*BreastBase + BreastBaseMod		; here BrestBase is purely used to scale the the result of the calculation

second variant is better I think

you then probably want to include a default value slider for BreastBase alongside the increment values in the main MCM settings page

maybe in the next release

The general base breast size can always be altered in raceMenu and for NPC's there is the mod Manipulator

Link to comment
25 minutes ago, cubucus said:

IT WORKS!

 

... just that I didn't catch that you removed the line before the calculation where you added BaseMod to BaseSize (BreastBase += BreastBaseMod) ?

Otherwise it now works as expected.

 

fix:


1105		;debug.notification(CurrentSize)
1106		CurrentSize = BreastBase + x*(BreastBase-BreastBaseMod)
1107		;CurrentSize = (BreastBase+BreastBaseMod + CurrentSize)*(1+BreastBaseMod)

to

1106		CurrentSize = BreastBase + x*BreastBase + BreastBaseMod
or
1106		CurrentSize = 1 + x*BreastBase + BreastBaseMod		; here BrestBase is purely used to scale the the result of the calculation

second variant is better I think

you then probably want to include a default value slider for BreastBase alongside the increment values in the main MCM settings page

maybe in the next release

The general base breast size can always be altered in raceMenu and for NPC's there is the mod Manipulator

idk, maybe  ?

       CurrentSize = (BreastBase+BreastBaseMod) + x

or

        CurrentSize = (BreastBase+BreastBaseMod) *  x

or

        CurrentSize = (BreastBase+BreastBaseMod) + ( MilkCnt * MaidBoobIncr ) + ( MaidLevel + ( MaidTimesMilked / (( MaidLevel + 1 ) * TimesMilkedMult ))) * MaidBoobPerLvl

x=those weird calculations

CurrentSize =x

Link to comment
5 hours ago, Ed86 said:

idk, maybe  ?

       CurrentSize = (BreastBase+BreastBaseMod) + x

or

        CurrentSize = (BreastBase+BreastBaseMod) *  x

or

        CurrentSize = (BreastBase+BreastBaseMod) + ( MilkCnt * MaidBoobIncr ) + ( MaidLevel + ( MaidTimesMilked / (( MaidLevel + 1 ) * TimesMilkedMult ))) * MaidBoobPerLvl

x=those weird calculations

CurrentSize =x

  • first variant would work just fine of course
    but then maybe you'll have to increase the maximum range for the increment values
    (max for MilkIncr = 0.5 | max for MaidBoobPerLvl = 0.3 maybe ?)
    the root function makes the size changes smaller the bigger the boobs get so maybe the boobs won't get big enough anymore for some folk
  • second one is out of the question becuase at level 0 with 0 milk we'd get a size of 0
  • The third ... that would make the changes a lot smaller and the boob potions would have very little visual effects too.

    wolfram alpha query for 1. and 3. variant plot (x is CurrentSize without BreastBase, BreastBaseMod):
    plot 1+x^(1/3) and (x+1)^(1/3) from x = 0 to 4

    maybe you want that but then the need for upscaling is even higher (increment sliders need to get a lot higher - maybe at least up to 3.0!)
    and the boob potions need to be cranked up to 11 to make a proper difference too
    ... now that I think about it... (again)
    This would probably be the most realistic version as we don't start with a volume of 0 for the boobs
    so we can define the increment as % of initial volume (MaidBoobIncr = 1 := 100% of initial volume)

 

out of curiosity

why did you make 'BaseSize' a variable and then only one that is 1 by default and can only be changed through the debug menu?

Link to comment
7 hours ago, cubucus said:
  • first variant would work just fine of course
    but then maybe you'll have to increase the maximum range for the increment values
    (max for MilkIncr = 0.5 | max for MaidBoobPerLvl = 0.3 maybe ?)
    the root function makes the size changes smaller the bigger the boobs get so maybe the boobs won't get big enough anymore for some folk
  • second one is out of the question becuase at level 0 with 0 milk we'd get a size of 0
  • The third ... that would make the changes a lot smaller and the boob potions would have very little visual effects too.

    wolfram alpha query for 1. and 3. variant plot (x is CurrentSize without BreastBase, BreastBaseMod):
    plot 1+x^(1/3) and (x+1)^(1/3) from x = 0 to 4

    maybe you want that but then the need for upscaling is even higher (increment sliders need to get a lot higher - maybe at least up to 3.0!)
    and the boob potions need to be cranked up to 11 to make a proper difference too
    ... now that I think about it... (again)
    This would probably be the most realistic version as we don't start with a volume of 0 for the boobs
    so we can define the increment as % of initial volume (MaidBoobIncr = 1 := 100% of initial volume)

 

out of curiosity

why did you make 'BaseSize' a variable and then only one that is 1 by default and can only be changed through the debug menu?

1 seems easier

 

who knows, maybe so ppl can change it?

 

Scripts.7z

Link to comment
1 hour ago, Ed86 said:

1 seems easier

well, Ok

 

.. maybe someday I'll figure out how the heck to get the compiler to actually compile anything so that I can give version 3 a try.

But for now I'm just presented with loads of error messages about stuff being undefined or can't be found.

And I don't know what else to include in the imports path.

1 hour ago, Ed86 said:

Scripts.7z

err... did you forget to compile?

BreastBaseMod is still reducing size

Link to comment
21 hours ago, cubucus said:

err... did you forget to compile?

BreastBaseMod is still reducing size

... so I was just missing some dependencies, that I had to download manually and I got the compiler to finally stop complaining ?

»» scripts.7z ««

 

now when I find the time I'll go and try to fit the sliders for option 3

Link to comment

.... If only I had known from the start, that the MCM Maid-Debug-Menu uses duplicate code to display the effective size this would have been much easier.

Thought I was going mad because none of my changes to MilkQuest.psc where showing in MCM.

 

Here is the alternate scaling option I was talking about earlier:

» Milk-Mod-Economy_alternate-boobscaling_patch-2918-12-1.7z «

 

I also fixed the MCM calculation of effective size subtracting the boob-potion modifier from total size.

 

"Volumetric" Boobscaling now assumes that the base size is 1 unit of volume.

You can change the base size in Maid-debug menu with the base size slider or use racemenu. Visually this should make no difference but if you use the MCM slider the size change is considered in other calculations like milk-gen and pain reduction I think. (not sure - needs confirmation from Ed86)

Maid-Level doesn't affect base volume. just boob size.

Boob-Potion modifier is still just added plain to total size so it will keep increasing size by fixed amount.

 

You can set 1 unit of milk have up to 500% of base volume (when you'r char has small/normal sized breasts by default and you want to consider 1 unit of milk to have the volume close to what 1 milk bottle appears to have) [though I still recommend 1.0 for 100%]

A level up can be set to increase volume by up to 300% of base volume (again for small base tits)

Link to comment
17 hours ago, raphitek said:

Sorry, I just installed MME on skyrim. MME and its dependencies are essentially all the mods I have yet. I found lactacid, drank it, became a milk maid, crafted a milking armor, but I can't use the pumping machines, my character just gets stuck in front of it for a couple seconds, then nothing happens. I also don't know how to use the milking armor, so this mod actually doesn't do shit for me right now. Any help please ? (I'm sorry, I'm kind of a noob in moding).

If you have Dialogue Milking enabled in the MCM, I think it's the Hey there dialogue menu that lets a NPC milk you. So that should be an option.

 

Regarding the pumping machines not working (and maybe even the harness?), I just had my install break in a similar way: when I activated a milk pump, my character would kinda just look at it then give up. I fixed it by running FNIS again.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   1 member

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use