Jump to content

Recommended Posts

Been kicking around feature/v2 from the repo (from yesterday), while being aware its in development and you may be aware of what I'm reporting, and I may be causing problems myself.


First off, the slider set mcm breaks initially with Trigger Name dropdown since before RMR is turned on the first time the MCM_TriggerNames property is empty.


Restarting RMR, either manually by turning off in MCM and on again, or the automatic restart, doesn't reaply the morphs from the current values.
Nearest I can figure is LenArm_Sliderset SliderSets still have their values set, so don't reapply the morph because they think they already have?


I adapted my previous stuff and expanded it to a RMT plugin that covers all the Sex Attributes values, and (apart from the above issue) it seems to be working ok for a bunch of slidersets over a few of the trigger values.
Though took me a second to realize I had to restart RMR, turn it off and on again, for it to add the new triggers to the dropdown.


I pray for those people who might try the 50 slider sets MCM and not using MCM Booster, it's still a chunky initial load, but at least with Booster it's not every time you open the MCM menu. Anyway, the bountiful number of sliders will help me when I get round to testing all the values I can.


I'm also wondering about multiple sliders using the same morph, adding multiple selectable keywords for the morphs is probably too much of a pain, but I wonder if providing it from the trigger plugin
I really should probably just hack something together to test and see if it's actually something useful before asking you though.

And there's still the issue I want to track down some time where some mods using the same morph, and are using their own keywords correctly, but the highest value doesn't get applied like the BodyMorph source (or my poor c++ skills interpretation of it) suggests it should.

 

A request maybe for the API to be able to ask it if a given trigger is actually in-use, ie if there's any slider sets using it. That way on the RMT plugin side I can avoid running update functions for triggers that aren't being used.

 

Also you may want to flag LenA_RadMorphing.esp and LenARM_Trigger_Rads.esp as esl

 

I have yet to look at RMR helper.

 

Anyway, great work on the new version.

 

Link to comment
1 hour ago, Haberdasher said:

First off, the slider set mcm breaks initially with Trigger Name dropdown since before RMR is turned on the first time the MCM_TriggerNames property is empty.

Yes, I am aware of that. I'm going to add the dummy / blank value sooner at some point.

 

 

1 hour ago, Haberdasher said:

Restarting RMR, either manually by turning off in MCM and on again, or the automatic restart, doesn't reaply the morphs from the current values.
Nearest I can figure is LenArm_Sliderset SliderSets still have their values set, so don't reapply the morph because they think they already have?

Trigger must re-register themselves and call RMR.UpdateTrigger with the current value when they receive the OnStartup event. That should reapply the morphs. At least it does in my tests.

 

 

1 hour ago, Haberdasher said:

Though took me a second to realize I had to restart RMR, turn it off and on again, for it to add the new triggers to the dropdown.

That should not be necessary. The moment you call RMR.RegisterTrigger the new name shows up in the MCM. Maybe the trigger mod is not calling it at the correct time?

 

 

1 hour ago, Haberdasher said:

I'm also wondering about multiple sliders using the same morph, adding multiple selectable keywords for the morphs is probably too much of a pain, but I wonder if providing it from the trigger plugin

I guess I could provide a couple of keywords to choose from. Not one for each of the 50 sets though... Too much clicking in CreationKit... :D

 

 

1 hour ago, Haberdasher said:

And there's still the issue I want to track down some time where some mods using the same morph, and are using their own keywords correctly, but the highest value doesn't get applied like the BodyMorph source (or my poor c++ skills interpretation of it) suggests it should.

I wasn't aware of that. But if I do offer multiple keywords I should probably look into that as well.

 

 

1 hour ago, Haberdasher said:

A request maybe for the API to be able to ask it if a given trigger is actually in-use, ie if there's any slider sets using it. That way on the RMT plugin side I can avoid running update functions for triggers that aren't being used.

Yes that probably makes sense. Together with an event whenever a trigger name starts being used (i.e. selected in a slider set) and stops being used (i.e. selected something else in a slider set). That way triggers can pause and resume their activity whenever needed.

 

 

1 hour ago, Haberdasher said:

