SexLab Inflation Framework

[qotsafan]

Update 1.2.1 up at Patreon:

• changed 000_Default_Lists.json back to Lists.json (Lists.json is now generated, instead of provided)
• added new page, where you can change the category of nodes/morphs in which they are displayed in the menu (adding new nodes/morphs via the menu planned, but only an idea atm)
• added current list size slider, which defines, how many nodes/morphs are displayed at once and current list index slider, which defines, which portion of the list is displayed
• that the categories 000_nodes and 000_morphs under "Filter by category" are empty is by design, since nodes/morphs that are only in these two lists are displayed here and have to be assigned a new list, if they should not only be displayed in the default list
• new nodes/morphs are now automatically added to the lists, if they aren't in any list (and can be assigned a category via the "Set list category" page)
• support for keys like "slif_left_breast"/"slif_right_breast"/etc. has been removed (legacy support still given, otherwise use nodes instead ("NPC L Breast"/"NPC R Breast"/etc.)) (dual node keys like "slif_breast"/etc. are still supported)
• added new translation keys

Patches:

• added Aroused Nips patch for version 1.1.2
• added MiniNeeds patch for version 3.2
• added SOS Grower patch for version 2.1
• updated Naked Dungeons patch for version 2.0.1

[sidfu]

@qotsafan fu forgot to update the sgo script with the bone changes as xmpms removed bones so the bones in script are wrong. back a page or 2 i put one with them fixed

[qotsafan]

11 hours ago, sidfu said:

@qotsafan fu forgot to update the sgo script with the bone changes as xmpms removed bones so the bones in script are wrong. back a page or 2 i put one with them fixed

Yeah, I noticed that after I uploaded the new version, but it was already pretty late and I had to get up early, so I wasn't able to reupload it, but I will fix that asap.

[qotsafan]

• updated Soulgem Oven patch with the fertility fix and the xpmse 4.32+ fix, which already included the fertility fix

[sidfu]

np thats why we here to remind u of fixes u missed

[Maddac]

when can we download 1.2.1 on loverslab? i dont mind waiting for the update but dont like being forced to pay patreon just to get it.

[Durante]

Do you think you could incorporate npc bodyscale randomizer into your mod? And perhaps add in a few stable sliders from your own? Just an idea

[qotsafan]

10 minutes ago, Maddac said:

when can we download 1.2.1 on loverslab? i dont mind waiting for the update but dont like being forced to pay patreon just to get it.

In a month, as described on my patreon.

[qotsafan]

7 minutes ago, Durante said:

Do you think you could incorporate npc bodyscale randomizer into your mod? And perhaps add in a few stable sliders from your own? Just an idea

Well, you can already use all the scales you want via my framework, npc bodyscale randomizer is basically just providing the numbers.

[chajapa]

qotsafan,

I am experimenting with getting SLIF integrated into Elsie LaVache. I'm using a "no dependency" method.

 

I can get my mod to register, and get inflation to happen, but now that leaves me trying to figure out how to continue.

 

My first obstacle:

