prideslayer

I updated the OP to indicate what you need to do.

If this is true, then I can include an ESP that just does that and as long as it's loaded last, it should correct any screwups loaded before it.. Maybe after I've merged in ZAZ and perhaps Slavery, people already complain about # of items in load order.

2.6.86b3 in OP - Updated new CBDialog conversation handler, again Sexout now removes the actor from the conversation partner array immediately upon a match rather than waiting until the end. Helps compatibility in the event that a simultaneous act is trying to use the same actor, though I've never actually seen this.

I've added a wiki page documenting the issues with the dialog callback (CBDialog) and a "better" way to achieve the same goal. Honestly, nobody should actually be using CBDialog anymore. It's problematic and is likely never going to work right, because of limitations in the engine itself related to startconversation. The page is @ http://git.loverslab.com/prideslayer/sexout/wikis/cbdialog The tl;dr is that, if you need a conversation to occur after an act is finished, you should use a spell and a quest together instead (or a similar mechanism) and do something like the following. This assumes a quest variable called 'stage' but you could use an actual quest stage or anything like that. 1. Initialize the stage to 0. 2. Start the act with a CBSpell. 3. In the CBSpell script, set the stage to 1 and dispel. 4. In the (gamemode) quest script, if the stage is 1, issue startconversation yourself, set a delay, and return. 5. In the conversation topic, set the stage to 2. Your script repeats stage 4, say once a second, until the conversation takes place -- which it 'knows' because the conversation sets the stage to a new value. I am trying to come up with a way for sexout to do this itself, and I think I might have one, but it's going to take some time and will still require mod support. At present, all sexout knows is if a conversation with the specified actor happened. It doesn't know if it was the *right* conversation (topic), and there are still some issues that arise if multiple acts finish around the same time with CBDialogs pointing at the same NPC. Long term, either use this system instead and forget about CBDialog, or wait for the new system. The new system I think will require the calling mod to set a quest/NX variable in the dialog result, and also supply a UDF that sexout can call that will check the value of that variable. This will ensure that the startconversation for your topic occurred and your variable was set, and sexout can keep retrying (as it does now) until the UDF returns 1, or the actor dies or something, while allowing the actor to be unlocked.

2.6.86b2 in OP - Updated new CBDialog conversation handler. This beta fixes a problem in the new CBDialog handler, which was causing CBDialogs to not function if the player was not one of the actors involved in the act. Thanks to Tomm343 for finding the issue and testing the fix!

2.6.86b1 in OP - sv_destruct refactoring in some scripts. - remove unused vars in some scripts. - new CBDialog conversation handler. The conversation handler menumode piece now adds new conversation parters to an array, as it sees them, if the player is involved in the act. The gamemode script checks this array for the target actor to determine if the CBDialog hook was successful or not, and clears the array. The intention here is to fix an issue where a conversation topic started by a CBDialog in turn starts a conversation with a different actor before returning to gamemode -- causing sexout to 'miss' that the CBDialog took place and repeat the attempt. Tested OK with console manual start w/ dialog, and in the Marissa tour in Legion Tryout. Had a CTD in TTW overhaul at the Butch/Amata scene but not sure if it's related, and the TTW takes so damn long to load that testing is pretty frustrating.

Well, this doesn't seem to be completely true. I went through all my UDFs and added sv_destructs at the end for every string var, now it's CTD city when sexout tries to run. Going to do some more testing. edit: eh could be unrelated, will sv_destruct twice in a row on the same var blow up? I'd rather not have to check for assignment on all of them before calling it, but might have no choice. edit2: ok false alarm it seems, looks like something is wrong with whatever version of sexoutsex or scr, both of which aren't exactly up to date. console sex worked fine.

Thanks.. as it's harmless, I think I'll "just do it" anyway. I wasn't sure if that was the case, or if destroying it would affect the caller.

Ah thanks, that's one of those things that I always forget to test. A fomod is just a renamed zip file.. I always just create them by zipping up a directory and renaming the file.

