prideslayer

Same behavior with NVSE 4.6.2. Removing the "sv_destruct stWild" at the end of the UDF had no effect either. That's the only place it's referenced in the UDF at present. Dafuck is goin' on.

Having the weirdest issue right now changing the interface to a UDF, NVSE 4.5.7.

A UDF defined like this:

scn fnSexoutArCompare; Compares two arrays to see if they are equal.; argsarray_var arLHSarray_var arRHSstring_var stWild; ...Begin Function{arLHS arRHS}...End

And called like this:

if eval(0 == (call fnSexoutArCompare inActFilt, arResult[item["value"]]["actors"])); ...

Works fine.

Changing the definition to this:

Begin Function{arLHS arRHS stWild}

And the call to this:

if eval(0 == (call fnSexoutArCompare inActFilt, arResult[item["value"]]["actors"], "both"))

Results in NVSE reporting an error in the calling script.

Operator := failed to evaluate to a valid result

No other changes made at all, the UDF isn't using the 3rd param yet. I tried commenting out the call to the UDF so that no scripts were using it, saving, quitting, restarting geck, and then changing the UDF definition and adding the call back in. No help.

Going to try a newer NVSE now but if anyone has seen this before, I'd like to know.

It always prints all three actors, so C being null for 2p anims is normal. What is the full call you made?

It's possible some gender check is messed up somewhere.

 

Nothing special.  I did have ActorB set to don't undress originally.  But removed it with the same results.  Updated to 16 already a few days ago when you first posted it.

 

ref.NX_SetEVFl "Sexout:Start::CallVer" 1ref.NX_SetEVFo "Sexout:Start::ActorA" refA (FemaleNPC)ref.NX_SetEVFo "Sexout:Start::ActorB" refB (Player)ref.NX_SetEVFl "Sexout:Start::isOral" 1ref.CIOS SexoutBegin

 

EDIT: Also I'm not currently using Amras anims if that means anything.

Found thie problem with this, working on it.

Regarding the other three anims, I can confirm that 715 and 610 aren't correctly positioned and am working on that problem.

Ok, I have 715 fixed and am in the process of moving all the alignment adjustments over to the new system. However I found a new problem with 715 that may all or many of the animations I recently imported from AP. This one, and perhaps others, are using the penis bone for something. In the release version of sexout this isn't a problem because the default mesh isn't painted, so adjusting that bone does nothing.

In this beta however, the new mesh IS painted, and so that bone has an effect -- and with 715, it's completely wrong. The penis is being bent downward horribly to the point that the scrotum is being pushed out behind the actor.

Hmm. It's possible the "gender" check stuff is screwed up somewhere. There are many animations that should match that pattern. I'll check in a bit.

Regarding the other three anims, I can confirm that 715 and 610 aren't correctly positioned and am working on that problem. 201 is fine in my testing though. It should be a blowjob with the male laying on his back and the female kneeling over him.

You've got a plugin with a broken MCM menu that's breaking other MCM menus. Start disabling plugins and testing to figure out which one.

Everyone also make sure you've updated NX. This beta requires the latest version (16). I updated the OP but didn't put it in the announcement post.

It always prints all three actors, so C being null for 2p anims is normal. What is the full call you made?

It's possible some gender check is messed up somewhere.

Thanks for doing that Odessa, and for helping me design and test the plugin system!

I have installed this new beta as well. I am not sure whether "bugs" would include animations which are not working properly or not, but I noticed after installation that animations 201 and 715 when activated using sexout sexkey, result in the male PC just standing there (undressed) while the female animation plays. I assume from the above post that I should not expect to see any change in the MCM menu at this time.

I'll check them out, both of those should be working. 121 and 611 were disabled for now due to problems with the animations during testing, but the rest should be working.

 

Pride, are you aware at all of the vanishing actor after sex bug? I haven't tested the new Beta yet, but I am getting this problem quite often with the previous version. It happens quite often when I use Soliciting, but saying that - Soliciting is pretty much the only mod I use these days - so it's a 50/50 between Sexout and Soliciting. I ask because though, I do remember seeing this occasionally long before Soliciting came along, which makes me think it is Sexout issue. 

 

Basically, immediately after the sex act ends, the NPC vanishes. Sometimes it is after the anims reset, sometimes during the actual sex anim, right at the end. 

 

EDIT: I thought perhaps it was save-related, as whenever I used that save, it would happen. That being said, I closed the game down, reloaded the same (presumably problematic save) and it hasn't happened since. So at least that's a solution. Would be nice to know what causes it though...

I haven't heard of this before. I know sometimes the NPCs can sort of fall under the ground or something like that, but I think it's other non-sexout mods that cause this to happen when the NPCs are ragdolled. I've never seen it in my testing, which I do with a very limited number of mods active to avoid conflicts. The only disappearing bug that I know for sure exists in sexout itself is where you are playing in first person and relying on sexout to switch to 3rd. If the switch to 3rd can't back up far enough (like there is a wall behind the player) then the player will be invisible during the act, but become visible again after.

