Submissive Lola: The resubmission

[Roggvir]

5 minutes ago, HexBolt8 said:

The site doesn't have a way for anyone other than the mod owner to post download files.  MrEsturk had been super busy in real life for an extended period, so he asked me help with the development.  Either the mod could grind to a halt, or I could post updates.  From time to time, MrEsturk made the latest update an official version, and I'd continue with updates from that point.

Aha, my apologies then, i didn't realize that.

[Roggvir]

12 minutes ago, HexBolt8 said:

I found that the property was missing in two other places and corrected those as well.

Can you please tell me where else was it missing, so i can add it into my personal hotfix in the meantime?

[HexBolt8]

4 minutes ago, Roggvir said:

Can you please tell me where was it missing, so i can add it into my personal hotfix in the meantime?

The zlib property was missing in vkjMQ and one other.  The timing is unfortunate since I just closed the editor and I can't see what I changed.  It was one other quest, vkjRoped I think (possibly vkjEnoughAction).

 

If you find any more bugs, just pass them along and they can get fixed too. 

[Roggvir]

1 hour ago, HexBolt8 said:

The zlib property was missing in vkjMQ and one other.  The timing is unfortunate since I just closed the editor and I can't see what I changed.  It was one other quest, vkjRoped I think (possibly vkjEnoughAction).

 

If you find any more bugs, just pass them along and they can get fixed too. 

Thank you.
I checked in the meantime, and...

vkj_zAddPiercings.psc - OK
Contains a zlib property declaration, refers to it in its fragment, but the script itself is not used anywhere (v1.1 with latest update).

vkj_zGetPiercings.psc - OK
Contains a zlib property declaration, refers to it in its fragment, and the script is used on TopicInfo 554FA on quest vkjTrick, where the property value is assigned.

