SexoutHookups

[jaam]

ANd a new version is up!!

This has major changes in how it's built up' date=' but you dear player will not notice too much differnce yet... You get new pickup lines, you get threesomes, but you don't get a stable script...

 

DEAR SCRIPTERS: Please have a look at the scripts! Tell me where I fucked up...

- NPC's don't always start conversation (about 1 in 10 does)

- If they start a conversation it will take many seconds with them just standing there (or following you if you move) looking at you.

[/quote']

 

SexoutHookupEffect has no duration. So it most likely ends right after adding the walkAI package. Unlesss the NPC is close enough to start the conversation right away the second time the scanner picks him.

Loogie had the exact same issue in WorkingGirl

I will try your plugin now to confirm.

 

Edit: before I forget, you need a c in "This looks like a good plae for some fun!"

 

 

[jaam]

OK. I got picked up by Sunny while being far more than 150 units away, so adding the duration seems to work.

 

By the way:

 

Both FF vaginal choices are identical. I suppose one should be "I want to lick your pussy"

Also in FF, the HUAFemaleDrink references "a guy".

[jaam]

Here is my current implementation:

 

I broke down the scan filter due to feedback from other plugin.

I filtered out MM as there are no sex choices for that.

I allowed back FM and FF though.

I also allowed back teammates.

 

I merged my change for integrating tryout plugins:

It takes the new ones into account.

It is done in the quest script rather than in the package.

It checks wether the tryout plugin is effectivly loaded.

MCM menu modified accordingly

 

note: Whoring is not OK yet as it only checks for Prostitute outfits at the moment. I don't know how to reference a buildref quest variable into a script. Maybe prideslayer can help.

 

I did not play test completly the last modification to the filter (exclude MM include FF FM) as I don't have any more women in Goodsprings except Trixy. But at least no Powder ganger asked my male character.

 

[attachment=4915]

[Bromm83]

Here is my current implementation:

 

I broke down the scan filter due to feedback from other plugin.

I filtered out MM as there are no sex choices for that.

I allowed back FM and FF though.

I also allowed back teammates.

 

I merged my change for integrating tryout plugins:

It takes the new ones into account.

It is done in the quest script rather than in the package.

It checks wether the tryout plugin is effectivly loaded.

MCM menu modified accordingly

 

note: Whoring is not OK yet as it only checks for Prostitute outfits at the moment. I don't know how to reference a buildref quest variable into a script. Maybe prideslayer can help.

 

I did not play test completly the last modification to the filter (exclude MM include FF FM) as I don't have any more women in Goodsprings except Trixy. But at least no Powder ganger asked my male character.

 

 

You are my hero! =)

 

Well the scripts you fixed for tryuts were all made by me also, so having the same problems really isn't a surprise I'll post your version as the current one, then I'll have a look at the scripts tomorrow and try to learn something =)

 

[prideslayer]

note: Whoring is not OK yet as it only checks for Prostitute outfits at the moment. I don't know how to reference a buildref quest variable into a script. Maybe prideslayer can help.

 

 

I thought I saw a bat signal..

 

I'm not exactly sure what you mean though; are you trying to access the quest variables in another mod? If so..

 

int idx
ref someOtherQuest

begin GameMode
 if GameLoaded || GameRestarted
   if IsModLoaded "other mod.esp"
     set idx to GetModIndex "other mod.esp"
     set someOtherQuest to buildref idx 
   else
     set someOtherQuest to 0
   endif
 endif
end

 

From then on, you can use someOtherQuest.stuff as if it were a quest defined in your own mod.

 

To get the ID, find the quest in the object viewer, expand the quest ID column, and convert the last 6 digits from base-16 to base-10.

[prideslayer]

Er sorry you can't use it JUST like another quest.

 

You can use it normally in the script where it's defined, say thats "MainQuest". In another script, where someOtherQuest isn't available directly, you need another ref ID to copy it into:

 

ref someOtherQuest
...
set someOtherQuest to MainQuest.someOtherQuest
...
someOtherQuest.

 

This is because you can't do MainQuest.someOtherQuest.stuff -- gecks "objects" don't support multiple reference levels.

[astymma]

Er sorry you can't use it JUST like another quest.

 

You can use it normally in the script where it's defined' date=' say thats "MainQuest". In another script, where someOtherQuest isn't available directly, you need another ref ID to copy it into:

 

ref someOtherQuest
...
set someOtherQuest to MainQuest.someOtherQuest
...
someOtherQuest.

 

This is because you can't do MainQuest.someOtherQuest.stuff -- gecks "objects" don't support multiple reference levels.

