Tonoma

In case you have not yet noticed (and assuming I am looking at the most recent version):

crQuestOrgasmScript line 50 is referencing deprecated SexoutSQLVAR.fLustZPlayer

crMachoistScript line 10 is referencing deprecated SexoutSQLVAR.fLustZPlayer (twice)

It looks like SCR supports or expects SexoutSQVAR.fSexoutLustVersion to be loaded (initialized) with your mod version? Could be useful to mods and patches in adapting to version changes...

(Since you asked for additional input ... )

Looks like SexoutNG now correctly supports masturbation and the Y-key. Probably can remove your patch for male masturbation? (crQuestMainScript, lines 73-79). Wonder if you still need to specify the sex and animation for the other masturbations (lines 260-266)? Dropping that would give more animation variety.

With female Courier, in my handful of tests, Cass always GIVES oral sex, yet is asking for sex. Perhaps should be random on who is giving/receiving (or a 69-type animation...)? Apparently determined within the several crNPCLustyAsk/crNPCLustAskYes and a few other dialogs?

Could change associated dialog scripts to something like:

if (playerRef.SameSex getSelf)
if (50 > GetRandomPercent)
set SexoutNG.actorA to playerRef
set SexoutNG.actorB to getSelf
else
set SexoutNG.actorA to getSelf
set SexoutNG.actorB to playerRef
endif
elseif (playerRef.GetIsSex Male)
set SexoutNG.actorA to playerRef
set SexoutNG.actorB to getSelf
else
set SexoutNG.actorA to getSelf
set SexoutNG.actorB to playerRef
endif
CIOS SexoutBegin

Consider providing a user-settable lust reduction factor (perhaps x 0.2 to 3, default=1.0). Doing so would give more meaning (range) to the Days-to-Max-Lust (DtML) setting, since now only a few settings (say days 3 to 7) make lust useful gamewise. Or, consider connecting the reduction rate to DtML.

Any chance you can keep a bug-fixed v5.8 available since 6.x is in beta? There probably are a fair number of current SexoutLust v5.8 users who use and enjoy the mod - not bad for a non-animation, non-senario Sexout plugin. It seems SexoutLust 6.x retains most of the v5.8 scripts pretty much intact. Maybe provide a user option for the v6.x series to enable just the v5.8 features (i.e., no orgasm, no arousal). Somehow I suspect you want to move forward and would rather not do so, but I submit that v5.8 (if bug-fixed) is really good as a pure Sexout Lust mod and should be kept around in one form or another (i.e., not abandoned).

