Rad Morphing Redux

[LenAnderson]

1 hour ago, Hex Memeniac said:

Do you plan to add more sliders?

 

Do you mean more than the 20 slider sets currently available in MCM? Because there really isn't any limit to the number of looksmenu sliders to morph (or which type of body you use) right now.

The list of MCM pages for RMR is already quite long so I would not want to increase it even more by default. I've though about adding a FOMOD option to install the mod with more slider sets available but at least the way its currently implemented that would mean also compiling the script multiple times and that's just going to introduce problems. Maybe something with a hidden MCM setting in a separate ini file may do the job. However, this is not high on my priority list right now.

  

 

 

1 hour ago, Hex Memeniac said:

or even profile, so we can share with each other preset like bodyslide xml

 

You can already share or switch between different presets by replacing .../Data/MCM/Settings/LenA_RadMorphing.ini

Just stop and restart the mod through MCM to reload the values from the new ini file.

[Hex Memeniac]

Yes because sometimei when im playing with TWB sliders , i find  more slider would be even better   to get the perfect shape , but its because of the chaotique nature of TWB sliders

Edited April 13, 2022 by Hex Memeniac

[Dutchygamer]

On 4/10/2022 at 1:21 PM, LenAnderson said:

 

Looks like my commits weren't automatically mirrored to github. The repo is now up to date again. Might make it easier to see what I've changed. 

Yeah, need to figure out an easy way to find all the differences between your version and mine. I've been doing some... reorganizing of the code, so that doesn't help my case. But I'll figure it out

[nousernamethanks]

this is positively ingenious

[Haberdasher]

Great reduxed mod, the flexibility the slidersets and slider and slot name parsing provides is amazing.

 

I hacked a proof of concept/for my own use version together that shifts detection type into slider set and uses that to choose other value functions for the slider sets to morph off.

Currently just added a few value functions.

So currently have my chars nipple length and clit size/length scaling to SexAttributes Arousal, and Vaginal/Anal Open on the SexAttributes Wear value for genuine gaping (and meat curtains), and then the others to the usual Rads scaling, all different value types working independently.

Haven't really tested the same slider over different value types yet.

 

Attached zip is just the modded files, not compiled.

Search the script for ;HBD, or just use diff tool vs 1.0.1 to see the changes.

 

Possibly more ideal/further step (but beyond my skill level) would be a plugin system to just provide the value calculation function, since there's really no limit to fun values to scale off, AP, each special value, the extra Advanced Needs stats, potential is endless.

Rad Morphing Redux - HBD Modded.7z

Edited April 26, 2022 by Haberdasher

[LenAnderson]

5 hours ago, Haberdasher said:

Great reduxed mod, the flexibility the slidersets and slider and slot name parsing provides is amazing.

 

I hacked a proof of concept/for my own use version together that shifts detection type into slider set and uses that to choose other value functions for the slider sets to morph off.

Currently just added a few value functions.

So currently have my chars nipple length and clit size/length scaling to SexAttributes Arousal, and Vaginal/Anal Open on the SexAttributes Wear value for genuine gaping (and meat curtains), and then the others to the usual Rads scaling, all different value types working independently.

Haven't really tested the same slider over different value types yet.

 

Attached zip is just the modded files, not compiled.

Search the script for ;HBD, or just use diff tool vs 1.0.1 to see the changes.

 

Possibly more ideal/further step (but beyond my skill level) would be a plugin system to just provide the value calculation function, since there's really no limit to fun values to scale off, AP, each special value, the extra Advanced Needs stats, potential is endless.

Rad Morphing Redux - HBD Modded.7z 13 kB · 0 downloads

 

Wow! That's pretty cool.

 

I've thought about using different stats for morphing before (after a long stretch of basically never taking rads), but did not pursue that idea further.

A plugin system would be ideal and on the papyrus side fairly trivial I think. RMR wouldn't even have to know about the plugins, they'd just call a function in RMR to let the mod know that their value has changed (e.g. something like RMR.statChanged(statName, newValue)) and RMR then acts on that (perhaps on the next tick) if it has slider sets with affected by that stat.

 

