Jump to content

Recommended Posts

Could you add an option to end the animation once the male orgasms ?  (If I'm not mistaken there are 5 stages)  Usually what happens in my game is that the male orgasms at stage 4 and I have to redo the whole buildup again.  It's also more immersive, the guy is done, the animation should stop at that point (be it stage 2 or 3 if he's too exited).

In the MCM, I have "next stage on no stamina" and "next stage on orgasm" enabled but males rarely orgasm on stage 5.

 

If it's again the spirit of your mod (eg being able to orgasm multiple times for males), then consider it only an option

Link to comment
10 hours ago, letterman said:

I'm wondering if you could add a feature where if the enjoyment level is high enough (say 90-95% or so), the actors that are close keep the scene going until they cum. It seems silly they'd be so close and then just stop anyway

i think its called ruined orgasm in pron

you can always change stages back

2 hours ago, yarz96 said:

Is there a Russian translation of this mod?

somewhere in russian internet?

1 hour ago, mangalo said:

Could you add an option to end the animation once the male orgasms ?  (If I'm not mistaken there are 5 stages)  Usually what happens in my game is that the male orgasms at stage 4 and I have to redo the whole buildup again.  It's also more immersive, the guy is done, the animation should stop at that point (be it stage 2 or 3 if he's too exited).

In the MCM, I have "next stage on no stamina" and "next stage on orgasm" enabled but males rarely orgasm on stage 5.

 

If it's again the spirit of your mod (eg being able to orgasm multiple times for males), then consider it only an option

this is what "next stage on orgasm" does

Link to comment
1 hour ago, mangalo said:

Yes, but if the male orgasms at stage 2, you're still only at stage 3.  I don't know if males in Skyrim are super virile or use viagra but shouldn't the animation end ?

 

Inb4 "no"

if it orgasms at 2, then slso skips stages to last stage

Link to comment
On 2/14/2019 at 6:43 AM, mangalo said:

Could you add an option to end the animation once the male orgasms ?  (If I'm not mistaken there are 5 stages)  Usually what happens in my game is that the male orgasms at stage 4 and I have to redo the whole buildup again.  It's also more immersive, the guy is done, the animation should stop at that point (be it stage 2 or 3 if he's too exited).

In the MCM, I have "next stage on no stamina" and "next stage on orgasm" enabled but males rarely orgasm on stage 5.

 

If it's again the spirit of your mod (eg being able to orgasm multiple times for males), then consider it only an option

For NPC on NPC action, have you tried lowering the "male enjoyment boost" setting so the males don't blow their load in the first couple of stages?? It might be hit an miss, but if you want to play NPC SLSO that's about all you can do I think. I play a male character and I disable auto advance so if my dude blows wad super early, I can let it keep running until later in the animation when all that enjoyment builds back up and BOOM end it there by tapping space. Same goes for the earlier example with your male character, just keep tapping space until it ends, or you can hit the END ANIMATION hotkey. Auto advancing animations (based on stamina etc) for the most part makes the scene really janky sometimes, as a lot of animations transition pretty poorly as it is between phases and that has nothing to do with SLSO.

 

The only addition I would like to see, is a slider to set how much enjoyment is gained by advancing phases in the animation.

Link to comment

I'm trying to register for Orgasm events with SLSO and I'm not getting any events, despite on-screen widgets being reduced to zero, camera shake effects, etc.

 

What I'm doing is:

 

        Debug.Notification("registering for orgasms")
        RegisterForModEvent("SexLabOrgasm", "SLSO_Orgasms")

And for the handler:

 

Event SLSO_Orgasms(Actor a, int enjoy, int count)
        Debug.Notification("orgasm: " + a.GetDisplayName())

EndEvent

Anyone see what I'm doing wrong? It's a year or more since I last touched the CK,, so I'm probably making a basic error somewhere.

Link to comment
45 minutes ago, DocClox said:

I'm trying to register for Orgasm events with SLSO and I'm not getting any events, despite on-screen widgets being reduced to zero, camera shake effects, etc.

 

What I'm doing is:

 


        Debug.Notification("registering for orgasms")
        RegisterForModEvent("SexLabOrgasm", "SLSO_Orgasms")

And for the handler:

 


Event SLSO_Orgasms(Actor a, int enjoy, int count)
        Debug.Notification("orgasm: " + a.GetDisplayName())

EndEvent

Anyone see what I'm doing wrong? It's a year or more since I last touched the CK,, so I'm probably making a basic error somewhere.

Actor a.

 

This must be 

Event SLSO_Orgasms(Form a, int enjoy, int count)

 

Also "SexLabOrgasm" is for vanilla SexLab. While it will work on SLSO, you should probably use this one (as it will trigger only if Separate Orgasm is enabled):

 

RegisterForModEvent("SexLabOrgasmSeparate", "SLSO_Orgasms")

Event SLSO_Orgasms(Form a, int tid)

 

Link to comment

 

Quote

 

 


Also "SexLabOrgasm" is for vanilla SexLab. While it will work on SLSO, you should probably use this one (as it will trigger only if Separate Orgasm is enabled):
 

 

 

 

Yeah, I tried both. Neither worked. SLSO raises its own SexLabOrgasm mod events, plus that one has a count attached, which could save some trouble.

 

 

Event SLSO_Orgasms(Form a, int enjoy, int count)

 

So it's that sensitive to event signatures? I remembered it being a lot more permissive than that. Oh well, like I said it's been a while.

 

Thanks for the help.

 

[edit]

 

Yep, that was it. Thanks again.

Link to comment
1 hour ago, DocClox said:

So it's that sensitive to event signatures? I remembered it being a lot more permissive than that. Oh well, like I said it's been a while.

Actor is a subclass of ObjectReference, which is a subclass of Form.

 

This is just type safety. It won't auto cast, so passing a Form object to a function expecting an Actor object is a type error. The papyrus log is going to warn you about that too.

Passing an Actor object to a Form-expected function is fine, the reason being that casting from Actor to Form will always succeeded (since Actor inherits from Form), where casting from Form to Actor may not succeeded (such as a non-Actor Form object).

Link to comment
14 hours ago, Hawk9969 said:

Actor is a subclass of ObjectReference, which is a subclass of Form.

 

Yeah yeah, I get it. I just remembered it being a lot less type-safe than apparently it is. Like I say, it's been a while.

 

[edit]

 

OK. I made a patch for PAHE to us SLSO. Basically, if you use sex to train a slave, and if you have victim arousal and orgasm enabled, then you get a boost to submission based on the number of times the slave came and how much pleasure you inflicted. 

 

I posted it to the PAHE thread last night. I'll link to it from here when I get back from work tonight.

Link to comment
  • 2 weeks later...

Question: is there, or could there be, a way to block NPC orgasm on a per-actor basis?

 

I want to add something to the Slaver's Spellbook to block orgasm for unruly slaves. I can do it by disabling orgasm for aggressive actions, but that affects everyone, and I'd like this to be something I can inflict and then leave in place until I see fit to remove it.

 

I had a quick look through the code and didn't see anything obvious. Maybe use StorageUtil to set a flag on the actor record?

 

Oh, and I plan to take another look at QAYL shortly, so I'll probably make use of the condition to deny player orgasm if SLSO was loaded.  The reason the Meat Stamp brand is so aggressive in locking arousal is that I couldn't find a way to block orgasm entirely.

 

If I can do it with SLSO, I surely will :)

Link to comment
2 hours ago, DocClox said:

Question: is there, or could there be, a way to block NPC orgasm on a per-actor basis?

 

I want to add something to the Slaver's Spellbook to block orgasm for unruly slaves. I can do it by disabling orgasm for aggressive actions, but that affects everyone, and I'd like this to be something I can inflict and then leave in place until I see fit to remove it.

 

I had a quick look through the code and didn't see anything obvious. Maybe use StorageUtil to set a flag on the actor record?

 

Oh, and I plan to take another look at QAYL shortly, so I'll probably make use of the condition to deny player orgasm if SLSO was loaded.  The reason the Meat Stamp brand is so aggressive in locking arousal is that I couldn't find a way to block orgasm entirely.

 

If I can do it with SLSO, I surely will :)

try

 

            if StorageUtil.GetIntValue(ActorRef, "forbid_orgasm") == 1
                Log("Orgasm blocked, " + ActorName + " is forbidden to orgasm")
                return
            endIf
 

ssl.7z

Link to comment

How about

 

	if StorageUtil.GetIntValue(ActorRef, "slso_forbid_orgasm") == 1
		Log("Orgasm blocked, " + ActorName + " is forbidden to orgasm")
		int modevent_h = ModEvent.Create("SexLabOrgasmSeparateDenied")
		if modevent_h
			modevent_h.PushForm(Seid, ActorRef)
			modevent_h.PushInt(Seid, Thread.tid)
			modevent_h.Send(Seid)
		endif
		return
	endIf

Then I can listen for denial events and maybe add some flavor text. Or use it as a punishment modifier.

 

Of course, there might be quite a few of them once she gets to that point. I might have to stop listening for a time after I get one of those

Link to comment
On 3/8/2019 at 11:36 PM, DocClox said:

StorageUtil.GetIntValue(ActorRef, "slso_forbid_orgasm")

Are there any mods that set this flag yet?

 

And ... not really related to this flag, just a general SLSO question...

 

 

I'm interested in implementing a mini-game for the PC, where they are told not to orgasm during a SexLab animation, and if they do, they get punished.

 

The question is - how can I set things up so that the PC has a predictable chance of "winning", without making it too easy, or too hard, and without it being a flat-out certainty one way or the other?

 

Is it even possible to make a viable game of this, given the four highly predictable options the player has in SLSO, and how much it depends on the starting arousal of the participants, the player's initial stamina and magicka, etc?

 

 

Maybe, it's possible to modify the game somehow during play?

By messing with the Actor Values, for example, or messing with some properties in SLSO?

 

I guess what I'm thinking of, is a mechanism where there are windows of opportunity, and other times that are disadvantageous.

But the player isn't told when these are...

 

In windows of opportunity where, for example, either the "reduce own excitement" action, or the "increase partner excitement" action might cost less, be free, or even increase stamina or magicka.

 

In the bad periods, they would be charged extra for clicking a disadvantageous action.

 

Presumably then, they have to experiment by clicking, and seeing if they get a good or bad outcome, but there are four different actions in SLSO, and the game would treat each individually. By playing stamina off against magicka, as well as using the window mechanic, I'm pretty sure I can make a game that has genuine "game" qualities.

 

Presumably, if they get a good result, they click that action again and again, until it stops being good, and then they have to find the next good action. But, an action that burns stamina might refill magicka, and if you already have a full magicka bar, then you're not gaining any extra benefit, so it starts to become more strategic. Should you burn magicka on the hope you can refill it? But what if the next window requires you to spend magicka to get stamina? In that case if you don't have magicka, you're caught, sitting, waiting, gaining excitement, and not doing much to prevent it.

 

 

To make this work as described, I would want the ability to tamper with the stamina/magicka costs for each action on self and partner, and also with the PC's excitement state, so I could continually ramp it up through the game, so they have to fight against it. This would probably ramp faster towards the end, to pile on the pressure.

 

 

I may not have explained this at all well, but I'm not sure exactly how I want to go about it yet.

Nor am I sure what I can change, and what SLSO will become confused by, if I change it.

Clearly, if I tamper with SLSO properties (for example) I don't know exactly what SLSO is doing, so the changes could be lost by a read-modify action by SLSO itself, or confuse SLSO code that expects a variable to stay unmodified.

 

For example, I haven't looked to see if SLSO works with a cached copy of Stamina and Magicka, or always acts on the AVs directly.

I haven't looked to see how easy it is to set up the baseline excitement and excitement delta/time for participants, and so on.

For now, I'm just trying to think of ways to implement a genuine "game" within the framework of SLSO's four actions.

Link to comment
1 hour ago, Lupine00 said:
On 3/8/2019 at 12:36 PM, DocClox said:

StorageUtil.GetIntValue(ActorRef, "slso_forbid_orgasm")

Are there any mods that set this flag yet?

 

 

Not yet. It's not in SLSO yet for that matter. The Next Slaver's Spellbook will probably have a spell to set and unset it on the target.

 

1 hour ago, Lupine00 said:

I guess what I'm thinking of, is a mechanism where there are windows of opportunity, and other times that are disadvantageous.

 But the player isn't told when these are...

 

 

I suppose you could have a quest that listens for the same events as the widget, and then makes its own, additional changes to the player's AV. Assuming as you say, that SLSO isn't working from a copy of the avs in question.

Link to comment
3 hours ago, Lupine00 said:

Are there any mods that set this flag yet?

I am building a bit of story around this in one of my mod ideas, too.

Quote

I'm interested in implementing a mini-game for the PC, where they are told not to orgasm during a SexLab animation, and if they do, they get punished.

Similar in concept to that :classic_laugh:

 

Plus, the option has roleplay opportunities, binding them to the technical rules of SL. I think it is a very nice feature. :classic_smile:

Link to comment
21 hours ago, Lupine00 said:

Are there any mods that set this flag yet?

 

And ... not really related to this flag, just a general SLSO question...

 

 

I'm interested in implementing a mini-game for the PC, where they are told not to orgasm during a SexLab animation, and if they do, they get punished.

 

The question is - how can I set things up so that the PC has a predictable chance of "winning", without making it too easy, or too hard, and without it being a flat-out certainty one way or the other?

 

Is it even possible to make a viable game of this, given the four highly predictable options the player has in SLSO, and how much it depends on the starting arousal of the participants, the player's initial stamina and magicka, etc?

 

 

Maybe, it's possible to modify the game somehow during play?

By messing with the Actor Values, for example, or messing with some properties in SLSO?

 

I guess what I'm thinking of, is a mechanism where there are windows of opportunity, and other times that are disadvantageous.

But the player isn't told when these are...

 

In windows of opportunity where, for example, either the "reduce own excitement" action, or the "increase partner excitement" action might cost less, be free, or even increase stamina or magicka.

 

In the bad periods, they would be charged extra for clicking a disadvantageous action.

 

Presumably then, they have to experiment by clicking, and seeing if they get a good or bad outcome, but there are four different actions in SLSO, and the game would treat each individually. By playing stamina off against magicka, as well as using the window mechanic, I'm pretty sure I can make a game that has genuine "game" qualities.

 

Presumably, if they get a good result, they click that action again and again, until it stops being good, and then they have to find the next good action. But, an action that burns stamina might refill magicka, and if you already have a full magicka bar, then you're not gaining any extra benefit, so it starts to become more strategic. Should you burn magicka on the hope you can refill it? But what if the next window requires you to spend magicka to get stamina? In that case if you don't have magicka, you're caught, sitting, waiting, gaining excitement, and not doing much to prevent it.

 

 

To make this work as described, I would want the ability to tamper with the stamina/magicka costs for each action on self and partner, and also with the PC's excitement state, so I could continually ramp it up through the game, so they have to fight against it. This would probably ramp faster towards the end, to pile on the pressure.

 

 

I may not have explained this at all well, but I'm not sure exactly how I want to go about it yet.

Nor am I sure what I can change, and what SLSO will become confused by, if I change it.

Clearly, if I tamper with SLSO properties (for example) I don't know exactly what SLSO is doing, so the changes could be lost by a read-modify action by SLSO itself, or confuse SLSO code that expects a variable to stay unmodified.

 

For example, I haven't looked to see if SLSO works with a cached copy of Stamina and Magicka, or always acts on the AVs directly.

I haven't looked to see how easy it is to set up the baseline excitement and excitement delta/time for participants, and so on.

For now, I'm just trying to think of ways to implement a genuine "game" within the framework of SLSO's four actions.

Hm... that sound like you would need to rewrite slso game and if you want it to be predictable  use predictable calculations rather than skill based

Link to comment
9 minutes ago, Ed86 said:

Hm... that sound like you would need to rewrite slso game and if you want it to be predictable  use predictable calculations rather than skill based

Is SLSO engineered to support a replacement game?

 

Or would I have to patch SLSO scripts?

 

If the latter, is it possible to refactor the game so that it can be patched cleanly so that replaced files only impact the game setup and update, and the rest of SLSO will not be touched?

 

I'm not suggesting you do anything, just comment on feasibility.

 

I guess I should look at the existing code...

 

I always wanted to make the game more involving for the player, but without any "stakes" it wasn't possible. By integrating this into a chastity storyline, there are actual win and lose conditions. That said, I could see using a slightly different setup to modify Radiant Prostitution so that you can get different satisfaction levels from customers too.

 

I'm getting increasingly interested in this, but whatever happens, I won't be doing it right away.

 

I guess another possibility is I make any changes I need, in a way that it's easy to toggle any new game functionality on/off and you might be able to merge it into mainline SLSO...

 

Something to think over, but don't take it seriously until I actually do something.

Link to comment
3 hours ago, Lupine00 said:

Is SLSO engineered to support a replacement game?

 

Or would I have to patch SLSO scripts?

 

If the latter, is it possible to refactor the game so that it can be patched cleanly so that replaced files only impact the game setup and update, and the rest of SLSO will not be touched?

 

I'm not suggesting you do anything, just comment on feasibility.

 

I guess I should look at the existing code...

 

I always wanted to make the game more involving for the player, but without any "stakes" it wasn't possible. By integrating this into a chastity storyline, there are actual win and lose conditions. That said, I could see using a slightly different setup to modify Radiant Prostitution so that you can get different satisfaction levels from customers too.

 

I'm getting increasingly interested in this, but whatever happens, I won't be doing it right away.

 

I guess another possibility is I make any changes I need, in a way that it's easy to toggle any new game functionality on/off and you might be able to merge it into mainline SLSO...

 

Something to think over, but don't take it seriously until I actually do something.

not really,

i have no idea how you see it, so probably need to replace game script, maybe some patches to sexlab scripts that slso modifies

Link to comment
4 hours ago, Lupine00 said:

Or would I have to patch SLSO scripts?

 

I had a quick look at this. The Game() code is implemented in a spell defined in SLSO_SpellGameScript.psc. The only reference seems to be in the MCM Config script. So the cleanest way is probably to write your own game spell and change the config property.  You can probably subclass the existing script and just rewrite the Game() function, but that's on the basis of about five minutes grepping, so don't take it as gospel.

Link to comment
1 hour ago, DocClox said:

 

I had a quick look at this. The Game() code is implemented in a spell defined in SLSO_SpellGameScript.psc. The only reference seems to be in the MCM Config script. So the cleanest way is probably to write your own game spell and change the config property.  You can probably subclass the existing script and just rewrite the Game() function, but that's on the basis of about five minutes grepping, so don't take it as gospel.

Thanks.

 

Looking at the effect script, it seems fairly well encapsulated.

Might be a more tractable problem than Ed suggests? :)

 

I might have a play about with this sooner rather than later.

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