Test disabling some of your other mods to see if they're responsible.

I really doubt it has anything to do with soliciting. Sexout maybe, but that's somewhat doubtful also.

2.10.93Beta5 in OP

Changes:

- SexoutNG Animation Registry implemented (thanks Odessa for collaboration!)

This is a fomod-ready 7z, just install it as a package with fomm/nmm/whatever.

Information for animators or those wishing to create custom animation plugins is in the Sexout wiki.

This one needs heavy testing. I've tested a little, so has Odessa, but there could be bugs still lurking. There are two more items on the todo list for this, but neither one will hold up a release if I run out of time soon.

- Implementation of the MCM menu for control over the random picker.

- Interface for modders to specify filters in an fnSexoutRun/RunFull call.

 

I'm pretty damn bored with my current save game, so I shall drive this new beta to hell and back and see if I come across any issues.  Its been awhile since I've come across any bugs with SexoutNG, the last bug I came across was months back when the PC just no longer could have sex anymore because of stuck tokens.  I haven't run into that issue in awhile *knock on non penis wood*.

This bug was introduced 5 or so versions ago and fixed 2-3 versions ago. It shouldn't ever occur again, as there is now a sort of unlock scanner that runs to forcibly remove invalid locks. It can take up to 5 seconds to happen but the "forever locked" should be crushed for good.

That's good information. Weird, but good.

2.10.93Beta5 in OP

Changes:

- SexoutNG Animation Registry implemented (thanks Odessa for collaboration!)

This is a fomod-ready 7z, just install it as a package with fomm/nmm/whatever.

Information for animators or those wishing to create custom animation plugins is in the Sexout wiki.

This one needs heavy testing. I've tested a little, so has Odessa, but there could be bugs still lurking. There are two more items on the todo list for this, but neither one will hold up a release if I run out of time soon.

- Implementation of the MCM menu for control over the random picker.

- Interface for modders to specify filters in an fnSexoutRun/RunFull call.

Because they were loaded in the GECK when you created the plugin. Clean them out in fnvedit or recreate the dummy plugin.

Prideslayer said:

In some cases, different "sides" of an animation are reused in other animations. There may be one animation for a guy thrusting that is used by three different animations in sexout that have a different female side. In one or two cases different pieces of existing 2p animations are combined to create a 3p animation. Replace one of those and you break all the others.

 

This is probably the main source for several problems.

Maybe could be better to have "duplicated" guy or girl animations for each different "actions" even if the single animation is the same. Simply duplicate the animation renaming the copy with a different naming system could be referenced in a better way.

Only an idea.

This was done at one point, I actually *removed* all the duplicates in the current release to shrink the data fomod size.

Whatever you do, please don't just start overwriting the sexout animation KFs again. You can do what want with your animation and mod, but if that happens again, I'll move the anims in sexout to break it -- intentionally this time.

 

With all due respect, Sexout now has a very talented animator and instead of making things easier for him by just allowing him to overwrite the really bad animations, you want to intentionally break things so that his superior animations don't work?

To be fair, I don't know what goes into the NG mod, maybe what he does causes problems for the mod itself due to how its coded, but before Amra's animations broke due to the latest NG, everything was working fine on my end. 

 

Again, I'm not disrespecting your work and I think NG is a great mod, I just don't get why NG can't allow people to overwrite the animations they don't want.  Does it break the mod?

It's not possible to disrespect "my" work in this sense -- I did not create any of these animations -- but I am making things as easy as I can. Saying that any of the animations are "really bad" is offensive though, even if said with "all due respect." But that's not really the point.

There are several reasons I don't want the files overwritten. Mainly though, it's simply because it's just rude. As soon as the NG beta gets the MCM menu stuff, it'll not only be rude, but pointless as well.

Sexout relies on knowing intimate details about the animations, as do the modders using sexout. If a modder wants a doggy style animation because in game dialog indicated that is what is going to take place, who do you think gets the bug reports when some other animation is shown? Even worse is when an oral animation replaces or is replaced by a sex animation. This results in not only bug reports to the mod that actually initiated sex, but also "screws up" things like orgasm visual effects. It also results in the character potentially getting pregnant from a "blowjob".

In some cases, different "sides" of an animation are reused in other animations. There may be one animation for a guy thrusting that is used by three different animations in sexout that have a different female side. In one or two cases different pieces of existing 2p animations are combined to create a 3p animation. Replace one of those and you break all the others.

This has all been hashed and rehashed endlessly. I tried to stop it before it started early in this thread and I got absolutely nowhere. I tried to fix it after the fact, with the same result.

I don't deserve the bug reports that overwriting the files generates. Neither do the other modders who may get them. Since my instructions on how to carefully replace the animations so as to not cause these problems were ignored, I'm forced to take more drastic measures.