What's a bit annoying is the rather static nature of MCM. Ideally you would pick the slider set's trigger from a dropdown. But that would require some kind of build-script for the MCM config to be run whenever the user adds a new plugin. As far as I know the options/values for dropdowns are statically defined in the MCM JSON and cannot be modified from elsewhere.

So the only other option I can think of really is to make it a text field and have the user type in the trigger's keyword.

 

I think I'll give this one a try and use that chance to rewrite the mod a bit as well. Just not sure how much time I have for this over the summer. So we may have to wait until winter again before the next update...

[vaultbait]

7 hours ago, LenAnderson said:

 

Wow! That's pretty cool.

 

I've thought about using different stats for morphing before (after a long stretch of basically never taking rads), but did not pursue that idea further.

A plugin system would be ideal and on the papyrus side fairly trivial I think. RMR wouldn't even have to know about the plugins, they'd just call a function in RMR to let the mod know that their value has changed (e.g. something like RMR.statChanged(statName, newValue)) and RMR then acts on that (perhaps on the next tick) if it has slider sets with affected by that stat.

 

What's a bit annoying is the rather static nature of MCM. Ideally you would pick the slider set's trigger from a dropdown. But that would require some kind of build-script for the MCM config to be run whenever the user adds a new plugin. As far as I know the options/values for dropdowns are statically defined in the MCM JSON and cannot be modified from elsewhere.

So the only other option I can think of really is to make it a text field and have the user type in the trigger's keyword.

 

I think I'll give this one a try and use that chance to rewrite the mod a bit as well. Just not sure how much time I have for this over the summer. So we may have to wait until winter again before the next update...

 

Yeah, if it could be adapted to have a food ingestion trigger via plugin, I would be thrilled. That wouldn't quite get all the way to a feeding/stuffing scenario on its own, but if there were also an associated decay rate...

[LenAnderson]

19 hours ago, vaultbait said:

 

Yeah, if it could be adapted to have a food ingestion trigger via plugin, I would be thrilled. That wouldn't quite get all the way to a feeding/stuffing scenario on its own, but if there were also an associated decay rate...

 

That should not be a problem. Even the decay rate would just have to be implemented in the plugin, probably with a game-time timer that reduces the "calories" trigger value every in-game hour or so and send the new value to RMR. As long as you have slider sets set up that follow the "calories" trigger the associated looksmenu sliders would increase and decease accordingly.

 

 

I sat down last night, deleted the whole RMR mod, and started over by setting up the framework for a possible plugin-based v2. Looks quite good and feasible so far, so I'm going to continue down that path.

RMR now has all the slider set and morphing logic, but does not check any values like rads itself. Instead to have any morphing happen you'll need a plugin mod that calls RMR and let's RMR know that a trigger value has changed. If you have a slider set that uses this trigger the morph calculation (including additive, doctors only, on sleep/periodic/immediate updates etc.) kicks in and applies the morphs according to the supplied trigger value and slider set configuration.

That means that while the plugins can of course be made as complex as you'd like, most the of complex RMR logic is still part of the mod and a plugin can be very basic to interact with RMR.

For example to have the original rad morphing back, a plugin would just have to start a timer to periodically check rads and pass that value through to RMR. Everything else will be taken care of by RMR. The same would go for other readily-available information like SexAttribute's values, AAF scene participants, health, AP, SPECIAL values, game time...

More complex stats like some kind of calorie intake / weight gain would have to be tracked in the plugin itself if there is no other mod available that provides such a value. So you'd have to listen to relevant events for consuming food and probably assign some kind of calorie value to each item. Maybe based on HP gain / healing. Keep track of how much you've eaten, translate that into a percentage value (0-100%), add a calorie decay value on a timer. And finally, notify RMR every time the player eats something or the value decays.

 

At least that's the idea and how, in principle, the prototype works right now. Let's see how far I'll get with this

[vaultbait]

42 minutes ago, LenAnderson said:

