Jump to content

The Sexoutng Api (How-To For Modders)


Recommended Posts

It should be reliable, exceptthat inuse can't distinguish between your act being finished and some other one. If that actor gets used again by another act in between your calls, you'll wait in the black until that act is finished. This could repeat indefinitely.

 

So it would be best if you just used a callback for both acts. The first one would start the fade to black, the second one would end it, no need for FinishNow or checking inuse.

Link to comment
Guest tomm434

Thanks but..

 

 

If that actor gets used again by another act in between your calls

How might that happen? Can that happen if my actors are having sex in my cell?

Link to comment

Thanks but..

 

If that actor gets used again by another act in between your calls

How might that happen? Can that happen if my actors are having sex in my cell?

 

They aren't "your" actors. Something like brutalrapers or tryouts approaches (just for example) could find them with the scanner and put them to work.

Link to comment
Guest tomm434

Well then what's the point in having them unlocked only of mine's code? I need them to be free of Sexout before I disable them and next time I enable them.

 

And thanks for the tip - I'll tell users to disable such mods because they will interrupt with cutscenes for sure.

Link to comment

I don't know what you mean by "unlocked only of mine's code"?

 

You should always check InUse before actually making a call to start sex, so your mod doesn't get actor in use errors, but that's not what you're talking about here -- you're talking about using it as a trigger to end a different scene.

 

You should just let both scenes end naturally and then enter your "loop" checking InUse on the actors and starting the next scene when they're available. Otherwise it might happen that the player ends up stuck in the fadetoblack forever -- unlikely, but possible, and I've learned to account for as many unlikely things as possible because someone will find the error, somehow. ;)

Link to comment
Guest tomm434

Got it. But the thing is -there is no real difference between getting stuck in fadetoblack scene and not being able to replay the scene again. In both cases player is screwed. BUT like you said I can check in use and cios SexoutNGFInish spell on them on next scene start. But that's tricky because they are disabled between scenes  which means I need to enable them. cios a spell, then check again and only then start a scene(more scripting :dodgy: ).

 

The only mod I fear is SexoutRapers because Tryouts do stuff only with NPC that are in particular factions I think.

Link to comment
Guest tomm434

Damn. I think I will make ingame warning with "IfGetmodLoaded" condition. Thanks. Any other Sexout mod I should be aware of? I don't remember anything else. But I didn't even know that in hookups NPCs spoke to player by themselves - I remembered it to be another mod like "small talk" or "smallerTalk" where player has to initiate dialogue himself.

Link to comment

Well then what's the point in having them unlocked only of mine's code? I need them to be free of Sexout before I disable them and next time I enable them.

 

And thanks for the tip - I'll tell users to disable such mods because they will interrupt with cutscenes for sure.

 

