prideslayer

Beta or release version of NG?

Reinstall NVSE and NX latest versions.

That form ID is for the conversation callback hook quest. It hasn't changed in months.

absolutely right, I think though, that I've found the problem.  I'm using NMM and I installed NX through it.  I'm going to reinstall NX and let you know what happens

You haven't. The spunk install instructions answer this question.

is there a version of NVSE newer than the one posted on the NVSE site?

Haha nice That's also the pascal way, and works in most SQL flavors.

There is. I suspect you're using spunk. If so, you need to read the install instructions in the spunk thread.

Your NX and/or NVSE is out of date. I forget which, probably NX.

Yes.. it's the NVSE cosave bloating. I thought we asked you about that on the previous page and you said it wasn't big. Means bodymorph is still leaking nvse junk somewhere, I'll fix it.

Looks fine to me at a glance. You may want to add in a gethealth/sethealth so that they don't get 'new' armor whenever you swap one.

Check you windows event log for application errors. Could be that it doesn't have permission to access some critical file or something.

I'd like you to double check the sizes of the three save files when the game is getting slow. Save it then and then report back the sizes of:

- The save file

- The .nvse cosave file

- The NX .csv cosave file (this will be in data/plugins/extender/saves)

Thanks.

I'd like you to double check the sizes of the three save files when the game is getting slow. Save it then and then report back the sizes of:

- The save file

- The .nvse cosave file

- The NX .csv cosave file (this will be in data/plugins/extender/saves)

Thanks.

1) Will check.

2) Yep.

I'm not the one that put 'plugin' in the name of my plugin!

No argument here, but what kind of coward gives up without trying?!

That sounds like a problem in the bodymorph plugin itself then, not in amras adjustment thing.. though without the size increasing I'm not sure what else could cause such a delay.. spells running on refs that aren't in the current cell maybe?

A.J. when the plugin is active it starts to delay loadtime between maps and wait time. The longer it is running the bigger the delay becomes. I am at about 9 hours in the game and the delay time is roughly 32 seconds between map loads. I am using version 15.

Have you tried it without that plugin and just with bodymorph? Same deal?

Maybe it's time for a geckscript obfuscation contest along the lines of the C & perl ones?

The answer is still the same too.

You did something wrong. Putting the loose files in the DATA directory "just works" as long as archive invalidation is on.

It sounds like the textures you tried to include aren't correct for the body or something.

Try some other textures first just to see how it goes. I don't use the included one myself, I extracted the reelfeel textures from that mod and made my own fomod to install them, and they work fine. The included texture is really pretty ugly, but it was the only "free to use" T3 compatible texture I could find.

The loose files do override whatever is in the BSA. The only reason they wouldn't is if they're installed with the wrong names or in the wrong place or something like that. If you're seeing underwear it's more likely you've installed some other body stuff than your texture and the two are conflicting somehow.

Edit: Or you don't have archive invalidation enabled in the mod manager, or you DO but you somehow corrupted it and need to reset it.

There's a ton of shit in the game engine that's this way. Stuff that is loaded when the game first starts, or on the first game load (or new game) that is cached and not refreshed or reset when another game is loaded later. Most of it isn't too important but it's one reason that, if you have some weird problem, just saving the game right then, quitting, and loading it may fix it.

A while back jaam said he was getting so irritated with it that he might want to put code in NVSE to basically disable loading a game if you'd already loaded one and hadn't quit first. I think that would cause the kids to riot and burn the whole place down, personally.

I don't know what he's got in mind for the NX idea. The NVSE function most likely is to put in special code for reinitializing stuff that isn't properly reset on a game load where you don't quit the game and start it again first.

For example the morphs that bodymorph applies to an NPC will "stick" between saves. If you morph an NPC, then load an older save, that NPC is still morphed visually though bodymorph doesn't think he is because the NX vars saying it did so have all been reset.

I should point out that with regular arrays erasing during a loop can work out pretty well automatically, but better safe than sorry. For maps & stringmaps, the ar_keys method looks pretty handy.

I haven't had a problem doing it this way as long as I count backwards.. e.g. from ar_size downto 0. That way if I delete 6, it doesn't matter if 7...10 get reindexed. When you count upward, that's when you can get screwed up.

That's normal behavior for arrays and why doc says to not do that in the tutorial. If you have an array like [0,1,2,3,4] and you're in a for or foreach loop on 2 and delete it, the next one is going to be 4 and 3 will be skipped. You can get around this with normal arrays (not maps or stringmaps) by counting downward instead of upward.

I'm going to edit that post now because I didn't think of normal arrays like that, which won't work correctly even using ar_keys -- that works only with maps and stringmaps which are mainly what I use.

If you erase an element from an array from within a foreach loop when that element is the one under iteration, that will most likely break the loop. With regular arrays, it doesn't always, but it does if you for instance pass the array as parameter to a UDF from within the loop. It'll always break with maps and stringmaps. The thing to do here is do your erasing when the loop is done, by for instance adding elements to erase to a new array during the loop and erase them from the original afterwards, or add the elements to keep to a new array and let the old one be a copy of that one afterwards.

There is an alternative approach that can be faster and perhaps not as confusing to people trying to iterate through an array (maps and stringmaps only!) and remove things during the iteration. If you use ar_keys you can iterate through that instead and safely delete from the array you want to.

This is unsafe:

foreach item <- arMyArray  if <somecondition>    ar_erase arMyArray item["key"]  endifloop

But this is nearly identical (two extra lines, one changed line) and is safe

let keys := ar_Keys arMyArrayforeach item <- keys  if <somecondition>    ar_erase arMyArray item["value"]  endiflooplet keys := ar_Null

NOTE: you can only do this with maps and stringmaps, not with normal arrays. It will break just like the unsafe way when used on a normal array.

Wait, MY MCM? I wouldn't be writing an MCM for this -- that's up to whoever is using these insane vars.

I can see it already.. NX_SetEVFl_Persist "has ever installed orgy" 1...

That will work also.