I can inflate both breasts (for example) to a value of 4.0. (which seems to equate to sliding Racemenu's slider to negative .40) I can deflate them by feeding that same routine a negative number. (Is there a deflate event or is negative number the way to do this?)

However, if I feed an NPC the same event twice (inflate 4.0 as the value) she still shows as having a value of 4.0 in SLIF's MCM so I am guessing the inflate value is absolute. "Make them this size" as opposed to "increase/decrease by this much". 

Is that correct?

 

Is there a proper way for me to read an NPC's current value for an sKey and then either add to it or subtract from it?

Or does that then require dependency to access SLIF_Main?

 

Keep in mind I was not scaling nodes prior to this, but rather I was using BodyMorphs ... like this...:

NiOverride.SetBodyMorph(akActorRef,breasts, NIO_KEY, ((breasts0)+(0.1)))

 

I'm trying to figure out the best way to incorporate SLIF without having to go through every single instance where I've morphed the body. 

Normally it's a set size. (Go to *this* size), but there are a few instances where I would like to be able to make a body part bigger or smaller than it's current setting.

Possible?

 

[qotsafan]

54 minutes ago, chajapa said:

qotsafan,

I am experimenting with getting SLIF integrated into Elsie LaVache. I'm using a "no dependency" method.

  

I can get my mod to register, and get inflation to happen, but now that leaves me trying to figure out how to continue.

 

My first obstacle:

I can inflate both breasts (for example) to a value of 4.0. (which seems to equate to sliding Racemenu's slider to negative .40) I can deflate them by feeding that same routine a negative number. (Is there a deflate event or is negative number the way to do this?)

However, if I feed an NPC the same event twice (inflate 4.0 as the value) she still shows as having a value of 4.0 in SLIF's MCM so I am guessing the inflate value is absolute. "Make them this size" as opposed to "increase/decrease by this much". 

Is that correct?

 

Is there a proper way for me to read an NPC's current value for an sKey and then either add to it or subtract from it?

Or does that then require dependency to access SLIF_Main?

 

Keep in mind I was not scaling nodes prior to this, but rather I was using BodyMorphs ... like this...:

NiOverride.SetBodyMorph(akActorRef,breasts, NIO_KEY, ((breasts0)+(0.1)))

 

I'm trying to figure out the best way to incorporate SLIF without having to go through every single instance where I've morphed the body. 

Normally it's a set size. (Go to *this* size), but there are a few instances where I would like to be able to make a body part bigger or smaller than it's current setting.

Possible?

 

Yes, values are absolute, you will have to make the calculation beforehand.

Negative values don't work in the original system, they can't go lower than 0.

There is no deflate event, just inflate with a lower number or unregister the node.

You can get the value like this, without adding SLIF_Main as adependency (0 is the default value):

StorageUtil.GetFloatValue(kActor, modName + node, 0.0)

I'm assuming here, you are using the old system, not the new one, correct me, if you are trying to set BodyMorphs directly via SLIF, that's a bit different.

[Durante]

On 9/4/2018 at 12:32 AM, qotsafan said:

Well, you can already use all the scales you want via my framework, npc bodyscale randomizer is basically just providing the numbers.

Yes but you have to do it manually, if something like randomizer was integrated into your mod as an option when registering NPC's, it would bring out the full potential of the framework

 

Besides that, I seem to only  get the option to remove a node when pressing on it? In the past I was able to change the values of target NPC's

[qotsafan]

1 hour ago, Durante said:

Yes but you have to do it manually, if something like randomizer was integrated into your mod as an option when registering NPC's, it would bring out the full potential of the framework

Ah, I see now, where you are coming from, you mean add more nodes to the randomizer. I could implement a randomizer of my own, I will see, what I can do.

1 hour ago, Durante said:

Besides that, I seem to only get the option to remove a node when pressing on it? In the past I was able to change the values of target NPC's

If you want to manually change values, I would suggest registering SLIF itself for the player/npc:

 

[chajapa]

1 hour ago, qotsafan said:

Yes, values are absolute, you will have to make the calculation beforehand.

Negative values don't work in the original system, they can't go lower than 0.

There is no deflate event, just inflate with a lower number or unregister the node.

You can get the value like this, without adding SLIF_Main as adependency (0 is the default value):

StorageUtil.GetFloatValue(kActor, modName + node, 0.0)

I'm assuming here, you are using the old system, not the new one, correct me, if you are trying to set BodyMorphs directly via SLIF, that's a bit different.

I'm using 1.20a beta.

I wanted to expand hips and hipbone, but I don't see keys for those. I really don't manipulate them much so I can continue to do that "manually" and set them (bodymorphs) to certain values. And no I'm not trying to do that from inside SLIF

 

There are a couple of little-used routines but I think I've made all of my normal stuff use SLIF. I still have to run a lotta tests. I had almost all of the functions in one script. I mainly have to see if the SLIF inflation values I used are close to the result I was getting when setting the morphs myself. 

[Macross.]

qotsafan, not sure your policy on outside suggestions/changes so sorry in advance if you prefer to manage everything in house.

 

I recently help someone correct an issue they were having when using this mod along with RedBlue's Devourment mod (with the patches of course). This may be an issue with their setup and not the fault of inflation framework; but as I also experienced the same bug when trying to find a fix, it is at least a common issue.

 

The problem: On a swallow event SILF doesn't seem to pick up the call from Devourment to scale the belly node, so the inflation in handled internally by Devourment and the visual change still occurs, but SILF registers Devourment as having a zero value for the belly node.

 

This results in some minor conflicts if other mods try to change belly size properly through SILF causing the competition your mod is designed to prevent. But the real problem occurs when any of the many options Devourment has to decrease the belly node are used, here SILF recognizes the change as intended but because in never applied the initial inflation it results in a negative value for the belly node within SILF.

 

Further, because SILF takes the deflation call instead of Devourment, the internal belly node scale in Devourment remains unchanged as a non-zero number. Interestingly these two bugs seem to cancel each other out visually for the first few interactions, but after a few iterations things start to get really strange and both mods stop working as intended.

 

 

The fix I came up with is to remove the IfElse checks to verify that SILF is installed along with the normal Devourment nioveride functions should it not be; so calling a SILF inflation event is the only thing that can happen. I realize this is probably not the cleanest or safest fix, but since the SILF compatibility patches shouldn't be installed without SILF itself, it is relatively innocuous from an end user standpoint.

 

Just wanted to bring the issue to your attention, and provide a possible (short term?) fix for you to consider.

 

 

P.S. I've never used Devourment without your patch so this may be an issue with that mod itself and entirely not your problem, but the While loops used to provide a gradual change in node scale in several scripts have the potential for residual unintended inflation if the associated powers are used again before the loop can complete. You may want to consider removing the iterative change method, or adjusting the rate/delay values to reduce the total process time to maximize stability.

 

Thanks for your time, and sorry for the text wall.

[Bullfye]

Pay for Download????

 

Is this ok or am I doing something wrong and went to the Patreon page ??? 

[Macross.]

1 minute ago, Bullfye said:

Pay for Download????

 

Is this ok or am I doing something wrong and went to the Patreon page ??? 

Just ran into this myself, the Patreon seems to be an early access system, everything is released there for 1 month before being added here for free. The previous version is still available here, and quite functional as is.

[g23028284]

Now we have skse64 , racemenu se , will you try to port this mod to se version please?

[Lugubrious0ne]

Hey Qotsafan,

 

Big fan of your work, and enjoying 1.21 so far with no problems. I have two thoughts on your mod I thought might be worth bringing to you:

 

1) Would you ever consider releasing a 'simplified' version of the MCM, with perhaps slightly fewer options and ESPECIALLY, a less detailed range on your sliders. It can be very time-consuming to get numbers that I'm happy with when the sliders for bodymorphs etc go to 2 decimal places, and there is no way to input a value directly. Regarding other simplification of the menu - it's taken me a very long time to work out exactly which parts of the MCM are 'relevant' to the game as I play it and which of them are not...and I invest a lot of time in Skyrim  For users who are simply looking for a way to get two mods to play nice together, it might be confusing.

 

2) As so many of the mods that your framework covers include in-game buffs/debuffs that are tied directly or indirectly to their scaling (Fill Her Up, SGO, Beeing Female, weightmorphs etc), would you ever consider adding functionality to SLIF that unifies these systems? This would allow the player to specify, say, a movespeed debuff that scales with total belly scale, a speechcraft buff that scales with total breast scale, etc. Customizable with checkboxes and sliders in an MCM page. What do you think?

