Rad Morphing Redux

[LenAnderson]

3 minutes ago, leesjig said:

 

Well I loaded back up the game and double checked the options with doctor.  Doctor just doesn't give any options to heal morphs.  Prolly my game then.  I'll start a new game and double check setup.

 

 

There is no explicit dialog option or message box to heal morphs in the current version of this mod.

Let the doctor heal rads. That will reset your morphs.

[Sgt. Marge]

I just wanted to post and tell you how much I love this mod, I've been using it for several months now.  I've even patched all my rad food to give 6 times the normal radiation in order to ramp up the game play loop of visiting doctors for treatments. 

 

I was very excited to check the thread the other day and saw that it's still being improved upon.  Great stuff, and thank you so much!

[vaultbait]

5 hours ago, leesjig said:

All is good,  Thanks LenA. On new start I made sure I had 'only doctors can reset morphs' checked in MCM early before any morphing started.  I exposed her to lots of rads, body morphed up.  I went to Doctor in D. City again, this time I made sure I had a little rads exposure on health bar, then Doctor reset all morph when I picked cure rads. 

 

On previous test, just guessing.  I didn't have any rads on health bar when talking to doctor, so thats why maybe the doc didn't reset morphs, or I actually didn't turn on 'only doctor can reset morph' way later after morphing had already begun.  So it could have been either of these causing the no healing morphs?  So yep, 1st You want a little rads on health bar, 2nd you want the animation of him thumping the needle, then screen fades to black.  That's what you want to see...I know, dang.  

 

Yes, it's a corner case with doctor morph resetting... it depends on being able to have rads healed by a doctor, so if you already cured your radiation damage (for example by taking Rad-Away) then the dialogue option for it just says something like "I'm not irradiated" instead and does nothing.

[tzenrick]

@LenAnderson In the 0.7.1.7 version, I edited the script and fought to recompile it, to make it so dismissed companions/followers don't revert morphs if they're dismissed while in a morphed state.

 

Can you just add it as an MCM toggle?(Please) Only because 'not everyone' may want it as the default.

 

From the 0.7.1.7 version I modified.

 

 

I've tried to do this with the current version, but compiling things in subdirectories is a huge pain-in-the-ass, and I haven't worked out all of the compiler arguments.

 

Maybe stop using a subdirectory? Just data\source\user\? Please?

 

 

If you don't, I'll just fight with the compiler until I get it right, but I'd rather see it as an "official" update.

[LenAnderson]

6 hours ago, tzenrick said:

@LenAnderson In the 0.7.1.7 version, I edited the script and fought to recompile it, to make it so dismissed companions/followers don't revert morphs if they're dismissed while in a morphed state.

 

Can you just add it as an MCM toggle?(Please) Only because 'not everyone' may want it as the default.

 

From the 0.7.1.7 version I modified.

 

 

I've tried to do this with the current version, but compiling things in subdirectories is a huge pain-in-the-ass, and I haven't worked out all of the compiler arguments.

 

Maybe stop using a subdirectory? Just data\source\user\? Please?

 

 

If you don't, I'll just fight with the compiler until I get it right, but I'd rather see it as an "official" update.

 

I'll keep that in mind and see if I can add that option in a satisfying way. However, enabling that option would most likely mean that there would be no way to restore a companion's original morphs ever, even when disabling RMR due to the limited array lengths.

 

I'll certainly keep my scripts in their namespace. Never had any issues with compiling in CK.

 

 

 

EDIT 1

 

All that CK does to compile is this:

"...\Fallout 4\Papyrus Compiler\PapyrusCompiler.exe" "%LOCALAPPDATA%\Temp\PapyrusTemp\EditorBuildTemp.ppj"

 

And the contents of the ppj