It's common (but bad practice / discouraged) to start a sex act in a dialog result script. You should just set a quest stage (that a gamemode quest script is watching for), cast a spell, or something like that. If that isn't what you're asking then.. errr.. dunno?

It's the first thing discussed in that tutorial, it's using GetButtonPressed though, which also works fine.

Doc (or anyone who knows), Does the need to sv_destruct apply to strings passed in as params to a UDF, that you did not assign or construct yourself? I have a few like this that are not being destroyed that might be the cause of some .nvse bloat. Ex. scn fnSexoutSetRVal; argsref rTargetstring_var svNameref rVal; internalstring_var nxKeyBegin Function{rTarget svName rVal} if (1 == IsReference rTarget) let nxKey := "Sexout:Values:" + svName rTarget.NX_SetEVFo $nxKey rVal sv_destruct nxKey endif sv_destruct nxKey SetFunctionValue 0EndShould I also be destroying svName?

it's just an iskeypressed in a gamemode block to kick things off.

The textures between the two are incompatible. You can install roberts if you want, but unless you install an erect nude mesh to the right location (I forget exactly, look in the sexout esm for the bodysuit) sexout won't work properly. It's meshes/sexoutng/upperbody_erect.nif or something like that. If you get that all installed correctly, then it's just alignments that will be off.

I will forward this along to jaam and see if he wants to include something in NVSE. If not, I'll get something in NX.

TTW isn't checking for sexout AFAIK, and sexout isn't checking for TTW either. If/when I get around to that and the companion stuff, I'll add them to the lists in sexout and let you know, so you can dump that code in SCR -- but I think for now, you're the only one doing it. I haven't checked to see if the baseform is actually the one from NV or not. If it's not then those actors will obviously stop working if SCR stops adding them -- and won't work without SCR -- at present.

The NG related issue, this line: fnSoCSv: NCR Trooper (1D00B48B) 'NULL' -> NCR Trooper (1D00B48B) 'NULL'is "impossible" if NVSE is functioning properly. Odessa verified that in her load order, nothing but sexout is calling the UDF (fnSexoutcopyStartvars) that prints that line. It happens at the top of the function: scn fnSexoutCopyStartvars; Copies Sexout:Start NX vars from rSrc to rTgt and renames them; into the Sexout:Started namespace.; argsref rSrcref rTgtstring_var sOKeystring_var sNKey; internalarray_var elementarray_var arTmpstring_var nxKeystring_var sReplfloat fValref rValBegin Function{rSrc rTgt sOKey sNKey} DebugPrint "fnSoCSv: %n (%i) '%z' -> %n (%i) '%z'" rSrc rSrc sOKey rTgt rTgt sNKeycall fnSexoutCopyStartvars self self "Sexout:Start::" "Sexout:Start:" + $nActId + "::"call fnSexoutCopyStartvars self rActor nxKey "Sexout:Started::"

Do you know which bits, waffles?

Do not activate the TTW ESM in the geck when working on the mod and you'll be fine.

I mean.. it does a lot of CPU intensive stuff. I don't know what all, but I doubt it edits FalloutNV.esm or Fallout3.esm (which one did you mean?) but it DOES add its own TTW esm which could be injecting records into either of those, or overriding existing records.

TTW does a *lot* of stuff during the install. It doesn't peg my 8core xeon for 20 minutes for no reason.

Sexout has all the NV baseforms for creatures in it's formlists, so as long as the TTW actors are using the NV baseforms (e.g. base supermutant, dog, etc.), then all those actors from FO3 will work just fine.

According to the wiki, getarmorrating is called on an actor (no param) and returns AR of currently worn item. refActor.GetArmorRatingIt returns a percentage, so it might need a float, not an int.

lolwut?

That just.. flabbergasts me. Maybe the issue has been there that long, or maybe it's something else. The two places I call that UDF, at least one of the parameters is a string literal -- it's impossible for it to be null unless something has gone wrong with NVSE, I'd imagine.