Rad Morphing Redux

[LenAnderson]

58 minutes ago, Haberdasher said:

[LenARM]   no base morphs

 Oh, I see. Without base morphs it's still comparing newMoph with CurrentMorph.  I thought I had changed that as well to FullMorph (which is 0 after a restart). That will fix it.

 

58 minutes ago, Haberdasher said:

So initial run of a new (not previously installed) rmt plugin, going immediately to slider set trigger drop down won't show the new triggers, one of the above has to be done first

Might not have been in yesterdays code, but during startup of the trigger script, I do the following:

Try to get a reference to RMR, if success, get trigger name from MCM, check if RMR is running, if yes, register trigger name, if success, update value.

Basically, trigger registering happens:

• When the name was changed in MCM
• When RMR sends the OnStartup event
• When the trigger script starts

 

58 minutes ago, Haberdasher said:

That's why I was thinking of having the keyword tied to (and supplied by) the trigger plugin to simplify things.

Hmm, interesting idea. I'd have to think about the possible side effects of removing / changing a trigger later on. The keyword would have to be saved in RMR to be able to do the morphing. No idea what happens when suddenly that keyword no longer exists. I think as far as BodyGen is concerned the morphs would just be removed, but what about the script variables that now have a value that no longer exists... hopefully it would just be set to none?

 

 

58 minutes ago, Haberdasher said:

Can you link me to somewhere that issue is mentioned?

I think I found somewhere on nexus and / or reddit how to save an esp as esl. Basically this:

Load the ESP in CK, File -> Compact Form IDs, File -> Convert to light master

Now there's a .esl file with the same name as the .esp, however that file can not be set as the active file in CK. Hence, that file is useless for development and creating an esl from the esp would just be one stop of publishing a release for me. Unfortunately it's a step that requires CK and cannot be automated...

So, if there's a better way of doing this where I can edit the same file that I will release, that would make me quite happy to learn.

 

 

58 minutes ago, Haberdasher said:

Also sorry when I'm describing your own code, it's not to describe to you how it works, you already know, it's to try and convey my understanding of how it works to you.

No worries. Reasoning about code is fun.

And just doing this one on the side (while spending most of the day in other codebases) with all the complexity resulting from the flexibility I'm trying to provide, it's easy to miss something. So a different perspective is really helpful.

 

 

EDIT: A new game is pretty much required to use v2 anyways, since it's a new esp, new script files, ... I would be surprised if FO4 managed to make any sense of it with a savegame that had v1 running before.

 

EDIT2: It's pretty cool that you're already working with the new version. Just be aware that it's all very fluid at the moment, Everything is subject to (drastic) change and for now I am only working off of a savegame that has no RMR installed, so that it's always basically starting fresh. I may at any point rename functions, variables, ditch some systems, completely rewrite or reorganize others...

Edited May 16, 2022 by LenAnderson

[vaultbait]

2 hours ago, LenAnderson said:

I think I found somewhere on nexus and / or reddit how to save an esp as esl. Basically this:

Load the ESP in CK, File -> Compact Form IDs, File -> Convert to light master

Now there's a .esl file with the same name as the .esp, however that file can not be set as the active file in CK. Hence, that file is useless for development and creating an esl from the esp would just be one stop of publishing a release for me. Unfortunately it's a step that requires CK and cannot be automated...

So, if there's a better way of doing this where I can edit the same file that I will release, that would make me quite happy to learn.

 

I've used FO4Edit to compact form IDs and flag a plugin as light/ESL, though from what I understand you have to be careful if you have any references in your scripts since they'll need to be remapped by hand. Supposedly FO4Edit is scriptable too, though I haven't tried to automate anything in it yet.

[tzenrick]

I was literally just commenting out a line and recompiling the script.

 

 

It gave me the effect I wanted.

 

If I stuck a check in there to get a state from an MCM variable bFollowersKeepMorphs, it would fail on me. To be fair, though, I haven't gotten the hang of dealing with MCM.

 

Also, looking at this, here and now, wouldn't 1042 and 1043 need to be swapped, so you're not deleting the values before you try to restore them?

[tzenrick]

On 5/12/2022 at 4:36 AM, LenAnderson said:

a proper papyrus debugger!

You mean, instead of spewing as notifications or into a log?! Wild.

 

 

[tzenrick]

5 minutes ago, tzenrick said:

I was literally just commenting out a line and recompiling the script.

 

 