[/quote']

 

If you're going to use this over and over in your mod, I'd suggest setting a global integer with a meaningful identifier so you can change it in one spot and it will make more sense in your code.

 

buildref idx 1456

versus

buildref idx SomeOtherQuestIdentifier

 

What do ya think?

 

[jaam]

Er sorry you can't use it JUST like another quest.

 

You can use it normally in the script where it's defined' date=' say thats "MainQuest". In another script, where someOtherQuest isn't available directly, you need another ref ID to copy it into:

 

ref someOtherQuest
...
set someOtherQuest to MainQuest.someOtherQuest
...
someOtherQuest.

 

This is because you can't do MainQuest.someOtherQuest.stuff -- gecks "objects" don't support multiple reference levels.

[/quote']

 

Where I am stuck is when I type:

if someOtherQuest.whoremode
...

the Geck refuses to compile that, saying whoremode is not a valid function.

 

Well I could ask Loogie to change it to a global

 

[astymma]

Er sorry you can't use it JUST like another quest.

 

You can use it normally in the script where it's defined' date=' say thats "MainQuest". In another script, where someOtherQuest isn't available directly, you need another ref ID to copy it into:

 

ref someOtherQuest
...
set someOtherQuest to MainQuest.someOtherQuest
...
someOtherQuest.

 

This is because you can't do MainQuest.someOtherQuest.stuff -- gecks "objects" don't support multiple reference levels.

[/quote']

 

Where I am stuck is when I type:

if someOtherQuest.whoremode
...

the Geck refuses to compile that, saying whoremode is not a valid function.

 

Well I could ask Loogie to change it to a global

 

You should probably surround usages of that syntax after a buildref with blocks like so:

 

if 1 == someOtherQuest.IsFormValid
   ;valid reference, keep going
   if someOtherQuest.whoremode
       ...
   endif
else
   ;invalid reference, show an error    
endif

 

or

 

if 1 == someOtherQuest.IsReference
   ;valid reference, keep going
   if someOtherQuest.whoremode
       ...
   endif
else
   ;invalid reference, show an error    
endif

 

or both...

 

[jaam]

You should probably surround usages of that syntax after a buildref with blocks like so:

 

if 1 == someOtherQuest.IsFormValid
   ;valid reference, keep going
   if someOtherQuest.whoremode
       ...
   endif
else
   ;invalid reference, show an error    
endif

 

or

 

if 1 == someOtherQuest.IsReference
   ;valid reference, keep going
   if someOtherQuest.whoremode
       ...
   endif
else
   ;invalid reference, show an error    
endif

 

or both...

 

 

The form is walid, it's just that the geck cannot interpret it a quest, so it does not understand the syntax.

[jaam]

Updated version which takes NPC sexual orientation into account (when its specified). See SexualOrientationExpress to initialize the lists.

 

I also corrected some test in the scan filter.

 

Known issue: EDE tried to pick me up, though creature are the first exclusion in the filter

 

[attachment=4961]

[prideslayer]

hmmmmm...

 

Truth is, I hadn't actually tried this with a quest before, just figured that "it should work". I do it with items and it works OK.

 

First order of business for testing then is to just assign a ref to your own quest, and see if you can use it that way or not, without the buildref involved.

 

set ref = myQuest
ref.something

 

If that doesn't work... looks like the battleship is sunk for doing this with quests, which is a major disappointment.

 

 

[prideslayer]

 

If you're going to use this over and over in your mod' date=' I'd suggest setting a global integer with a meaningful identifier so you can change it in one spot and it will make more sense in your code.

 

buildref idx 1456

versus

buildref idx SomeOtherQuestIdentifier

 

What do ya think?

 

[/quote']

 

That would be fine, but generally I do not call buildref repeatedly. Not sure if it has any performance penalties or not. e.g. in Sexout.esm if the user has selected breezes, i set the sexoutng.malebodyref (or whatever I called it) to the built ref of the breezes male body suit, otherwise i set it to sexoutNude (built in unisex bodysuit).

 

Then I just use that ref where I need it.

 

During a load I will check that breezes is present. If it's not and the bodysuit is set to that, it reverts back to the built in one and resets the setting in MCM.

 

 

[astymma]

 

If you're going to use this over and over in your mod' date=' I'd suggest setting a global integer with a meaningful identifier so you can change it in one spot and it will make more sense in your code.

 

buildref idx 1456

versus

buildref idx SomeOtherQuestIdentifier

 

What do ya think?

 

[/quote']

 

That would be fine, but generally I do not call buildref repeatedly. Not sure if it has any performance penalties or not. e.g. in Sexout.esm if the user has selected breezes, i set the sexoutng.malebodyref (or whatever I called it) to the built ref of the breezes male body suit, otherwise i set it to sexoutNude (built in unisex bodysuit).

 

Then I just use that ref where I need it.

 

During a load I will check that breezes is present. If it's not and the bodysuit is set to that, it reverts back to the built in one and resets the setting in MCM.

 

 

 

Oh, no... I wasn't talking about performance penalties at all. I was just talking from the point of code re-use and maintenance. If the mod you're referencing changes a formid and you're using this technique in a bunch of scripts, changing one global in FNVEdit is a lot simpler than loading your file up in the GECK (and going through demastering/mastering if needed) and editing each script and recompiling them. The additional bonus of a meaningful identifier making your code more self-documenting is a bonus over using hard coded integer values.

 

[prideslayer]

If you are going to call buildref repeatedly in a bunch of different scripts then sure, I'd set the integer once globally somewhere. My point was I don't call buildref repeatedly with the same form ID -- I will only call it once and store the result globally (with a meaningful name).

[dizzyman]

Using jaam's alt version from the 16th with the latest smallertalk (in preparation for Tryouts). The option to accept an opproach without them following you somewhere seems to have gone. Just had Ralph from Mick & Ralphs following me after choosing "ok lets go find somewhere" but when I spoke to him again there was no sexout dialogue at all (or usable cigarettes), so I couldn't get him to stop following.

 

I don't know if it's a smallertalk issue.

 

Guess I'll try a version from before the 15th or play hard to get instead (would be nice if following was an option however an approach ended up accepted).

[jaam]

Using jaam's alt version from the 16th with the latest smallertalk (in preparation for Tryouts). The option to accept an opproach without them following you somewhere seems to have gone. Just had Ralph from Mick & Ralphs following me after choosing "ok lets go find somewhere" but when I spoke to him again there was no sexout dialogue at all (or usable cigarettes)' date=' so I couldn't get him to stop following.

 

I don't know if it's a smallertalk issue.

 

Guess I'll try a version from before the 15th or play hard to get instead (would be nice if following was an option however an approach ended up accepted).

[/quote']

 

Noticed that too and forgot to ask Bromm83 about it.

I just checked the plugin and the dialog topic has been removed in the Alt version.

 

Also, looks like the threesome code needs some work, due to the issue Prideslayer gave in another topic. The actors references should be stored into private variables on agreement to follow, not when starting the sex. I might have time to change it tomorow.

[dizzyman]

Had it happen again with another named NPC. Tried one of the vanilla dialogue options (can I ask you some questions), then returned to the initial dialogue list and the "this is a good place to do it" option was then available.

[astymma]

Had it happen again with another named NPC. Tried one of the vanilla dialogue options (can I ask you some questions)' date=' then returned to the initial dialogue list and the "this is a good place to do it" option was then available.

[/quote']

 

Those vanilla dialogue options are responses tied to a GREETING, the sexout plugins generally have their own top level topics that are NOT responses under GREETING. they assume the NPC can be spoken to to get past GREETING, hence the need for SmallerTalk to exist (to provide a bypass for those NPC's who do not have a GREETING or have only goodbye flagged responses to GREETING which terminate dialogue). When you lead someone to a new location and then talk to them again, you start the process all over again. SexoutSex/Howabout/etc. should be placing the "ok this place is fine" type of dialogue AS a response under GREETING so it appears in the topic list (but check some flag variable given/assigned to them when they initiated the follow to make sure it's step 2 of the process). They should NOT be using non-GREETING responses for step 2, only step 1. If they use that approach for step 2, you'll get the result you got, i.e. you have to go through an initial dialogue option first and then it will appear. But if you hand the NPC a token when they are asked to follow, you can check for the presence of the token in a GREETING response and it will display on GREETING without having to go through a vanilla dialogue first.

 

 

[astymma]

I know the above sounds backwards and counter-intuitive but here's how it works:

 

You and your buddy, SmallerTalk, go to meet Betty.

SmallerTalk knows Betty, you don't.

SmallerTalk introduces you to Betty, Betty says Hi, then you get to speak.

You say hey, follow me, Betty.

 

You go to a quiet place with Betty.

Since you've already been introduced by SmallerTalk to Betty, you need no more introductions, you just say "This place will do."

You begin having some interesting amusements with Betty.

 

It looks like to me that the sex mods are assuming that you need to be introduced both times by SmallerTalk before you can speak to them... just the first time is true.

[prideslayer]

I think that's actually just an artifact of how they were coded to work with smalltalk. Since it just removed all the goodbyes, you can stick your stuff anywhere with it, as long as it's top level.

 

I agree the intro ones *should* be in greeting, and they must already be checking a flag for step 2, so that wouldn't have to be added.

[Bromm83]

SexoutSex looks for the script package SexoutSEFollowPlayer to open a dialogue after following. This so that I don't have to add yet another item. Shouldn't that work just as well as a token?

 

Sexout Hookups also use a package, but for threesomes it uses a script variable.

 

 

Should I change it so that these mods use tokens in stead?

[prideslayer]

Ohhh hmm. That depends. Script packages will work unless the package has completed, or EVP has been called on the actor. I think a script variable is the safest. You can use a ref and set it equal to the actor, and check for that in the dialog conditions.

 

I only use items for stuff so much in sexout because the sexout variables get overwritten all the time and I need something persistent.

[Bromm83]

also a big thanks to all of you who have been tinkering on this the last week or so. I have been unable to actually do something with it because of work.

 

I have started on next update. Will be improvement (Unless I just brek it... we will see!) to the threesome selection and storing of variables locally so that sexoutNG.ActorABC will only be set in same dialogue as SexoutBegin is cast.

[Bromm83]

Ohhh hmm. That depends. Script packages will work unless the package has completed' date=' or EVP has been called on the actor. I think a script variable is the safest. You can use a ref and set it equal to the actor, and check for that in the dialog conditions.

 

I only use items for stuff so much in sexout because the sexout variables get overwritten all the time and I need something persistent.

[/quote']

 

That wasn't a bad idea..

I'll look into it.

Will put it in my next release (still a few days away, going to work now and won't have much computer time until tuesday).