astymma

Out of the box, Sexout should, upon an act starting, toggle you automatically into what's known as the TFC camera. Same thing as if you opened the console and typed TFC (toggle free camera). You should post your load order inside a spoiler tag so that we can see if you might have a conflicting mod.

Try http://www.oceanlightwave.com/morrowind/TESAnnwyn.html

It's about as close as you're gonna get to what you are asking for imo.

Eyebrows and Eyelashes can be added one of two ways, assuming on how the original modder created them.

If you're using a head with combined parts, like a combined mouth and teeth mesh, it exposes one of the combined parts as a new mounting slot. If your race has a combined mesh, for example, all of the Mikoto races... you can add eyelashes and eyebrows as Head Parts, like Mikoto does to its races. You'll notice for Mouth it has MouthHumanMerged.nif and for the parts now merged into the mouth, like teeth, it uses Vacuus.nif. For the Tongue, it uses Eyelashes. So, changes to a merged mouth race can be made in the RACE record as well as the NPC record as an HNAM entry.

If you're using a race that doesn't have a merged mouth, pretty much everything except Mikoto or any races based on Mikoto, you'll need to add the Eyelashes and Eyebrows as HNAM entries in the NPC's record.

So, basically, create an HDPT record (Head Part) for the Eyelash or Eyebrow, then add it to the Head Parts (HNAM) list for your NPC in their record. Or, if it's a race with a merged mouth, you can make it part of the RACE record by adding the nif as part of the head entries, replacing upper or lower teeth or the tongue.

If it's for your own character, i.e. the player, simply make a head part entry like before, an HDPT record... and it'll be pickable like eyebrows and beards and moustaches are from the normal character creator... meaning any NPC that can give you a haircut can let you pick the new eyebrow/eyelash so long as you set the HDPT entry to be "playable". If you open FalloutNV.esm in FNVEdit, check the HeadParts list, you'll see exactly what I mean... you can even mix and match... for example, combine eyelashes and eyebrows by adding one or the other as an "extra part" to the other entry... for example, the NVEC error correction mod, added the EyebrowM entry as an extra part to all the male beards so they had nice eyebrows as well as the beard itself. So any HDPT can be added to any other HDPT as an extra part.

Smaller Talk shows empty in the MCM menu for me?

Considering SmallerTalk has functioned perfectly fine for a long time, for a lot of people, I'd seriously doubt SmallerTalk is your probelm. Then again, you didn't provide enough information to determine if that's the case.

To get proper indentation, post the code inside a BBCode CODE block. Just highlight the text in your post and click the button that looks like <>.

Also, you should remember that an OnActivate block blocks further activation... which includes dialogue.

If you want an OnActivate block to continue normal activation and produce dialogue on a creature (robot), then add an Activate call like so:

Begin OnActivate

    ;do a bunch of stuff

    Activate

End

That way, all the "do a bunch of stuff" code gets done, but it will continue with normal activation. This applies to all OnActivate blocks. They should include a call to Activate to allow for whatever their normal behavior would be if the OnActivate didn't exist if your intent is to allow that.

Should post your code Jezzy... it's likely not your call to that, but something else.

You could also be using NX_GetRandom.

It might be processing the line...

if iEquipped == 1 && Player.GetEquipped 01Swimsuit == 0

..as...

if iEquipped == 1 && Player.GetEquipped (01Swimsuit == 0)

...instead of...

if iEquipped == 1 && (Player.GetEquipped 01Swimsuit) == 0

...as you intended.

Although, why you'd not use OnUnequip is beyond me... seems a bit strange to mix your methodology.

NX Variables written to disk to persist information are located in Data\NVSE\Plugins\Extender\Saves.  These are CSV files (comma separated value). You can edit the file for your save or simply delete it... which will reset everything to default values.

Note: I'm still using a very old version of Sexout, so if changes have been made to the directory, I'll be off... but drilling down inside the NVSE directory inside the DATA directory should find the files.

