prideslayer

Further information. This is linked to from the main wiki page: http://git.loverslab.com/prideslayer/sexout/wikis/cbdialog I updated it after the last round of fixes, it explains in more detail what is going on.

I would really really really recommend you avoid doing anything like that. Use FinishNow, wait for the actor to return 0 to InUse, and then start the dialog. There is more than just the NX vars to clean up, and even if I gave you an exhaustive list of everything right now, it could change without warning in a future release.

You wanted to ask people looking for help "is there any ideas on making SexoutNG more lore-friendly?" I don't know what you're trying to say, or whom you're trying to say it to, but this is the support thread for the SexoutNG Mod (sexout.esm). Posts here should be: - Announcements about SexoutNG (core and data). - Requests for help with SexoutNG (core or data). - Questions about SexoutNG (core or data). - Replies to those items. If you have a question or concern about a particular mod, you should go to the thread for that mod. If you have a question or concern in general, that isn't tech support, just start a new thread.

Those mods are all written by individual authors, none of whom are me. If you have problems with a specific sexout mod not being lore friendly, read the thread for that mod, and contact the author about it. Read first because they might say outright that they aren't concerned with lore.

You've oversimplified a bit. There's one case relating to dialog that is problematic; Your scene supplies a CBDialog, and the dialog leads (potentially) to another scene initiated by the dialog result script. This is just a "you should not do" situation, not an "it won't work" situation. In fact, it should work fine at present, but I can't guarantee it -- not as reliably as I can "guarantee" everything else. All in all, with the latest updates, you should be fine. If you DO experience trouble with sexout doing "weird things" in your scene, and you're using CBDialog in a sec act to start a conversation that might end with MOAR SEX from a dialog result script -- and you run into problems -- it's best if you try to rework it to eliminate EITHER the CBDialog OR the sex starting from the dialog result script. Either alone is fine, it's just together that they can be problematic.

I'm more or less with you here, but as was stated, Sexout itself doesn't impact lore one way or the other. A big problem with "lore" is everyone who is hung up on it assumes that everything they read in game that isn't 3rd party narration, and everything another NPC (or book, terminal, etc) ever says to them, is the gospel truth. As my avatar said, "everybody lies."

Well no, because it doesn't keep adding it and removing it and doing all that crazy stuff. It just adds it once and it won't change unless a script adds one of its own, or the conditions specified in the geck change. It's similar, but more reliable and simpler.

Well there is a difference with using the geck vs not; AddScriptPackage only works for one package at a time, so if you call it with PackA and a few seconds later with PackB, PackB will replace PackA -- it won't coexist alongside it, like packages added in the GECK do. As this is a custom NPC (right?) it's probably smarter to add the package in the geck, as the top package, and put a condition on it checking a quest variable.

Possibly, jaam has been a busy little bee lately.

Well, I still think this sounds very overcomplicated for what you're trying to do. Other companions and lots of other mods do similar things without so many problems or such "crazy" ways if fighting back against those problems. I think there is a mistake (or incorrect assumption) somewhere in here that is screwing everything else up, but the only way I can think to find it is to "start over" with the packages and take it slow and simple. This may sound harsh, but that "double check the package" is gibberish. There's no way it's going to have any effect, it's impossible for that value to change right there between those lines unless you've done something really foolish like install one of those script engine multi-threading mods/tweaks. By default, NV only uses one thread for all script processing, and it's that way for a reason.

If you really want to use the packages like this, I would do as already suggested, basicaly: 1. Create a travelpackage. In the package done script, set stage to 2. 2. Create a dialogepackage. In the package done script, set stage to 3. The main script (with a much less aggressive script delay! Call it 0.5s or even 1.0s): 1. If stage 0, do nothing. 2. If stage 1, check the current package. If it's not the travel package, remove it, add travel. 3. If stage 2, check the current package. If not dialog package, remove it, add dialog. 4. If stage 3, do your post-dialog whatever, set stage back to zero. To start everything in motion, all you need to do is set the stage to 1. The script will then handle adding the travel package and everything from then on is automatic. You need to ensure that you only set the stage to 1 when it's 0. No "fast" script, no looking at the AI procedure or any of that. Test it this way and make sure it works most of the time, if not all the time, and if it fails.. report back in.