It gave me the effect I wanted.

 

If I stuck a check in there to get a state from an MCM variable bFollowersKeepMorphs, it would fail on me. To be fair, though, I haven't gotten the hang of dealing with MCM.

 

Also, looking at this, here and now, wouldn't 1042 and 1043 need to be swapped, so you're not deleting the values before you try to restore them?

 

And I just caught up to the rest of the thread, and it's looking like I made this a "thing."  My bad.

 

I was just using it as an easy shortcut to making my strippers "more strippery," without having to open looksmenu for all of them.

[LenAnderson]

6 hours ago, vaultbait said:

I've used FO4Edit to compact form IDs and flag a plugin as light/ESL, though from what I understand you have to be careful if you have any references in your scripts since they'll need to be remapped by hand. Supposedly FO4Edit is scriptable too, though I haven't tried to automate anything in it yet.

Ok, so after reading some more:

Setting the flag in FO4Edit seems to keep the esp extension which lets you edit the file in CK.

Apparently, when going the CK route, you can also rename the resulting esl to esp and then it's the same as setting the flag in FO4Edit.

And it looks like editing an esp file with an esl flag in CK will reset it to a regular esp, so you'd have to re-do the flagging in FO4Edit or the esp-to-esl-to-esp shenanigans in CK whenever the esp was changed.

 

 

3 hours ago, tzenrick said:

Also, looking at this, here and now, wouldn't 1042 and 1043 need to be swapped, so you're not deleting the values before you try to restore them?

1042 only removes the companion reference, not the list of original morphs. So that's fine.

 

 

4 hours ago, tzenrick said:

If I stuck a check in there to get a state from an MCM variable bFollowersKeepMorphs, it would fail on me.

Hard to guess why without seeing the context (papyrus, mcm configs and inis...).

[Haberdasher]

OK this has been doing my doing my head in, but think I finally figured it out, tangent to your mod, but affecting it (and all mods that use SetMorph).

 