<?xml version='1.0'?>
<PapyrusProject xmlns="Papyrus:Project-Schema" Output="E:\Games\Steam\SteamApps\common\Fallout 4\Data\Scripts\" Flags="Institute_Papyrus_Flags.flg">
	<Imports>
		<Import>...\Fallout 4\Data\Scripts\Source\User\</Import>
		<Import>...\Fallout 4\Data\Scripts\Source\Base\</Import>
	</Imports>
	<Scripts>
		<Script>LenARM\LenARM_API.psc</Script>
		<Script>LenARM\LenARM_Main.psc</Script>
		<Script>LenARM\LenARM_Util.psc</Script>
		<Script>LenARM\LenARM_Debug.psc</Script>
		<Script>LenARM\LenARM_SliderSet.psc</Script>
	</Scripts>
</PapyrusProject>

 

 

 

 

 

EDIT 2

 

Thought some more about what it would mean to not restore companion morphs on dismiss. Not only would there by no way to ever restore their original body, the morphed body that they had when dismissed would be treated as the new "original" body to base any new morphs on...

 

- Companion joins, save their current morphs (m0 = the original companion body) as original
- Take rads, morph companion based on original (m0) morphs
- Dismiss companion, keep current morphs (m1 = modified by RMR), forget original morphs to make room for new companions
- Companion joins again, save their current morphs (m1) as original
- Take rads, morph companion based on "original" (m1) morphs

Edited May 11, 2022 by LenAnderson
(1) add compile info (2) more thoughts on not restoring companion morphs

[tzenrick]

All right. I know the script is there... Why does this compiler suck?

 

 

[tzenrick]

50 minutes ago, tzenrick said:

All right. I know the script is there... Why does this compiler suck?

 

 

 

edit: Because my directory structure was wrong. Scripts belonged in Source\DLC04\DLC04

[vaultbait]

17 minutes ago, tzenrick said:

edit: Because my directory structure was wrong. Scripts belonged in Source\DLC04\DLC04

 

I experienced the same thing when I first started experimenting with recompiling Papyrus scripts. The wiki doesn't go into nearly enough detail about these things because 1. it's assumed by the CK authors that the compiler will be called by the CK rather than invoked directly by users (ugh), but also they assume you'll use the CK to do the base script unpacking (it prompts automatically the first time you fire up the UI) and so they don't bother documenting where things will actually get put/expected.

[vaultbait]

10 hours ago, LenAnderson said:

Thought some more about what it would mean to not restore companion morphs on dismiss. Not only would there by no way to ever restore their original body, the morphed body that they had when dismissed would be treated as the new "original" body to base any new morphs on...

 

I've seen it said that some mods (and notably the BodyGen feature of LM itself) use specific tags on the morphs they apply in order to accomplish this. The up side is that a mod can supposedly recognize the morphs it applied later and so not confuse them with original body states or morphs applied by other mods, but the down side is that users can't really adjust these directly either because the slider manipulation interface in LooksMenu shows only untagged morphs.

[LenAnderson]

31 minutes ago, vaultbait said:

 

I've seen it said that some mods (and notably the BodyGen feature of LM itself) use specific tags on the morphs they apply in order to accomplish this. The up side is that a mod can supposedly recognize the morphs it applied later and so not confuse them with original body states or morphs applied by other mods, but the down side is that users can't really adjust these directly either because the slider manipulation interface in LooksMenu shows only untagged morphs.

 

I'm going to have to look into that. Not having to keep track of the original morphs would be quite nice.

[tzenrick]

4 hours ago, vaultbait said:

they assume you'll use the CK to do the base script unpacking (it prompts automatically the first time you fire up the UI) and so they don't bother documenting where things will actually get put/expected.

 

Which leads me to ask, how come they didn't make the CK smart enough to unpack the DLC scripts?

[vaultbait]

13 minutes ago, tzenrick said:

Which leads me to ask, how come they didn't make the CK smart enough to unpack the DLC scripts?

 