Just stabbing in the dark but about that first check again, running a dialogue package the procedure could be any of: 0 - Travel 3 - Wait 4 - Dialogue 11 - Follow 19 - Travel to target 27 - Accompany 43 - Dialog activate 49 - Movement blocked And probably some others as well. Again this whole system just seems vastly overcomplicated for what you're trying to do. Personally, I would abandon this approach and rethink it, simplify.

I didn't understand what you meant before, and what you've mentioned so far seems overly complicated; I was under the impression that you have removed all of this and "started over" testing with a simplified approach. If you want me to take a look anyway.. If this is just working from memory but not an actual copy/paste then some of this may be incorrect if you remembered incorrectly, that definitely makes things more difficult. I added line #s for reference and indented for easier reading. 1. Line 6 should have a "LunetteRef.GetType" shouldn't it? Is this just you remembering wrong, or is this script running on a different reference? nevermind. 2. The check on line 1 does not make much sense to me, what's the purpose? You're removing the entire package if the current procedure (a package can have more than one procedure) is not a dialog activation. That means you're removing the package if it's running a travel procedure (to get close enough to the target) to start the conversation. There also will probably be a wait procedure between the travel and dialog, if the target is busy. Overall this chunk (lines 1 - 4) seems like a bad idea. 3. The first half of line 6 makes no sense. If "ConversationPackage" is a package, then that first check is always going to be true. This means that whole line is really just:   06: if LunetteRef.isFollowing ==107: LunetteRef.addscriptpackage ConversationPackage08: return09: endifIs that really what you want to do? Keep adding the package over and over if the actor is following? Then you remove it again in the next run (0.05s later or whatever?) if the procedure isn't dialog (e.g. travel, wait, etc) within that package?

Woah... This... Is not at all reliable in my experience. There is no guarantee that the dialog/menumode is going to start immediately upon executing that line. Any number of things could delay it, from distance to the NPC, to general lag on the players computer at just the wrong moment. There is also no guarantee that the script will pick up on the line where it left off -- this almost never happens in fact. Usually it starts over from the top. Since these things aren't guaranteed, what I do when writing scripts like this, is not just assume the "bad thing" is going to happen -- but force it to happen every time. I am almost 100% certain that is what is to blame here -- assuming that it picks up where it left off, when that is not always the case. Add that super-hyper-fast repeat rate and it's a recipe for disaster. Try something like this (gamemode). if (0 < fDelay) ; delay and return set fDelay to fDelay - GetSecondsPassed returnendifif (0 == stage) ; placeholder, not doing anything, you may not need.elseif (1 == stage) ; Adding package, waiting on dialog to clear the flag set fDelay to 0.5 NPCRef.Addscriptpackage MyDialogueelseif (2 == stage) ; The dialog could have set it to this, or to 0, or whatever.endifThat is just a basic structure but I hope you get the idea.

Ok first, to be honest, I've never had the problems you're describing. Unless there are errors in the script itself, I've never had a "one time" script fail to run, no matter how complex, and no matter how many of them I have. I think if you've experienced that, you probably have bugs in your scripts also. That said, your problem then is moving this out of the dialog result script means now you don't have anywhere good to put it, because you don't know if the dialog took place or not? Welcome to hell! I suggest you just set ONE var there, it can be a quest var, an NX var, whatever, and do nothing else. There is no way that is going to be unreliable. If anything screws you up but the dialog has happened successfully, it's going to be because either: 1. You made a typo or something in the result script. 2. Some other script RESET your variable back to its default value, so it only looks like it didn't run. You can watch for either of these by putting a DebugPrint inside the dialog script in question, before and after setting the variable. DebugPrint "Setting..."set somequest.somevar to 1DebugPrint "Set."Keep in mind that if you change the order of the variables in your quest, you need to recompile every script referencing those variables, including dialog result scripts. So "don't do that." Once you've put a variable in a quest and started using it elsewhere, you must never add or remove any variables that come before it.