(Reiterating a bit) BodyGen.SetMorph resolves to _this_
UserValues is an unordered map of UInt32 to id the keyword (it's simply just the pointer to the BGSKeyword), or 0 if no keyword, mapped to the morph value.

 

UpdateMorphs resolves to _this_
Where it's just iterating over all of the elements to find the highest morph value.

 

Which is nice and simple, in a modding landscape where you have no idea of what other mods may be running that modify the same morph, basically having it choose highest morph value wins is OK.
Though it does restrict the usage of negative morph values.

 

However the in game behavior I was seeing, and with a lot of custom testing, didn't match with that code.

 

So I eventually arrived at the thought, what if the source I'm looking at isn't up to date, maybe there's some uncommitted code that LooksMenu f4ee is built off?
Ah. It's actually the _opposite_

See the most recent change is to GetEffectiveValue.

See the commit date is 22 Jul 2021.
See the most recent LooksMenu release is 4 Nov 2020.

 

In all versions prior to this commit (which is up to BodyGens initial introduction in 2017),
max_element was called without a comparison function, so (as near as I can figure) means it's actually finding the highest map key, which is the Keyword pointer as Uint32, instead of the highest (morph) value of the key.

 

Which causes the following behavior:
Setting Base/None value for a morph will overwrite the Base value (as expected).
But when any keyword morph values are added to a morph it becomes a crapshoot to what's chosen.
If there's one keyword on the morph the keyword morph value will be chosen, even if the Base/None value is higher.
If there is more than one keyword value for a morph, then the morph value of the highest keyword id (which is just.. something).
Either way it's clearly not something usable/manageable from a mod author or user standpoint, it's just plain broken logic.

 

All this I kind of confirmed by in game observations and custom testing of using SetMorph/RemoveMorph with specific keywords and values as well as logging with the various BodyGen.Get information functions.

 

However there is that fix, it makes it so it gets the highest map value out of all the key/values (which includes the Base/None at key 0), which seems to be what was always intended for the system.

 

But the fixed version isn't released, so the community at large still has the bug.

 

Edited May 19, 2022 by Haberdasher

[LenAnderson]

6 hours ago, Haberdasher said:

OK this has been doing my doing my head in, but think I finally figured it out, tangent to your mod, but affecting it (and all mods that use SetMorph).

 

(Reiterating a bit) BodyGen.SetMorph resolves to _this_
UserValues is an unordered map of UInt32 to id the keyword (it's simply just the pointer to the BGSKeyword), or 0 if no keyword, mapped to the morph value.

 

UpdateMorphs resolves to _this_
Where it's just iterating over all of the elements to find the highest morph value.

 

Which is nice and simple, in a modding landscape where you have no idea of what other mods may be running that modify the same morph, basically having it choose highest morph value wins is OK.
Though it does restrict the usage of negative morph values.

 

However the in game behavior I was seeing, and with a lot of custom testing, didn't match with that code.

 

So I eventually arrived at the thought, what if the source I'm looking at isn't up to date, maybe there's some uncommitted code that LooksMenu f4ee is built off?
Ah. It's actually the _opposite_

See the most recent change is to GetEffectiveValue.

See the commit date is 22 Jul 2021.
See the most recent LooksMenu release is 4 Nov 2020.

 

In all versions prior to this commit (which is up to BodyGens initial introduction in 2017),
max_element was called without a comparison function, so (as near as I can figure) means it's actually finding the highest map key, which is the Keyword pointer as Uint32, instead of the highest (morph) value of the key.

 

Which causes the following behavior:
Setting Base/None value for a morph will overwrite the Base value (as expected).
But when any keyword morph values are added to a morph it becomes a crapshoot to what's chosen.
If there's one keyword on the morph the keyword morph value will be chosen, even if the Base/None value is higher.
If there is more than one keyword value for a morph, then the morph value of the highest keyword id (which is just.. something).
Either way it's clearly not something usable/manageable from a mod author or user standpoint, it's just plain broken logic.

 

All this I kind of confirmed by in game observations and custom testing of using SetMorph/RemoveMorph with specific keywords and values as well as logging with the various BodyGen.Get information functions.

 

However there is that fix, it makes it so it gets the highest map value out of all the key/values (which includes the Base/None at key 0), which seems to be what was always intended for the system.

 

But the fixed version isn't released, so the community at large still has the bug.

 

Oh wow. That's a real pity. Then again, even the fixed version doesn't do what I would have expected and what (from my point of view at least) would make sense for multiple mods acting on the same slider. I would have actually expected that all keyworded morphs would be added on top of the base value. The way the unreleased update works, not only are negative values discarded if any other keyword-morph is present, you also cannot have the compound effect of, say, a weight-gain plus pregnancy mod if both affect the same sliders.

In the end, even with keywords (and a fixed LooksMenu), this means that you have to look out that you only have a single mod modify any particular slider, or the resulting morphs will not be as intended.

[Haberdasher]

There's been a bunch of discussion in the past for Skyrims equivalent, and it doesn't seem to be an easy problem.
You can see an attempted solution and discussion _here_, and immediately people (including mod authors, and Expired6978 the author of RaceMenu/LooksMenu even makes an appearance) are suggesting different solutions due to how they think the mods they're using (or creating) should treat it.

 

[LenAnderson]

2 hours ago, Haberdasher said:

There's been a bunch of discussion in the past for Skyrims equivalent, and it doesn't seem to be an easy problem.
You can see an attempted solution and discussion _here_, and immediately people (including mod authors, and Expired6978 the author of RaceMenu/LooksMenu even makes an appearance) are suggesting different solutions due to how they think the mods they're using (or creating) should treat it.

 

 

Well, that was an interesting read

Yeah, I guess there's not easy answer to the question of how multiple morphs on the same slider should be consolidated, and people have different expectations. That just shows that configurability is king.

[sett]

is there any way to make this mod's heal morphs at doctors setting compatible with Horizon without me having to recompile horizon's scripts? 

[LenAnderson]

30 minutes ago, sett said:

is there any way to make this mod's heal morphs at doctors setting compatible with Horizon without me having to recompile horizon's scripts? 

 

Unless they've changed the crucial part over the last two years, Horizon is not compatible with only doctor healing. See below for why.

Since Horizon seems to still play the original doctor scenes (at least it did when I looked into it in 2020), it shouldn't be a problem anymore in the upcoming v2 of RMR.

 

On 4/23/2020 at 9:25 AM, LenAnderson said:

With "Only Doctors" it does not work because a doctor healing radiation needs to be detected and Horizon interferes with that.

 

This is what happens when vanilla doctors heal rads:

1. Player picks "Heal Rads"
2. Healing scene starts and waits for healing procedure to be complete
3. Needle animation plays + fade out, fade in
4. Rads are removed + DoctorJustCuredRads property in the doctor script is set + healing procedure is marked as complete --> healing scene ends ("anything else bothering you?")

With "Only Doctors" the mod listens for the healing scene to end and then checks if DoctorJustCuredRads is set in the doctor script. Only if that's the case, morphs are reset.

 

Here is what happens in Horizon (guessing from the log file):

1. Player picks "Heal Rads" (in Horizon's doctor message box)
2. Rads are healed immediately
3. Mod picks up on that and increases unhealable base morphs (if additive morphing is enabled)
4. When you exit Horizon's doctor message boxes the healing scene starts and ends after about 1 second, but there is no information as to what the doctor did (DoctorJustCuredRads is not set)

If Horizon were to set the DoctorJustCured... properties before ending the healing scene the vanilla way of detecting doctor actions would still work. Unfortunately it doesn't.

 

 

[Haberdasher]

Continuing the saga that probably should have been it's own post:
Good news, I made a dumb mistake. I thought I was on the current LooksMenu version (1.6.20), but was on 1.6.18 (the earliest version that works on the current FO4 exe version).
Testing seems to show the morph value fix was actually introduced in LooksMenu 1.6.19, and remains in 1.6.20.

 

So, if people are on the current LooksMenu version, and the mods they have are using their own keywords instead of overwriting the base value, the highest morph value of all the values on the morph will be applied.

 

There's another problem though, the AAF Guide
has been specifically telling people to use 1.6.18 (probably why I had it installed) because "Any version above breaks erections.".
Anyone have any insight to this?
I'm wondering if there's a different bug, though looking at the code I can't see how, and I haven't noticed any issue with 1.6.20 myself.

Or was it that whatever mod they saw the issue on was designed around the previous broken logic so needs to be updated?

 

Might poke at the mods I have installed to see if there's any not using keywords. And I do remember seeing one that did initially look like it was using keywords, but the keyword property on the object the script was attached to wasn't actually set to anything, so it was the equivalent of None/set base value.

 

I also did do a basic test of applying keyword value to a morph then uninstalling that (custom test) mod and f4ee seemed to nicely just remove the morph values.
But probably wants more testing (by someone other than me) to make sure.

 

Still have other stuff to do, but hopefully will be able to get back to checking out the more recent commits of your mod Len after that.

 

[vaultbait]

4 hours ago, Haberdasher said:

There's another problem though, the AAF Guide
has been specifically telling people to use 1.6.18 (probably why I had it installed) because "Any version above breaks erections.".
Anyone have any insight to this?
I'm wondering if there's a different bug, though looking at the code I can't see how, and I haven't noticed any issue with 1.6.20 myself.

Or was it that whatever mod they saw the issue on was designed around the previous broken logic so needs to be updated?

 

I switched to LM 1.6.19 as soon as it was released, and then same for 1.6.20. I saw erections randomly not happen in animations even with 1.6.18, but even with 1.6.20 it happens infrequently for me. I've seen other people say 1.6.20 fixed erection issues they were seeing with 1.6.18, so it's really hard to say. The explanations I've gotten are based on circumstantial anecdata, and as far as I know nobody has identified the actual reason for the erection morph bug some people have with versions >1.6.18.

 

I stick with 1.6.20 because it includes some fixes for bugs in 1.6.18, incorporating some improvements from earlier Buffout 4 versions, and the F4EE patch in Buffout 4 is explicitly made for LM 1.6.20, and the one with the 1.6.18 fixes is only available in (now very) old Buffout 4 versions.

[NiX10]

So mod is great and i love it, i noticed however that at least for me, while starting a new game and having the mod installed, my game loads forever, i have to start a new game without the mod and then install it after i do it, dunno if that is me or its a weird bug.

[rubber_duck]

Just now, NiX10 said:

So mod is great and i love it, i noticed however that at least for me, while starting a new game and having the mod installed, my game loads forever, i have to start a new game without the mod and then install it after i do it, dunno if that is me or its a weird bug.

 

Must be your load order. I've started dozens of new saves with RMR enabled and each time it loaded correctly.

 

That being said, upon starting the new game it is important to give the game a few moments to load everything. I, for one, always wait at least 60 seconds after selecting to start the new game since I have quite a load order.

 

If the game appears to be stuck, just press 't' or Return key once or twice. The game gets loaded but doesn't automatically redirect you to the character creation. It's a known issue.

[vaultbait]

5 hours ago, NiX10 said:

So mod is great and i love it, i noticed however that at least for me, while starting a new game and having the mod installed, my game loads forever, i have to start a new game without the mod and then install it after i do it, dunno if that is me or its a weird bug.

 

As a safety precaution, I keep an entirely unmodded vanilla save from immediately after exiting Vault 111 and always start new playthroughs from that. As soon as all the mods start up, I use the console commands showspecialmenu and showlooksmenu player 1 to set my name/stats and apply a saved LooksMenu preset. RMR has never given me any startup trouble following that (admittedly somewhat paranoid) process.

[LenAnderson]

5 hours ago, NiX10 said:

So mod is great and i love it, i noticed however that at least for me, while starting a new game and having the mod installed, my game loads forever, i have to start a new game without the mod and then install it after i do it, dunno if that is me or its a weird bug.

 

I could imagine the disabled warning or update messages popping up while the screen is still black. I've noticed that with some other mods sometimes when loading a game (not just starting a new game but loading an existing save) that there seems to be some confirm dialog coming up right after loading while the screen is still black and preventing the black from fading out. And just like rubber_duck said, pressing return or E a couple of times fixed it (you can hear the sound of the button click).

[Haberdasher]

@vaultbait thanks for your feedback/info.

Here's a mod I made while working through looking at these issues, mostly for logging and clearing values to get an idea of what's going on with the current state of your games morphs.

I had intended to expand my testing system to more easily test a morph with base and multiple keyword values in a generalized/flexible way, but ended up just bashing out some hard-coded functions for my tests due to time, and since that's not so useful for general testing so I pulled those out.
 

 

[Nuka Cherry]

Great to see this being developed further!

 

Innevitable "would it be possible" question incoming: would you consider adding a mechanism for armor/clothing removed by RMR to be destroyed (chance or always)?

Edited June 1, 2022 by Nuka Cherry

[LenAnderson]

3 hours ago, Nuka Cherry said:

Great to see this being developed further!

 

Innevitable "would it be possible" question incoming: would you consider adding a mechanism for armor/clothing removed by RMR to be destroyed (chance or always)?

 

That would just be RemoveItem without a target container, right? Shouldn't be an issue to add as a feature.

[Nuka Cherry]

With the tearing sound included, that would make sense of the noise and add a consequence.

[joaosagrath]

Another invitable "if possible" question:

 

What about import a bodyslide preset to change morph when get rads?

let me explain with images:

 

I have my default body preset like this: 

Thick CBBE

 

But when I get about 50% rads, the mod wil morph my preset in this:

Consequences of Radiation CBBE

 

and if get to 75% the morph doubles this preset (pretty mess, but hey, this is a lot of rads)

 

And of course, after get rid of the rads, the morphs reset to original preset.

 

cheers

 

 

[LenAnderson]

42 minutes ago, joaosagrath said:

Another invitable "if possible" question:

 

What about import a bodyslide preset to change morph when get rads?

let me explain with images:

 

I have my default body preset like this: 

Thick CBBE

 

But when I get about 50% rads, the mod wil morph my preset in this:

Consequences of Radiation CBBE

 

and if get to 75% the morph doubles this preset (pretty mess, but hey, this is a lot of rads)

 

And of course, after get rid of the rads, the morphs reset to original preset.

 

cheers

 

 

 

Not sure that's doable as part of the mod as I don't think we have a way of reading the presets.

However, I could probably add something in the RMR Helper that sets up slider sets so that the selected (base/original) preset would morph into another. Basically have the helper do all the calculations you would otherwise have to do manually to get the desired results.

[joaosagrath]

2 hours ago, LenAnderson said:

 

Not sure that's doable as part of the mod as I don't think we have a way of reading the presets.

However, I could probably add something in the RMR Helper that sets up slider sets so that the selected (base/original) preset would morph into another. Basically have the helper do all the calculations you would otherwise have to do manually to get the desired results.

 

It's already something to get! 
 

I myself have already tried to transpose the values of a preset into the mod, but this led me to a series of sliders and values that I ended up losing my way.

if we could, for example, set the slide to a fixed value, it would already be possible to transpose the current preset to the desired one, as it would be enough to repeat the values of that preset within the RMR.

This would also give the option to decrease some slider, after all Radiation doesn't necessarily need to inflate the breasts, it can also wither isn't it LOL!