One of the many mysteries of the cosmos. They packed CC and survival script sources into Base.zip, but for some reason the various DLC sources are each in their own separate zipballs and, no, the CK doesn't auto-unpack them at all. I agree it's bizarre. The FAQ does attempt to point out the need to unpack Base.zip (and even gets the location wrong!), but makes no mention whatsoever of the DLC sources.

[LenAnderson]

Started using BodyGen with a keyword for morphing instead of saving the original morphs and that seems to work really well. That should open up the option to not restore companions on dismiss as I no longer have to keep track of their body.

 

I also looked into compiling outside of CK and into the other features of the VS Code extension for papyrus. Now I have build tasks that do all the papyrus compiling, FOMOD stuff, and even zipping a new release with the proper versioned filename directly in the editor. And one more thing I had never dared to even dream of: a proper papyrus debugger! Pretty awesome to be able to finally set breakpoints, step through code, see call stacks and local variables... Even if it's not perfect (e.g. FO4 crashes for me whenever I try to expand a struct or object variable in the variable viewer), this makes development so much easier.

[vaultbait]

4 hours ago, LenAnderson said:

I also looked into compiling outside of CK and into the other features of the VS Code extension for papyrus. Now I have build tasks that do all the papyrus compiling, FOMOD stuff, and even zipping a new release with the proper versioned filename directly in the editor. And one more thing I had never dared to even dream of: a proper papyrus debugger! Pretty awesome to be able to finally set breakpoints, step through code, see call stacks and local variables... Even if it's not perfect (e.g. FO4 crashes for me whenever I try to expand a struct or object variable in the variable viewer), this makes development so much easier.

 

Very cool! Almost like actual software development (but still with a generous helping of Bethesda-induced masochism). ?

[ebbluminous]

@vaultbait... You've expressed a desire for weight change in FO4, well check this out!

 

It is not in it yet, but the mod creator has it on their to do list.

 

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

[Dutchygamer]

7 hours ago, LenAnderson said:

Started using BodyGen with a keyword for morphing instead of saving the original morphs and that seems to work really well. That should open up the option to not restore companions on dismiss as I no longer have to keep track of their body.

 

I also looked into compiling outside of CK and into the other features of the VS Code extension for papyrus. Now I have build tasks that do all the papyrus compiling, FOMOD stuff, and even zipping a new release with the proper versioned filename directly in the editor. And one more thing I had never dared to even dream of: a proper papyrus debugger! Pretty awesome to be able to finally set breakpoints, step through code, see call stacks and local variables... Even if it's not perfect (e.g. FO4 crashes for me whenever I try to expand a struct or object variable in the variable viewer), this makes development so much easier.

Ooooh, that sounds nifty! Also, any chance of putting that RMR helper on the GitHub? Or is it too much intertwined with your v2 rework?

[LenAnderson]

4 hours ago, Dutchygamer said:

Ooooh, that sounds nifty! Also, any chance of putting that RMR helper on the GitHub? Or is it too much intertwined with your v2 rework?

 

Yeah, I'll set up a mirror for GitHub soon. The helper is of course targeting v2 which uses a couple of different ini keys and some enums have different values. It may be able to load a v1 ini file, but I'm not sure how well.

 

All the VS Code configs for building and debugging are already on the v2 branch of RMR (launch.json and tasks.json in the .vscode folder, and you need to remove the "Game" attribute in the PPJ).

[vaultbait]

9 hours ago, ebbluminous said:

@vaultbait... You've expressed a desire for weight change in FO4, well check this out!

 

It is not in it yet, but the mod creator has it on their to do list.

 

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

 

Thanks! Sounds reminiscent of "Workout Through the Fallout" (which seems to have been removed from Nexus, likely during the mass Nexodus), though that only ever supported the dreaded triangle as the author had minimal interest in LooksMenu integration.

[LenAnderson]

On 5/11/2022 at 1:24 AM, tzenrick said:

@LenAnderson  make it so dismissed companions/followers don't revert morphs if they're dismissed while in a morphed state.

 

Looks like this is going to happen!

 