Also you may want to flag LenA_RadMorphing.esp and LenARM_Trigger_Rads.esp as esl

I actually just read up on ESLs last week. My understanding is that you must use the ESP in CreationKit (ESL cannot be the active file), and the ESL can really only be used for publishing. So, yes, I plan to release them as ESLs, but creating the ESL will be a release-only step since it is not suited for development.

 

 

 

Unrelated to the above, here are some changes to the MCM I am playing around with.

  • Healing costs are now configurable
    Fallout4_Vp6VJhgloB.thumb.jpg.5edcddfcda5f7e690d12b1ccffddd48c.jpg
     
  • SliderSets can be applied to only player, only companion, or player & companion
    Fallout4_6H36rl276F.thumb.png.8c67f514d2ed3a61cd3cc4917cc39163.png
     
  • SliderSets can be applied to female only, male only, both, independent of whether they apply to companions or players
    Fallout4_UO5pY7xc4Z.thumb.png.6313bbc5096141aa928c22150aad48f3.png

 

 

Link to comment
9 hours ago, Haberdasher said:

Restarting RMR, either manually by turning off in MCM and on again, or the automatic restart, doesn't reaply the morphs from the current values.
Nearest I can figure is LenArm_Sliderset SliderSets still have their values set, so don't reapply the morph because they think they already have?

 

7 hours ago, LenAnderson said:

Trigger must re-register themselves and call RMR.UpdateTrigger with the current value when they receive the OnStartup event. That should reapply the morphs. At least it does in my tests.

 

The plugin is adapted from your rads example so it is doing that.

 

I initially thought that it was working with only the Rads RMT plugin installed, but then realized the change I did to trigger the restart was to change a threshold, which of course did cause a morph recalculation.
A test (still with only Rads RMT plugin installed) by changing a setting that doesn't change the thresholds,
with Sliderset 0 (and others) using Rads trigger, after the RMR Restart (due to RMR MCM setting change):

[LenARM] Rad Morphing Redux has been restarted
[LenARM] API.RegisterTrigger: Rads
[LenARM] AddTriggerName: Rads
[LenARM]   updating MCM for SliderSet 0
... the other rads slider sets
[LenARM] API.UpdateTrigger: Rads = 0.427000
[LenARM] SetTriggerValue: Rads = 0.427000 --> 0.427000
[LenARM] SliderSet.SetTriggerValue: Rads = 0.427000
[LenARM]   SliderSet0: CurrentTriggerValue=0.000000  NewTriggerValue=0.000000 -> 0.427000
... the other rads slider sets
[LenARM] ApplyImmediateMorphs
[LenARM] SliderSet.SliderSet_CalculateMorphUpdates: 0
[LenARM]   no base morphs
[LenARM]   new morph is same as current morph
[LenARM]   don't change current morph, don't apply
[LenARM]   TargetMorph:    6.000000
[LenARM]   BaseMorph:      0.000000 -> 0.000000
[LenARM]   CurrentMorph:   0.325882 -> 0.325882
[LenARM]   FullMorph:      0.000000 -> 0.000000
... followed by the other slider sets with same deal

Applying some more rads and it jumps back to its (increased) morph as expected

[RMR_Rads] UpdateValue
[RMR_Rads]   0.427000  -->  0.447000
[LenARM] API.UpdateTrigger: Rads = 0.447000
[LenARM] SetTriggerValue: Rads = 0.447000 --> 0.447000
[LenARM] SliderSet.SetTriggerValue: Rads = 0.447000
[LenARM]   SliderSet0: CurrentTriggerValue=0.427000  NewTriggerValue=0.427000 -> 0.447000
... the other rads slider sets
[LenARM] ApplyImmediateMorphs
[LenARM] SliderSet.SliderSet_CalculateMorphUpdates: 0
[LenARM]   no base morphs
[LenARM]   new morph is different than current morph
[LenARM]   change current morph, apply
[LenARM] SliderSet.SliderSet_CalculateFullMorphs: 0
[LenARM]   sliders:        Boobs Yuge
[LenARM]   TargetMorph:    6.000000
[LenARM]   BaseMorph:      0.000000 -> 0.000000
[LenARM]   CurrentMorph:   0.325882 -> 0.349412
[LenARM]   FullMorph:      0.000000 -> 0.349412
... followed by the other slider sets with same deal