Fairly sure that MenuMode 1007 is the game loading screen, i.e. the save game picking screen.  Now I could be wrong... but...my advice, when you detect MenuMode 1023 ( pip boy data screen), record the position of the character. When you no longer detect MenuMode 1023 (in a GameMode block that's alerted by a flag you set when you enter MenuMode 1023), check position again. If a significant move has occured, they fast traveled. Or use Odessa's suggestion, of GetParentCell.

TBH, a lot of ways of accomplishing this.

Um, feel free to include SmallerTalk in this compilation. You have my permission.

Yeah I'm recovering pretty well. The meds are sometimes worse than the symptoms, but what're ya gonna do right?

Hey everyone, been away from Fallout modding a while now... in fact, all modding pretty much, though I still log into SL.

I stopped modding because my health declined, as a few people knew. Last year I had another heart attack... and this year, in April, I suffered a minor stroke. So... yeah... RL has not been pleasant lately.

Hope Sexout is progressing well. Glad to see Odessa ran with Sexout Positioning. I'm still around and can help with advice or handle questions regarding my mods. Thought for sure you'd have gotten past my skeleton by now.

Asty

I've always followed a simple rule, and YES, it's because when I started programming we were still storing everything on magnetic tape or punch cards, but that rule is a good one to follow:

Explicit is always preferred to implicit.

Implicit code was created to promote elegance NOT functionality. IMO, elegance is vastly overrated... it's elegance that confuses people who are inexperienced.

When you write code like...

MoveTo PlayerREF

...vs. code that says:

ref rSelf

set rSelf to GetSelf

rSelf.MoveTo PlayerREF

...you run into various problems which aren't obvious at a glance.

The first example is relying on implicit compiler/interpreter behavior. If that behavior changes, the code runs differently.

The first example depends on the programmer understanding that implicit compiler/interpreter behavior to understand the code itself.

The first example is NOT self-documenting and thus is harder to debug at first glance.

I can tell you from experience, and I mean 30+ years of it, IMPLICIT bugs are the hardest bugs to find, especially if they're the result of implicit compiler/interpreter behavior changing. EXPLICIT code is self-documenting... the above second example is very clear as to what it does, the code itself documents what it's doing. It is easier to find bugs in explicit code, usually at first glance.

And... I'm preaching at this point, so I'll stop... besides, you get the idea...

EDIT: Or... I coulda "liked" Pride's posts... meh.

Hmmm try this re-up of Ahztek's weapon pack maybe?

SmallerTalk is also tied directly to the "activate" control. AKA the "talk option". As for issues with SmallTalk, see the OP

I will look into some way to make it work with controllers properly. I can't test it though... I'm one of those people who believes consoles are "THE EVIL".

...

Astymma, I assume you would check on key press (E) and the crosshair ref, and if it's actor and if it can really talk etc.etc. in a quest script with something like 0.01 script delay. I say an OnActivate Event Handler which triggers when you actually activate the ref seems more reliable.

Actually, what my testing showed in writing SmallerTalk, was that using OnActivate, and it would need to be a generic OnActivate, without restrictions, is that OnActivate is LESS reliable.The one main reason I moved away from an OnActivate block is the silly behavior in the engine to always force a player to rise from a sitting position to a standing position if they activate anything that has an override of its default activation. I noticed it because I was testing Cass, and I'd sit down next to her at the bar and I kept standing up when I'd initiate conversation. My OnActivate handler was doing it.

TBH what you suggested is simply handled by this:

SCN WhatWasLastActivated

ref refLastActivated

Begin GameMode

    If IsControlPressed 5

        set refLastActivated to GetCrosshairRef

    Endif

End; GameMode

After all, we don't care what was last activated, since we're checking in a dialog script, it HAS to be the actor we want. Who cares if they activated a chair, a door, their ammo crate and THEN the actor? The refLastActor will simply have the ref of what they last activated. We don't even need to care IF they're an actor, IF they can talk, any of that. When we need the value, we know what it's gonna be... the other person in conversation with the player. I don't see how OnActivate would be more reliable in this situation.

But... this doesn't help NX make calls like Pride would need... it would still need a local var declared to set it equal to this quest variable we're constantly updating before the NX call could use the value since NX isn't currently working with quest.questvar syntax. Then again, it sure as hell doesn't hurt to talk these problems out like this one bit. Everyone benefits.

you know what, for SO you could make it easier. When you talk with someone, you "could" need to start sex. So why don't just put an event OnActivate that stores the destinatary of your speech, always, on a quest.var, everytime you start a dialogue. Then, if you won't have sex, no matter, that ref will be overwritten next time you speak with someone else

Which is pretty much exactly what SmallerTalk used to do before being rewritten.

You don't want to do it in OnActivate, far too susceptible to problems. It's simpler, and more stable, to check for the keypress for activate and record the ref of whatever the GetCrosshairRef return value is. That way you never stomp on other OnActivates or on the default activate.

Of course this still doesn't help the situation, as you'd have to declare a local to put the value in to send it via NX since it's not accepting quest.questvar syntax.

Well, I see no problems with leveraging the bad behavior of the engine to stomp on actor's vars in their script. Normally I preach to NEVER rely on engine behavior because it might change. In this case, I think we all know that Fallout New Vegas has been "finalized" hehe. But you're right, not a real solution. Be a funny plugin though... SexoutKludge.esp... adding a ref var to every actor in the game

Hmm, if it's a true alias... then I'm misremembering using it... not the first time

Yup, checked the nvse.log, it's a pure alias. Odd.. oh well.

Hmm, if everything worked for you and not for Pride, maybe it's the speaker of the dialog. Er... or target... whichever runon is set to.

The answer to both of your questions is the same. Test it yourself.

Keep adding mods until you have problems. If you then remove a mod and it fixes it, you know where your plugin limit is.

Try both iNumHWThreads settings and see which works best for you.

Heh I know it wouldn't compile, I was saying if "this" wasn't a keyword alias for getself, the code for "this" would be what you quoted.

Technically it's more than an alias for getself. It's variable declaration and initialization in one, vs getself being only initialization, you need to declare your own variable. However, I'm sure it has all the weaknesses of getself. My thought was that if getself is returning 0, this will be 0 as well.

To be more clear... using getself you need to do something like...

ref rSelf

set rSelf to getself

rSelf.FunctionCall

When using this, you can simply do the following (the getself call is implicit)

this.FunctionCall

Although I would definitely add...

if this

    this.FunctionCall

endif

I take it that the real goal here is to uniquely identify a call to Sexout EVEN if it comes from a script fragment?

Couldn't the implementation of "call" include an internal hash generator that's modindex based?

Does the "this" keyword store a 0 in a script fragment?

I mean it's basically shorthand for:

ref this

set this to getself

Hmm maybe if I'd actually read your post closely I would have noticed it HAD worked with a quest var hehe

What about:

ref self

set quest.questvar to getself

set self to 0

set self to quest.questvar

;NX call to NX_SetEVFo "blah" self

Hideously ugly...

I think getself executed in a script fragment is attempting to reference the script fragment itself.

Also, according to the geck:

GetSelf will return 0 if called on a reference that has been created dynamically (for example, created via PlaceAtMe, or dropped from an inventory into the game world).