sosae Schlongs of Skyrim AE-NG

[Spongebob Hentai Mod]

17 hours ago, patron_st said:

Yesterday, with the help of AI, I found the cause. I opened the save with ReSaver and found that in all saves, under Schlongs of Skyrim.esp, the contents of the SOSAE_MCM entry in Script Instances were still the old MCM contents. Your uninstall button, as well as the updated versions, did not change this entry; instead, this entry kept overwriting the new MCM. After I deleted this entry from the latest save and refreshed the MCM, it worked normally.

 

On 10/13/2026 at 9:51 AM, Spongebob Hentai Mod said:

I think the MCM is not updating properly, I suggest instead of Installing over a new save, is better to Uninstall the mod, save the game, after going some cells, save the game again and install the mod again

I will check it, but if I found a solution it will probably need a fresh save

[Spongebob Hentai Mod]

13 hours ago, modball said:

It's odd but apart from when I first migrated from the old SOS to SOS AE and the installed addons populated, if I run the MCM cleanup before updating, SOS_AddonData.json gets cleared of all addons (both gender_groups are empty) and they never repopulate.

 

However I restored a backup of SOS_AddonData.json, relaunched the game and the addons are functional.

 

Any way you could add a function to the MCM to force an addon rescan? 

 

Alternately, how necessary is it to clear data when updating? It seems to work fine, for me at least, without doing that.

 

I said fine but a very minor issue is that the No Futa addon does not populate in MCM even though it was detected on first launch and is present in the json, it does not appear in the MCM. However, the No Schlong function seems to work a lot better than legacy SOS did - maybe something to do with what was hinted at earlier in the thread about females frequently getting schlong assignments despite setting very low probabilities. Still testing out the new version with the changes to SOS_SchlongEligibleActorMods.txt

 

Attached addons esp files and addondata.json 

 

*edit: looks like addons are not being distributed to males (even Skyrim vanilla) with 3.2.0

 

SOS Addons.zip 12.48 kB · 1 download SOS_AddonData.json 29.18 kB · 0 downloads

I think I can migrate all the MCM to SKSE Menu Framework if this bug is happening, I will check how easily will be the update, for the males I will check what is happening on the code, but the next update will take more time if I see the MCM redundant, but SKSE Menu Framework will be a dependency

[Spongebob Hentai Mod]

11 hours ago, patron_st said:

Several of us in the comments — myself included — hit this after updating to3.2.0: NPCs no longer get an addon automatically when they undress.I ues AI to went through your source code and I think I found the cause. Would you take alook and tell me whether it's right? Full analysis below.

Hi, thanks for maintaining this. I've been chasing a long-standing problem and
I believe I've found the cause in the current source (main, 3.2.0). I read through src/ and this looks like a regression rather than a config issue.

== Symptom ==

Automatic addon assignment never works for male NPCs. A male NPC undresses completely and still shows the vanilla underwear body - no addon is equipped.
100% reproducible, across saves and across NPCs. Meanwhile, assigning an addon manually from the MCM works perfectly for the very same NPC. So the equip path, the armour resolution and the slot-52 logic are all fine.

== Cause ==

1) src/Actors.cpp -> ModifyNPCWithSOS()

    //Add KW to NPC based on TXT
    static bool ModifyNPCWithSOS(RE::TESNPC* a_npc, RE::BGSKeyword* a_kwNone,
                                 const std::unordered_set<RE::BSFixedString>& a_whitelist) {
        if (!a_npc || !a_kwNone) return false;

        if (!Util::IsFemale(a_npc)) {
            if (!a_npc->HasKeyword(a_kwNone)) {
                a_npc->AddKeyword(a_kwNone);   // <- added to *every* male NPC
                return true;                   //    whitelist ignored
            }
            return false;
        }

        auto* file = a_npc->GetFile(0);
        if (!file) return false;

        RE::BSFixedString modName(file->GetFilename());
        bool isInList = a_whitelist.contains(modName);   // only the female branch uses it

        if (g_isWhitelistMode != isInList) { ... }
    }

The function comment says "Add KW to NPC based on TXT", and the signature takes
a_whitelist - but the male branch never consults it. Every male TESNPC gets
SOS_NoneDefault.

