prideslayer

Cool cool. Non-Edit-damn-you-auto-append: Have any of you that have tried the last 2-3 releases (the 7z with the new meshes) had any male mesh issues vs. the release version? Alignment issues, penis pointing in wierd directions / not resetting, anything like that?

Thanks. I'll wait for another response or two, then push beta5 with your fix as well since this one won't catch (un)intentional duplicate adds to the registry.

2.10.93Beta4 in OP Changes: - Round 1/2 of array assignment fixup. - Top level NG anim idle group and male masturbation now using NX vars rather than tokens. This is a fomod-ready 7z, just install it as a package with fomm/nmm/whatever. Beta4 should resolve the nvse bloat issue.. really this time. This one does not have Odessa's fix in it yet, but beta5 will. I need some additional testing on this before I implement that, just so I can make sure that the issue is in fact resolved, since the next round will 'mask' this fix.

Ok. I'll have a new beta up in a few minutes, see if that fixes your issue.

I think this is probably due to a problem in the current sexout beta that is being addressed. You didn't mention, are you using the NG beta or the release version? The CSV is tiny, nothing to worry about there.

Ok, that issue pointed to the root cause which is elsewhere.. that append should always 'work' and be unique unless the main array wasn't cleared properly, or the calling mod added the same animation twice. I'm going to add it in as a backstop but in testing the real 'fix' was two things.. ok technically 3. 1. Fix fnSexoutGetReady. This was defined as a GameMode rather than Function. Oops! 2. Call fnSexoutGetReady around the main body of SexoutNGTASQS. 3. Set SexoutNGTASQ.arSorted to ar_Null in SexoutNGMain before the call to fnSexoutUpgrade. Together this ensures that AddAnim can be called and the anim added to the temp holding area (arTBD), but that arTBD isn't processed until arSorted has been reset. If you're game I'd like you to try this out before I add your check in as well, to make sure it's correcting the root issue before I add the ar_Find as a backstop. I tested with 4 start/load/savenew/quit cycles and no growth; the cosave actually shrunk on the 3rd save, which itself is a bit of a mystery. I have to investigate to make sure all the anims made it into the registry but I think it's ok.

That's the correct location. You can also set bodysuits to none and then it will use whatever standard nude male you have installed.

Storage by flag is intentional, but something is obviously not being cleared correctly. This may be related to the 'fix' for those console errors you were getting in testing. Oh dear well that's egg on face a bit I guess. I'll need to test further, after coffee, but thanks!

goddamn you jerks. Fine. I guess I still have some crap to fix in there somewhere. I'll try to get to it tomorrow. In the meantime.. er... well beta's gonna beta I guess. Thanks for the reports, really did look fixed on my end.

Odessa, make one more going from the 144K save. This one should have cosaves a little bigger than beta2 did, but they should not continue growing. 150Kish is in the right neighborhood. Jaam, thanks, will check that out.

Ok, new beta is up. It will still grow the file a little bit the first time as it has more animations in the registry, but it shouldn't keep growing it indefinitely. Unfortunately there is nothing short of a clean save that can shrink the cosave file if it's already large.

2.10.93Beta3 in OP Changes: - Additional array and string var cleanup in the fight against cosave bloat. This is a fomod-ready 7z, just install it as a package with fomm/nmm/whatever.

There will be a new beta in a minute or two with the issue fixed.

Well I have found one spot.. FYI it happens whenever you load a save with the beta, so if you're testing with something like load 1 -> save 2 -> load 2 -> save 3 -> load 3 -> save 4... it's going to grow. load 1 -> save 2 -> load 1 -> save 3... will not grow. Working on tracking it down fully and fixing. It's in the upgrade script which normally runs only once for a new version, but with betas, it runs every time a game is loaded even if it was already saved with the current beta, because stuff in the beta may change between releases.

I think the culprit might actually be the ESM itself. I have a theory I'm testing... probably a new beta soon.

Ok. I'm digging and may know which one is to blame already. This wasn't happening with the previous beta (beta1) or the release version?

Ok. If you have the time, it would help to know which other plugin being active causes the file to grow. With sexout alone it shouldn't be growing, is it? Knowing which mod is causing it to grow should provide a clue as to what interface method(s) is leaking.

Ok.. is this the release version or the beta? Looks like I've got something in there that's not cleaning up after itself properly.

Oh boy whatever it is is still running.. and running amok. I'm pretty confident it's an array/string thing, those are the only variable types in the NVSE cosave that it can't always properly clean up. Question is which plugin.. and then which script within that plugin.

Probably some 'trigger' in one of the mods caused some script to run that hadn't run before. Disabling and testing for shrinkage should at least narrow down which mod it is. Someone needs to find time to write a cosave viewer so we can just peek inside and see wtf is going on. It shouldn't be TOO difficult as the record format is the same as what's in the savefile, which itself is basically the same as an esp/esm if memory serves.

Yes that's the right one, see my (goddamn auto-amended) previous post.

I use greasemonkey, requestpolicy, and a custom usercontent.css for 'ad blocking' and nothing else. Greasemonkey is great if you know javascript. I wrote one for youtube that just repeatedly clicks the 'off' button for annotations..

Well the NX files look fine. Not having any cosaves for NVSE is very odd though.. are you sure? Check again, maybe they're marked hidden or something? They should be in the same directory as the actual savegames (.fos files). You have a lot of stuff in your NVSE plugins that may or may not be related. I don't use NVAC, anti-stutter, or any of that stuff myself. The "componentDLLs" directory is something I've never seen before. That NVSE save sounds VERY large. It looks like maybe sexout or one of the sexout plugins is not properly freeing arrays/strings. You should be able to figure out which one(s) it is by just disabling some mods, loading the game, and then saving it. Don't have to play for hours. I'd try that with some of the larger sexout plugins and if disabling one of them results in a drastically smaller NVSE file than the one that was loaded.

Yeah. 14kb is a "little" large. Go ahead and attach one of them that was made when a save was slow. Also how big is the corresponding nvse cosave (.nvse file next to the normal savegames) for that same save?

This isn't anything new. Most of the time they aren't "detecting" the adblocker or anything like that. They first put up a placeholder that says "please don't block ads", and during the page load, the ad-serving scripts replace it with the ad. If you're blocking the ad, that script never runs, and the original is never replaced.   Not all sites do this, but many do and it's been around a long time.