I'm basically lost, having trouble understanding really what the problem is. If as AJ said it is really this simple I don't see the problem? You said you're worried about something crashing, and maybe the dialog result script not running? Why not use the script in the package end instead then? Regardless the answer is not to just keep reducing the script delay, that isn't reliable.. it'll make slow/struggling computers slower, and won't fix the issues on fast ones.

The skills stuff in sexout is always empty. The counters should go up I think but I'm not sure. The rest of that is leftover from old versions of sexout and is just there for other mods to use if they want to. You'll have to check in with amra about that, make sure you've installed the right bodies over there. Test without it and make sure alignment is good -- if it is, then it's not Sexout that is misaligned. If it is, note down the anim #s and make sure you test on a solid flat surface away from any obstructions.

Why don't you just ensure the package is 'must complete' and so on, and don't spam it so often. Just have gamemode look to see if that package is active on the actor or not -- if it's not, add it again. Keep doing that (once a second or so is enough) until the dialog occurs and sets the flag to stop it. There's no need for menumode at all here.

I sent loogie a fix for that a while back, maybe it got lost, or maybe the print message is just wrong. It did used to simply be a '<=' check, so 0 matched against 0 (so 1/100 chance since the range is 0-99). I changed that to a simple '<' but I'm not sure if that made it into the release or not.

There is no 'after sex' KO setting, only after rape. If they're disabled, actors are knocked down for 2 seconds regardless of rape or consensual sex -- which is the same as the consensual time. There are no problems with other mods and the knockdown that I'm aware of. It's done simply via damage to fatigue.

If you don't want it executing twice, in stage 1, set it to 2 or some other value so the script doesn't do anything. Then later on if you need it to run again, set it back to 1 (or 0, or whatever).

The quest variables are a problem if you have two spells (or any kind of scripts) running at the same time that both need it. If the spell is on npcA and npcB and both need to use the quest variable, how do you make sure they don't interfere with each other? NX vars (the NX_Set* and NX_Get* functions) were created to solve this problem.

I settled on evp (which DID work contrary to what I said in that post), but it only worked on the npc. Just for information's sake. I don't know what I'm going to do for the player yet. I added the WakeUpPC call but haven't tested it, and I don't think it's going to work where it is -- since the script only runs in gamemode, and if you're sleeping, you're in menumode. I can probably just safely ignore both states (sleeping, sitting) for the player. I have up until now with no problems.

The effect can be set with a duration of all 9's which will make it last several decades or something like that. This is how all the sexout effects work, more or less. They also tend to use gamemode blocks rather than scripteffectsrart/scripteffectupdate. When they are done running, they dispel themselves. Every spell can have multiple effects (you'll see this in the GECK). Every effect can have a script. You can put as much stuff as you want in each script. I prefer using one effect with one script, and letting the script do a lot of different things, because there's not an "easy" way for multiple scripts to communicate with each other -- at least there isn't without NX variables.

IsIdlePlaying you mean? That will return 1 if they're playing a special idle. I used to use that in sexout but stopped because it still meant that there were 'gaps' where the actors were standing. There had to be, in order for that to return false and trigger me to call playidle again. So instead I just took the hard road and made sure every animation had correct looping enabled, and was set to loop in the geck. I missed one but it's fixed in the beta. Now I can be sure that the animation keeps playing until I stop it, without having to keep checking that it didn't stop on its own. I emphasized special idle because it does not return 1 if they're playing some other kind of animation. You can also test/check GetAnimAction. I don't know what you're doing so I don't know if checking like this is enough. It's no good for sexout.