prideslayer

How large is the NX CSV file associated with one of the slow saves? If it's over 10-20KB or so, please attach it. If not, what about the size of the NVSE cosave?

It can be done by a plugin, or via the console manually. http://www.loverslab.com/topic/8655-sexoutng-beta-21093b2-release-thread/?p=1066691 I don't think I've updated the wiki with that information yet.

No.

Attach (don't copy and paste) the CSV file please. I'm curious about it's size and what it contains. The only thing NX does during saves that could be slow is writing out all the data.

2.10.93Beta2 in OP Changes: - fnSexoutGetReady UDF. Returns 1 if sexout is ready, 0 if not. - SexoutNG.bSexoutReady is now ALWAYS 0. This will stop plugins that use it from working until they are updated. - About half the ZAZ animations are in the registry. - New weighted erect male meshes, courtesy of AJ. - New reset KF which will reset the penis bone, courtesy of AJ. The nude mesh is the standard sexout erect breezes, with the penis weighted by AJ to work with Amras animations. For testing, it replaces both the standard nude male mesh AND the sexout male bodysuit, so it should be used regardless of your Sexout MCM bodysuit setting. If you're using Roberts, uninstall it, or expect to see screwed up male textures. This is a fomod-ready 7z, just install it as a package with fomm/nmm/whatever.

Yes, as soon as I'm satisfied that what Odessa and I are using is going to work. If I document it right now and have to change it later, it's a lot of work for everyone, so I'm making sure it doesn't need changed first.

What are you going to do when my init takes 10 seconds? About half the zaz animations added now, what mind numbingly tedious work. ESM has blown up another 40k.

Ever seen Verilog?

Just the thought that those fucktards are probably running hackified versions of sexout for exactly that purpose is very nearly enough to push me over the edge and lock it down. They're just lucky my time is so short right now.

That wouldn't work out of the box, bodymorph code would still have to change to know which ones are doubled up like that, so that calling scaleup/scaledown would actually work every time -- not just every other time -- by skipping 'duplicates'. I think eventually I'm going to have to bite the bullet and just rewrite the fnvedit script and the script in bodymorph that does the lookups, but I just have too much on my plate right now. You're welcome to take a crack at it though, if you have time and drunken code doesn't put you off.

Heh if only it were that easy.. I already do that. The "issue" is that the raw scales aren't really known by bodymorph, since it can't control them. It plays animations (morphs) on the actor, and the animation files themselves have the actual bone scales in them. So we may have 5 scales that are allowed, from -2..+2 for example. This range is 'hard coded' and used for every bone. AJ makes all those morph files. That range is all that bodymorph actually tracks, so for the smallest pelvis size, it's just storing something like "pelvis = -2". 0 is the neutral/default size, a scale of 1.0. I have an fnvedit script that auto-generates all the IDLE records in the geck, as well as a list of bones. It's just one loop inside another making records. What this means is that right now, there must be the same number of morphs (5, in this example) for every bone. If there's just one bone that we want to allow a larger size on, say changing it from a max scale of 1.1 to 1.2, there are 3 ways to go about it. The easy-but-ugly way, the harder-for-AJ way, and the harder-for-pride way. Easy but ugly: We keep the # of sizes for each bone fixed at 5, and just increase the distance between them for that one bone. This requires only that AJ create the new morphs for that bone, and I run the script and put the new files in the download. It's "ugly" because it means you lose granularity. The step from 0->1 will be bigger for this bone than it is for any others, in order to keep +2 as the maximum offset. Tougher for AJ: We increase the number of steps for all bones. We can go from -2..+2 to -4..+4 for example. All the bones we don't want to touch will get even finer control over their size (the scale size between steps decreases for them) while the one we're trying to change keeps it's old step size, but gets double the number of steps. The result is that one bone can now get twice as large or small as it was before. This requires AJ to recreate every single morph file, a task I wouldn't ask for in 100 years. It's easier for me because my end is automated and so, I don't have to do anything except get the files, adjust the constants in my fnvedit script, and run it again. Tougher for me: I change the fnvedit script so that it can now accept a different number of steps for every bone, rather than requiring every bone have the same number of steps as every other. This would allow pelvis to change from -4..+4 but leave everyone else at -2..+2. I would have to make similar changes in the script inside the ESP. This is much easier for AJ since now only the morphs for the one bone we want to change need to be created. It's something I haven't actually contemplated doing in the fnvedit and geck scripts yet though, and knowing me, would have a fair number of errors in the first 3-4 versions.

VectorPlexus got tired of working on it, asked for a ban, and asked someone to host it here. http://forums.nexusmods.com/index.php?/topic/564026-account-closure-requests/page-301#entry20803134

Yeah that's the only way I'm aware of. In the console calling them by name, calling them by refid with and without quotes.. none of that works. I think the problem is that 'call' only takes a ref. Maybe we need is a con_call in NVSE that can take a hex string (or normal string -- or both! If it's valid hex, assume it's hex, otherwise look for name) to make it work.

Hah I haven't played in.. forever. Only saves I have are all level 1 PC in goodsprings, again. Does the bSexoutReady thing affect you? A few posts up, in yellow.

60 downloads... well? Tryout/WG issues fixed? Other issues introduced? Gonna just keep quiet until it goes release and then bitch about problems like last time? *ducks*

Oh if there's a rename then NX is going to honor that as well. It's hooked into the normal spots; create, delete, rename.

Look in the download area for the SexoutNG beta. Download that and try it out.

When you save a game the normal way, all three potential save sources (the game, nvse, and NX) all just create a new file and fill it in. When you quicksave (or autosave) it's just one file, so all those sources must first delete their save files. I don't know what the game engine or nvse themselves do when 'overwriting'. They may actually overwrite the file, or they might delete it and make a new one. NX does the latter -- when any save is created (normal, quick, or auto) it first checks to see if it's cosave file exists already. If it does, it deletes it before making a new cosave.

On a save (quick or not) NX just deletes any existing CSV and creates a new one. It never tries to 'update' them. If there are a LOT of NX vars set, then that will make it a bit slower. Also a lot of mods are now using the NVSE arrays and such which involves the nvse cosave file (.nvse) which can also contribute to saving being slower than before. If you're using one of those plugins that does a quicksave and then a quickload, that can definitely cause a slowdown the first time you use it in a session. Loading is a lot slower than saving, because it has to compare the current load order to the one in the save file, and fix up any IDs for mods where the load order has changed.

I have yet to find any way to invoke UDFs via console, and I've asked a few times and nobody else has been able to suggest a way to do it either. When I need to test that sort of stuff, I usually make a simple quest script to call the UDF and have it just watching some NX variable. I set the NX variable to 1 in the console, the quest script runs the UDF and sets the NX var back to 0. You can use a quest var if you're more comfortable with that than NX. I'm all for more sizes, and granularity between them. Another 'tough' spot we have is that right now all the idle record generation and stuff is automated on my end via an fnvedit script. Adding a bigger size to one bones means making it available for all of them -- and some just do not look right at all at max sizes that others work fine with. I haven't thought much about how to deal with that.

yes, 707 is the right #, and the only thing I need when there's an alignment issue, as long as the version is up to date and there aren't other pose/aim plugins installed.

The second way. The first way will clear any that start with 'SOP' including 'Sophist:' or 'Soprano:'.

This. Erect nipples may come someday via bodymorph.

Oh sure, they'll always find a way. I don't disagree. But I won't make it easy on them for that way to involve my mods.

Yes, the events seem like they'll work wonderfully for this. I will see about implementing at least a few, starting with the ready notification and global notifications in the current beta cycle.