[Macross.]

20 minutes ago, Lugubrious0ne said:

1) Would you ever consider releasing a 'simplified' version of the MCM, with perhaps slightly fewer options and ESPECIALLY, a less detailed range on your sliders. It can be very time-consuming to get numbers that I'm happy with when the sliders for bodymorphs etc go to 2 decimal places, and there is no way to input a value directly.

While I too struggle with determining the relevant portions of the MCM, I can offer a bit of help with the slider range issues. This is obviously non-ideal, but since most mods provide their source code .psc files, you can do minor tweaks on your own files and recompile using the creation kit with relatively low odds of messing anything up (but you will need to extract the scripts folders from the skyrim BSA files or the compiler will likely throw a fit).

 

I'll use weightmorphs as an example since we both use it, and I have done a good bit of modification to it myself (and it doesn't seem to be getting updates anymore, so your changes aren't likely to be overwritten). Assuming you are using the normal WeightMorphs MCM and haven't done something I'm unaware of to control it fully through SILF you will want to look at the WeightMorphsMCM.psc file which is what dictates how the sliders act in game (also, this file isn't changed or provided by SILF so it isn't really Qotsafan's role to change it for you).

 

You are going to start by looking for the Event Block:

Event OnPageReset(String a_page)

This is should be the same for any script controlling an MCM. Within this block you are looking for lines of the following form:

