SexoutNG

[prideslayer]

Rapes seem to be able to interrupt sequences frequently. While not happening to me' date=' the legion slavery initiation tour seems to be one. Seems easier to just turn stalking off for it.

 

I was assuming the rapes were breaking things. If not actually callbacks, there still must be something that can be done (within the rape code, too) that could prevent rapes from being attempted while another mod needs exclusive 'rights' to the player's toon. Some sort of means for reserving 'rights' to the toon for a period.

[/quote']

 

Neither of those are using sexoutNG callbacks.

 

BrutalRapers most often interferes with multi-stage sex acts (as often appear in Tryouts, and also Sewerslave) because it 'queues up' rapists internally who just keep trying to rape rape rape you and don't stop until you are available.

 

So in tryouts you'll have something like this:

do some dialog
have sex
do some more dialog
have sex
have different sex
do some more dialog
... etc ...

 

while rapers is doing this:

while i-did-not-rape do
rape
end

 

That rapers loop happens really fast, so in the tryout (or whatever) mod, the raper initiates sex with the player or other actor in the middle of the sex scene, or even *before*. This is why the lockout can't really play nicely between the two right now no matter what I do.

 

Tryouts approaches and rapers both use a scanner that first sets an NPC walking/running towards the player or another actor, which is completely independent of any sort of sexout thing. By that time, they are already 'committed' to doing their thing, so it's just a 'race' to who gets to the target first.

 

I suppose what I really need is to add another token, like SexoutTarget, that modders can add to their targets manually -- and also check for before setting a target. This would mean whoevers scanner runs first "wins" and other mods using the token won't do anything with the target until that token disappears.

[prideslayer]

Oh, just a by the way, I cannot "fix" this with another list or anything. For example, if I gave you a command (another spell) like "SexoutLockActor" so you could say "player.CIOS SexoutLockActor", we're right back to square one. That call is NOT a function call, it is a spell, and the script behind it won't run until at *least* the next frame -- and when it does run, there is no telling if it will run before or after some other script has run that has also locked the actor.

 

You an only guarantee atomicity within a single script, and only within a single event loop of that script. This means, for this kind of locking to truly work, every script that initiates sex in any mod needs to do this:

 

if (0 == (target.GetItemCount SexoutTargetToken))
 target.addItem SexoutTargetToken 1
endif

... do your stuff ...

... then in this script, or in another ...
target.RemoveItem SexoutTargetToken 1

 

That is the *only* way in the present system to ensure that scripts do not walk over one another.

[sen4mi]

You an only guarantee atomicity within a single script' date=' and only within a single event loop of that script.

[/quote']

 

Also, when you set a quest stage, that script runs immediately and completes before the next instruction in the script that set the quest stage. And, this can nest, relatively deeply.

 

And, I think that formlists can hold references to quests? So, for example, you might implement callbacks (or whatever) using a specific numbered quest stage in some quest added to a list, and people could also activate sexout using a quest stage setting?

 

Does this sound like anything you can work with?

 

[zippy57]

What if you created a variable, say you called it PlayerReserved or something, and every mod that needed to use it had a number (let's say SexoutLegion uses 1723). When SexoutLegion began the tour sequence it would first check if PlayerReserved == 0. If it does, then no other plugin is reserving the Player, and it sets PlayerReserved to 1723. This way, if (for whatever reason) SexoutLegion needs to check that it is reserving the player, it would check if PlayerReserved was the right number, and if any other mod needed to reserve the player it would not only know that the player was already reserved, but would also be able to tell what plugin was reserving the player if it wanted to. Rapers would just not allow stalkers to rape once they reach the player if PlayerReserved was not 0.

[prideslayer]

You an only guarantee atomicity within a single script' date=' and only within a single event loop of that script.

[/quote']

 

Also, when you set a quest stage, that script runs immediately and completes before the next instruction in the script that set the quest stage. And, this can nest, relatively deeply.

 

This is only partially true, and is not reliable. If your script is running towards the end of a frame, then there isn't going to be time to run the quest stage script until the following frame, so it may not happen right away; that is my understanding anyway.

 

The stages do take effect right away though, even if the script doesn't run, so I could use sexout quest stages as a sort of 'lock' since I'm not using them for anything else right now. Meaning if the sexout stage is not 0, then you have to wait for it to become 0 before you are "allowed" to do anything with the sexout quest or spells.

 

I'll think about this some more.

 

And, I think that formlists can hold references to quests? So, for example, you might implement callbacks (or whatever) using a specific numbered quest stage in some quest added to a list, and people could also activate sexout using a quest stage setting?

 

Does this sound like anything you can work with?

 

 

I don't think formlists can hold quests no, I believe I tried that, but I'm not 100% sure. I definitely tried adding idle animations to a formlist and that absolutely does not work; not in the geck, and not in a script either.

 

However I can use the stage as a lock / signal, meaning if you see that the sexoutNG stage is 0, you can set it to 1, setup your vars, and call the spell, and if it's not 0 then you wait.

 

Then I'll do what I need to do to get the quest vars cleaned up and copied, and then set it back to 0 when I'm ready to process another request. No need for any additional formlists or any quest stage scripts.

[prideslayer]

What if you created a variable' date=' say you called it PlayerReserved or something, and every mod that needed to use it had a number (let's say SexoutLegion uses 1723). When SexoutLegion began the tour sequence it would first check if PlayerReserved == 0. If it does, then no other plugin is reserving the Player, and it sets PlayerReserved to 1723. This way, if (for whatever reason) SexoutLegion needs to check that it is reserving the player, it would check if PlayerReserved was the right number, and if any other mod needed to reserve the player it would not only know that the player was already reserved, but would also be able to tell what plugin was reserving the player if it wanted to. Rapers would just not allow stalkers to rape once they reach the player if PlayerReserved was not 0.

[/quote']

 

That would work fine for the player, but what about all the NPCs?

 

BrutalRapers (just as a for example) has no problem telling Motor-Runner to rape Cass, the playerReserved flag wouldn't be checked (as the player is not involved), and we're back to sexout mods stomping on one another.

 

Now if I just made it a simpler variable like "SexoutNG.InUse" and you could set it to 1 only if you found it to be 0, that would work similar to the quest stage thing just discussed. I don't think there's a big advantage to doing it one way over the other -- as long as all the mods honor it, and don't ever set it to anything if it's not 0, then it will work.

 

 

[zippy57]

What if you created a variable' date=' say you called it PlayerReserved or something, and every mod that needed to use it had a number (let's say SexoutLegion uses 1723). When SexoutLegion began the tour sequence it would first check if PlayerReserved == 0. If it does, then no other plugin is reserving the Player, and it sets PlayerReserved to 1723. This way, if (for whatever reason) SexoutLegion needs to check that it is reserving the player, it would check if PlayerReserved was the right number, and if any other mod needed to reserve the player it would not only know that the player was already reserved, but would also be able to tell what plugin was reserving the player if it wanted to. Rapers would just not allow stalkers to rape once they reach the player if PlayerReserved was not 0.[/quote']That would work fine for the player, but what about all the NPCs?

 

BrutalRapers (just as a for example) has no problem telling Motor-Runner to rape Cass, the playerReserved flag wouldn't be checked (as the player is not involved), and we're back to sexout mods stomping on one another.

 

Now if I just made it a simpler variable like "SexoutNG.InUse" and you could set it to 1 only if you found it to be 0, that would work similar to the quest stage thing just discussed. I don't think there's a big advantage to doing it one way over the other -- as long as all the mods honor it, and don't ever set it to anything if it's not 0, then it will work.

 

 

I figured if a Sexout mod needed to reserve the Player, then the Player is likely busy doing something and wouldn't care much that Rapers had temporarily stopped in the background and so it would just check PlayerReserved in all cases, not just when the Player is actually involved. I blame my choice of example variable name here.

 

EDIT: You could also have another variable where 1 = only player, 2 = player and companions, 3 = stop everything. Or you could just have your InUse example act like that. But that might be a bit overdoing it as you've already come up with the quest stage thing. So... ignore me.

[iron_jack]

On an unrelated and unhelpful (but well-meaning) note, I'm glad to see you back Pride.

[prideslayer]

Zippy we may be talking at cross purposes now that I think of it. I'm trying to come up with a way that stops the "quest variable stomping" that goes on in sexout and its mods, but this won't fix the issue where one sexout mod interrupts a "chained" set of acts in another mod, between the acts.

 

That said, your idea is going down a road that will solve both problems, I am just trying to work out a problem with two potential "what if" scenarios that can cause sexout to get disabled entirely.

 

- A mod forgets to decrement the value back to the default (which would be 1). This "locks" out all other mods.

 

- The user saves the game after your mod sets the value to 1576 and next time they start the game, your mod is gone -- or they clean saved without it, erasing your "special value."

 

My brain is spinning trying to come up with a solution.

 

On an unrelated and unhelpful (but well-meaning) note' date=' I'm glad to see you back Pride.

[/quote']

 

[muertos69]

Zippy we may be talking at cross purposes now that I think of it. I'm trying to come up with a way that stops the "quest variable stomping" that goes on in sexout and its mods' date=' but this won't fix the issue where one sexout mod interrupts a "chained" set of acts in another mod, between the acts.

 

That said, your idea is going down a road that will solve both problems, I am just trying to work out a problem with two potential "what if" scenarios that can cause sexout to get disabled entirely.

 

- A mod forgets to decrement the value back to the default (which would be 1). This "locks" out all other mods.

 

- The user saves the game after your mod sets the value to 1576 and next time they start the game, your mod is gone -- or they clean saved without it, erasing your "special value."

 

My brain is spinning trying to come up with a solution.

 

On an unrelated and unhelpful (but well-meaning) note, I'm glad to see you back Pride.

 

 

I may be completely misunderstanding something, but in your second problem case unless the save occurred in the middle of one of those chained events, couldn't a line in the initial scripts starting reset the value to its unlocked state when the game loads and prevent any permanent locks?

[sen4mi]

This is only partially true' date=' and is not reliable. If your script is running towards the end of a frame, then there isn't going to be time to run the quest stage script until the following frame, so it may not happen right away; that is my understanding anyway.

[/quote']

 

But... I have seen my framerate massively drop sometimes, and I have seen the game stutter, and I have seen the game crash or even fail to render some content when processing gets too heavy.

 

(This of course does not mean that someone did not put something special into quests, just to break quest stage logic.)

 

That said' date=' your idea is going down a road that will solve both problems, I am just trying to work out a problem with two potential "what if" scenarios that can cause sexout to get disabled entirely.

 

- A mod forgets to decrement the value back to the default (which would be 1). This "locks" out all other mods.

 

- The user saves the game after your mod sets the value to 1576 and next time they start the game, your mod is gone -- or they clean saved without it, erasing your "special value."

[/quote']

 

Note that you do not need to make sexout work in all of the broken cases. When things are broken its good if you can make the breakage clear and if you can identify the cause of the breakage. These are the sorts of things that get problems fixed.

 

Identifying the cause of the breakage will not be possible for mods that edit variables directly, if that is all that is happening. However, if they have to leave evidence to take action (objects, quests, whatever) then you can present this evidence (perhaps in console log, when someone has a reproducible problem and has turned on debugging)?

[prideslayer]

I may be completely misunderstanding something' date=' but in your second problem case unless the save occurred in the middle of one of those chained events, couldn't a line in the initial scripts starting reset the value to its unlocked state when the game loads and prevent any permanent locks?

[/quote']

 

No can do. The idea I have is to have sexout init the var to 1, and then as long as it's 1, any mod can set it to it's value and keep it there until it's "done." Normally this would just be for the duration of one act/call, but for more complicated mods like Legion and Fiends tryouts, and sewerslave, they'd need to hold it for longer -- until their "gangbang" sequence parts are done so they don't get interrupted.

 

So if anyone saves during that sequence (which can last quite a while), then they're screwed, even if they did something as simple as go through a 'cleave save' cycle without that mod in order to update it.

 

Since this can be problematic with NPCs and not just the player, telling players "don't save while you're having sex" is not enough. Some mods like Legion tryout and brutalrapers cause sex to happen at random places in the world that are well out of your current viewable area.

[muertos69]

I may be completely misunderstanding something' date=' but in your second problem case unless the save occurred in the middle of one of those chained events, couldn't a line in the initial scripts starting reset the value to its unlocked state when the game loads and prevent any permanent locks?

[/quote']

 

No can do. The idea I have is to have sexout init the var to 1, and then as long as it's 1, any mod can set it to it's value and keep it there until it's "done." Normally this would just be for the duration of one act/call, but for more complicated mods like Legion and Fiends tryouts, and sewerslave, they'd need to hold it for longer -- until their "gangbang" sequence parts are done so they don't get interrupted.

 

So if anyone saves during that sequence (which can last quite a while), then they're screwed, even if they did something as simple as go through a 'cleave save' cycle without that mod in order to update it.

 

Since this can be problematic with NPCs and not just the player, telling players "don't save while you're having sex" is not enough. Some mods like Legion tryout and brutalrapers cause sex to happen at random places in the world that are well out of your current viewable area.

 

Oh, thanks for explaining that, thought my idea was kinda simple, just wasn't certain how it would/would not work.

 

[prideslayer]

It's just one of those things you don't expect, and hardly even have to cope with in "real" programming.. but.. well yeah. You all knew that once I came back, it wouldn't take long for me to start hulking out again.

 

In better news, new version is coming along.

- Added Bloatflies.  Anim #1901. New list, SexoutCListBloatfly (17 entries).  Added to randomizer.
- All factions cleared/emptied but left in place to prevent reference errors in mods.
- Cleared some random dirty edits on creatures (where that come from?!).
- Cleared some fnvedit found errors in the crawl idle group (just removed for now since it does not work anyway).

 

Continuing on.

[Guest Loogie]

- Cleared some random dirty edits on creatures (where that come from?!).

 

Some, not all, windows in the GECK make a dirty edit if you hit OK instead of the X to close it.

 

 

[prideslayer]

Loogie, I'm integrating the rape punch fix now and I'm seeing an edit in FNVEdit that doesn't make sense so I just want to make sure it was just an accident I can ignore.

 

The main edit, to 00SexoutRapeWeapon (the script), looks good.

 

However the edit to the weapon itself (SexoutRapeFists / Rape Punch) doesn't look like it had any flag changed -- it just says the "Attack Shots/Sec" has changed from 1.578948 to 1.578946.. did I miss something here, or did you upload the wrong thing?

[Guest Loogie]

I uploaded the correct thing. I didn't touch any values in the weapon itself, just the script - if you copy and paste that script over what's in Sexout now you should be golden.

 

Also, after further testing and as pointed out by Iron Jack, the rape punch doesn't always stop combat from occurring, it just does most of the time. I plan on making a mod this weekend that will make rape punch obsolete, though.

[prideslayer]

So should I just disable this damn thing instead and say "ask loogie" when they ask me where it went? That would definitely be easier.

[Guest Loogie]

I'd keep it in, and if anyone complains about it's functionality point them to what I'll be doing. This new thing isn't for everyone.

[prideslayer]

Done deal.

 

Upload coming in just a minute.

[prideslayer]

New Plugins and Anims in OP.

 

V2.3.61

- Added Bloatflies. Anim #1901. New list, SexoutCListBloatfly (17 entries). Added to randomizer. (Thanks Kaloshnikov!)

- All factions cleared/emptied but left in place to prevent reference errors in mods.

- Cleared some random dirty edits on creatures (where that come from?!).

- Cleared some fnvedit found errors in the crawl idle group (just removed for now since it does not work anyway).

- New ghoul animation (1204). (Thanks Donkey!)

- Replaced animations 631 - 634. (Thanks Donkey!)

- Integrated fixed rape punch. (Thanks Loogie!)

- Rememberd to up nVerRelN, now 61 as it should be.

 

Edit: Yes the new ESM is smaller, it should be, since I deleted a few dozen (or hundred) records from it -- creature records that were modified by adding them to sexout factions.

 

[Chbaakal]

TY for putting in the Bloatfly anims, but found a bug with the....bugs. Actor A (or is backwards. Would have fixed the issue, myself, but couldn't remember how (did it once for a far earlier Sexout patch, before). Just have to find that post in this extensive thread...

 

 

 

[prideslayer]

TY for putting in the Bloatfly anims' date=' but found a bug with the....bugs. Actor A (or is backwards. Would have fixed the issue, myself, but couldn't remember how (did it once for a far earlier Sexout patch, before). Just have to find that post in this extensive thread...

[/quote']

 

I will check into it.

 

You can find it by searching the animations for 1901a.kf and 1901b.kf and then swapping and renaming them until I update the anims download. My mistake for not trying them before just copying them in.

[Chbaakal]

 

I will check into it.

 

You can find it by searching the animations for 1901a.kf and 1901b.kf and then swapping and renaming them until I update the anims download. My mistake for not trying them before just copying them in.

 

Thanks for the swift reply, mate! Already swapped original FO3 file for 1900b, but found an odd distortion in the Bloatfly body (probably a bad overwrite/swap of the mesh on my part...).

 

Now, back to my attempts to add Facial Expression values to Rapees (using FaceGen to develop a suitable 'Rapeface' look, then I'll figure out how to script (Damnit!) that bloody mess into a Sexout animation). Glad I have several backups for anim files, since I know I'll be screwing up whichever ones I use for testing. A lot!

 

Cheers

 

 

 

[prideslayer]

If you can get the face stuff working that'd be great.. everyone wants expressions working in the animations, you're not alone -- except in the attempt I suppose!