Uncle64 Posted January 9, 2016 Posted January 9, 2016 I think you have some error in your DLL file. This is what I did get. Because I did need to remove those small plugins. Check the spelling.
h38fh2mf Posted January 9, 2016 Posted January 9, 2016 If you use regular SKSE dll it says correctly ? I only changed SKSE logging, this message box isn't even a part of SKSE and has nothing to do with it.
Uncle64 Posted January 9, 2016 Posted January 9, 2016 I did remove your dll and it was correct after, whit your plugin it was wrong. I was stunned my self about this message to. It should not do that, could not find anything other then the DLL that did it. Perhaps some call for mods that SKSE do, I dont know. Did notice in my logs that SKSE did call for mods, perhaps it is that? But from what I did test it looks good.
h38fh2mf Posted January 9, 2016 Posted January 9, 2016 Well yea you only needed the dll to check sizes of sections. After that put regular SKSE dll back.
Uncle64 Posted January 9, 2016 Posted January 9, 2016 Yes that is clear. That is what I did. If I find the issue I will let you know.
Kakabishan Posted January 10, 2016 Author Posted January 10, 2016 That sounds way too much. My SKSE co-save is 19 kB after playing for a long time. I made a modification to SKSE so it logs the size of different sections (attached to post). Use it to load into that bad save and then exit game, go to "Documents/My Games/Skyrim/SKSE/skse.log". Find the first line "loading co-save", it was around line 86 for me but it depends how many plugins you have. Under it, now it shows: Loading mod list: ... (all your plugins here) Size of MODS section was 1201. Loading menu open/close event registrations... Size: 0 Loading key input event registrations... Size: 0 Loading control input event registrations... Size: 0 Loading mod callback event registrations... Size: 0 Loading crosshair ref event registrations... Size: 20 Loading camera event registrations... Size: 4 Loading actor action event registrations... Size: 0 Unhandled chunk type in Core_LoadCallback: 4E494E55 (UNIN) Size: 4 Loading SKSEPersistentObjectStorage data... Size: 8 Loading SKSEDelayFunctorManager data... Size: 0 Plugin 'SKSE' loaded its data, length: 7138 Plugin 'SchlongsOfSkyrim' loaded its data, length: 4498 Plugin 'SexLabUtil' loaded its data, length: 4118 Plugin 'papyrusutil plugin' loaded its data, length: 2855 The last 4 lines starting with "Plugin" are about co-save. For you it may be less or more lines depending on your plugins. The sizes are in bytes, if I add them up it becomes 18609 which is approximately the size of my co-save (actual size in windows is 18 677 bytes). When you are done, put back the regular SKSE dll. You guys who have very large co-saves post this info here, it could be useful to solve a bug some mod is having. Thanks h38, I'll give this a go now and post my log Edit: Alright, here it is, at a glance could you see what is the problematic skse plugin? Looks like Nioverride has the most value and probably the culprit What couldve caused this to skyrocket to such a crazy number.. Jeez o.o Size of MODS section was 6161. Loading menu open/close event registrations... Size: 0 Loading key input event registrations... Size: 0 Loading control input event registrations... Size: 0 Loading mod callback event registrations... Size: 0 Loading crosshair ref event registrations... Size: 36 Loading camera event registrations... Size: 28 Loading actor action event registrations... Size: 0 Unhandled chunk type in Core_LoadCallback: 4E494E55 (UNIN) Size: 12 Loading SKSEPersistentObjectStorage data... Size: 8 Loading SKSEDelayFunctorManager data... Size: 0 Plugin 'SKSE' loaded its data, length: 58829 Plugin 'JContainers' loaded its data, length: 97017 Plugin 'KNNPlugin' loaded its data, length: 363536 Plugin 'SchlongsOfSkyrim' loaded its data, length: 12213 Plugin 'SexLabUtil' loaded its data, length: 14193 Plugin 'papyrusutil plugin' loaded its data, length: 190832 Plugin 'chargen' loaded its data, length: 1937 Plugin 'nioverride' loaded its data, length: 1791614 dispatch message (3) to plugin listeners sending message type 3 to plugin 5 sending message type 3 to plugin 8 sending message type 3 to plugin 19 sending message type 3 to plugin 26 Adding it up gives 2530171, which is about 2530 kb, and my co save is now 2471 kb, so yeah its about right... skse log.7z
h38fh2mf Posted January 10, 2016 Posted January 10, 2016 Yeah it's nioverride, it's a bad plugin, i'll say it again.
ratrace Posted January 10, 2016 Posted January 10, 2016 I just reverted to XPMSE 2.82 and after 1 hour of playing my co-save size is as follows: old: 590 kb (and rising with each new save) new: 412 kb The gameplay is much more fluent. Until now I had a micro/macro stutter each time I encountered new NPCs. My setup is extremely clean. I use MO and Wrye Bash in tandem, I clean my mods where necessary, make my own compatibility patches where necessary yadayadayada. I'm not an expert, but definitely not new to modding. Been through a hard school in old Oblivion days, that's why I am so very meticulous when installing mods. It's all the more frustrating to trip over probs you cannot solve. EDIT: Roughly another hour later it seems to settle down at around 419 kb. Gameplay is still completely fluent.
Kakabishan Posted January 10, 2016 Author Posted January 10, 2016 Man, but I cant live without nioverride though D:.. And the latest XPMSE, I'm not sure if I should revert it all the way to 2.8.. Isnt 3.7 supposed to be more stable than when it was during 3.0?So is there any way to clean up the nioverride somehow to make my skse co save a little less bloat ridden?
ratrace Posted January 10, 2016 Posted January 10, 2016 Man, but I cant live without nioverride though D:.. And the latest XPMSE, I'm not sure if I should revert it all the way to 2.8.. Isnt 3.7 supposed to be more stable than when it was during 3.0? So is there any way to clean up the nioverride somehow to make my skse co save a little less bloat ridden? The early 3.0 versions had an even more serious skse co-save prob, if I recall correctly. XPMSE v2.8 also uses the NiOverride features. Though there are new NiOverride features that are not made use of in 2.8. However, I can't tell which ones. I'm sceptical as to whether there can be improvements made on the SKSE bloat. XPMSE is so full of features, and I guess (far from knowing though) that all of that contributes to the problem. It speaks volumes about Bethesdas game engine. A fast SSD, 8 GB RAM, an AMD six core CPU, a GTX 970. All in all slightly upper middle class I'd say. Enough for nowadays games anyway. Furthermore I run a meticulously well-kept Skyrim with optimized textures that are below my rigs abilities. My Windows is reduced to what it really needs so that there are no unnecessary services running eating up performance. And still: NOPE. Poor Groovtama. He's stuck with a super-popular mod that he has to tweak for this game. dEDIT: Skelly XPMSE v2.8 didn't so the trick in the long run. SKSE co save back to 520 kb. Stuttering increasing again. So screw it, I guess.
Kakabishan Posted January 11, 2016 Author Posted January 11, 2016 Bugger, sorry to hear ratrace.. I understand completely, this dated shit engine really has to just get tossed, even moreso of a joke that they used the same shit on fallout 4, so theres going to be more scripts baked in saves and other modding terrors as the geck is released. :/.Does XPMSE contribute a lot to nioverride getting bloated? Or is it racemenu or something else. I just need to pinpoint what is making it so high so I can at least be cautious in my next save
Nasseliten Posted January 11, 2016 Posted January 11, 2016 You can delete xpmse.esp without issues (you will loose some sliders tough) I had same issue with bloated skse co save and massive save times. Deleting it fixed everything for me.
Guest Posted February 8, 2016 Posted February 8, 2016 I managed to manually remove the entire NiOverride section off the co-save file. I of course had to figure the format of the whole thing to know how it worked. With a hex editor I lowered the plugin count by one, looked for a "NIOV" signature, then, counting the length of all its data I just shaved off everything. After restarting the game and loading my save, I had to go into racemenu to reload my character preset, since a lot of sliders were zeroed. Re-saving was ridiculously faster than usual, after all, I got rid of 800KB of random morphs. I now have the cloak script and styles for all disabled in XPMSE, maybe that's exactly what caused this madness in the first place. I'll probably write a tool to automate this eventually. Turning it into a full-fledged editor is not something I'd ever be capable of, though.
Groovtama Posted February 8, 2016 Posted February 8, 2016 600 kb on ugrid 5 with XPMSE is not bloating, it need to save for at least 15 up to 25 cells, edits to the skeleton of the actor, where it spiked are cities. 3000 kb+ on ugrid 5 with old XPMSE3 was bloating because cleanup didn't work corectly. 2000 kb on ugird 9 with XPMSE is not bloading because it need need to save like 4 times the amount of data from ugrid 5. 7000 kb+ on urgrid 9 with old XPMSE was bloating... XPMSE 2.82 has lower co-save usage because it does only half of the XPMSE3 stuff and newer XPMSE3 versions coming with a randomizer. NiO\XPMSE3 have to manage a shitload of data compared to 2.82. XPMSE 2.82 works by setting everything and hoping NiO detects that it should clean up the dynamic generated mess, all data that is not cleaned up will be stucked in there till you remove NiO and save one time or delete your Co-Save. XPMSE tells explicitely to clean up stuff. XPMSE3 uses the auto removal feature of NiO if you remove the XPMSE.esp, anything that XPMSE generates on the fly is removed, that is why co-save sizes drop, when you uninstall XPMSE3 and install XPMSE2.82, that has nothing to do with XPMSE2.82 using\saving less data. XPMSE3 generates less Co-Save data for the features 2.82 has, XPMSE3 has just a lot of expensive features, yeah you can semi-randomize any actors weapon styles, but yeah it generates extra data that needs to be saved.
Kakabishan Posted February 8, 2016 Author Posted February 8, 2016 I managed to manually remove the entire NiOverride section off the co-save file. I of course had to figure the format of the whole thing to know how it worked. With a hex editor I lowered the plugin count by one, looked for a "NIOV" signature, then, counting the length of all its data I just shaved off everything. After restarting the game and loading my save, I had to go into racemenu to reload my character preset, since a lot of sliders were zeroed. Re-saving was ridiculously faster than usual, after all, I got rid of 800KB of random morphs. I now have the cloak script and styles for all disabled in XPMSE, maybe that's exactly what caused this madness in the first place. I'll probably write a tool to automate this eventually. Turning it into a full-fledged editor is not something I'd ever be capable of, though. Awesome! That sounds like great news . Just gotta find out why it's being bloated so much. I managed to manually remove the entire NiOverride section off the co-save file. I of course had to figure the format of the whole thing to know how it worked. With a hex editor I lowered the plugin count by one, looked for a "NIOV" signature, then, counting the length of all its data I just shaved off everything. After restarting the game and loading my save, I had to go into racemenu to reload my character preset, since a lot of sliders were zeroed. Re-saving was ridiculously faster than usual, after all, I got rid of 800KB of random morphs. I now have the cloak script and styles for all disabled in XPMSE, maybe that's exactly what caused this madness in the first place. I'll probably write a tool to automate this eventually. Turning it into a full-fledged editor is not something I'd ever be capable of, though. Awesome! That sounds like great news . Just gotta find out why it's being bloated so much. 600 kb on ugrid 5 with XPMSE is not bloating, it need to save for at least 15 up to 25 cells, edits to the skeleton of the actor, where it spiked are cities. 3000 kb+ on ugrid 5 with old XPMSE3 was bloating because cleanup didn't work corectly. 2000 kb on ugird 9 with XPMSE is not bloading because it need need to save like 4 times the amount of data from ugrid 5. 7000 kb+ on urgrid 9 with old XPMSE was bloating... XPMSE 2.82 has lower co-save usage because it does only half of the XPMSE3 stuff and newer XPMSE3 versions coming with a randomizer. NiO\XPMSE3 have to manage a shitload of data compared to 2.82. XPMSE 2.82 works by setting everything and hoping NiO detects that it should clean up the dynamic generated mess, all data that is not cleaned up will be stucked in there till you remove NiO and save one time or delete your Co-Save. XPMSE tells explicitely to clean up stuff. XPMSE3 uses the auto removal feature of NiO if you remove the XPMSE.esp, anything that XPMSE generates on the fly is removed, that is why co-save sizes drop, when you uninstall XPMSE3 and install XPMSE2.82, that has nothing to do with XPMSE2.82 using\saving less data. XPMSE3 generates less Co-Save data for the features 2.82 has, XPMSE3 has just a lot of expensive features, yeah you can semi-randomize any actors weapon styles, but yeah it generates extra data that needs to be saved. I have around 2000 kb because of nioverride. Is this solely because of xpmse and the weapon styles etc? 600 kb on ugrid 5 with XPMSE is not bloating, it need to save for at least 15 up to 25 cells, edits to the skeleton of the actor, where it spiked are cities. 3000 kb+ on ugrid 5 with old XPMSE3 was bloating because cleanup didn't work corectly. 2000 kb on ugird 9 with XPMSE is not bloading because it need need to save like 4 times the amount of data from ugrid 5. 7000 kb+ on urgrid 9 with old XPMSE was bloating... XPMSE 2.82 has lower co-save usage because it does only half of the XPMSE3 stuff and newer XPMSE3 versions coming with a randomizer. NiO\XPMSE3 have to manage a shitload of data compared to 2.82. XPMSE 2.82 works by setting everything and hoping NiO detects that it should clean up the dynamic generated mess, all data that is not cleaned up will be stucked in there till you remove NiO and save one time or delete your Co-Save. XPMSE tells explicitely to clean up stuff. XPMSE3 uses the auto removal feature of NiO if you remove the XPMSE.esp, anything that XPMSE generates on the fly is removed, that is why co-save sizes drop, when you uninstall XPMSE3 and install XPMSE2.82, that has nothing to do with XPMSE2.82 using\saving less data. XPMSE3 generates less Co-Save data for the features 2.82 has, XPMSE3 has just a lot of expensive features, yeah you can semi-randomize any actors weapon styles, but yeah it generates extra data that needs to be saved. I have around 2000 kb because of nioverride. Is this solely because of xpmse and the weapon styles etc?
Groovtama Posted February 8, 2016 Posted February 8, 2016 600 kb on ugrid 5 with XPMSE is not bloating, it need to save for at least 15 up to 25 cells, edits to the skeleton of the actor, where it spiked are cities. 3000 kb+ on ugrid 5 with old XPMSE3 was bloating because cleanup didn't work corectly. 2000 kb on ugird 9 with XPMSE is not bloading because it need need to save like 4 times the amount of data from ugrid 5. 7000 kb+ on urgrid 9 with old XPMSE was bloating... XPMSE 2.82 has lower co-save usage because it does only half of the XPMSE3 stuff and newer XPMSE3 versions coming with a randomizer. NiO\XPMSE3 have to manage a shitload of data compared to 2.82. XPMSE 2.82 works by setting everything and hoping NiO detects that it should clean up the dynamic generated mess, all data that is not cleaned up will be stucked in there till you remove NiO and save one time or delete your Co-Save. XPMSE tells explicitely to clean up stuff. XPMSE3 uses the auto removal feature of NiO if you remove the XPMSE.esp, anything that XPMSE generates on the fly is removed, that is why co-save sizes drop, when you uninstall XPMSE3 and install XPMSE2.82, that has nothing to do with XPMSE2.82 using\saving less data. XPMSE3 generates less Co-Save data for the features 2.82 has, XPMSE3 has just a lot of expensive features, yeah you can semi-randomize any actors weapon styles, but yeah it generates extra data that needs to be saved. I have around 2000 kb because of nioverride. Is this solely because of xpmse and the weapon styles etc? If you put enough mods\edits using that use NiOverride in your game, yeah then you have a lot of data.
Kakabishan Posted February 9, 2016 Author Posted February 9, 2016 600 kb on ugrid 5 with XPMSE is not bloating, it need to save for at least 15 up to 25 cells, edits to the skeleton of the actor, where it spiked are cities. 3000 kb+ on ugrid 5 with old XPMSE3 was bloating because cleanup didn't work corectly. 2000 kb on ugird 9 with XPMSE is not bloading because it need need to save like 4 times the amount of data from ugrid 5. 7000 kb+ on urgrid 9 with old XPMSE was bloating... XPMSE 2.82 has lower co-save usage because it does only half of the XPMSE3 stuff and newer XPMSE3 versions coming with a randomizer. NiO\XPMSE3 have to manage a shitload of data compared to 2.82. XPMSE 2.82 works by setting everything and hoping NiO detects that it should clean up the dynamic generated mess, all data that is not cleaned up will be stucked in there till you remove NiO and save one time or delete your Co-Save. XPMSE tells explicitely to clean up stuff. XPMSE3 uses the auto removal feature of NiO if you remove the XPMSE.esp, anything that XPMSE generates on the fly is removed, that is why co-save sizes drop, when you uninstall XPMSE3 and install XPMSE2.82, that has nothing to do with XPMSE2.82 using\saving less data. XPMSE3 generates less Co-Save data for the features 2.82 has, XPMSE3 has just a lot of expensive features, yeah you can semi-randomize any actors weapon styles, but yeah it generates extra data that needs to be saved. I have around 2000 kb because of nioverride. Is this solely because of xpmse and the weapon styles etc? If you put enough mods\edits using that use NiOverride in your game, yeah then you have a lot of data. I see.. This is going to be tough narrowing down what mod uses nioverride excessively
txzeenath Posted February 9, 2016 Posted February 9, 2016 If you put enough mods\edits using that use NiOverride in your game, yeah then you have a lot of data. I've noticed most mods that use NiOverride to make frequent adjustments just apply a scale of 1 to "remove" scaling. Rather than actually clearing the override. So if you have a mod that applies overrides to NPCs in the cell, I'd imagine there's going to be a lot of override data piling up.
Groovtama Posted February 9, 2016 Posted February 9, 2016 If you put enough mods\edits using that use NiOverride in your game, yeah then you have a lot of data. I've noticed most mods that use NiOverride to make frequent adjustments just apply a scale of 1 to "remove" scaling. Rather than actually clearing the override. So if you have a mod that applies overrides to NPCs in the cell, I'd imagine there's going to be a lot of override data piling up. XPMSELib SetScale calls the RemoveTransform function when you set a scale of 1.0 for a transform. What dumb things other people do in their code is non of my nor others buisness.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.