More complex stats like some kind of calorie intake / weight gain would have to be tracked in the plugin itself if there is no other mod available that provides such a value. So you'd have to listen to relevant events for consuming food and probably assign some kind of calorie value to each item. Maybe based on HP gain / healing. Keep track of how much you've eaten, translate that into a percentage value (0-100%), add a calorie decay value on a timer. And finally, notify RMR every time the player eats something or the value decays.

 

Exciting! And yeah, there are definitely mods (e.g. survival-oriented) which assign nutritional value from one or more of base sale price, inventory weight, irradiated effects, or via formlists of specific consumable IDs. My Papyrus scripting skills are, at best, still rather rudimentary for the moment, but that doesn't sound too challenging so I should be able to come up with something.

[LenAnderson]

Quick example using the console to show how a plugin would talk to RMR.

 

 

 

[Haberdasher]

So that looks like in RMR slider set you'd set a string tag/id (in that example "rads"), and plugins call rmrs setriggervalue with the tag (and value), and rmr updates all the slidersets that have that tag?

[LenAnderson]

1 hour ago, Haberdasher said:

So that looks like in RMR slider set you'd set a string tag/id (in that example "rads"), and plugins call rmrs setriggervalue with the tag (and value), and rmr updates all the slidersets that have that tag?

 

Exactly. Unfortunately the trigger name has to be typed by the user, as I cannot provide the available options to MCM dynamically. You just need to make sure you don't have two plugins that use the same trigger name as they would override each other. Or, ideally, the plugins would even offer a way to modify the trigger name through MCM, that way there's an easy way around any conflicts.

 

 

[LenAnderson]

Ok, it's getting better. I've found some info in the MCM changelogs that wasn't documented elsewhere (I think?) about getting MCM options from form lists and properties.

And now we can pick triggers from a dropdown as long as the plugins register themselves with RMR

 

 

 

(I have too many mods in my MCM)

 

[vaultbait]

2 hours ago, LenAnderson said:

I have too many mods in my MCM

 

This week I had the pleasure of finding out that MCM Settings Manager will refuse to export if there are more than 3K settings in aggregate, so now I have to decide if I value being able to export my settings enough to trim down my MCM-using mods (or custom edit them to simplify their MCM configs in order to reduce their settings count somehow).

[LenAnderson]

Since morphs aren't necessarily linked to rads anymore, healing morphs also shouldn't be triggered by healing rads...

 

 

 

[Haberdasher]

Looking good.

 

On my current hacked up version, one thing I've added is a 'Test value', with a slider to set it in the 0-1 range, so I can test slider sets over the value range without having to resort to tweaking the actual stats the other trigger value functions use.

 

You could possible have a similar test plugin that doubles as an example for mod authors as well as being useful for users.

 

[Nivea]

Love that this works for both females and males.

[LenAnderson]

3 hours ago, Haberdasher said:

Looking good.

 

On my current hacked up version, one thing I've added is a 'Test value', with a slider to set it in the 0-1 range, so I can test slider sets over the value range without having to resort to tweaking the actual stats the other trigger value functions use.

 

You could possible have a similar test plugin that doubles as an example for mod authors as well as being useful for users.

 

 

I've actually been thinking about making a tool to help with creating and tweaking slider sets that can be used with BodySlide instead of inside FO4.

You would open BodySlide with your preset and the preview window open. Then open the RMR helper, load your RMR ini (or create from scratch), load the xml for the body you're using, Now you can set up the slider sets, preview morphs and save it all to your ini.

While you won't see your full character and all the clothes, I think this would be a much quicker way than going in and out of MCM again and again to tweak and test.

 

Got a barebones test to see if I can easily communicate with BodySlide and that looks ok. Finding the right sliders and manipulating them is no problem.

 

 

 

[Haberdasher]

A ramble about the state of wrestling with morphs as a user (not really about your mod):
It's strange how disjointed the different slider/morph handling is across even the 'official' supports. Though that's a bit understandable from ad-hoc development of features over time, and in the case of Bodyslide vs looksmenu being two different teams. But the morph handling even within looksmenus two morph features is inconsistent.

 