This also means SOS_SchlongEligibleActorMods.txt and
"SOS_SchlongEligibleActorMods is a Whitelist" have no effect at all on male
NPCs, which is very confusing when trying to debug this.

2) Nothing ever removes the keyword

As far as I can tell there is no RemoveKeyword / RemoveKeywordString call
anywhere in the repo. The flag is only ever set. So once a male NPC has been
marked it stays marked for the whole session - and it is re-applied on every
launch, since the change is made in memory at kDataLoaded.

3) src/SchlongLogic.cpp -> DetermineWinningAddon() treats it as a permanent veto

    if (npcBase->HasKeywordString(NPCKW)) {        // NPCKW == "SOS_NoneDefault"
        Storage::SetNPCAddonData(baseID, "", 1);
        return nullptr;                            // bails out before candidates/roll
    }

Together: male NPC -> flagged at kDataLoaded -> DetermineWinningAddon() returns
nullptr forever -> no automatic addon, regardless of probabilities or Enabled
flags.

== Supporting evidence ==

SOS_AE.log on a normal launch ends with:

    [info] SOS: Processed 5858 NPCs.

That number is the count from ProcessNPCs() - i.e. the number of NPCs that were
actually given the keyword. It should be small (only the ones the text-list
logic genuinely matches). 5858 means essentially the whole NPC table is being
flagged. That is the fingerprint of the bug.

Also: because masculine ceiling is set to totalWeight, the
"if (roll > totalWeight)" branch is dead code for males, so the addon chance
percentage has no effect for them at all.

== Regression ==

In commit f210981 (before 2026-09-30) ModifyNPCWithSOS() had no male branch at
all - males went through the same whitelist logic as females. Note the 3.1.0
binary (2026-10-02) already postdates that commit, so downgrading does not
avoid it.

== Suggested fix ==

Either remove the unconditional male branch so males go through the same
g_isWhitelistMode != isInList logic, or - if the intent really is "males default
to no addon" - then the keyword must be removed again whenever an addon is
actually assigned (in OnActorActivated() / OnWearChange() in
Schlongification.cpp), and DetermineWinningAddon() should not treat it as a
permanent veto.

== Secondary request: observability ==

Log level is pinned to info in SetupSimpleLog(), while every diagnostic message
in DetermineWinningAddon() is debug (and the "Total Probability" line is
commented out). So when auto-assignment fails there is no way to tell why.
Please consider raising the level to debug, or logging at info when the
SOS_NoneDefault keyword vetoes an NPC, when candidates.empty(), and the roll
result.

== Environment ==

- Skyrim SE 1.6.1170, SOS AE NG 3.2.0
- 4 addons (3 male, 1 female), all races enabled, chance set to 100% while testing
- Reproduced with a fresh co-save, cleared overwrite folder, and a manually
  cleaned SOSAE_MCM script instance
- Confirmed: manual MCM assignment works for the same NPC; "Clear NPC data and
  load saved one" has no effect; "Remove Slot52 and Underwear" has no effect

Happy to test a build if that helps.

Thanks I didn't read that, I think I will need to update the mod with this, and the SKSE Menu framework, for now I suggest use the previous version of SOS AE-NG, Schlongs of Skyrim AE 3.1.0.7z

[Spongebob Hentai Mod]

OK I will make a mayor update to the mod, I make some revisions and i see that the script is really hard to read at the moment, and thanks to the feedback after a year of the mod online, I will make things better for the next major update

probably I Will make a new page for the mod, but I think is necessary because the mod will be fresh, so wait until the next update

[ptmc2112]

I would have suggested MCM Helper, as it builds the menu using an ini file, and can store settings, as well as prevent hotkeys being assigned if already assigned by any other mod also using MCM Helper. It sill uses the papyrus script to handle actually using the settings and what happens when hotkeys are used, but it requires extending it's own script (which already extends the same script used for MCM menus)

 

The thing is, I don't know if it can be used to build pages "on demand" that this mod does for each schlong, as I haven't really looked into the documentation. I also don't know if you can exclude specific settings either.

 

It might even be possible to use both SKSE menu framework and MCM helper, with the MCM helper being used to prevent other mods using the same hotkeys, and simply having a page that instructs how to use the SKSE menu, where the actual settings are and possibly assigning hotkeys.

Edited 4 hours ago by ptmc2112