vkjdevicecontrol.psc - Fixed?
Script is attached to quest vkjGagged, and the property was not assigned (v1.1 with latest update).
Should be fixed by assigning the property value in the plugin, but that works only for new games (or maybe if the quest gets restarted? i didn't try that as i think that restarting the quest would make a mess of things anyway - am i wrong?).
To fix this also retrospectively on saves created before fixing it in the plugin, the property needs to be assgined from some script (like increasing version number in vkjMCM.OnConfigOpen() and adding a code that runs when updating from older version and assigns the value if it wasn't set).

vkjenoughaction.psc - OK
Contains a zlib property declaration, but doesn't use it anywhere, so it probably doesn't matter.
(unless some other script would try to access this property on this script, but why would anybody do that is beyond me - so, it really probably doesn't matter).

vkjmq.psc - OK
Contains a zlib property declaration, and the property is correctly assigned on the script attached to vkjMQ quest.
(at least that's how it is in the plugin from latest update, available on page 48).

 

[HexBolt8]

47 minutes ago, Roggvir said:

Should be fixed by assigning the property value in the plugin, but that works only for new games (or maybe if the quest gets restarted?

It should be fixed the next time the quest starts.

[Roggvir]

Another error:

[10/01/2020 - 10:48:05PM] ERROR: Unable to call GetOwningQuest - no native object bound to the script object, or object is of incorrect type
stack:
	[<nullptr form> (5605CD14)].vkj_zMotivate.GetOwningQuest() - "<native>" Line ?
	[<nullptr form> (5605CD14)].vkj_zMotivate.Fragment_1() - "vkj_zMotivate.psc" Line 23

Occurs after the mistress complains about Lola not taking her service seriously (or something like that), after which you can reply with "Please, no, I'll do better!" to which the mistress responds with "Yes you will, after this little lesson."

[INFO:0805CD14] ('Yes you will, after this little lesson.' in GRUP Topic Children of vkjSimpleDomActionMotivationNo "Please, no, I'll do better!" [DIAL:0805CD0A])

The code where the error happens is in vkj_zMotivate.psc:
 

15: Function Fragment_1(ObjectReference akSpeakerRef)
16:     Actor akSpeaker = akSpeakerRef as Actor
17:     ;BEGIN CODE
18:     if Utility.RandomInt(1,3) < 3
19:         (GetOwningQuest() as vkjOwnerComment).MQ.Spank(akSpeaker, true, true)
20:     else
21:         (GetOwningQuest() as vkjOwnerComment).MQ.WhipPlayer(true, true)
22:     endif
23:     (GetOwningQuest() as vkjOwnerComment).End()
24:     ;END CODE
25: EndFunction

 

And I THINK the reason is that by the time GetOwningQuest() is called on line 23, the Topic Info which run this fragment is already discarded and unloaded from memory (as the error says: "no native object bound to the script object"), because both Spank() and WhipPlayer() take a long time to finish.


One way to fix this problem, would be to change the original code above into the following:
 

15: Function Fragment_1(ObjectReference akSpeakerRef)
16:     Actor akSpeaker = akSpeakerRef as Actor

17:     ;BEGIN CODE
18:     vkjOwnerComment vkjOC = GetOwningQuest() as vkjOwnerComment

19:     if Utility.RandomInt(1,3) < 3
20:         vkjOC.MQ.Spank(akSpeaker, true, true)
21:     else
22:         vkjOC.MQ.WhipPlayer(true, true)
23:     endif
24:     vkjOC.End()

25:     ;END CODE
26: EndFunction


EDIT: Also have a look at Fragment 2 on that script, as it seems the same problem can occur there too (code calling Punish() which looks like a long running function, and then trying to call GetOwningQuest() at a point where there may be nothing to call it on anymore if the Punish() func took long enough to run).

 

EDIT 2: Actually, i just got the same error, even after using the aforementioned "fix".
Right now i have no idea what the hell is going on.

[Roggvir]

And another error:

[10/01/2020 - 11:58:30PM] ERROR: Array index -1 is out of range (0-32)
stack:
	[vkjMQ (56026EC9)].vkjmq.SexlabDomNoStrip() - "vkjMQ.psc" Line 1202
	[vkjMQ (56026EC9)].vkjmq.Spank() - "vkjMQ.psc" Line 998
	[topic info 5605CD14 on quest vkjOwnerComment (5602A4F0)].vkj_zMotivate.Fragment_1() - "vkj_zMotivate.psc" Line 20

Occured during the "motivational spanking" which is one of the outcome mentioned in my previous bug report above.

Caused by this code in vkjMQ.psc:
1193: Function SexlabDomNoStrip(sslBaseAnimation[] anims, actor partner)
  ...
1201:    while i >= 0
1202:        i -= 1
1203:        slots[i ] = false
1204:    endWhile

  ...
1213: endFunction

 

Should be fixed by changing the greater than or equal to just greater than:

1193: Function SexlabDomNoStrip(sslBaseAnimation[] anims, actor partner)
  ...
1201:    while i > 0
1202:        i -= 1
1203:        slots[i ] = false
1204:    endWhile

  ...
1213: endFunction

 

[HexBolt8]

@Roggvir thank you.  I wasn't aware that the owning quest could just disappear like that in a long-running script fragment.  I've added your fixes for vkj_zMotivate (both fragments) and the one for vkjMQ.  Bug reports that are this detailed (and especially ones with solutions) are very welcome. 

[Roggvir]

2 hours ago, HexBolt8 said:

I wasn't aware that the owning quest could just disappear like that in a long-running script fragment.

I know what you meant there, but please forgive my urge to correct the wording, just in case somebody else would took it literally and get confused:

Spoiler

It is not about the owning quest disappearing, but the native object on which vkj_zMotivate.psc calls the GetOwningQuest() function (in this case a native TopicInfo script object that has been "said" and started the script fragment provided by vkj_zMotivate.psc).

In other words:
vkj_zMotivate.psc extends TopicInfo script object which provides the GetOwningQuest() function.
When vkj_zMotivate.psc calls GetOwningQuest() the way it does, it calls that function sitting on the script object it extends (the TopicInfo object) and that is the thing which got discarded, resulting in no more access to that GetOwningQuest() function which went away with it.

 

[Teddar]

15 hours ago, HexBolt8 said:

@Roggvir thank you.  I wasn't aware that the owning quest could just disappear like that in a long-running script fragment.  I've added your fixes for vkj_zMotivate (both fragments) and the one for vkjMQ.  Bug reports that are this detailed (and especially ones with solutions) are very welcome. 

And he came up with that without using his head ?

[Roggvir]

Question:
The amount of gold/septims in follower's inventory does not change when they take their share from player's prostitution.
Is that intended? or is it some toggle i missed?

The problem seems to be that with "Owner's poverty treshold" and "Forced prostitution if owner is poor" set, the forced prostitution keeps getting repeated even though the follower should already have more than enough gold.
The follower had 238 gold in their inventory, and the "poverty treshold" is set to 500.
The forced prostitution already repeated 3 times, each time earning about 500 (with 90% being owner's share), yet the follower still has only 238 gold in their inventory, and the forced prostitution is now about to be repeated for the 4th time.

Before i dive into it, looking for a problem, am i just misunderstanding something?
 

EDIT: Nevermind, it seems to be caused by Extensible Follower Framework.
Must be because EFF separates follower's "equipment" from their "inventory".
Even using console to give gold to the follower didn't increase the amount of gold that is listed when using the "inv" console command, BUT when using the EFF GUI to go to follower's "inventory" i see they have already more than 3K gold.

...so, i guess a compatibility patch for EFF may be needed.
I'll look into this, since i can't even to begin to consider playing without EFF, but in case somebody already knows about a solution - don't keep it to yourself please.

 

EDIT 2: Looks like maybe the best way to fix this, would be to make sure the gold (and anything that needs to stay in follower's inventory) is given to the follower by moving it from player's inventory using RemoveItem() (it allows to specify optional destination container where the removed item is put).
That way it would work for both the ppl NOT using EFF, and the ppl using EFF, without even having to check for existnce of EFF.

EFF uses OnItemAdded event handler to move added items into the follower's special "inventory" container.
Only equippable items, food items, and items given by player or picked up by the follower, are left to remain in the REAL follower's inventory.
So, using PlayerRef.RemoveItem(gold, 500, true, OwnerRef) (specifying the follower reference as the destination container) will make it look to the EFF as if the item was given by player and allowed to stay.

That would be the simplest solution, but i have to admit i find this separation of equip and inventory in EFF quite annoying.
Lola cannot be the only mod having to deal with this.
Better solution would probably be to use some functions provided by EFF, if there are any - for example, when checking how many items/gold the follower has, instead of using GetItemCount (which is bound to return an incorrect value, if the item is in the fake inventory), there would be a function provided by EFF which would count items in both inventories - then it wouldn't matter where that gold ends up.
 

This sucks, at this rate i will never get to actually play the game.

[HexBolt8]

5 hours ago, Roggvir said:

So, using PlayerRef.RemoveItem(gold, 500, true, OwnerRef) (specifying the follower reference as the destination container) will make it look to the EFF as if the item was given by player and allowed to stay.

Nothing is ever simple with Skyrim.  This mod already uses RemoveItem() to transfer gold from PC to owner.  As an example, look at TakeGoldFromPlayer() in vkjMQ.  So apparently that won't solve your problem. 

 

Perhaps that separation of follower inventory and equipment can turned off in EFF (I can't say, I'm using NFF) or maybe you can hack its implementation of OnItemAdded handling or convince the author to add a switch so that gold stays in the follower's inventory. 

 

On a tangent, the business of moving things out of inventory is just troublesome.  DD gags that block eating & drinking do so by moving those items from PC inventory to a hidden container, and as a consequence this mod's quests to fetch booze for or cook a meal for the owner couldn't be turned in because the item the owner wanted got whisked away.  To avoid that situation, this mod won't start those quests while the PC is wearing a gag with the zad_effGagNoFood effect.  So nonintuitively, being gagged in many cases means you can't cook for your owner or fetch a bottle of wine.

 

Edit:  To be clear, I understand why DD gags work that way and I'm not criticizing the implementation.  It works very well for what it intends to do.  It just has non-obvious consequences.

[Roggvir]

2 hours ago, HexBolt8 said:

This mod already uses RemoveItem() to transfer gold from PC to owner.  As an example, look at TakeGoldFromPlayer() in vkjMQ.  So apparently that won't solve your problem. 

 

Perhaps that separation of follower inventory and equipment can turned off in EFF (I can't say, I'm using NFF) or maybe you can hack its implementation of OnItemAdded handling or convince the author to add a switch so that gold stays in the follower's inventory.

Right, i didn't realize that using RemoveItem() alone cannot help, because its gold - not equippable, not a food item - which means that regardless of where the item came from, it will still be moved by EFF into that special container.

The separation of inventory and equipment in EFF cannot be turned off, no such option.

But i fixed it by patching Lola scripts, replacing all inventory related function calls with calls to custom functions that do take into account the special EFF containers (if the EFF is installed).
So, problem solved.

 

2 hours ago, HexBolt8 said:

On a tangent, the business of moving things out of inventory is just troublesome.  DD gags that block eating & drinking do so by moving those items from PC inventory to a hidden container, and as a consequence this mod's quests to fetch booze for or cook a meal for the owner couldn't be turned in because the item the owner wanted got whisked away.  To avoid that situation, this mod won't start those quests while the PC is wearing a gag with the zad_effGagNoFood effect.  So nonintuitively, being gagged in many cases means you can't cook for your owner or fetch a bottle of wine.

Ahh, yeah, i totally forgot about DD doing that. That is annoying.

[Roggvir]

On 10/1/2020 at 11:35 PM, Roggvir said:

Spoiler

Another error:

[10/01/2020 - 10:48:05PM] ERROR: Unable to call GetOwningQuest - no native object bound to the script object, or object is of incorrect type
stack:
	[<nullptr form> (5605CD14)].vkj_zMotivate.GetOwningQuest() - "<native>" Line ?
	[<nullptr form> (5605CD14)].vkj_zMotivate.Fragment_1() - "vkj_zMotivate.psc" Line 23

Occurs after the mistress complains about Lola not taking her service seriously (or something like that), after which you can reply with "Please, no, I'll do better!" to which the mistress responds with "Yes you will, after this little lesson."

[INFO:0805CD14] ('Yes you will, after this little lesson.' in GRUP Topic Children of vkjSimpleDomActionMotivationNo "Please, no, I'll do better!" [DIAL:0805CD0A])

The code where the error happens is in vkj_zMotivate.psc:
 

15: Function Fragment_1(ObjectReference akSpeakerRef)
16:     Actor akSpeaker = akSpeakerRef as Actor
17:     ;BEGIN CODE
18:     if Utility.RandomInt(1,3) < 3
19:         (GetOwningQuest() as vkjOwnerComment).MQ.Spank(akSpeaker, true, true)
20:     else
21:         (GetOwningQuest() as vkjOwnerComment).MQ.WhipPlayer(true, true)
22:     endif
23:     (GetOwningQuest() as vkjOwnerComment).End()
24:     ;END CODE
25: EndFunction

 

And I THINK the reason is that by the time GetOwningQuest() is called on line 23, the Topic Info which run this fragment is already discarded and unloaded from memory (as the error says: "no native object bound to the script object"), because both Spank() and WhipPlayer() take a long time to finish.


One way to fix this problem, would be to change the original code above into the following:
 

15: Function Fragment_1(ObjectReference akSpeakerRef)
16:     Actor akSpeaker = akSpeakerRef as Actor

17:     ;BEGIN CODE
18:     vkjOwnerComment vkjOC = GetOwningQuest() as vkjOwnerComment

19:     if Utility.RandomInt(1,3) < 3
20:         vkjOC.MQ.Spank(akSpeaker, true, true)
21:     else
22:         vkjOC.MQ.WhipPlayer(true, true)
23:     endif
24:     vkjOC.End()

25:     ;END CODE
26: EndFunction


EDIT: Also have a look at Fragment 2 on that script, as it seems the same problem can occur there too (code calling Punish() which looks like a long running function, and then trying to call GetOwningQuest() at a point where there may be nothing to call it on anymore if the Punish() func took long enough to run).

 

EDIT 2: Actually, i just got the same error, even after using the aforementioned "fix".
Right now i have no idea what the hell is going on.

 

By the way... that GetOwningQuest() error in vkj_zMotivate doesn't seem to be fixed by this.
I just saw the same error even while using the "fixed" script. WTF?
Anybody has any explanation?

EDIT: it needs more testing, but it seems like now it mostly happens if i click through the dialogue too fast.

[AnnaShapard]

10 minutes ago, Roggvir said:

By the way... that GetOwningQuest() error in vkj_zMotivate doesn't seem to be fixed by this.
I just saw the same error even while using the "fixed" script. WTF?
Anybody has any explanation?

EDIT: it needs more testing, but it seems like now it mostly happens if i click through the dialogue too fast.

means in plain language, DO NOT INTERRUPT YOUR MISTRESS, SLAVE!>:D

[HexBolt8]

17 minutes ago, Roggvir said:

it needs more testing, but it seems like now it mostly happens if i click through the dialogue too fast.

I've seen this kind of problem before.  I have no solution.  Everything works better if the dialog gets to play for a couple of seconds.  Mostly I hit the problem when I'm testing a scene for the 99th time and clicking way too fast.  Anyway, I'll leave the fix in.  It can't hurt and might help.

[Roggvir]

24 minutes ago, HexBolt8 said:

I've seen this kind of problem before.  I have no solution.  Everything works better if the dialog gets to play for a couple of seconds.  Mostly I hit the problem when I'm testing a scene for the 99th time and clicking way too fast.  Anyway, I'll leave the fix in.  It can't hurt and might help.

Well, i guess a real fix would be to replace the GetOwningQuest() with Quest.GetQuest("vkjOwnerComment").
It sounds a bit dumb, replacing native function that should work with function from SKSE requiring a quest name no less, but it really does fix whatever the problem is.
SKSE is required anyway, so its not like you'd be adding a new dependency.
And having to ask for a specific quest, identified by its name, isn't a problem, because it is always this "vkjOwnerComment" quest.

So, i recommend the following fix, replacing every call to GetOwningQuest() with Quest.GetQuest("vkjOwnerComment"):

Spoiler

;BEGIN FRAGMENT CODE - Do not edit anything between this and the end comment
;NEXT FRAGMENT INDEX 3
Scriptname vkj_zMotivate Extends TopicInfo Hidden

;BEGIN FRAGMENT Fragment_0
Function Fragment_0(ObjectReference akSpeakerRef)
Actor akSpeaker = akSpeakerRef as Actor
;BEGIN CODE
(Quest.GetQuest("vkjOwnerComment") as vkjOwnerComment).MQ.MinimalReward()
;END CODE
EndFunction
;END FRAGMENT

;BEGIN FRAGMENT Fragment_1
Function Fragment_1(ObjectReference akSpeakerRef)
Actor akSpeaker = akSpeakerRef as Actor
;BEGIN CODE
vkjOwnerComment _vkjOC = Quest.GetQuest("vkjOwnerComment") as vkjOwnerComment
if Utility.RandomInt(1,3) < 3
	_vkjOC.MQ.Spank(akSpeaker, true, true)
else
	_vkjOC.MQ.WhipPlayer(true, true)
endif
_vkjOC.End()
;END CODE
EndFunction
;END FRAGMENT

;BEGIN FRAGMENT Fragment_2
Function Fragment_2(ObjectReference akSpeakerRef)
Actor akSpeaker = akSpeakerRef as Actor
;BEGIN CODE
vkjOwnerComment _vkjOC = Quest.GetQuest("vkjOwnerComment") as vkjOwnerComment
_vkjOC.MQ.Punish()
_vkjOC.End()
;END CODE
EndFunction
;END FRAGMENT

;END FRAGMENT CODE - Do not edit anything between this and the begin comment

 

 

[HexBolt8]

47 minutes ago, Roggvir said:

i recommend the following fix, replacing every call to GetOwningQuest() with Quest.GetQuest("vkjOwnerComment"):

I don't know about this.  That's a sweeping change.  If you do a "find in files" search you'll see many many uses of GetOwningQuest(), not only in base Skyrim but in very respected and mature mods.  It doesn't seem plausible that it's so bad everywhere.  That boggles the mind.  If there are a few specific instances where reasonable clicking through dialog consistently breaks something in the mod, that could be a candidate for a change.  But I personally haven't seen much weird behavior with dialog in this or other Skyrim mods, excluding known conflicts involving blocking dialog and force greetings.

 

If this particular thing is worrisome to you, you might want to ask about it in a general Skyrim technical or modding discussion to see what others have to say about it.

[Roggvir]

3 minutes ago, HexBolt8 said:

I don't know about this.  That's a sweeping change.  If you do a "find in files" search you'll see many many uses of GetOwningQuest(), not only in base Skyrim but in very respected and mature mods.  It doesn't seem plausible that it's so bad everywhere.  That boggles the mind.  If there are a few specific instances where reasonable clicking through dialog consistently breaks something in the mod, that could be a candidate for a change.  But I personally haven't seen much weird behavior with dialog in this or other Skyrim mods, excluding known conflicts involving blocking dialog and force greetings.

True, but i didn't mean to replace it EVERYWHERE, but only in this tiny script - like you wrote "specific instances where reasonable clicking through dialog consistently breaks something" - this is exactly the case.
It's up to you, i did it in my personal hotfix and everything is fine now, so i'll stop nagging

[HexBolt8]

14 minutes ago, Roggvir said:

True, but i didn't mean to replace it EVERYWHERE, but only in this tiny script - like you wrote "specific instances where reasonable clicking through dialog consistently breaks something" - this is exactly the case.

I just took the meaning of "replacing every call to GetOwningQuest()" as replacing it everywhere.  I got hung up on the word "every".    Sure, if it's a problem in one script and the change has tested out better for you, I appreciate the suggestion and I'm happy to make the change.

 

Edit:  Done now for the next update.

[cerebus300]

Just a question on one of the new options in the MCM, the Anti-Cheat toggle. I'm not sure if this locks down JUST the two functions on that page (gold and keys from master) or if it locks down all of the toggle settings within the game. Just want to know before I use it. It would be nice if that was set so that it can be reset once you are no longer under the control of a Lola master. Then you could readjust things but have it locked down as long as the character was enslaved. 

[HexBolt8]

1 hour ago, cerebus300 said:

Just a question on one of the new options in the MCM, the Anti-Cheat toggle. I'm not sure if this locks down JUST the two functions on that page (gold and keys from master) or if it locks down all of the toggle settings within the game.

Just those two options, and only if they're enabled.

1 hour ago, cerebus300 said:

It would be nice if that was set so that it can be reset once you are no longer under the control of a Lola master.

It doesn't work that way.  It's permanent.  Of course it only applies to a Sub Lola owner, not followers in general.  Honestly I don't recommend locking it and making it permanent, but some players like anti-cheat features so it's there.

[coffeeink]

btw.

 

Can you link the Solutions post for the Sexlab Surival and Devious Follower in the front post?

[Herowynne]

1 hour ago, coffeeink said:

Can you link the Solutions post for the Sexlab Surival and Devious Follower in the front post?

 

I cannot make any changes to this mod's front page, but I can provide links to my posts.

 

Improving Compatibility between Submissive Lola and Devious Followers Continued (DFC)

 

Improving Compatibility between Submissive Lola and Sexlab Survival (SLS)

[cerebus300]

16 hours ago, HexBolt8 said:

Just those two options, and only if they're enabled.

It doesn't work that way.  It's permanent.  Of course it only applies to a Sub Lola owner, not followers in general.  Honestly I don't recommend locking it and making it permanent, but some players like anti-cheat features so it's there.

Thanks. Yeah, I will probably not enable it. I like some of the anti-cheat features in mods but I don't want them to be permanent. Thanks for updating this mod. I was really happy to see some more options present themselves. I use this and Devious Followers together and it makes for a nice range of options, but still allows for adventuring and getting out and about in the world. I like the conversation that you have made so central to the relationship. It definitely makes it more engaging. 

 

One thing that I would like to see is more settings to control the extent of some of the effects. I've found that the master turning on the vibes can be really invasive. It just happens so often that I feel like I can't walk across the street without them going off and bringing me to a halt. It is especially a problem in dungeons. I don't have a problem with it, even when it messes me up, but the sheer amount of time that it is active gets frustrating. It is that which usually makes me end the slavery and I uninstalled the mod at one point because I didn't want to wind up back in it. I have reinstalled the latest edition and am enjoying it again, but yeah, the amount of time that is dominated by vibrating plugs is frustrating. A sliding scale would be wonderful.