The current sexout beta has a breezes mesh weighted for the astymma skeleton. If you use that, I can include the animations directly in sexout. If you use the same one you've been using, Odessa should be able to include it in the upcoming plugin no problem. Anything else and it's up to you to create a plugin to add it to the sexout registry once the current beta is released and the API is published.

Whatever you do, please don't just start overwriting the sexout animation KFs again. You can do what want with your animation and mod, but if that happens again, I'll move the anims in sexout to break it -- intentionally this time.

MCM to enable/disable individual animations in the random picker on a per-plugin basis is in the works. Note that this will NOT entirely disable animations -- it just adds/removes them from the valid pool for the random animation picker. Mods that use a specific sexout animation by number will still play that animation even if it's "disabled" via MCM.

The next beta won't have the MCM, but it will have the animation registration stuff, and I suspect Odessa will release the Amra plugin shortly after. That will at least get all those animations back into sexout, via the random picker, along with some new ones that Amra created but never updated the plugin to use. The MCM will come some time after that.

What I'm thinking of is something along the lines of the version being just an integer (internal).

iSexoutSCRVersion := 2015031505

This will fit in a signed integer until 2147.

Then for display, to reintroduce the decimal..

printC "%g.%g" floor(iSexoutSCRVersion / 100), iSexoutSCRVersion & 63

I'm not suggesting he switch away from the date format, just that it be stored as an integer rather than a float to get away from all this floating point and printing stuff.

--------

Err the "& 255" is wrong, it should be "& 63" which is as large as it can be without overlapping any of the date part, allowing for releases from yyyymmdd(0..63).

You don't need it for any integer. They will all print correctly no matter the value. The format specifier needs a type there, the '%8.0' on it's own won't work by itself -- needs to be '%8.0f' for example, and if you say %f for float (%g doesn't have precision) then you probably just end up with more scientific notation gibberish.

Even multiplying that value by 10 will blow up once the fractional part gets to 0.11 and results in a 1.1.

All the weird edge cases like that just aren't worth it IMHO. One big integer or a few smaller integers are the way to go.

It's still a float though, which means eventually you might run into precision problems.

Also of course if you do that with iVersion/floor, you can just use %g -- no need for the sv_construct.

Print "SCRStartLog:SCR version %g.%z" iVersion fVersion

Though this and yours will both print "wrong". fVersion will be something like 0.1, not 1, without a multiplication. That means it'll print 20150101.0.1 or something like that.

At present no you can't manage a single game with FOMM + NMM. You used to be able to do this, but NMM changed their installlog format and some other things, so it no longer works. One day in the future it may work again. For now just deactivate all the packages within NMM, then add them and activate in FOMM.

You don't have to remove the packages themselves (the "right hand" tab in NMM / the package window in FOMM), just deactivate them all.

Sweet jesus hal!!

If we had fixed-point math I'd be with you, but floats aren't fixed point.. they're floating point. Why not just store them separately as integers, or use the bigger integer without the decimal point?

Quick question to Pride,

Are there any plans to merge SexoutPositioning with SexoutNG? Seems like the kind of functionality a master plugin could make use of. Just curious.

Yes and no. The plan is to let positioning handle the actual adjustments, but modify sexout so that the offsets that have been setup with positioning can be saved separately from everything else and then shared/traded amongst users. So one person could setup the the offsets for certain body/size pairings in positioning and then give the export file to someone else without positioning and sexout would load it.

 

Silly question, how do I check if an actor is engaged in sex so I can block any outfit swapping?

I've been doing this, but now I just realised I'm comparing a form to an integer so it probably isn't right.

 

(rActor.NX_GetEVFo "Sexout:Started::spellTarget" == 0)

Call the fnSexoutActorInuse UDF.

if eval(0 == call fnSexoutActorInuse); .. actor not in use ..endif

I believe NMM has that problem with a bunch of things, not just NX. When I first started working on FOMM there was code in it to prevent some file types (like DLLs and EXEs) from being installed, and NMM is based on FOMM. However NMM *does* install those types of files -- for example it installs bodyslide (some EXEs) just fine for Skyrim so there must be more to the story.

In any case, if you haven't left something out, I'm not "wrong". You said this:

Also, is there a version of NVSE newer than the one posted on the NVSE site? I downloaded one from here at loverslab, but it was about four months old.

Installing the one from here OR the one from the official site is wrong. Spunk will not work with either of those no matter if you install them manually, with FOMM, or with NMM. If it's all working, it's because you did at last follow the spunk directions and downloaded the correct version of NVSE listed there -- which may have worked fine with NMM, though I've never tested.

The automatic tostring in the first example is doing that. NVSE doesn't actually use printf/sprintf to format strings, it uses its own bizarre version. My suggestion is to do like sexout does -- use integers rather than a float. Or use an integer and go to plain YYYYMMDDNN (ditch the decimal).