lee3310

First of all, use "SKK Object Counter" to confirm the problem. Next step, is to find the culprit and stop the bleeding (read this topic for more infos).

I mentioned that i only saw the bug in another location (neon Flat) and i found this video: Watch it and you will notice the flashing dots. It's Definitely a game engine bug (something to do with emittance in interior cells) or we both have broken cards. Just one or two secs after opening the video, look at the ground to the left, you will see a flashing dot. More visible ones will appear if you keep watching (focus on the ground). If anyone has this CC content can confirm the bug. I think this is the culprit.

It's really easy to inject formList inside another formlist using robco patcher: you do it like this: filterByFormLists=MyMod1.esp|FormListID:formsToAdd=MyMod2.esp|FormListID I tested this and i was able to retrieve an injected formList inside a parent one.

I start noticing some weird flashing white dots (pixel) in an interior location i was working on (after changing some windows emittance/light FX). I tired generating previs but nothing changed, then i tried changing some settings and i found the culprit: "God rays". Setting it to ultra causes the flashing dots but no FPS impact or anything. I only saw this bug once in another interior location added by a CClub mod (neon flat). Here's a skyrim video that illustrate the bug, though mine is not that pronounced (only when i move the camera in specific area of the cell) and i don't use ENB. Couldn't find more info about the phenomenon so if you know what causes it (faulty GC, driver issue, engine bug...) I'd appreciate it.

The forum was offline for so long that i forgot to mention this: MatSwap doesn't work on headpart models, i got confirmation from someone who worked with headparts @blaze69 (it's game limitation).

Interesting, All those nifs are generated by FaceGen in order to animate the face ! i have no idea how it works but it looks archaic.

