Jump to content

Dialogue, sexLab animations, question


chajapa

Recommended Posts

I'm working on a dialogue mod and at the end of some of the threads, the final topic has a script to run a sexlab animation appropriate to the conversation that preceded it.

 

This works great.

 

I had an idea though, where I'd need to have a topic that runs a sexlab animation, and then instead of that being the end of the topic thread, the conversation continues and then runs another animation.

 

Something like this:

 

TopicA:

Me: I'd really like to do THIS to you.

NPC: OK, that sounds fun.

 

Run animation with Me in position 1 and NPC in position 2

 

This topic links to TopicB.

 

TopicB:

Me: Wow.. that was awesome.

NPC: Oh, yes. Now it's my turn to do it to you.

 

Run animation with Me in position 2 and NPC in position 1

 

This topic links to TopicC

 

TopicC:

Me: We have to do this again some time.

NPC: Soon...

 

This would be a "goodbye" Topic and end the conversation.

 

Would this work? Or does running an animation exit us from dialogue?

 

Link to comment

If you want to avoid scenes and AI packages for now, you can set it the following way:

 

  1. Have your original dialogue branch as it is now.
  2. Along with the script code that starts the SexLab animation, have it set a script variable or global from 0 to 1.
  3. Make a new dialogue branch, of type Blocking, that has the aforementioned variable == 1, as one of the conditions. This is the branch that will handle your "after the first sex scene" conversation.
  4. When you're done with the blocking dialogue branch, set the variable back to 0 so the NPC will default back to their normal dialogue.

 

Note that you'll still need to talk to the NPC after the first animation, to kickstart the blocking dialogue. If you want the NPC to do this automatically, you'll need to use a ForceGreet AI package in addition to the blocking dialogue branch.

Link to comment

WraithSlayer,

 

I appreciate your help very much, but please understand just how much of a n00b I am at this. While I'm sure this is simple for some, even your instruction to "set a script variable or global from 0 to 1" is something I don't know how to do. :)

 

I keep asking questions and, thankfully, I get help and answers. So I'm adding to my knowledge, but...

 

Could I ask you to explain how to do this setting of a script variable? 

 

If I have a script fragment that starts the animation and go to "edit source" of the script fragment, I'm assuming I'd put that instruction to set the variable outside of the fragment code much the same as when I add the sexlab property line? Or would I put the instruction to set the variable in the fragment box with the code to start the animation?

 

and.... (I TOLD you I'm a n00b)... what does that instruction look like? Do I have to declare the variable's existence before trying to set it?

Or is this as simple as putting in a line like:

GoToBlockingDialogue = 1

 

The more I learn, the better my (little and very simple) mods are turning out, but.... I am sorely new to this.

Link to comment

If you're not comfortable with using variables from scripts in conditions, you can simply define a new Global Variable in the CK to handle the same functionality. You can use the condition GetGlobalValue in your dialogue conditions to decide whether it should be displayed, and you can use the SetValue() function in your scripts to toggle it on and off (0 or 1). This is essentially all you need to control the blocking dialogue I described earlier.

 

On the other hand, if you're curious about script variables and want to use those instead of Globals:

The only bad thing about Globals is that they overcrowd your ESP, since they need a unique form ID. To avoid using globals, you can instead make use of Property variables already defined in your quest scripts. Instead of using GetGlobalValue in your dialogue conditions, you use GetVMQuestVariable. However, unlike Globals, script properties are not usually visible to your dialogue conditions, so there's an extra step you need to take. Go to your script that houses the variable you want to use, and add the following bits I've outlined in red:

 

 

Scriptname YOUR_SCRIPT_NAME extends Quest Conditional

Int Property THE_SCRIPT_VARIABLE  Auto  Conditional

 

Essentially, when both the script definition and the property definition have the Conditional flag, and you've compiled the script after these changes, the property will then become a valid target for your GetVMQuestVariable conditions. At this point, you can manage the value of THE_SCRIPT_VARIABLE at your own leisure in any script that contains a reference to this property, as simply as THE_SCRIPT_VARIABLE = 1.

 

If you need any further help, you need only ask. :)

Link to comment

How persistent is a script variable?

 

 

Depends. In most cases they may as well be permanent.

 

You can only define a property as Conditional if the script you're on is of type Quest (or extends Quest), and these scripts are always associated a quest form in the CK. As long as you don't reset the quest, those variables will keep whatever values you set them to, indefinitely.

 

 

 

I mean, if I use this in a script fragment for a dialogue topic, does that variable stay set until I change it? Even after that script fragment has fired for the topic?

 

Yes. It doesn't matter if your Topic Info script dies, your variable isn't even stored there. (it's stored in a script of type Quest, as mentioned above) Any modifications you do to the variable from your Topic Info script are maintained as long as the Quest script that houses the Conditional var stays alive.

 

I've made a step-by-step summary on how to use Conditional script vars, if you still need guidance:

 

http://i.imgur.com/TJrqnOF.png

 

http://i.imgur.com/NkVuOtl.png

Link to comment

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use