You've got Bodyslide, the original, and now mostly just useful as a visualizer for people who use zeroed sliders and use the in-game morphing.
This has its settings 'preset' (sliders/morphs actually set to values) in its own xml format.
 

Then via the looksmenu you have Bodymorph, which gives you in-game slider editing, has it's own format files for defining the sliders(.json), then for actual profiles its a section inside the saved preset, which is yet another format.
And some people run into issues so I've seen the suggestion to not use it and use BodyGen template instead.

 

So BodyGen template - more specifically the BodyGen applied to Actors at runtime when it first encounter them. Defined again by yet another format, where it has all the different profiles combined in it's own format (morphs.ini) referenced by another (templates.ini)

 

Now there is a helpful tool to help a bit going between the two formats, but it still requires some copy/pasting rather than just actually reading the files.

https://www.nexusmods.com/fallout4/mods/41781?tab=description

(Though that it even has to exist really underlines what the problem is the first place.)

 

Ideally I think there should have been a single file format for set/saved slider values, then visualization tools/morph applying features could reference those.
But another issue is all the above have no concept that you might want to apply/manage multiple presets targeting different morphs.

 

But this is just my armchair cane-waving as someone coming late to the party.

 

On top of all that you have all the mods using BodyGen to its full power to set morphs how they see fit to dynamic/run-time values.

In your case you've got your work cut-out for you there in that you're trying to make it easy for the user to set up something visual that's essentially adjusting on two axis, the morph value itself, controlled by another (trigger) value.

 

I have my own script for just outright clearing the BodyGen on an Actor/my player, and to dump to papyrus log what the state of bodygen is for an actor (printing each morph each keyword value for the morph) which has helped my sanity a little when trying to fix stuff.

 

Also I've been using a combination of Bodyslide and my test value to wrestle my slider sets for this mod to something I'm happy with, so I think your tool will be a real help.

 

Again, good work on all this.

 

[LenAnderson]

1 hour ago, Haberdasher said:

A ramble about the state of wrestling with morphs as a user (not really about your mod):
It's strange how disjointed the different slider/morph handling is across even the 'official' supports. Though that's a bit understandable from ad-hoc development of features over time, and in the case of Bodyslide vs looksmenu being two different teams. But the morph handling even within looksmenus two morph features is inconsistent.

 

You've got Bodyslide, the original, and now mostly just useful as a visualizer for people who use zeroed sliders and use the in-game morphing.
This has its settings 'preset' (sliders/morphs actually set to values) in its own xml format.
 

Then via the looksmenu you have Bodymorph, which gives you in-game slider editing, has it's own format files for defining the sliders(.json), then for actual profiles its a section inside the saved preset, which is yet another format.
And some people run into issues so I've seen the suggestion to not use it and use BodyGen template instead.

 

So BodyGen template - more specifically the BodyGen applied to Actors at runtime when it first encounter them. Defined again by yet another format, where it has all the different profiles combined in it's own format (morphs.ini) referenced by another (templates.ini)

 

Now there is a helpful tool to help a bit going between the two formats, but it still requires some copy/pasting rather than just actually reading the files.

https://www.nexusmods.com/fallout4/mods/41781?tab=description

(Though that it even has to exist really underlines what the problem is the first place.)

 

Ideally I think there should have been a single file format for set/saved slider values, then visualization tools/morph applying features could reference those.
But another issue is all the above have no concept that you might want to apply/manage multiple presets targeting different morphs.

 

But this is just my armchair cane-waving as someone coming late to the party.

 

On top of all that you have all the mods using BodyGen to its full power to set morphs how they see fit to dynamic/run-time values.

In your case you've got your work cut-out for you there in that you're trying to make it easy for the user to set up something visual that's essentially adjusting on two axis, the morph value itself, controlled by another (trigger) value.

 

I have my own script for just outright clearing the BodyGen on an Actor/my player, and to dump to papyrus log what the state of bodygen is for an actor (printing each morph each keyword value for the morph) which has helped my sanity a little when trying to fix stuff.

 