You'll see see UpdateTrigger is already being called after the rmr restart but:
SliderSet_SetTriggerValue (what it resolves to) wont set HasNewTriggerValue because the CurrentTriggerValue (and/or the current HasNewTriggerValue?) still has the current value, it's not aware that it should be resetting.

 

 

9 hours ago, Haberdasher said:

Though took me a second to realize I had to restart RMR, turn it off and on again, for it to add the new triggers to the dropdown.

7 hours ago, LenAnderson said:

That should not be necessary. The moment you call RMR.RegisterTrigger the new name shows up in the MCM. Maybe the trigger mod is not calling it at the correct time?

 

Basically when RMR is running it only calls OnStartup (which the RMT plugins are subscribed to do their RegisterTrigger) if:
Manually toggling RMR off and on.
Changing a RMR MCM setting (after exiting MCM).


After RMR is restarted then the triggers will be available in the slider set trigger drop down.

 

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. It's basically the same problem as the new rmr install first run.

I don't think it's really a problem, just a quirk to be aware of?

 

 

9 hours ago, Haberdasher said:

I'm also wondering about multiple sliders using the same morph, adding multiple selectable keywords for the morphs is probably too much of a pain, but I wonder if providing it from the trigger plugin

7 hours ago, LenAnderson said:

I guess I could provide a couple of keywords to choose from. Not one for each of the 50 sets though... Too much clicking in CreationKit... :D

That's why I was thinking of having the keyword tied to (and supplied by) the trigger plugin to simplify things. Though the somewhat freeform aspect of triggers ids just being strings, moreso since your rads plugin even lets the user define what the trigger id is, may make that approach dicey.

But like I say, it's probably better if I just hack out a test myself to see what the actual behavior is for multiple applications of same morph, and think whether it's worthwhile to even use/has an interesting use case.

 

9 hours ago, Haberdasher said:

Also you may want to flag LenA_RadMorphing.esp and LenARM_Trigger_Rads.esp as esl

7 hours ago, LenAnderson said:

I actually just read up on ESLs last week. My understanding is that you must use the ESP in CreationKit (ESL cannot be the active file), and the ESL can really only be used for publishing. So, yes, I plan to release them as ESLs, but creating the ESL will be a release-only step since it is not suited for development.

I don't think I've come across that issue (in my admittedly limited experience), I don't remember the apparently in depth articles/videos I looked at mentioning it, though I may have missed it somewhere.
Can you link me to somewhere that issue is mentioned?

 

I had already converted and flagged the sattrib rmt plugin in fo4edit, and CK didn't complain (though all that's in the esp is the single quest).

In my tests I've basically just been initially sketching out mods in CK, then using FO4Edit since it's a lot faster/less confusing for me than juggling a million slow to open windows. Though I have opened some of my more complex esl mods to do changes and haven't come across any issue.

I am aware that trying to have a non esl use an esl as a master is an issue, but don't have any of my mods being used as masters at the moment.

My reasoning to make the change early was to avoid the save file issue that comes from the formid changes when converting to esl, or at least avoiding having to uninstal and clean when jumping from non esl version to esl.
But then I guess they'd already have to do that anyway as the current version is non esl.
And if CK is an issue that's not really a point/valid route anyway.

 

 

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.


Your updates look good.

Edited by Haberdasher
Link to comment
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 by LenAnderson
Link to comment
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.

Link to comment

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

 

rmr.png.65780fe79a1f37c8928f8cb7d02371e8.png

 

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?

Link to comment
5 minutes ago, tzenrick said:

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

 

rmr.png.65780fe79a1f37c8928f8cb7d02371e8.png

 

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.

Link to comment
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...).

Link to comment

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 by Haberdasher
Link to comment
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.

Link to comment

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.

 

Link to comment
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 :D

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.

Link to comment
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.

 

 

Link to comment

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.

 

Link to comment
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.

Link to comment

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.

Link to comment
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.

Link to comment
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.

Link to comment
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).

Link to comment

@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.
 

 

Link to comment
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.

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