Overlay framework UIDs that are not unique after a while

[MSM_Alice]

I am posting this in case anyone else was banging their head on a wall about it.

It took me a bit of investigation to realize that overlay UIDs (Unique IDs ) from the Overlay framework are not really unique after some time.

But I finally know
A. Why were certain overlays that I was applying in my mod starting to disappear mysteriously, when other mods were removing their own overlays by UID...
B. Why were overlays from other mods disappearing mysteriously when I was removing MY own overlays by UID... 

It is because UIDs were no longer unique a short time after starting a new playthrough.
The darn UIDs stop being unique, and any operation done by UID is effed up.
Everything needs to be done by overlay name or something similar, and not by UID.

 

This is because of a big issue in f4ee.dll in Looksmenu.
There is a patch for OG ( not sure if there is one for NG looksmenu)
 f4ee-patched at Fallout 4 Nexus - Mods and community

 

But finally, I  can sleep and not wonder why overlays behave inexplicably... whenever any operations are done on them by their UIDs.

 

Any mod that adds and removes overlays dynamically with any significant frequency, and does so by UID,  will  run into this
Probably
-TatsAfterRape,
-Scripted Cumoverlays.

-and what I do for the skin cleaning napkins, basic  nail polish, and tattoos in my mod

Would be affected by this bug.

I need to reimplement my functionality, if possible, by not using UIDs at all, only overlay names.
At least until a reliable patch appears for NG, too. 

 

 

 

Edited July 25, 2025 by MSM_Alice

[nopse0]

1 hour ago, MSM_Alice said:

I am posting this in case anyone else was banging their head on a wall about it.

It took me a bit of investigation to realize that overlay UIDS (Unique ID's ) from the Overlay framework are not really unique after some time.

But I finally know
A. Why were certain overlays that I was applying in my mod starting to disappear mysteriously, when other mods were removing their own overlays by UID...
B. Why were overlays from other mods disappearing mysteriously when I was removing MY own overlays by UID... 

It is because UIDs were no longer unique a short time after starting a new playthrough.
The darn UIDs stop being unique, and any operation done by UID is effed up.
Everything needs to be done by overlay name or something similar, and not by UID.

 

This is because of a big issue in f4ee.dll in Looksmenu.
There is a patch for OG ( not sure if there is one for NG looksmenu)
 f4ee-patched at Fallout 4 Nexus - Mods and community

 

But finally, I  can sleep and not wonder why overlays behave inexplicably... whenever any operations are done on them by their UIDs.

 

Any mod that adds and removes overlays dynamically with any significant frequency, and does so by UID,  will  run into this
Probably
-TatsAfterRape,
-Scripted Cumoverlays.

-and what I do for the skin cleaning napkins, basic  nail polish, and tattoos in my mod

Would be affected by this bug.

I need to reimplement my functionality, if possible, by not using UIDs at all, only overlay names.
At least until a reliable patch appears for NG, too. 

 

 

 

 

I am the author of the patch. Really annoying bug in LooksMenu. I first thought this was a bug in NAF-Bridge, so I added traces to the NAF-Bridge scripts which printed out the overlay UIDs when overlays were added and removed, and then I noticed, that after a while, when cum overlays had faded away (I made their duration very short for testing), suddenly all newly added overlays got the same UID, replacing each other, and this had nothing to do with NAF-Bridge (AAF is affected, too; in fact I am using AAF now instead of NAF-Bridge, because, well, its more compatible to AAF :), and it has a lot of additional features, like stripping Power Armors when having sex, etc.). Then I looked into the LooksMenus sources , how the next free overlay UID is calculated, and saw it!

 

No source code for the NG LooksMenu version, Expired didn't publish them, so currently no chance for a NG fix.   

Edited July 24, 2025 by nopse0

[MSM_Alice]

8 hours ago, nopse0 said:

 

I am the author of the patch. Really annoying bug in LooksMenu. I first thought this was a bug in NAF-Bridge, so I added traces to the NAF-Bridge scripts which printed out the overlay UIDs when overlays were added and removed, and then I noticed, that after a while, when cum overlays had faded away (I made their duration very short for testing), suddenly all newly added overlays got the same UID, replacing each other, and this had nothing to do with NAF-Bridge (AAF is affected, too; in fact I am using AAF now instead of NAF-Bridge, because, well, its more compatible to AAF :), and it has a lot of additional features, like stripping Power Armors when having sex, etc.). Then I looked into the LooksMenus sources , how the next free overlay UID is calculated, and saw it!

 

No source code for the NG LooksMenu version, Expired didn't publish them, so currently no chance for a NG fix.   

 

Thank you so much for publishing that patch. 
Until I saw it on nexus and read the description (actually ChatGPT sent me there when asking it what I was doing wrong about UIDs that they end up being non unique),  I was assuming I was misunderstanding/misusing UIDs in the Overlays framework  somehow.

And it was frustrating as at start of every playthrough there was a really short window where everything seemed to work okay, and then it got weird.

Edited July 25, 2025 by MSM_Alice