This is a continuing problem in a mod setup that has mods like Sex Assault & Tryouts where actors approach actors for sex, while other mods may want to reserve any of those actors (eg approaching doesn't fit with their character or background) or reserve the scene (cutscenes, fadetoblacks). Saying people can't have the 'generic' mods installed at all is a bit overkill, we just need a way to sort it out.

 

Before, we thought of a few nx vars to signify these:

EVFL "SO:NotNow" ; boolean, on the playerref, claims the scene

EVFL "SO:Reserved" : boolean, actor is reserved

 

Of course, we do need to make sure the generic mods respect these. I think Sex Assault does, Lust does up to a point (Reserved) but I'll tighten that up more as I remove everything but the approaches. Tryouts?

 

I also had some thoughts about expanded use, where we build in some safety against mods setting these vars but not clearing them, or people uninstalling them:

 

 

We could also add an extra var detailing the mod name that does the reservation, might be handy for troubleshooting. My gut tells me adding to the evfl key ("SO:Reserved:MyModNameString.esp") might be best, that way multiple mods may pile on or back out without the reservation becoming orphaned. You could clear yours and then if ar_size of the stringmap that is returned by NX_GetEVFlAr "SO:Reserved" is only 1, you can clear the original "SO:Reserved" too.

Edit: having the full mod name there (with .esp) would also make it possible for a central mod like say NG to go over reserved actors, checking their reserved nx vars for the mods that set them, checking if those mods are loaded & removing the vars if they're not.

 

Link to comment

Got it. But the thing is -there is no real difference between getting stuck in fadetoblack scene and not being able to replay the scene again. In both cases player is screwed. BUT like you said I can check in use and cios SexoutNGFInish spell on them on next scene start. But that's tricky because they are disabled between scenes  which means I need to enable them. cios a spell, then check again and only then start a scene(more scripting :dodgy: ).

I think you're missing the thrust of what I'm saying. If you proceed as I suggest, then the player is not 'screwed'. Your mod will do the normal thing, proceed through the fade to black, and then continue as soon as it is able to. That will usually be right away, but could possibly take some time -- time that if spent in a fadetoblack may make the players think the game has crashed.

 

The only mod I fear is SexoutRapers because Tryouts do stuff only with NPC that are in particular factions I think.

That's true for tryouts, except for Prostitution. I don't remember the check that uses, maybe it's gamblers faction? They only approach if you're inside certain casinos though.

 

In any case I'm trying to.. help you see a bigger picture.

 

There are other mods out there. Some adjust faction membership. Some add new NPCs that are members of different factions. The player may even have companions with them that are members of one of those factions, and 100 other things. You cannot possibly account for every possibility.

 

So the best thing to do is to do the "right thing" WRT sexout. Check inuse before issuing the sexout call. Always. You can always just set a delay and try again a second later. This not only saves you from mod conflicts, it saves you from yourself -- if you don't do this and you call scenes rapidly, they'll fail, because the actors aren't finished standing up, getting dressed, etc.

 

Not doing the check inside a fadetoblack is just a convenience for the player so they don't panic.

Link to comment

 

Well then what's the point in having them unlocked only of mine's code? I need them to be free of Sexout before I disable them and next time I enable them.

 

And thanks for the tip - I'll tell users to disable such mods because they will interrupt with cutscenes for sure.

 

This is a continuing problem in a mod setup that has mods like Sex Assault & Tryouts where actors approach actors for sex, while other mods may want to reserve any of those actors (eg approaching doesn't fit with their character or background) or reserve the scene (cutscenes, fadetoblacks). Saying people can't have the 'generic' mods installed at all is a bit overkill, we just need a way to sort it out.

 

Before, we thought of a few nx vars to signify these:

EVFL "SO:NotNow" ; boolean, on the playerref, claims the scene

EVFL "SO:Reserved" : boolean, actor is reserved

 

Of course, we do need to make sure the generic mods respect these. I think Sex Assault does, Lust does up to a point (Reserved) but I'll tighten that up more as I remove everything but the approaches. Tryouts?

 

I also had some thoughts about expanded use, where we build on some safety against mods setting these vars but not clearing them, or people uninstalling them:

 

We could also add an extra var detailing the mod name that does the reservation, might be handy for troubleshooting. My gut tells me adding to the evfl key ("SO:Reserved:MyModNameString.esp") might be best, that way multiple mods may pile on or back out without the reservation becoming orphaned. You could clear yours and then if ar_size of the stringmap that is returned by NX_GetEVFlAr "SO:Reserved" is only 1, you can clear the original "SO:Reserved" too.

Edit: having the full mod name there (with .esp) would also make it possible for a central mod like say NG to go over reserved actors, checking their reserved nx vars for the mods that set them, checking if those mods are loaded & removing the vars if they're not.

 

I still need to think about this in more detail. My goal with a solution like this is probably unattainable but I'm going to burn some brain cells on it anyway. I want the system to 'work' *without* every mod having to be updated to support it, because that will never happen, just like all mods converting from the quest interface to NX has never happened.

 

The best I can think of right now is to let a mod reserve an actor, and then SAN error on all future calls on that actor that don't come from that mod. I would have to add additional sanity checking there WRT the mod name and index, to ensure that an actor isn't reserved indefinitely if a mod reserves them and then is disabled by the player.

 

A mod reserving an actor and then crashing is a problem as well. I've been putting a lot of effort into ensuring that one mod cannot "screw up" every other mod through a script crash or the mod getting disabled and I'd hate to circumvent all that effort intentionally.

Link to comment
Guest tomm434

Prideslayer, I have a "projector" feature in my mod. Player can choose a scene and it will play. I can't place a check just before sex because scene will stop. Fade to black scene is sort of transition between scene and normal gameplay.

 

This is what happens:

 

1) Scene starts

2) Scene ends with 2 actors fucking with each other

3) these actors are disabled

4) When player starts scene again these actors are enabled and placed before player

So if these actors were locked by Sexout just before disabling  - when they are enabled they do animation right away. So I have no choice but to make player wait wth Black Screen unless these actors are free of Sexout to make sure they don't do animation after being enabled again. Or I can skip black screen and not enable player controls untill actors are free. Is that what you meant?

Link to comment

I'd probably do as follows.

 

1. Fade to black.