For me, I will stay with v5.8 (my archived copy with a few personal changes/tuning) since I am not yet sold on the arousal complexities versus the v5.8 simple and understandable lust (I've come to this conclusion after wasting too much time trying Arwen's and Imp's reality mods - I find the micro details eventually become too tedious gamewise.)

(Anyhow, I need to stop waiting for all these many different mod enhancements (not just yours) and do an actual full playthru with Sexout as a side component (with a FONV highly crippled economy making Sexout more important.) All along this has been my (continually postponed) goal. Once I do that, I can quit FONV and these mods and get my life back ... maybe?)

If I'm reading the script correctly' date=' the problem is the return statement on line 146.

[/quote']

I agree that the crNPCLustTrackerSCRIPT RETURN statement is the cause of the problem. The Return statement causes an early exit of the script and thus bypasses the "SCR Update Variables" (meaning SexoutSQLVAR.fLustZCass is not updated, but retains the previous SCR value). (Fixed reduction does not have this problem since that code branch does not encounter the RETURN statement.)

Chase:

Sorry to be so persistent, but trying to help solve this problem of lust-stuck-high (except I use your fixed-lust-reduction option, so this bug does not affect me.)

In short, it seems that you "Import SCR Variables" more often than you "Update SCR Variables".

So to quickly check, I duplicated your lust print statement and placed it at three other locations: (1) just prior to "; Import SCR Variables", (2) just prior to "; Check Gender", (3) normal/current position, and (4) just after the "set SexoutSQLVAR.fLustZCass to lust" statement. I also slapped out a little ditty to monitor SexoutSQLVAR.fLustZCass every 5 seconds (SOSCRPeek). Here is a small piece of what I got on the tail end of one Courier-Cass sex event:

statements used at locations mentioned above:
printToConsole " (1) %n - timePassed: %.5f / Lust: %.4f / LMult: %.2f / MLust: %.2f" thisNPC timePassed lust lustMultiplier maxLust
printToConsole " (2) %n - timePassed: %.5f / Lust: %.4f / LMult: %.2f / MLust: %.2f" thisNPC timePassed lust lustMultiplier maxLust
printToConsole " (3) %n - timePassed: %.5f / Lust: %.4f / LMult: %.2f / MLust: %.2f" thisNPC timePassed lust lustMultiplier maxLust
printToConsole " (4) %n - timePassed: %.5f / Lust: %.4f / LMult: %.2f / MLust: %.2f" thisNPC timePassed lust lustMultiplier maxLust


SOSCRPeek: Courier:-0.8184 Cass:100
(1) Cass - timePassed: 0.00105 / Lust: 96.8000 / LMult: 1.00 / MLust: 100.00
(2) Cass - timePassed: 0.00105 / Lust: 100.0000 / LMult: 1.00 / MLust: 100.00
SOSCRPeek: Courier:-0.792 Cass:100
(1) Cass - timePassed: 0.00105 / Lust: 96.8000 / LMult: 1.00 / MLust: 100.00
(2) Cass - timePassed: 0.00105 / Lust: 100.0000 / LMult: 1.00 / MLust: 100.00
(1) Cass - timePassed: 0.00105 / Lust: 96.8000 / LMult: 1.00 / MLust: 100.00
(2) Cass - timePassed: 0.00105 / Lust: 100.0000 / LMult: 1.00 / MLust: 100.00
SOSCRPeek: Courier:-0.8184 Cass:100
(1) Cass - timePassed: 0.00105 / Lust: 96.8000 / LMult: 1.00 / MLust: 100.00
(2) Cass - timePassed: 0.00105 / Lust: 100.0000 / LMult: 1.00 / MLust: 100.00
(1) Cass - timePassed: 0.00105 / Lust: 96.8000 / LMult: 1.00 / MLust: 100.00
(2) Cass - timePassed: 0.00105 / Lust: 100.0000 / LMult: 1.00 / MLust: 100.00
SOSCRPeek: Courier:-0.792 Cass:100
(1) Cass - timePassed: 0.00105 / Lust: 96.8000 / LMult: 1.00 / MLust: 100.00
(2) Cass - timePassed: 0.00105 / Lust: 100.0000 / LMult: 1.00 / MLust: 100.00
SOSCRPeek: Courier:-0.8024 Cass:100
(1) Cass - timePassed: 0.00106 / Lust: 96.8000 / LMult: 1.00 / MLust: 100.00
(2) Cass - timePassed: 0.00106 / Lust: 100.0000 / LMult: 1.00 / MLust: 100.00
SexoutNGBES: v04 in use flag unset on A! 0x00000000
SexoutNGBES: v04 in use flag unset on B! 0x00000000
(1) Cass - timePassed: 0.00106 / Lust: 96.8000 / LMult: 1.00 / MLust: 100.00
(2) Cass - timePassed: 0.00106 / Lust: 100.0000 / LMult: 1.00 / MLust: 100.00
(3) Cass - timePassed: 0.00106 / Lust: 100.0000 / LMult: 1.00 / MLust: 100.00
(4) Cass - timePassed: 0.00106 / Lust: 100.0000 / LMult: 1.00 / MLust: 100.00
SOSCRPeek: Courier:0.00444843 Cass:100

By my interpretation, it shows that lust drops to 96.8, then is overwritten by SCR value to 100. Next loop, lust drops to 96.8, but again overwritten, and so forth for each lust reduction computation. SOSCRPeek shows that SexoutSQLVAR.fLustZCass is pegged at 100 and not showing any decrease at 5 second intervals which is consistent with the lust printc values.

Well, right or wrong, at least I am learning how to patch the mod and perhaps adapt it to my own preferences (maybe a MCM slider for lust reduction factor)...

Yeah' date=' this has been an ongoing problem. :\

[/quote']

Regarding SexoutLust 5.8 (I know you are moving-on/busy with its successor - disregard if this is now irrelevant.)

(1) You don't suppose part of the problem of lust-stuck-high on companions (Cass) is due to overwriting current local lust value with previous value from SexoutSQLVAR:

; line 90: crNPCLustTrackerSCRIPT - - - Import SCR Variables

if(thisNPC == "00135f19") ; Cass
set lust to SexoutSQLVAR.fLustZCass ; overwrites previous local lust value
elseif(thisNPC == "000e32a9") ; Veronica
set lust to SexoutSQLVAR.fLustZVeronica ; overwrites previous local lust value
...

If this is the problem, an obvious simple fix is to write to SexoutSQLVAR.fLustZCass each time lust is recomputed.

(2) If I understand how this mod works, I see the following related problem to lowering companion lust. Currently if/when the player has no method of starting sex with a companion other than that from SexoutLust (i.e., no installed plugin that permits companion sex) then the player has a general problem reducing the companions's lust below a certain moderately high value. For fixed-lust reduction, it would be almost impossible to get much below lust 70; for timed-sex, then maybe lust 50 or so for 1-minute sex, and worse (much less reduction) if the player has decided to use default display time of 15 seconds. In the fixed case, supposing the player picked days-to-max-lust of 5 days, Cass would accumulate 20 lust per day and take roughly 5 days before hitting on the Courier. But after that first hit, dropping to lust 70, Cass would hit on the Courier every 1.5 days (worse/sooner if Cass starts drinking or days-to-max-lust is set much shorter.) A simple but non-elegant solution is to drop the companion lust to zero or near zero (or a random low value) upon having Courier sex - then the player would get the expected lust-sex roughly every 5 days. (Or, leaving things as is, the player could just set days-to-max-lust to 17 days to accrue 6 Cass lust points a day to get back to a hit every 5 days.)

(3) Curious. Absolutely cannot figure out purpose of "timeSinceLastSex" unless it is a left-over from previous code. Seems it (and its IF statement) could be removed if it serves no purpose. (You have "short waitingForChat" declared twice in both crQuestMainScript and crNPCLustTrackerSCRIPT - apparently the compiler is ok with that.)

Any chance you can change the global version number for your alpha/beta versions? Currently the stable 5.8 is version 5.8 as are the test versions.

Actually it's been SexoutSQLVARZPlayer.fLust for a while now' date=' I'm going to remove the old variables eventually

[/quote']

Didn't know about SexoutSQLVARZPlayer.fLust. I picked up SexoutSQLVAR.fLustZPlayer from SexoutLust; what little I know is by reverse engineering what others have done or reading these forum topics.

Hope Chase moves to the new SCR variables sooner than later since, wrt Lust, many may use his code as a template/example - I do/did.

I think I see the advantage of SexoutSQLVARZPlayer.fLust over SexoutSQLVAR.fLustZPlayer. Pretty much simple copy/paste to maintain similar or same variables for player, companions, etc? But you went further by using the same (Quest) script for the many main characters. Brilliant, and obvious once shown. Sure makes things easier for both the user of the variables, and the maintainer! Just learned something... (Now I will have to spend some time looking over SCR for tidbits like this, I had ignored it up to now, sorry.)

Are we talking just for reading' date=' or reads/writes? If Halstrom adds the SCR value, I'll gladly write to it in the next update.[/quote']

I can add that in the next update, does fBaseLust sound good enough?

From my end, just about any name would do; but since it is SCR, you seem to have a bit of a naming scheme that has meaning to yourselves and others...

Currently the full Courier's lust (base_Lust + bonus_lust) is SexoutSQLVAR.fLustZPlayer

My guess is that you and Chase might prefer something similar indicating player specific? Maybe: fBaseLustZPlayer

(Or maybe that is what you meant and I am being too literal?)

Thanks.

Are we talking just for reading' date=' or reads/writes? If Halstrom adds the SCR value, I'll gladly write to it in the next update.

[/quote']

Reads. With the total and the Courier's base value, can determine how much due to bonuses versus intrinsic, etc. Since SexoutLust computes the bonuses and base values continuously would be nice to have that available...

Thanks

Chase: For those having mods or patches that use SexoutLust, the Courier's base lust value is or could also be important. Of course the base value is the total_lust minus the lust_bonuses. Any chance the Courier's baseLust value could be stored in SCR so that accessing that value would not require a dependency upon SexoutLust.esp as a master?

I may be way off base ... but in testing one of my patches I occasionally got apparent false secondary key-pressed detections. Perhaps caused by random timing of scripts or my heavy finger holding the key down too long? Or the FONV engine just ran too fast (if so, those with a faster computer would experience this more frequently.) Whatever the cause, in such cases SexoutSexkey would fire off an unintended second (duplicate) CIOS to SexoutNG, which SexoutNG dutifully ignored since it was busy with the identical earlier animation request. Still, probably not good sending spurious CIOS to SexoutNG ...

CIPSCIS addresses by example how to "debounce" key detection using a simple flip-flop technique. Following his (efficient) method, the beginning of your script could be as shown below. In my patch, this solved the unexpected keypress detections.

int bIsXPressed

    if bIsXPressed != IsKeyPressed XKey
        set bIsXPressed to IsKeyPressed XKey 
        if bIsXPressed
		 ...
		endif
	endif

Hello!

I'm lv 2 and i win only 1 xp.

The sex time's is 80 (this is really long)' date=' or 10 sec, it's the same result.

What's wrong with my mod?

[/quote']

The version in the first post uses sex duration, but that plugin should not be used since it modifies part of Sexout.esm. A totally different alternate implementation is at post #36, but it does NOT use sex duration (there is a readme file within that 7zip that briefly explains what it does use.)

With the alternate version (loads as SexoutXPM.esp) you can use the MCM menu (accessed in game by pressing ESC) to change the MAX percentage XP points awarded - you can push that as high as 10%, default is 2.5%. On average, expect about 1/4 to 1/3 of the max percentage, almost never the max, and often just 1 point. Higher awards require moderate to high lust - if SexoutLust is loaded, consider increasing or maxing rate of lust production (alcohol and drugs help)- if not loaded, another MCM setting will allow you to simulate a higher lust rate.

Frequent sex with Lust below the threshold value (another MCM setting) almost always yields just 1 XP. Drop the threshold (a role-playing factor) to zero to allow a CHANCE for a few more points.

In any case, amount of XP awarded depends upon several factors, don't expect many; much sex is required to level-up by sex alone.

Lastly, FONV XP awards are integers and always rounded down. At lower levels this point clipping might seem more pronounced since the range of possible awards is small. (At level-2, one percent is 3 points.)

If none of the above helps, post again and I will re-examine the internal logic for number of points awarded.

Updated BETA release in the NG thread first post.

Before visiting the forum today I tested sexout beta-63b1 with nearly all other mods disabled (except for MikotoBeauty, DarNifiedUINV, pipboy2500_edisleado, MCM, and my custom race) and started a new character from scratch with a fresh save as a base-testing-save (I suppose it never hurts to have one of those handy.) Of course I obtained the same result as before.

I just finished running the same test sequence using that base save against your newer Sexout-2-3-63b2. As I am sure you now expect, all ran well - no 8.1 abort messages; each sex event occurred as expected; Courier did not vanish nor end up in the blue "sky"... Masturbation still is random, but that is not a callback problem. As far as I can tell SexoutNGFLGlobalCBEndS works as you intended and not much more testing is needed on that feature. (On my private (enhanced) version of SexoutXPM I will switch over to SexoutNGFLGlobalCBEndS, so there will be continuing indirect testing as it will be in active use.)

It seems bugs that don't run at all are to be preferred over those that just misbehave (as if one had a choice).

If a script starts to do setup by setting sexout or sexoutNG vars' date=' and then ...

[/quote']

Ok, more testing; took SexoutXPM out of the equation. Using SexoutNotify to test SexoutNGFLGlobalCBEndS and the "Aborting due to 8.1".

In short, SexoutNotify using SexoutNGFLGlobalCBStartS (as distributed with SexoutNG) works fine using SexoutSex for M-F sex and Y-key for female masturbation (as was the previous case with SexoutXPM.) BUT SexoutNotify, modified to use SexoutNGFLGlobalCBEndS, only performs masturbation properly until sex with a partner occurs, then masturbation (using Y-key) fails with "Aborting due to 8.1" (as was the previous case with SexoutXPM.)

So, based on your previous feedback, the 8.1 error code (not sure an 8.2 code exists) means that SexoutNG is somehow receiving old and new (mixed) style actor references (sexout.male/female vs sexoutNG.actorA/B/C). SexoutNotify monitors exactly these changes in references, including sexout.male/female. Not once in either test did Notify print-to-console that sexout.male or sexout.female were changed. After sex with the settler, I moved the Courier a few feet away, then pressed the Y-key. That should be more than enough frames for SexoutNotify to capture any change in actor references, especially to sexout.female/male. Of course, for both tests (CBStart/CBEnd) SexoutNotify did discover reference changes, but only to SexoutNG.actorA/B.

Just did another Notify CBEndS run to check what happens if after the masturbation failure, the settler still works. It does not. Settler and Courier agree to type of sex (V), he looks at the Courier, then walks away. To test further, I immediately send the Courier to Sunny, they agree to sex, sex starts but Courier is invisible, THEN, the Courier appears in a blue screen field - my guess fell through the floor or more likely transported into the sky or something - cannot move or perceive movement, but feet and arms are slowly flailing. That pale blue backgroud sounds like an FONV problem - lost coordinates, but so far I have ONLY seen it during the CBEndS testing (now twice)...

Below is the console scof for this second Notify CBEndS test (the one where Y-key masturbation fails after M-F sex, and settler sex has no animation after Y-key masturbation fails, then Sunny ... I have edited with ;comments what was happening on-screen.

SetConsoleOutputFilename >> 'CBend_Notify2.txt'

SCR1Main: Starting at 5 1

SCR1Main: Starting at 5 2

SCR1Main: Starting at 5 3

SCR1Main: Starting at 5 4

SCR1Main: Starting at 5 5

SexoutNGSAN: random O=1 V=1 A=1 type=1 Anim=0 noAnim=0

Notify: Sexout.actorB changed to Sissy

SexoutNGRAN: 2 actors anim 232

SexoutNGBES: PCFd: 1 1 1 1 1 1 1

Notify: Sexout.actorB changed to

; *** Y-key Courier masturbation starts, animation is seen (but random)

Notify: SexoutNotifyEffectScript responding to CallBack ...

Notify: listed so Sissy is masturbating!

SexoutNotify: FLA is 0 after clear

SexoutNotify: FLV is 0 after clear

SexoutNotify: FLO is 0 after clear

; *** Courier hits on Settler (sexoutsex), animation is correct

Notify: Sexout.actorA changed to Goodsprings Settler

Notify: Sexout.actorB changed to Sissy

SexoutNGSAN: random O=1 V=1 A=1 type=1 Anim=0 noAnim=0

SexoutNGRAN: 2 actors anim 607

SexoutNGBES: PCFd: 1 1 1 1 1 1 1

; *** around here Y-key for Courier masturbation ==> no animation, no abort code, no response

Notify: Sexout.actorA changed to

Notify: Sexout.actorB changed to

SexoutNGSAN: random O=1 V=1 A=1 type=1 Anim=0 noAnim=0

Notify: Sexout.actorB changed to Sissy

SexoutNGRAN: 2 actors anim 239

; *** hit Y-key again, get two abort codes

SexoutNGSAN: Aborting due to 8.1

SexoutNGSAN: Aborting due to 8.1

Notify: Sexout.actorB changed to

; *** Courier hits on Settler (sexoutsex sextypeV), no animation

Notify: Sexout.actorB changed to Sissy

Notify: Sexout.actorA changed to Goodsprings Settler

; *** Courier hits on Sunny (sexoutsex sextypeO), animation with invisible Courier

Notify: Sexout.actorA changed to Sissy

Notify: Sexout.actorB changed to Sunny Smiles

SexoutNGBES: PCFd: 1 1 1 1 1 1 1

; *** Courier stands up in blue field floating, nothing else visible

Notify: Sexout.actorA changed to

Notify: Sexout.actorB changed to

; quit

RE SexoutSex may be the problem - evidence is not strong for that theory. The abort after error code 8.1 should reset all the actor references to zero as a recovery reset. The Y-key is not processed by Sexoutsex, yet it also fails even after the error reset, and the Y-key response script is within Sexout.esm. None of these problems is seen when using SexoutNGFLGlobalCBStartS, so that lessens the chance that two mods are tampering with the actor references (why do they misbehave when CBendS runs but are well behaved for CBStartS runs.) There's always the possibility that I do not understand how to set up the SexoutNGFLGlobalCBEndS callback correctly, but I only changed the Start's to End's - the first few callback print-to-console responses look the same as when using SexoutNGFLGlobalCBStartS (i.e., prior to first ActorA/ActorB sex.)

Well I might have to bite the bullet and fire off CIOS from the console running only with sexout.esm and sexoutnotify.esp... never done that, but I squirreled away some notes somewhere...

I will look into the masturbation thing.

The 8.2 calling convention thing is indicating that values were set in multiple places' date=' e.g. both sexout.male AND sexoutng.actora were set (not null / 0) when sexout checked the vars. You need to use sexoutl.male/female [i']or sexoutng.actora/b/c. If one or more are set in both groups, you get an 8.2

Problem is SexoutXPM just awards XP points and does not use sexoutng.actor a/b/c nor sexout.male/female nor does it use SexoutBegin. As noted, only 4 lines were changed to test SexoutNGFLGlobalCBSEndS (changing to SexoutNGFLGlobalCBEndFLA etc.)

I'll use FNVEdit to extract the actual scripts of the working SexoutNGFLGlobalCBStartS version and the SexoutNGFLGlobalCBEndS test version, then do a differences compare to see if anything unknown slipped in...

From your comment I suppose you are saying plugin-A can, for example, modify (step on) sexout.male thereby breaking plugin B's actor.CIOS SexoutBegin if plugin B is using sexoutng.actora/b? That is understandable. (Just searched on the one quest script (only script modified for the test) that sets up the callbacks - found no references to "sexout." nor "sexoutng."

Sexout.male/female, sexoutng.actora/b/c are quest variables - so it is possible for a dirty save to be loaded and cause an 8.2 error?

I will have to explore further and perhaps do the conversion and test again from scratch with a new character...

The End* stuff is in the current beta in the NG thread' date=' first post. I haven't tested it yet, so please do and get back to me.

[/quote']

You asked for testing of SexoutNGFLGlobalCBEndS, and I did, particularly since currently few use callbacks. SexoutNGFLGlobalCBSEndS itself seems to be working, maybe. Other problems did occur, maybe unrelated. But my testing skills are marginal.

Tested with SexoutXPM since it uses callbacks plus familiarity with the corresponding debug messages. For the test, the only changes to SexoutXPM were:

(for this test, no other changes should be necessary?)

; ListAddForm SexoutNGFLGlobalCBStartFLA SexoutXPMFLA

; ListAddForm SexoutNGFLGlobalCBStartFLO SexoutXPMFLO

; ListAddForm SexoutNGFLGlobalCBStartFLV SexoutXPMFLV

; ListAddForm SexoutNGFLGlobalCBStartS SOXPMae

; DebugPrint "SexoutXPM: SexoutNGFLGlobalCBStartS Callback initialized "

; ListAddForm SexoutNGFLGlobalCBEndS SOXPMaeUpdate ; NOP for now

ListAddForm SexoutNGFLGlobalCBEndFLA SexoutXPMFLA

ListAddForm SexoutNGFLGlobalCBEndFLO SexoutXPMFLO

ListAddForm SexoutNGFLGlobalCBEndFLV SexoutXPMFLV

ListAddForm SexoutNGFLGlobalCBEndS SOXPMae

DebugPrint "SexoutXPM: SexoutNGFLGlobalCBSEndS Callback initialized "

I outline here the simplest of my five SexoutNGFLGlobalCBEndS test runs. Disabled (via FOMM) all sexout mods except Sexout.esm, SexoutCommonResources, SexoutSex, SmallerTalk, and SexoutXPM. Loaded clean save for female Courier, level 1, at Goodsprings soon after Sunny training.

Console SCOF and enable SexoutXPM debugmode (MCM option). Hit Y-key to masturbate. Works, except incorrectly gives random animation (as already mentioned in my post #2623 of Official SexoutNG thread). Obtained expected debug console output from SexoutXPM (shown below). So SexoutNGFLGlobalCBSEndS works (as you predicted, SexoutActorToken=0). SoloSex a second time, still works with incorrect random animation but did log 2nd callback debug messages.

Now approach male northwest settler, use SexoutSex to ask for Sex-Type-V. Animation happens, but no console debug output (aborted my script that had just worked?) Seen this in earlier attempts of the SexoutNGFLGlobalCBSEndS test, so expected this.

Now try soloSex (twice) using Y-Key, previously worked with debug output. This time no animation, no debug output, but got console message "Aborting due to 8.1" ==> (We are going to bail and tell them not to mix calling conventions)

Don't see how SexoutXPM could impact the calling order/convention of other mod's SexoutBegin.

(Note, Y-Key response apparently serviced by Sexout.esm. Works until 2 actors involved?)

SetConsoleOutputFilename >> 'aanow.txt'

SCR1Main: Starting at 5 1

SCR1Main: Starting at 5 2

SCR1Main: Starting at 5 3

SCR1Main: Starting at 5 4

SCR1Main: Starting at 5 5

SexoutXPM: Version 4.3-1 DebugMode flipped to (1)

SexoutXPM: Version 4.3-1

SexoutXPM: Initializing (prev vers 3.99)

SexoutXPM: SexoutNGFLGlobalCBSEndS Callback initialized

SexoutNGSAN: random O=1 V=1 A=1 type=1 Anim=0 noAnim=0

SexoutNGRAN: 2 actors anim 231

SexoutNGBES: PCFd: 1 1 1 1 1 1 1

SexoutXPM: Callback Event 1 handled by SOXPMEffectScript

SexoutXPM: self=Sissy Courier's SexoutActorToken=0 ; normal, SexoutXPM script always sets actorB=self

SexoutXPM: actorA=Sissy actorB=Sissy actorC= ; normal, SexoutXPM script sets actorA=actorB if actorA=

SexoutXPM: isSEXV=0 isSEXO=0 isSEXA=0 isrape=0

SexoutXPM: isCoerced=0 isEnslaved=0 isHooker=0 noBabyRisk=1

SexoutXPM: isGaySex=0 strCourier=1 gayCourier=0 bisCourier=0

SexoutXPM: nLuck=5, RandomLUCK=0.981 (Range: High=+1.000 Low=-1.000)

SexoutXPM: SexoutSQVARZPlayer.iIsEnslaved=0

SexoutXPM: Lust=10.1 Lust(noBonus)=10.1 Threshold=10.0 LustFactor=2.2 useSCRLust=0

SexoutXPM: Rolling Dice, iRandom=43 jRandom=8 kRandom=28

SexoutXPM: Female isSoloSex, bonus=0 dimLust=0.922 nLustFactor=2 (1||0)

SexoutXPM: Lust=9.3 Lust(noBonus)=9.3

SexoutXPM: SoloSex throttle XP by half when lust below 60

SexoutXPM: Awarded 1 XP points, gainXP=0.007, gainMCM=2.5, nLevel 1, levelXP=200

SexoutXPM: lastSEX (GDP) value of 0 updated to 6.45281

SexoutNGSAN: random O=1 V=1 A=1 type=1 Anim=0 noAnim=0

SexoutNGRAN: 2 actors anim 236

SexoutNGBES: PCFd: 1 1 1 1 1 1 1

SexoutXPM: Callback Event 2 handled by SOXPMEffectScript

SexoutXPM: self=Sissy Courier's SexoutActorToken=0

SexoutXPM: actorA=Sissy actorB=Sissy actorC= ; normal, expected

SexoutXPM: isSEXV=0 isSEXO=0 isSEXA=0 isrape=0

SexoutXPM: isCoerced=0 isEnslaved=0 isHooker=0 noBabyRisk=1

SexoutXPM: isGaySex=0 strCourier=1 gayCourier=0 bisCourier=0

SexoutXPM: nLuck=5, RandomLUCK=-0.964 (Range: High=+1.000 Low=-1.000)

SexoutXPM: SexoutSQVARZPlayer.iIsEnslaved=0

SexoutXPM: Lust=9.4 Lust(noBonus)=9.4 Threshold=10.0 LustFactor=1.8 useSCRLust=0

SexoutXPM: Rolling Dice, iRandom=53 jRandom=65 kRandom=79

SexoutXPM: Female isSoloSex, bonus=0 dimLust=0.949 nLustFactor=1 (1||0)

SexoutXPM: Lust=8.9 Lust(noBonus)=8.9

SexoutXPM: SoloSex throttle XP by half when lust below 60

SexoutXPM: Awarded 1 XP points, gainXP=0.006, gainMCM=2.5, nLevel 1, levelXP=200

SexoutXPM: lastSEX (GDP) value of 6.45281 updated to 6.45876

SexoutNGSAN: random O=1 V=1 A=1 type=1 Anim=0 noAnim=0

SexoutNGRAN: 2 actors anim 714

SexoutNGBES: PCFd: 1 1 1 1 1 1 1

; missing expected callback debug messages,

SexoutNGSAN: random O=1 V=1 A=1 type=1 Anim=0 noAnim=0

SexoutNGRAN: 2 actors anim 237

; missing expected callback debug messages

SexoutNGSAN: Aborting due to 8.1 ; attempted soloSex

SexoutNGSAN: Aborting due to 8.1 ; attempted soloSex

; Quit

Footnote1: Reinstalled SexoutNGFLGlobalCBStartS version of SexoutXPM but still using Sexout.esm-beta. The few tests then all worked properly (except for random solosex animation). So either I messed up changing those 4 lines (which did work for the first few soloSex events), or there is something going on when a mod courses through the SexoutNGFLGlobalCBSEndS script.

Footnote2: Probably just a one off, but just in case of value or interest - The first test run had most major sexout plugins active; on first sex event (gardening settler), with a fence post positioning problem, the Courier became transparent during sex (expected, known behavior of collsions), BUT upon standing up, the screen snapped to pale blue, everything (buildings, dirt, trees, settlers) disappeared except for the clothed Courier standing in a blue nether-world but otherwise looking normal - stayed that way until I exited FONV a minute later - first time I have had this happen, ever. Of course my note taking was zero since I expected no problems on that first test.

It does sound interesting... however

Thanks for the feedback. Here are some clarifications and a question or two:

re: Use sexout counters Sexout.numRape and Sexout.numRaped - SexoutXPM uses "set isRape to (player.GetItemCount 00SexoutRapee)". Would Sexout.numRape be better/easier for some reason? (I do conceptually prefer fetching variables over items. Do wonder why a few Courier-specific Sexout.esm stat bytes (IsRaped, IsRaping, IsActorA, IsActorB, IsSexA, IsSexO, IsSexV, IsSolo, GaySex) don't exist that could be valid during the period between SexoutNGFLGlobalCBStartS and SexoutNGFLGlobalCBEndS?)

re: Use global sex notification hook - SexoutXPM uses "ListAddForm SexoutNGFLGlobalCBStartS SOXPMae" with the associated SexoutNGFLGlobalCBStartFLx V,O,A's. (It is I who has been asking/reminding about the timeframe for SexoutNGFLGlobalCBEndS. SexoutXPM-v1.0 used SexoutNGFLGlobalCBStartS within days of your announcement of its release. I found out SexoutNGFLGlobalCBEndS was not implemented when it compiled but functioned as a NOP.)

re: Use Sexout.frequency to track how often sex takes place - One could do that, or just track lastGDP and compute the time between events or a weighted average, etc. This mod does not try to reward (encourage) gratuitous sex nor reward a historical slowly moving average - the XP awards are based on nearer term events - type of sex, rape, coerced (enslaved), solo, etc. (For some players wouldn't sexout.frequency (which means rate) and similar values eventually after many encounters average out to a boring almost constant value?)

re: Lust - this mod uses lust but does not modify it. SexoutLust controls all aspects of lust; this mod uses those fluctuating values (would be useful if Chase's lust bonuses were in SCR though.) Lust is used because it is the only sex-based player value that fluctuates for a reason related to sex (currently alcohol, drugs, sex, time between sex). IF a player does not use SexoutLust or does not want to use it, the mod still functions by creating an internal lust equivalent value as a (less full featured) substitute. Normally (with a small exception) the player will have little to no knowledge of its existence or use within this mod. It is an input variable in determining a non-linear award XP factor.

This variant of SexoutNGXP (i.e., SexoutXPM) predates fritz's SexoutNGXP, and is built from a larger non-public version. It uses none of fritz's technique - it does not use the cum effect, nor does this variant modify any other plugin scripts, effects, values, etc. Its only external impact is awarding XP to the FONV engine. It is a variant for those interested in this type of XP awards where the cum effect is not used nor is sex duration and where XP awards scale properly for all game levels. It rewards infrequent sex (moderate to high lust), rewards sex likely to achieve climax, and partially randomizes probability and size of awards to simulate possible outcomes (since outcome flags do not (yet?) exist.)

My thesis is/was: "... there are just a handful of Sexout players actually interested in Courier-sex XP awards." Certainly it has been a neglected aspect of sexout's interaction with the FONV player's progression (i.e., leveling and allowing sexout to be a greater part of the full game.)

The lack of activity here probably means there are just a handful of Sexout players actually interested in Courier-sex XP awards; I am among those interested few...

Regarding SexoutNGXP, the mod needs several improvements. For me, one problem is that it is based on sex-duration; a feature some like, but I do not. I have already elsewhere voiced my opinion on why using duration did not make sense. Then the mod uses the cum-effect which (1) modifies SexoutNG (as clearly noted by others) and (2) gives the Courier XP for non-Courier sex activity. The mod does not discriminate between types-of-sex (A,O,V) nor the circumstances (rape, enslaved, etc.) Finally, and most importantly, it does not scale the XP awards to the amount needed for each game-level transition - the awards are or can become out of balance in advancing game levels. Yet I do appreciate the effort invested to get this mod going and in the discussion it has started.

Several months ago I wrote for myself a different style mod/patch/plugin to generate experience points based on Lust and type-of-sex (I used Lust as a frequency-of-sex meter). It soon evolved to also include my own formula for Lust reduction, but still used SexoutLust for Lust generation and various Lust effects. Next I explored adding mood factors (Arwen's, then Imp's, then my own), but have largely abandoned that endeavor as too much effort for too small an improvement in game-play. Nevertheless, the main theme of my plugin was and is awarding XP for Courier sex.

So, perhaps the attached stripped down version of this plugin (SexoutXPM) would be of interest to a few of you since many of the above features already exist within it (if interested, see the included readme file). It might hold you over until something better comes along. For those not using Lust, it's been patched to work with or without SexoutLust (but use with SexoutLust v5.8 is recommended.)

EDIT: SexoutXPM updated to support newer Courier SCR lust variable as used by Sexoutlust v6. Only briefly tested with v6. (SexoutXPM is within the SexoutNGXP-Alt attachments... previous version for those still using Sexoutlust v5.8.)

SexoutNGXP-Alt.7z

SexoutNGXP-Alt20120822.7z

Minor bug: The Sexout (not SexoutNG) MCM menu is still being used to configure the Sexout mod (animation duration, enabling the Y-key, etc.) Within the Sexout 00SexoutMCMQuest script are 5 instances of the following dysfunctional line:

SetUIFloat "StartMenu/MCM/MCM_Options/columns" 1

It should read as:

SetUIFloat "StartMenu/MCM/MCM_Options/_columns" 1

(Of course the issue is the missing underscore preceding "columns" - underscores are used this way throughout the MCM script. Potentially the menu items will change to some other menu's _columns which might not be 1 - that scrambles the menu, then later mysteriously works ok.)

A bit baffled why the masturbation animations (at least the female ones) are not working when I press the Y key (both when SexoutLust is installed, and when not installed.) Instead I get random animations using SexoutNG (v2.3.62 fomod.) At least a while back, if I recall correctly, those animations were appropriate for solo-sex.

Eventually found that keypress-Y is serviced by 00SexoutActorScanScript from the Sexout branch of code. That script passes just sexout.female and no animation to SexoutBegin. A fix might be to explictly add animations 101 and 105 for male and female as shown here:

Sexout.esm \ Script \ 0A00D1E8 <00SexoutActorScanScript>

...
elseif me == player
if IsKeyPressed 21 && Sexout.masturbateY
if me.GetItemCount 00SexoutActor == 0
set Sexout.female to me
if me.GetIsSex Male ; patch
set Sexout.Anim to 101 ; patch
else ; patch
set Sexout.Anim to 105 ; patch
endif ; patch
me.CIOS SexoutBegin
elseif me.GetItemCount 00SexoutSoloing && me.GetItemCount 00SexoutRecovering == 0
if me.GetItemCount 00SexoutAnim == 35
me.AddItem 00SexoutAnim 1 1
me.CIOS SexoutAnimStarter
elseif me.GetItemCount 00SexoutAnim == 36
me.RemoveItem 00SexoutAnim 1 1
me.CIOS SexoutAnimStarter
endif
endif
set delay to .5
...

Sexout.esm \ Script \ 0A00D1E8 <00SexoutActorScanScript>

During this exploration did notice that SexoutNGRNDEffectBaseScript also handles solo-sex if numActors=1, but could not figure out why that was not correctly handling the me.CIOS SexoutBegin from 00SexoutActorScanScript (thought all CIOS to SexoutBegin were now converted to SexoutNG parameters - previously enabling that was an MCM option.)

current snippet from scn SexoutNGRNDEffectBaseScript showing handling of solo-sex (numActors=1)

if 1 == numActors
; Chose a masturbation anim and ignore sextype
if actor.GetIsSex Male
set Sexout.Anim to 101
CIOS SexoutNGBegin
else
set Sexout.Anim to 105
CIOS SexoutNGBegin
endif
elseif 2 == numActors

Anyhow, to check my logic and not waste anyone's time, I applied the mentioned patch to 00SexoutActorScanScript which in my quick testing did fix the problem.

Is there documentation on the callback form lists somewhere? I'm trying to figure out who is the give/receiver.

Cannot find the reference, but I did cut/paste the key comment from Prideslayer comments (it was sufficiently important that I included the comment within one of my patches, and that is where I just now retrieved it):

; For 2p and 3p, set actorB to the actor playing the part of the "female", "receiver", "taker",

; whatever you want to call it. actorB is the one that will GET fucked, GIVE blowjobs, EAT pussy, etc.

I have been using the callback for about at least two months, and have done quite a few print-to-consoles related to it (mapped out many M-F, F-F, and a few M-M encounters wrt the callback.)

Maybe this is obvious, but I learned it the hard way. I found that "self" is always actorB and therefore not on the list (the list has the actors that are servicing actorB). Of course the first listed actor is ActorA (traditionally male role), the second would be ActorC (for my purposes I always disregard this actor.) If no actor, then ActorB is doing self-service.

Of course the Courier could be "self" (i.e., ActorB) or ActorA, depending on what the Courier is doing (for example, F-F), or the sex of the courier.

I did have a couple of instances where the callback occurred but 00SexoutActor token was not in the player's inventory, yet the player/courier was having sex - probably a rare timing error intrinsic to the design of FONV. So now with callbacks I do not rely on player's 00SexoutActor inventory, but rely on either ActorA or ActorB being the Courier (if I am screening for Courier sex.)

Hope this helps.

... implement several concepts of lust (maybe a monthly concept' date=' and maybe two or three orgasm based concepts, where each orgasm based concept has different rates, so they do not all go off together).

[/quote']

I can do that.

Lots of new ideas being floated, some sound interesting or even great, others give me mixed feelings ...

Hopefully you will provide MCM option switches/values for some of these features so that players can play in the style they prefer? Also I subscribe to the principle "keep it simple", especially when the benefit of the feature is small (a nuance or hard-to-model).

You can see how I've done this with my script in SCR "SexoutS0SexHappening" which is a copy of the SexoutNotify script.

Did you mean SexoutS2SexStartedScript? (Looked in several versions of SCR for SexoutS0SexHappening and could not find it.)

A simple method to (almost) restrict your script to just the Courier is to encapsulate the relevant script segment with:

if (player.GetItemCount 00SexoutActor) ; a token given to those actively having sex

...

endif

This will skip awarding xp if the Courier is not having sex, but it will probably trigger if the Courier is having sex at the same time as another pair (I suppose a male is required --- hmm, does your mod currently work for female-female sex?) Perhaps ok for an interim fix (after all, FONV already gives xp for kills by companions).

A possible starting point for moving this away from the cum effect is to use SexoutNotify as a template - it uses a callback (more efficient and better timing than polling) soon after sex starts. Unfortunately Prideslayer has not yet implemented the callback for when sex ends. Just change the script and variable names within SexoutNotify and stick in your code. You will need to figure out who are "ActorA" and "ActorB" to get this exactly right (i.e., player must be either ActorA or ActorB - I learned that the hard way). If you want to use this approach and get stuck or want a faster start, I can post for you a script snippet here that deciphers the callback actors.

(I can barely get my own minor patches to work but what little I know I figured out by reverse engineering SexoutLust - that and SexoutNotify are good mods to study. SexoutNotify shows how to interlink the quest and effects... If I recall correctly, I renamed the SexoutNotify esp and then used FNVEdit to rename the quest and script names, edited the scripts (Notepad++ with the gek plugin), then compiled the scripts using GECK - I try to use GECK as little as possible since it is so non-intuitive.)

I don't think you need SexoutLevelUp for this' date=' LevelUp track SexXP, but this is just normal GameXP

[/quote']

Based on my reading of the SexoutNGXP script, this mod does use Sexout.sexLevel which is computed by SexoutLevelUp. So both SexoutLust and SexoutLevelup are requirements for this mod to work as designed, but are not required masters. His XP awards are proportional to sexLevel.

fritz_t_coyote:

Your SexoutNGXP's xp awards scale with sexLevel and Lust. If sexLevel is high, but Lust is low, few xp points. Actually that is good since it makes it harder to exploit sex for xp points - more points are earned as sex becomes less frequent (as determined by days-to-max-lust in SexoutLust.)

However I would not use sexLevel and instead would use the Courier's game level (removes requirement for SexoutLevelup plus is more predictable regarding game leveling).

For example, you could:

set nLevel to player.GetLevel

set XPForSex to (1 + (3 * nLevel * lustPct))

For your lustPct, this would give a minimum of at least 0.2% towards level advancement, a reasonable 1% for lust=50, and a maximum of about 2% if lust reaches 100 (lust can go higher).

or set XPForSex to (1 + (3 * nLevel * lustPct * soxpFactor))

to adjust the xp higher or lower by some factor you define for soxpFactor (could be via MCM).

I would also exclude using sex-scene display time. If one changes that value, xp awards would change proportionately - a player may want longer or shorter display times based on situation or current viewing preference and should not have a game affecting value (an xp award) changed based on how long the player wants to view the animation. (Thus I do not consider animation time as being the actual sex duration time - plus some mods modify the game time-scale indoors versus outdoors, etc. Consider, if it were the actual sex duration time then in the mysterious FONV world, all sex of all types and in all situations have exactly the same duration - adding one realism kills the other.)