_myMultBreastsSSH = AddSliderOption("Breasts SSH", WMorphs.MultBreastsSSH, "{2}")

The important part here is the "{2}" which dictates how many decimal places the slider displays ie; "{0}" = 1 "{1}" = 1.0 "{2}" = 1.00 and so on. So if you want to limit the precision, just decrease that number for each slider you want to change.

 

Next, you need to find another Event Block:

Event OnOptionSliderOpen(Int a_option)

This is where you actually define the data behind the slider, which takes the following form:

ElseIf a_option == _myMultBreastsSSH
		SetSliderDialogStartValue(WMorphs.MultBreastsSSH)
		SetSliderDialogDefaultValue(0.0)
		SetSliderDialogRange(-2.0, 2.0)
		SetSliderDialogInterval(0.01)

These are hopefully fairly self explanatory, but the important part is that if your slider dialog interval is finer than the value you set in the previous step, it will not display properly once set. I've never actually done this so I'm not sure if it will just break things outright, but at the very least it will cut off the exceeding decimals in the page view.

 

Finally, you need to find one more Event Block:

Event OnOptionSliderAccept(Int a_option, Float a_value)

Which reestablishes the slider after you change the value in game. Here you're looking for a similar syntax to the first block

ElseIf a_option == _myMultBreastsSSH
		WMorphs.MultBreastsSSH = a_value
		SetSliderOptionValue(a_option, WMorphs.MultBreastsSSH, "{2}")
		WMorphs.UpdateWeight()

Where you again need to change the value within the "{2}" section. This should match the value you used in the first block or you will see issues.

 

TL;DR open WeightMorphsMCM.psc and change the 2s in "{2}" to 1 or 0 if you want less decimal places in your display values, change the SetSliderDialogInterval (0.01) lines to use a larger number so that the slider has courser control. And change the SetSliderDialogRange (-2.0, 2.0) lines to adjust the slider minimum and maximum values.

 

Then recompile the script and you should be good to go in game. (Again, this should be all you need to do to change the properties on just about any slider in any MCM, but I do not guarantee that the rest of the mod will be able to handle things if you start setting the slider to numbers it doesn't expect).

[PsychosCreed]

how can I fix the issue where the framework says I'm using the wrong papyrus when I'm not

[qotsafan]

15 hours ago, PsychosCreed said:

how can I fix the issue where the framework says I'm using the wrong papyrus when I'm not

if you are using mod organizer, place papyrusutil on the left side below the sexlab framework (make sure, that nothing overwrites it), otherwise reinstall papyrusutil.

[hamthe3rd]

How can I download the new version? It seems to go to Patreon, which wants me to become a member.

 

 

[BearWithASword]

Quick question, could I use this to change the affected node for mods like SGO? Such as changing the affected node from belly to pregnancybelly?

[chajapa]

7 hours ago, hamthe3rd said:

How can I download the new version? It seems to go to Patreon, which wants me to become a member.

 

 

The Patreon link is for the latest version which will be available to non-Patreon supporters after 1 month. In other words... the latest version is available to Patreon supporters 1 month before it's available to LoversLab users. 

By doing this, the author still offers the mod and updates for free, but those who support him on Patreon get it a bit sooner.