I started working on morphing companions today. And now that I'm using a BodyGen keyword and no longer have to keep track of original morphs, the option to keep followers morphed on dismiss was fairly easy to implement.

 

Keeping the list of current companions up to date was a little troublesome. In v1 I just ran a function to find current companions each time rads would change, and then handle dismissed and added companions. I also had a listener on Actor.OnCompanionDismiss for all current companions, but that event never seems to fire.

Well, after some more digging through the official quests and scripts I found a quest called "Followers" with a script "FollowersScript". That script has a CustomEvent CompanionChange that fires whenever a companion is added or dismissed. A bit weird that it's a custom event since this is a Bethesda script, but whatever. This event seems to reliably fire whenever a companion is added or dismissed, so that's what I'm going to use going forward. Should also reduce the performance impact compared to constantly re-checking the current followers and comparing those with the saved list of companions. And the whole companions-no-longer-being-companions while in combat issue should also be avoided.

Not sure how well that will work with custom companions (should not be a problem I think, as long as they are implemented as regular companions), or with multi-companion mods (will probably not work). But we'll see.

[Dutchygamer]

19 hours ago, LenAnderson said:

 

Looks like this is going to happen!

 

I started working on morphing companions today. And now that I'm using a BodyGen keyword and no longer have to keep track of original morphs, the option to keep followers morphed on dismiss was fairly easy to implement.

 

Keeping the list of current companions up to date was a little troublesome. In v1 I just ran a function to find current companions each time rads would change, and then handle dismissed and added companions. I also had a listener on Actor.OnCompanionDismiss for all current companions, but that event never seems to fire.

Well, after some more digging through the official quests and scripts I found a quest called "Followers" with a script "FollowersScript". That script has a CustomEvent CompanionChange that fires whenever a companion is added or dismissed. A bit weird that it's a custom event since this is a Bethesda script, but whatever. This event seems to reliably fire whenever a companion is added or dismissed, so that's what I'm going to use going forward. Should also reduce the performance impact compared to constantly re-checking the current followers and comparing those with the saved list of companions. And the whole companions-no-longer-being-companions while in combat issue should also be avoided.

Not sure how well that will work with custom companions (should not be a problem I think, as long as they are implemented as regular companions), or with multi-companion mods (will probably not work). But we'll see.

Can confirm that I also had issues with Actor.OnCompanionDismiss not seemingly triggering. Unsure if we use it incorrectly or it is just plain broken.

 

Does this also solve the issue that eventually companion morphs will break because it has filled up the OriginalCompanionMorphs array? From the sounds of it that array won't be neccesary anymore with this solution.

[LenAnderson]

11 minutes ago, Dutchygamer said:

Can confirm that I also had issues with Actor.OnCompanionDismiss not seemingly triggering. Unsure if we use it incorrectly or it is just plain broken.

 

Does this also solve the issue that eventually companion morphs will break because it has filled up the OriginalCompanionMorphs array? From the sounds of it that array won't be neccesary anymore with this solution.

Yes, with keywords there's no need to keep track of original morphs because setting every slider to zero (with the keyword) already restores the original body. Also means that there's no conflict with other mods modifying sliders.

 

EDIT: RMR Helper is now being mirrored to GitHub.

https://github.com/LenAnderson/RMR-Helper

Edited May 14, 2022 by LenAnderson

[LenAnderson]

First version of a working rads trigger for v2 is now also mirrored to GitHub for anyone interested.

https://github.com/LenAnderson/RMR-Trigger-Rads

 

At the moment this is mainly for myself, for testing. Later on I will probably flesh this out further with more detailed comments and a readme and turn it into a how-to for modders.

[Haberdasher]

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.

 

[LenAnderson]

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

 

 

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
  
   
• SliderSets can be applied to only player, only companion, or player & companion
  
   
• SliderSets can be applied to female only, male only, both, independent of whether they apply to companions or players
  

 

 

[Haberdasher]

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

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 May 16, 2022 by Haberdasher