2. Set actors restrained.

3. Start scene.

4. Fade back in.

5. Wait for scene to finish.

6. Fade back out.

7. Unrestrain and whatnot.

8. Fade back in.

 

The restrain will keep them from moving around or anything after the act (sexout preserves this setting, whatever it's value, during the act). You could additionally add a do nothing AI package to the actors so they don't even try to sandbox.

 

This will show them getting knocked down and dressed afterwards which is a minor visual 'break from character' that won't affect gameplay, and once the scene is working, you can address it by obscuring them with an effect or something. You could also clone the actors before the act, use the clones in the act, and delete them during the fade to black at the end. This would let you fade out and back in at the end without waiting for the act to finish.

Link to comment

What I was talking about with the nx vars is not just a hard lock on acts, but also on what leads up to it - stalking, dialog etc. To make different content mods play nice together.

 

A more central solution in ng would be preferable though. The nx vars are a matter of convention, & also can get stuck accidentally.

Link to comment
Guest tomm434

Prideslayer, These scenes happen in the gameplay cell(player can go there) so I can't do that. I even move all existing actors elsewhere, play scene, then move them again. That is my fault because I was lazy to copy the cell, delete all markers, do navmesg again..

 

But damn! Cloning idea is good. Now I realise that actors scripts will work on them even if they are created via placeatme (I use a lot of "begin OnSayToDone" and "begin OnPackageEnd" blocks.) So I think I will consider it. Is it safe to disable and markfordelete actors which are currently engaged in Sex?

 

 

 

What I was talking about with the nx vars is not just a hard lock on acts, but also on what leads up to it - stalking, dialog etc. To make different content mods play nice together.

 

A more central solution in ng would be preferable though. The nx vars are a matter of convention, & also can get stuck accidentally.

hm okay. An additional list will do. But then we have an issue when some mods will forget to delete actors from list, unset variable and whole game will be spoiled. Unless SexoutNG wil have a reset option.

Link to comment

Well I'm planning to get the queue system implemented before tooooo long and it should be able to address the issue as well, now that I think about it.

 

If during the act prep, you tell it to queue, it won't fail with any of the lock errors -- it will just automatically run the act as soon as it can. Only mods that set the flag will have their acts queued (I'm pretty settled on this now), so that means things that approach will fail if the actor is inuse as normal, but queued acts won't.

 

An approach act could still happen between acts that the modder expects to be sequential, but their act would still succeed after the approach act(*) is done without them having to check inuse etc.

 

(*)Obviously if in the intervening time an involved actor dies, is moved to a different cell, etc, the queued act will fail, but that's not bad considering the alternative. ;)

Link to comment

Prideslayer, These scenes happen in the gameplay cell(player can go there) so I can't do that. I even move all existing actors elsewhere, play scene, then move them again. That is my fault because I was lazy to copy the cell, delete all markers, do navmesg again..

The cell the player is in doesn't matter. I don't see how it could..

 

But damn! Cloning idea is good. Now I realise that actors scripts will work on them even if they are created via placeatme (I use a lot of "begin OnSayToDone" and "begin OnPackageEnd" blocks.) So I think I will consider it. Is it safe to disable and markfordelete actors which are currently engaged in Sex?

I've never tried it, but it should be. I'd put a finishnow on them anyway, just in case. If scripts keep running after they're marked for delete, then the finishnow will end them. If they don't, then the finishnow will just get discarded with everything else.

Link to comment

Well. then I won't be able to start animation with them. Most of the scenes contain sex.

 

Restricted is ignored by sexout internal functions and should be used for actors only "available" through quest. It is different from SexouListBannedActor which contains actors that cannot have sex.

Link to comment

I thought we used it more :(. At least it is in SexoutSex and SexoutSexAssault (and SexoutBrutalRapers but I don't have it anymore).

 

It is strange though,  I was sure I used it in SexoutWorkingGirls, and SexoutHookups, but I had so many unpublished version of those it might have been lost.

 

 

 

Link to comment

I (/Jallil) added several easy options to prevent SexAssault from screwing up scripted sequences:

 

1. Add your cells to the SexoutNG restricted list: SexoutListRestrictedCell and SA will back off if the player is in one.

2. Add your actor refs to the SexoutNG restricted list: SexoutListRestrictedActor

3. Add your actor refs to the SCR restricted list: SexoutSLActorDataIsReserved

4. Set the NX EVFl "SO:NotNow" on the PlayerREF, and unset it when you are done, because it will not reset automatically.

 

You should only need to use one of them.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • 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