Also I've been using a combination of Bodyslide and my test value to wrestle my slider sets for this mod to something I'm happy with, so I think your tool will be a real help.

 

Again, good work on all this.

 

 

Yeah, it's certainly all over the place. But I guess that's just what you get with modding compared to more or less centrally planned software  Then again, you have behemoths like SAP that are just as bad with inconsistencies...

 

I just spent way more hours than I expected to get the basics for the RMR helper going. Finding the right sliders to modify in BodySlide proved not as straightforward as it first looked. Not just are the display names shown in BodySlide not unique ("Size" is used in many different categories), the sliders and categories are also in a completely different order (not sure what order, not alphabetical) than the SliderCategories XML, and there are even categories that just don't exist in the XML file... The category headers in BodySlide are also separate from the sliders as far as the window tree is concerned. So now I am looping through all the windows / elements in the scrolling part of BodySlide, record the pixel-position of the sliders and of the category labels, assign all sliders that are positioned below a category label and above the next category label to that category, compare the category labels with the categories from the XML, skip the categories that are not in the XML, link the slider labels through the display name from the XML with the actual slider name... and then I finally have something to work with.

All the trial and error means that the code is now super messy and full of remains of all my attempts to figure out something that might just work

I'll have to rewrite most of that next time I return to this project...

 

But hey, I can now apply slider set morphs through my helper tool by changing the trigger value and it updates the BodySlide preview live!

 

 

 

[Dutchygamer]

This all looks very promosing indeed! I see that you've already started splitting up the main .psc file into separate .psc files. I wish I understood how to do that, as one of my main gripes of the current version's codebase is that it isn't easy to find something as everything is crammed into one large file. You can only go so far with creating comment headers and such, seeing that Papyrus doesn't really have regions you can declare to group code together.

 

If I may gave one piece of advice: make it a separate mod from the current RMR I assume that switching from the current release to the one you are working with would break the game in multiple ways.

[vaultbait]

54 minutes ago, Dutchygamer said:

If I may gave one piece of advice: make it a separate mod from the current RMR I assume that switching from the current release to the one you are working with would break the game in multiple ways.

 

Not only that, but the name of the existing mod is probably less relevant to an extensible/pluggable morphing framework, since it would be able to morph from lots of triggers besides radiation.

[LenAnderson]

1 hour ago, Dutchygamer said:

This all looks very promosing indeed! I see that you've already started splitting up the main .psc file into separate .psc files. I wish I understood how to do that, as one of my main gripes of the current version's codebase is that it isn't easy to find something as everything is crammed into one large file. You can only go so far with creating comment headers and such, seeing that Papyrus doesn't really have regions you can declare to group code together.

 

If I may gave one piece of advice: make it a separate mod from the current RMR I assume that switching from the current release to the one you are working with would break the game in multiple ways.

 

You can just add more than one script to the quest and have the different scripts reference each other through properties.

LenARM_Util Property Util Auto Const

When assigning the property in CreationKit, you have it point to the quest that you attached the script to (which in this case is the same quest, LenARM_Main).

 

Whether disabling v1 and then removing it before installing v2 works remains to be tested, but I will definitely advise to use a new game once v2 is released. At the moment I still plan to just make it the next version of RMR and provide the rads trigger with it. So that out of the box you'd get pretty much the same features as in the current version. Of course with a big fat warning about upgrading, just like when I made major changes in v0.3.

[LenAnderson]

Some progress on the RMR Helper.

 

The mod itself is also coming together. Basic player morphing with all the different options (doctor only, additive, limits...) and healing for caps is ready. Overrides are working. Still a lot of things that need to be implemented (morph after sleeping, companion morphing, stripping and strip sounds, configurable healing costs, some actual trigger plugins, fomod option for more or fewer slider sets needs to be tested).

 

 

 

[Haberdasher]

Looking good.

I'm wondering if invert-trigger value (the simple 1-value, assuming 0-1 scaled value) could be an option.