Thanks. You can actually assigne the material in editor and you can even see the texture/color change in the render window when you do it but when you load the game, the default material set in the nif is the one that gets displayed. I will try the material you sent me (basehumanfemaleskinhead) to see if it changes anything cause i suspected a nif/bgsm problem but i can't see how unless there is a special flag that has to be set/unset for the matswap to work.I need to use matswap instead of Texture sets cause i'm trying to mimic the blending mod used by the game when you apply a face tint using looksMenu UI ("BlendOp" : "HardLight", SofLight...) and i can only achieve that by tweaking the material file (hardly cause i'm not very familiar with the settings). This is just plain vanilla stuff, I sent it instead of a screenshot. ) This bgsm is assigned to the vanilla head in nif by default. Various parts of the face are also meshes with their own materials, also written in nif. Its as if the entire face consists of separate overlay meshes. I checked, all materials work. It is not textures from nif that are loaded, but specifically bgsm materials. If you remove bgsm and leave only textures, terrible seams come out. I don't know how all these parts work either. I looked, many parts have no textures at all, only gradient textures. The head itself has a D dxt5 texture for some reason. This is a controlled alpha channel format.https://disk.yandex.ru/d/jEWqPaxu0oRVqQ You are talking about the whole head not just "BaseFemaleHead.nif" ? then yeah, eyes, hair, mouth, scras... are separate meshes and even if they have a material file set in the .nif, Bethesda only using texture sets in order to change the color for them (like hair). I ended up making a .nif for each head part like with older Bethesda game (before matswap became a thing) and now i'm curious about this F4SE function: HeadPart[] Function GetHeadParts(bool bOverlays = false) NativeWhat is this bOverlys flag or overlay list referring to

Thanks. You can actually assigne the material in editor and you can even see the texture/color change in the render window when you do it but when you load the game, the default material set in the nif is the one that gets displayed. I will try the material you sent me (basehumanfemaleskinhead) to see if it changes anything cause i suspected a nif/bgsm problem but i can't see how unless there is a special flag that has to be set/unset for the matswap to work. I need to use matswap instead of Texture sets cause i'm trying to mimic the blending mod used by the game when you apply a face tint using looksMenu UI ("BlendOp" : "HardLight", SofLight...) and i can only achieve that by tweaking the material file (hardly cause i'm not very familiar with the settings).

I'm referring to Material Swap in CK (MSWP record in xedit) and headPart like hair, beard, eyes... . I have no idea how headPart works internally, all i know is that i can handle them in papyrus unlike LooksMenu face tints. I was planning on using one nif and just replace the material in editor but it doesn't work for head part, and TXST (texture sets), ignore all the custom effects set in the material like glow, emittance, transparency... I will have to duplicate the nif and manually set the material in nifscope but i just wanted to make sure that matsawps do indeed not work with headparts.

Does anyone managed to get the matswap applied to a nif used in headpart to show up ingame ? Only texture sets are working for me. I used matswaps for different objects in the past with not a single problem excepte with head parts. No matter what i try, the default material (texture) set in the .nif is the only one that gets rendered ingame. I can see the new texture when i edit the nif in editor (render window) and apply a new material. It's like the matswap is completely ignored by the game when it comes to head part. Is this a know limitation/bug ?

Well, i continued the conversation on GOE mod page, what you are experiencing is the bug i was talking about. Even if DPPI shows nothing and the ref is flagged as temporary, the game can decide to keep it as Persistant. PP as LarannKiar explained means "Persistent Promoter" and in this case, the promoter is the ref it self. To avoid this behavior, you should never make a save with a temp ref still stored in a script var...(persistent). I found out that if i use "abDeleteWhenAble = true" with placeAtme to flag the ref as temp or GOE "SetTemporaryReference" function, clear all the vars/aliases/linkedRef... pointing at it then kill/disable the ref, it will get cleared as soon as the cell unloads. However, if you save the game with the ref still attached to something, there is a good chance that it will stick in game, even if you free it afterward (on game load for example).. Hopefully you can get rid of PP (if DPPI returns empty) using "RemoveAllPersistentPromoters()". ForcePersistent() will also work but all script instances will stay attached and SetEditorPersistence(false, true) can cause CTD if there is something holding the ref ingame. Never forget to clear script vars pointing at refs in active magic effect and reference alias scripts (any script that attaches to ref and receives same events), cause if the var is not cleared prior to quest shutdown / effect finish, there is a risk that you can't access the var ever again, even after recompiling the script and resurrect the ref... .

For the records, i was able to properly dispose of almost all the persistent dead refs using those functions: If GardenOfEden2.SetTemporaryReference(AllDeadRefs.GetAt(Count), true) if GardenOfEden2.RemoveAllPersistentPromoters(AllDeadRefs.GetAt(Count)) GardenOfEden2.SetEditorPersistence(AllDeadRefs.GetAt(Count), False) Else GardenOfEden2.SetEditorPersistence(AllDeadRefs.GetAt(Count), False, true) EndIf EndIf I said almost cause i was down to 61 not 0 (from 10231), the remnants were held by a MGEF script that has an Actor variable pointing at the ref (could be fixed by editing the script itself and clearing the var). So problem solved, all attached instances were removed along the refs and the game can finally save and load correctly as far as i can tell. PS More details can be found here.

No Papyrus errors and complete script instance removal are unfortunately not really in harmony.. :smile: MarkForForcedDeletion() flags the references "to be removed" on the highest possible level but it doesn't queue up the reference's VM data. It lets the native code to decides what to delete.. this was the least harmful ( and wouldn't like to call it safe ) method I found to make a reference disappear. I understand the issue though.. it's not good for save games. Supposedly, the engine "should" free up the RefID slot and remove the instance data... eventually. However, the vanilla "cleanup process" rather keeps references persistent for eternity than remove something that "might be" needed later. Actually, MarkForForcedDeletion() was meant for those certain object references and inventory items ( the ones that have a persistent reference linked to them, these are typically quest objects but not necessarily ) that the engine fails to remove. For an all-in-one solution, these functions below may prove much more useful. I'll update the script extender tomorrow with them: Bool Function RemovePersistentPromoter(ObjectReference akReference, int aiFormID) native global Function DeleteNoCleanup(ObjectReference akReference) native global Bool Function SetTemporaryReference(ObjectReference akReference, bool abTemporary) native global Bool Function SetEditorPersistence(ObjectReference akReference, bool abSetPersistent) native global Bool Function ForcePersistent(ObjectReference akReference, bool abForcePersist) native global Function DeleteForm(Form akForm) native global Function UndeleteForm(Form akForm) native global With these, it will be possible to hook up the ref to those cleanup events that remove script instances ( and everything the game actually supports ) as well. SetTemporaryReference() sets/unsets the "temporary ref flag" ( Console: [T] ) which determines whether to ignore or include the reference in certain Form cleanup. And, if persistence = 0 and temporary = 1 ( Console would show: 'RefName' (ff0123456) [T] ), OnUnload(), the game traces back the necessary VM data and not just purges the reference itself. I tested them with IsCreated() refs that had both [PP] and [EP] persistence and they work. Wonderful, Fo4 persistence manager is a new territory and we are lucky that you chose to explore it. I will wait for the new functions.

Thanks for those valuable informations, i have a better understanding of how the game handles persistence (delicate subject). I tried to clear the refs by removing the attached scripts (only works on newly spawned actors) even if there is no vars or properties that point at self in them, and i disabled the linking statements. After that the refs became non-persistent (deleted from memory after kill/disable/delete() like it should be) but if i let other mods interact with them, they end up persistent again. DPPI comes clean (absolutely nothing), and GetPersistentPromoters() returns "self" so i gave up on trying to find the cause since i don't own the other mod(s) manipulating the refs and can't work with self promoters (i don't know where to start). [10/17/2023 - 01:36:16AM] Customers in list = 4 [10/17/2023 - 01:36:23AM] Form not peristent [10/17/2023 - 01:36:23AM] Customers in list = 3 [10/17/2023 - 01:36:24AM] Forms locking this actor = ["0xff3efda4"] [10/17/2023 - 01:36:25AM] Customers in list = 2 [10/17/2023 - 01:36:26AM] Form not peristent [10/17/2023 - 01:36:27AM] Customers in list = 1 [10/17/2023 - 01:36:28AM] Forms locking this actor = ["0xff3efda6"] [10/17/2023 - 01:36:29AM] Customers in list = 0 [10/17/2023 - 01:36:30AM] Forms locking this actor = ["0xff3efd6a"] [10/15/2023 - 11:55:14PM] Persistence information for (FF1A8579): [10/15/2023 - 11:55:14PM] Object Variables: [10/15/2023 - 11:55:14PM] Stack Variables: [10/15/2023 - 11:55:14PM] Remote Events: [10/15/2023 - 11:55:14PM] Animation Events: [10/15/2023 - 11:55:14PM] Combat Events: [10/15/2023 - 11:55:14PM] Custom Events: [10/15/2023 - 11:55:14PM] Distance Events: [10/15/2023 - 11:55:14PM] Inventory Filters: [10/15/2023 - 11:55:14PM] LOS Events: [10/15/2023 - 11:55:14PM] Menu Events: [10/15/2023 - 11:55:14PM] Sleep Events: [10/15/2023 - 11:55:14PM] Teleport Events: [10/15/2023 - 11:55:14PM] Timers: [10/15/2023 - 11:55:14PM] Tracked stat events: [10/15/2023 - 11:55:14PM] Wait Events: [10/15/2023 - 11:55:14PM] VM is thawing... I quickly made a cleaning quest similar to "SKK Object Counter", that only targets dead, unloaded refs with appropriate VMScript attached and delete them using MarkForForcedDeletion(): As you can see it worked, no extra error in papyrus log before or after loading the new save but in fallrim however, all attached script instances are still there: ( i don't know why the numbers are different :happy: ) They are attached to "NONEXISTENT CREATED FORMS" now. Is it safe to clean them ? does it matter ? and more importantly, if the refs were normally removed by the game without use of "MarkForForcedDeletion" will the attached instances get removed from the save file or not ?. Edit: If i clean the the unattached script instances in fallrim (only the scripts attached to deleted Refs), it will generate a bunch of errors on first load (nothing after saving and loading again).

Please do promote tools you made, especially when it's highly relevant to the matter at hand, i was about to request a forceDelete() function before reading you comment (MarkForForcedDeletion() saved the day). So i did a lot of tests using Garden Of Eden functions, first it was a linkedRef holding the refs into the game even if i was linking them to "none" before delete. Then, GetPersistentPromoters() was just returning the actor's RefID "Forms locking this actor = ["0xff3efda4"]", you said that ForcePersistent console cmd will cause such results, since i'm not flagging the refs as persistent with placeAtme(), do you know of any other way/function that can make a ref "to became its own promoter" ? is there even a papyrus counterpart to ForcePersistent ? And you where right about fallrim too, i managed to fix one of the broken saves using it but it's not humanly possible to manually delete "10333" ChangeForms (AHCR) and script instances, and the risk of deleting a wrong instance is relatively high if you filter by attached scripts. That's why i'm going to use "MarkForForcedDeletion()" to clean up my last loadable save, fix the mod, and see how it goes.