Devious Followers - Continued

[Lupine00]

  

40 minutes ago, HexBolt8 said:

SendModEvent("SSLV Entry") is the mechanism for other mods to send the player to SS.  It's not something that SS broadcasts to announce that the PC has arrived at the slave market.  SS is the consumer of that event.

Except of course, when it does send it  

But if you look up, you'll see that's exactly what I said (I quote it below, again in green), give or take some phrasing.

 

The key point here is that SS is not the sole consumer of that event.

 

34 minutes ago, HexBolt8 said:

Okay so we're all good then?  No problems?

I'm not sure you read my post. You might need to revisit that. 

Maybe you wrote your response while I was writing mine and so never saw it, I'd say it has some relevant information you should see...

 

In particular, this: unless you are enslaved via the Defeat SS hook, the enslaving mod is responsible for calling SSLV Entry, and that is what puts you into the auction.

Yes, I know I say different things each post, but that's due to adding more facts each post, as I spend my evening digging into the delights of SS and how DF integrates with it - which I did look into a couple of months back, but already erased from my memory, like an unpleasant and embarrassing drinking incident where you slipped over while dancing on tables and landed bum first in a puddle of spilled beer, narrowly avoiding a concussion.

 

DF calls it, and I should assume that ANY mod that puts you in SS must call it, or SS will not work correctly.

 

As such, DF should always be seeing that event and handling it too.

And that code in DF removes the DF follower.

 

So, if the follower isn't removed, it's likely for the reasons I posit above, which you may have skimmed over.

 

 

What's going on in SS isn't really ... OK ... and I'm not surprised it is unreliable in its function, because it is objectively broken in various ways.

 

We can be reasonably confident that the DF is removed if DF sends you, but they may not be removed if called by some other mod, and SS crashes during event handling, which it looks quite capable of doing.

 

 

You touched that mess now, so you own it  

[valcon767]

4 hours ago, Lupine00 said:

I'll check the code. It's very easy to reset from the console if you feel it should be fixed.

It isn't reset, and now I think about it, that wasn't an accident.

Boredom is reset, but fatigue isn't.

Fatigue is a more lasting consequence. You can get rid of it via the donation mechanic, if you have the money.

It would probably make sense if you lose a point or two every time you sleep without a DF.

 

Which version of Simple Slavery?

 

IIRC SS+ will remove the DF.

SS++ should be the same?

Old SS, definitely doesn't remove them.

 

DF doesn't even know you are in SS, so doesn't remove the follower.

its not i think it should be fixed, just wanted to make sure it was working correctly, and it is, so that's all good.

 

1 hour ago, Lupine00 said:

I believe the issue is that the PC can end up there without being sent by DF, while a DF follower is still attached.

 

The "SSLV Entry" event code in DF was written by Lozeak, and is definitely for handling follower removal.

 

I see this code in SS:

  Reveal hidden contents

 

In SSLV_MainScr.psc

event oninit()
    debug.trace("registering for mod event 'SSLV Entry'")
    RegisterForModEvent("SSLV Entry", "on_new_slave")
    RegisterForModEvent("PlayerRefEnslaved", "PEnslave")
    RegisterForModEvent("PlayerRefFreed", "PUnEnslave")
    RegisterForModEvent("PlayerRefIsFree", "PEnslaveCheck")
    UnregisterforUpdate()
    RegisterForSingleUpdate(1.0)
endevent

 

In SSLV_SSDefeat.psc

Function BeginQuest()
    SetData()

    int iModEvent = ModEvent.Create("SSLV Entry Extended")
    ModEvent.PushForm(iModEvent, theLast)
    ModEvent.Send(iModEvent)

    SendModEvent("Defeat_Event", "Restore")

    stop()
EndFunction

 

 

My conclusion is that unless you are enslaved via the Defeat SS hook, the enslaving mod is responsible for calling SSLV Entry, and that is what puts you into the auction.

It also causes DF to remove your follower.

 

DF fires that event to send the player to SS.

 

In all those cases, it explicitly fires a DF-RemoveFollower event before firing it.

So, even if it doesn't react to its own event, the follower is still removed.

 

did a fast test case of this one.

used DCL combat surrender to ensure i was sent (by it) to SS++.

went to auction, was sold, ended up in DCL Rubber Doll quest.

my DF was not fired, still had the same debt, and the DF MCM showed that i had 1 DF still.

debt did NOT increase after waiting one day then fast traveling to Deep Folk Crossing then walking to Dragon Bridge (to give DFC plenty of time to increase debt

if it was going to).  then i fast traveled to Lakeview Manor (MYIYH set home location of DF).

 

was able to change minimum contract setting (which you cannot do if you have a DF following you even if contract time is over).

 

once in proximity to previous DF she joined (without me hiring her) again as a DF.  tried again outside, before going near previous DF, and

was able to have Rachel (housecarl) follow me and she fired right off as a DF.  DF debt then increased at normal daily rate (and yes extra followers does cost me more)

as far as i could tell it all proceeded normally as if i had a single DF with no extra followers, until i went near previous DF, she then joined party (without me hiring her)

and DF debt rate changed properly.  all then worked as it should for having 2 DFs with me.

 

i do think the failure of the DF being fully fired is due to a quirk of the version of IAFT i use  (it takes firing her twice to actually get the right fire dialogue to

show from the "i think its time to part ways" dismissal line for me).

while i cannot say that it did fully fire my DF, it did make it so that at least the follower was not currently following me and DF debt was not increasing.,

and i could adjust the MCM settings as if i had no DF at all.

while not a perfect result it works for me.  i do think the failure to fully fire the DF was/is due to a quirk of my setup.

 

[Lupine00]

1 hour ago, valcon767 said:

i do think the failure of the DF being fully fired is due to a quirk of the version of IAFT i use

Your AFT shouldn't do that, it's broken.

 

Nevertheless...

 

Spoiler

 

This event code should be triggered by "SSLV Enter"

 

Event SSClean(String eventName, String strArg, Float numArg, Form sender)
    If Q.getstage() >= 10
        Q.RemoveFollower()
        Q.Tool.MCM.ResetQuests()
    EndIf
endEvent

 

and we have

 

Function RemoveFollower()
    Actor who = Alias__DMaster.GetActorRef() As Actor
    Q2.RemoveFollower(who)
    who.AddToFaction(pDismissedFollower)
    Alias__DMaster.Clear()
EndFunction

 

Where Q2 is the follower controller...

 

Function RemoveFollower(Actor who)
        
    If 255 != Game.GetModByName("AmazingFollowerTweaks.esp")
        _df_AFT_extensions.RemoveFollower(who)
        Return
    EndIf
    
    If 255 != Game.GetModByName("EFFCore.esm")
        _df_EFF_extensions.RemoveFollower(who)
        Return
    EndIf

    If 255 != Game.GetModByName("nwsFollowerFramework.esm")
        _df_NFF_extensions.RemoveFollower(who)
        Return
    EndIf

    (pDialogueFollower As DialogueFollowerScript).DismissFollower(0, 0)
        
EndFunction

 

and

 

Function ResetQuests()

    (DealController As  QF__DflowDealController_0A01C86D).ResetAllDeals()
    BoredomQuest.Reset()
    Dflow.Reset()
    SEvents.Reset()
    Games.Reset()
    QuestStage.SetValue(1)
    Resist.SetValue(10)
    Will.SetValue(10)
    DFPotQ.ResetQuest()
    ForcedStart.Reset()
    GoldCont.Endit()
    MDC.End()
    MDC.Update()
EndFunction

 

And the AFT Code...

Function RemoveFollower(Actor who) Global

    Form dialogFollower = Game.GetForm(0x000750BA)
    TweakDFScript aftScript = (dialogFollower As TweakDFScript)
    
    If aftScript
        aftScript.DismissFollowerEx(who, 0, 0)
    EndIf

EndFunction

 

 

i.e. If DF is actually running (stage >= 10) then remove the follower by removing them from the follower framework, and the DF alias, and resetting all DF quests.

 

So ... something is probably broken in your game, and it sounds a bit like you don't have the built-in DF patch for AFT overwriting correctly.

 

Debt is not reset, by design, that happens on hire, if you hire cleanly, but everything else is, such as deals.

Looking at this, the resist value is a bug, so ... hey ... got some value here.

 

The follower count takes a little while to update sometimes, but is dependent on the AFT patch working properly.

 

You say:

once in proximity to previous DF she joined (without me hiring her) again as a DF.  tried again outside, before going near previous DF, and

was able to have Rachel (housecarl) follow me and she fired right off as a DF.

 

I'd say that she was removed from DF but not AFT.

She could not join if DF wasn't in a quest stage < 10.

 

 

Remember that normally, if you remove a DF, other followers in the framework may still be attached, and may become the DF.

That is probably very broken for SS. DF needs to be able to purge all followers in that case - very sad - a lot of bother to make that work as I have to reinstall each one of the frameworks in turn and fix for each. Will take days, alas. Don't hold your breath for that one.

 

I guess this means the whole look into SS was a wild goose chase, and the issue was the AFT patch not being properly applied, or not working because it's wrong somehow. It did work at some point...

 

IMHO, SS should be removing these followers. It's absurd to expect DF to do it.

 

If you get enslaved while DF is not running, or not installed, and have a follower, that follower is probably going to be sitting in the auction house with you, free, in their armor, not enslaved. Just like happened to me with DCL Leon last time I used him.

 

Some mods may "handle" followers, but how? Does it have an enslavement for them? AFAIK, only SD+ can handle follower slaves, apart from actual follower-slave mods like PAH or Sex Slaves, etc. I don't think they would continue to need to be followers in that case, and probably shouldn't if you're going to be enslaved - potentially separately. 

 

Joking aside, Hexbolt and friends can't really be expected to fix this in SS, but I hope they might  

[Balgin]

1 minute ago, Lupine00 said:

Ah. It was posted here? I have her blocked so I know nothing about it.

I did wonder why you didn't respond to those two post on the previous page.

[valcon767]

55 minutes ago, Lupine00 said:

Your AFT shouldn't do that, it's broken.

 

Nevertheless...

 

  Reveal hidden contents

 

This event code should be triggered by "SSLV Enter"

 

Event SSClean(String eventName, String strArg, Float numArg, Form sender)
    If Q.getstage() >= 10
        Q.RemoveFollower()
        Q.Tool.MCM.ResetQuests()
    EndIf
endEvent

 

and we have

 

Function RemoveFollower()
    Actor who = Alias__DMaster.GetActorRef() As Actor
    Q2.RemoveFollower(who)
    who.AddToFaction(pDismissedFollower)
    Alias__DMaster.Clear()
EndFunction

 

Where Q2 is the follower controller...

 

Function RemoveFollower(Actor who)
        
    If 255 != Game.GetModByName("AmazingFollowerTweaks.esp")
        _df_AFT_extensions.RemoveFollower(who)
        Return
    EndIf
    
    If 255 != Game.GetModByName("EFFCore.esm")
        _df_EFF_extensions.RemoveFollower(who)
        Return
    EndIf

    If 255 != Game.GetModByName("nwsFollowerFramework.esm")
        _df_NFF_extensions.RemoveFollower(who)
        Return
    EndIf

    (pDialogueFollower As DialogueFollowerScript).DismissFollower(0, 0)
        
EndFunction

 

and

 

Function ResetQuests()

    (DealController As  QF__DflowDealController_0A01C86D).ResetAllDeals()
    BoredomQuest.Reset()
    Dflow.Reset()
    SEvents.Reset()
    Games.Reset()
    QuestStage.SetValue(1)
    Resist.SetValue(10)
    Will.SetValue(10)
    DFPotQ.ResetQuest()
    ForcedStart.Reset()
    GoldCont.Endit()
    MDC.End()
    MDC.Update()
EndFunction

 

And the AFT Code...

Function RemoveFollower(Actor who) Global

    Form dialogFollower = Game.GetForm(0x000750BA)
    TweakDFScript aftScript = (dialogFollower As TweakDFScript)
    
    If aftScript
        aftScript.DismissFollowerEx(who, 0, 0)
    EndIf

EndFunction

 

So ... something is probably broken in your game, and it sounds a bit like you don't have the built-in DF patch for AFT overwriting correctly.

 

I'd say that she was removed from DF but not AFT.

She could not join if DF wasn't in a quest stage < 10.

 

 

Remember that normally, if you remove a DF, other followers in the framework may still be attached, and may become the DF.

 

thought there might be an issue with the IAFT i was running, so re-downloaded and re-installed it.

that did clear up the double fire needed.  now it fires correctly with a single dialogue.

 

retested the SS++ portion after that.   follower is removed as a DF (and from DF) but not from IAFT, when sent to SS++ from combat surrender (Cursed Loot).

so follower ends up in the SS++ slave pen with me and unless fired fast does become a DF again.  don't think there is really anything you can do about that, as

it is not something your mod controls.  the part your mod controls works.

 

so improvement, at least the IAFT and DFC work better together now.

 

now if there was only a easy way for SS++ to fire all followers.  ah well i know that is a pipe dream.

 

[ck2modfan]

Please consider adding penalties for follower carrying too much stuff. Either add a cost similar to aroused followers or if exceed a limit automatically require a deal. Having the follower be a mule and carry enough loot to pay off the debt should not be encouraged ?

[Mikarun]

Would you ever consider renaming the Dragon/Skeever/Slaughterfish/Wolf deals? I legit thought that they were creature content and almost filed a bug report about them still triggering with the toggle off before I realized what they were. And I still can't remember which is which, making it annoying to agree to them without knowing what they are. Or is the mystery part of the point?

 

[HexBolt8]

8 hours ago, Lupine00 said:

You touched that mess now, so you own it  

I know.  When I was being encouraged to take it over I initially declined, stating that I didn't want to own SS's problems.  However, now that I have taken it over, yes I own any messes there. 

 

6 hours ago, Lupine00 said:

IMHO, SS should be removing these followers. It's absurd to expect DF to do it.

I'm not going to venture into the discussion of what other mods should do.  They receive the SSLV Entry event from the defeat or enslaving mod and can do whatever they think is best. 

 

Regarding SS++, I'll just say that it will not remove followers.  To the best of my knowledge it never dismissed followers itself, and I don't want to add follower dismissal as new functionality now, over 6 years into SS's life.  All it does is strip the PC, play an auction scene, and hand the PC off to an enslavement mod.  I'd like to keep it that way.  If follower dismissal is in limbo that's unfortunate, but I don't want SS to take on a new job.

 

From my perspective as a player, I wouldn't want SS or a defeat mod to dismiss my follower, unless the defeat mod has special handling and can make its own decision that dismissal is appropriate.  For example, after combat defeat the follower is locked in a cage while you're sent off to SS auction.  That defeat mod could reasonably dismiss the follower and leave it to the player to choose whether to go back to rescue and re-recruit the follower.

8 hours ago, Lupine00 said:

I'm not sure you read my post. You might need to revisit that. 

Maybe you wrote your response while I was writing mine and so never saw it, I'd say it has some relevant information you should see...

 

In particular, this: unless you are enslaved via the Defeat SS hook, the enslaving mod is responsible for calling SSLV Entry, and that is what puts you into the auction.

Looking at the timeline, it appears that we were posting at the same time, so the responses don't mesh well.  Regarding comment edits, this site doesn't provide a notification that a previously-read comment was changed, so unless I obsessively keep scrolling up to eyeball previous posts and look more anything that might be different, I'll miss it.  You can't expect a reader to keep scrolling up like that.  Admittedly, I edit my own comments at times to clarify or offer more detail, but in those cases my audience is people who haven't read it yet.  I wouldn't expect anyone who's already seen my post to keep checking back for changes. 

 

Regarding your point in green, we are 100% in agreement.  So we disagree on whether SS should dismiss followers itself.  Other than that, I don't think there's a problem between this mod and SS++. 

[Lupine00]

4 hours ago, HexBolt8 said:

Regarding comment edits, this site doesn't provide a notification that a previously-read comment was changed, so unless I obsessively keep scrolling up to eyeball previous posts and look more anything that might be different, I'll miss it.  You can't expect a reader to keep scrolling up like that.

I wasn't talking about comment edits, I was talking about refining the story in successive posts. There was no need to scroll back, only a need to follow the information in the latest post

 

4 hours ago, HexBolt8 said:

I'm not going to venture into the discussion of what other mods should do.  They receive the SSLV Entry event from the defeat or enslaving mod and can do whatever they think is best. 

And yet, SS is deciding what other mods should do, if they use it.

 

There are, like it or not, good practices for modding, and bad. If we don't identify, establish and communicate those, things cannot improve.

 

4 hours ago, HexBolt8 said:

From my perspective as a player, I wouldn't want SS or a defeat mod to dismiss my follower, unless the defeat mod has special handling and can make its own decision that dismissal is appropriate. 

The problem you have is that SS is the mod creating the odd behavior, 100%, it doesn't need a conflicting mod to get involved for that to happen.

 

If you have a vanilla follower, no other mods of note, and an "innocent" source of SS events, you simply raise your SS Entry event and the player ends up in SS, along with their follower. Are there such sources? Should we blame the defeat mod when it doesn't handle followers? Said mod could reasonably expect them to be handled in the single obvious place, instead of replicating that handling into every defeat mod.

 

The actuality, is that players have been living with sketchy behavior from SS from day one, and they accept a mod that has problems because:

1) the auction scene is compelling,

2) it let them get new slavery outcomes from diverse mods, and the calling mods didn't have to know about the ultimate destination

 

4 hours ago, HexBolt8 said:

Regarding SS++, I'll just say that it will not remove followers.  To the best of my knowledge it never dismissed followers itself, and I don't want to add follower dismissal as new functionality now, over 6 years into SS's life.  All it does is strip the PC, play an auction scene, and hand the PC off to an enslavement mod.  I'd like to keep it that way.  If follower dismissal is in limbo that's unfortunate, but I don't want SS to take on a new job.

 

The problem with SS, is that it has no code design, and no model of responsibilities.

The source (now) contains huge chunks of cut+paste. The main file is 80% duplicate nonsense. There's support for mods in there it doesn't even support now (the active code elements are commented out so the enslavement doesn't happen), and it has never (as you note) taken responsibility for removing followers; something that should always have been its responsibility.

 

The version we see today has been hacked about by different authors who really only wanted to add support for a new mod and don't want to suffer the pain of fixing the years of accumulated damage and poor decisions in there.

 

 

No matter how you spin it, an argument that it is unsafe for SS to remove followers doesn't stack up.

 

 

Any defeat mod has ample opportunity to handle followers prior to calling SS Entry, and should.

Those followers should be long gone before you enter SS.

 

But... why should every defeat mod have to implement this functionality (which is actually complex)?

It could be in one place. Done right. Once. Don't Repeat Yourself.

Certainly, there is no harm in it being present in SS.

 

They should always be removed by some means, because there's no situation where you want the vanilla follower scripts running on a follower while you are trying to run an SS auction (or an enslavement for that matter).

I'll zero in on the key phrase here, "no situation".

There are certainly things a defeat mod might want to do with a follower in that case, but none of them involve running vanilla follower AI during a slave auction.

If you want to enslave or imprison followers, put that NPC in a completely different alias, and handle them there; don't put them in the most contentious shared alias in the game.

 

If a defeat mod wants to put your followers in a cage, they need to stop being followers; that is far more robust solution than giving your cage quest enough priority to override any other AI that any follower framework may execute, or that mods may push onto followers with no regard or understanding of the slavery condition. The chance of reliably caging a follower while leaving them in the follower alias, is slim to none, and even if it worked it would still be a poor design decision.

 

If your follower is not with you, why is the precious shared resource of your follower slot filled with an NPC who is in a cage on the other side of the map?

It's unjustifiable; or only justifiable in terms of "hey I did this mod, I have no idea what I'm doing and I make no promises, it probably breaks your game, enjoy".

We accept that mods have bad decisions in them because people didn't know better.

There are still areas of Skyrim where we don't know what is right or best, and there always will be.

But when we see an oft-repeated mistake, it's time to say "that's not best practice, please don't do that", and stop doing it ourselves, or defending it.

 

 

 

With SS, we know the problems.

We know what's right, and to SS has always worked this way, so don't change it.

It's like saying, "It should stay broken because it is broken."

 

That position simply blocks ever fixing anything.

 

Yes, I know it's a straw man, but the point is that deference to pre-existing behavior only makes sense as a prioritization factor, and has no place in arguments about best-possible outcomes.

 

 

 

Defeat mods that keep followers in the follower slot and don't dismiss them fail because of it. This is trivially demonstrable in the defeat mods we have today.

They fail to remove the follower, and the results are frequently bad.

DiD sometimes managed to keep followers out of the way, and often failed at it. Newer DiD still fails. (Not that DiD even uses SS).

The root cause is that the follower is still in a follower alias. If you remove them from it, the problem is gone.

And that's for DiD's own imprisonment.

DCL also has a poor track record of follower removal. It looks like it only removes them if they are registered for DD handling, so male followers, or dominant followers likely won't be handled.

SexLab Defeat is - as far as I can tell - being handled by code in SS itself - because Defeat itself is not maintained.

I don't think DA works with SS unless you also have Defeat?

That's all the defeat mods.

I know there's a mod that puts your followers in cages (Caged Followers?) but if it leaves them in the follower aliases while it does it, it's making a mess and it should probably stop.

 

Having them in the auction is immersion destroying enough, but the followers can't just be left there to break the destination slavery mod.

 

In any case, there is no vast number of actively maintained defeat mods. There is only one: DCL.

DiD is in the middle of a rewrite that may (or may not) one day materialize, and in the meantime the released working version is also abandonware that has been posted as "will not fix". Again, I understand this is only peripheral to SS, but it's related to establishing protocol for followers.

 

 

So, setting apart some non-existent future defeat mod that wants to do something fancy with followers, and maintain state while slavery mods it potentially knows nothing about are executing, there is no good reason to retain followers in SS. And if you look at what I just said, the idea of a defeat mod trying to do that is plain crazy and will never work reliably, especially if it thinks to keep the follower(s) slotted during that process.

It cannot work.

Ever.

DF itself would break that model.

Submissive Lola breaks that model.

 

They all break it because they use the follower slot - a precious shared resource - for the enslavement master.

 

That itself might be a broken pattern, but its so often replicated and bound into so much code, it's hopeless to try and fix that.

OTOH, SS has a small amount of code, much of which is cut+paste, or incredibly poor ways to handle random selections of strings; it can be fixed.

 

 

Leaving followers slotted during defeats is a broken pattern, and this needs to be recognized and understood.

It has consequences for SS.

 

 

Removing followers in SS, before porting the PC into the pre-auction holding cell, should never be wrong.

Any defeat mod that thinks passing a PC with followers into SS is simply wrong. It cannot work.

 

 

It is absurd to require every single SS source to re-implement follower removal for multiple follower frameworks; it should be in one place.

 

 

It's SS that breaks because first because of these followers, and it should clean its own house.

It's also the best place to put that code ONCE so others don't have to re-implement it (and get it wrong).

 

 

However, if whoever is adding plusses to the end of the SS name today doesn't want to do that ... that's fine ... but building up an argument that SS shouldn't be responsible for cleaning followers, when it is by far the best and most obvious place to do so, and is broken if it doesn't, isn't helping the future of SS when the next plus-adder comes along.

 

 

The design of SS, where the enslavement code has to be added to the SS source, is trivially avoidable.

All a mod should need to become an SS outcome is to call a mod event that tells SS what mod event name IT should fire to enslave into the target mod (and what to show in the menu). Two strings, basically.

 

Anyone who has ever called a mod-event can see how this would work. It's incredibly simple and dependency free.

 

 

If that had been done, day one, we wouldn't have this crazy situation where everyone who wants to add support for a new mod has to alter the SS source; cut+pastes the same piece of code and changes a line at the end to enslave into their own mod.

 

Support for old mods could exist in a single file that shims the events, and that would never need updates because those mods don't change.

 

 

For a long time I've thought about sorting out SS properly.

 

It needs to be re-coded from scratch to work properly with DD and Zap.

It needs to remove any dangling followers prior to port-in.

It needs to use the mod-event mod-registration approach described above.

The existing auction house has gaps and holes in it.

And it could be updated to make better use of existing NPCs,

to better comments about the current state of slavery mods,

to allow new auction participants to be added via JSON so players can even make their own,

to have auction comments that have some tiny amount of relevance to the PC being sold,

and so on.

 

 

Until SS came and left a brown curly emoji on my doorstep, this was something I could ignore, but now it's becoming a problem for me.

 

I've wasted many hours already tracking down a non-bug in DF, digging through SS source, and now writing an essay on basic principles of software design as applied to followers in Skyrim.

 

 

I've made a post that recaps some of this on my blog.

There needs to be some code that works from a mod event that will remove all followers, including the ones that don't use the vanilla slot.

SS would be one place to put that.

It could also live in a standalone mod.

 

 

• The scope of Simple Slavery should be such that it takes in "dirty" PCs and cleans them before handing them to the destination. It's already trying to do this, just not doing it completely.
• New mods should register to SS; SS should not be secretly adopting them as targets.
• SS should not contain set-up code for the destination (except in so far as some legacy cases need to be supported).
  That is to say, anything required to induct the PC into a destination mod should be in the destination mod, not SS, except in so far as the mod should be able to assume the PC is clean, device-free and follower-free on entry. (Excepting some legacy cases).

 

As for who should do this?

SS has no exclusive owner.

Whoever wants to do this should do it.

 

Maybe that means it never happens, but arguing against it, or deliberately getting in the way of it isn't helping.

[HexBolt8]

I'll just say that I disagree.  As a player, I don't actually want SS dismissing my followers.  SS is a conduit.  It's a courier that delivers the package without caring what's inside, as long as it reaches the right address.

 

My intent was simply to make SS+ a little better.  You can mock my efforts and the extra + (which was actually jfraser's suggestion, though I liked it too), but it is better than SS+.  The auction scene plays reliably now.  It looks nicer, has configuration options, and lets the player decide whether to proceed when wearing blocking or quest devices.  The main script is 20% smaller but does more. 

 

Again, my intent was to make SS+ a little better.  And then this.  Was Lozeak's life like this?  I hope not.

[cat013]

1 hour ago, HexBolt8 said:

Again, my intent was to make SS+ a little better.  And then this.  Was Lozeak's life like this?  I hope not.

Pity you took Lupine's wall of text negatively - this feature would greatly improve overall compatibility situation. Because unfortunately SS is not a courier. It is more like an assembly line worker who is too often ordered to force square pegs into triangular holes. Yes, this is the whole problem with couriers: for this metaphor to work both sender and receiver need at least to speak the same language.

 

As a side note: I believe the right thing for the most followers in a defeat situation would be to show up among the buyers and bid on PC (driving the prices up as a side effect). How high they can bid and whether they're doing it out of goodness of their heart or for more selfish reason - it's up to particular follower. PC's prior owners, if any, may also bid... you get the idea. This, of course, needs to be initiated on the follower/owner side, unless strictly vanilla (LL-agnostic) followers are involved.

[Lupine00]

12 hours ago, HexBolt8 said:

You can mock my efforts and the extra +

Attempts at humor on the internet are prone to go awry it seems.

 

I didn't intend to mock, even if I disagree with the matter of follower dismissal, I'm not trying to attack anyone here.

Nor did I claim that updating SS+ into SS++ was doing anyone a disservice.

 

The problem with SS++, if there is one beyond the pre-existing state of SS, is that its brought attention to SS functionality, which then leads to complaints about DF's integration, which is pretty ironic, given that of all the mods that can send you to SS, DF is the only one ever likely to support any follower frameworks.

 

That I'm now being pushed to do that work is partly my own fault for not thinking of it earlier, but I don't think that DF is the correct place to solve this.

Fixing DF to support correct dismissal of all followers will not help a single other mod.

That's what I'm getting at here.

 

On the blog post, I address this a little differently, and consider other locations for this code, besides in SS itself.

 

One place it definitely should not be, is redundantly duplicated on every mod that can send you to SS.

That is clearly a poor scenario.

However, in actuality, we have an even worse case; it's replicated incorrectly on some mods that can send you to SS, and incompletely on some others.

There is no mod at all that gets this right for all follower frameworks and a good range of popular special followers.

 

I can't understand the rationale of how purposely not fixing the root problem will deliver benefits to players or modders alike.

 

I could understand an argument that players can put up with the existing bugs, so let's not bother fixing the issue ... sure ... this may not be worth the effort.

I'll see how much people complain about it.

 

 

If you don't want to do it yourself, I understand, that. I don't want to do it either. I don't imagine anyone does.

Though maybe we could scope it down a bit...

But if I fixed this now for DF, it would be done in a way that no other mod benefits from, due to the quirky nature of the DF follower-framework integration.

 

Is that ideal?

Would we rather have this never fixed?

Is it realistic to expect it ever to be fixed in old SS source mods that are not maintained? Those mods can't change, but SS can.

[Fruktoza]

Hello. Game situation: the player (fem.) wears a gag and a belt. Result: the exchange trade scene (_DFlowModDealControllerMerchant, _DFlowModDealController quest) starts but has no continuation and is reset because some of the dialogues in the second stage of the scene do not allow gags or belts, or both. Further, with any approach to the merchant, the same thing happens. We have to remove the devices through debugging, then put them on again (we are playing honestly ...) The conclusion suggests itself that the devious follower at the first stage of the scene either must remove the necessary devices (gag, belt) and then return them, or should not offer the player's dealer in exchange for discount if the player wears a gag and belt.
P.S. Sorry, translation – machine.
(Привет. Игровая ситуация: игрок (женщина) носит кляп и пояс. Результат: сцена меновой торговли (_DFlowModDealControllerMerchant, квест _DFlowModDealController) запускается, но не имеет продолжения и сбрасывается, поскольку в условиях некоторых диалогов второй стадии сцены не разрешены кляпы или пояса, или и то, и другое. Далее при любом подходе к торговцу происходит то же самое. Приходится снимать девайсы через отладку, потом снова надевать (мы же честно играем…) Напрашивается вывод, что коварный спутник на первой стадии сцены либо должен снимать необходимые девайсы (кляп, пояс) и после их возвращать, либо не должен предлагать торговцу игрока в обмен на скидку, если игрок носит кляп и пояс.)

[Lupine00]

3 hours ago, Fruktoza said:

Hello. Game situation: the player (fem.) wears a gag and a belt. Result: the exchange trade scene (_DFlowModDealControllerMerchant, _DFlowModDealController quest) starts but has no continuation and is reset because some of the dialogues in the second stage of the scene do not allow gags or belts, or both. Further, with any approach to the merchant, the same thing happens. We have to remove the devices through debugging, then put them on again (we are playing honestly ...) The conclusion suggests itself that the devious follower at the first stage of the scene either must remove the necessary devices (gag, belt) and then return them, or should not offer the player's dealer in exchange for discount if the player wears a gag and belt.

Yes. I understand.

 

This was changed recently. 

 

Previously, NPC would just try to sex you anyway, and it would be broken due to lack of good animations.

As it is, it ends with no sex, but you can at least trade.

It SHOULD work if only gagged, or if only belted.

 

Belt removal seems reasonable for this, or not being offered at all. I can fix one or the other.

[Fruktoza]

3 hours ago, Lupine00 said:

As it is, it ends with no sex, but you can at least trade.

No, you can't trade: the player is in a stupor for about ten seconds, the dialogue is reset, and with a new attempt to speak, everything is repeated. ?

[Lupine00]

8 hours ago, Fruktoza said:

No, you can't trade

Shouldn't repeat. There's a cooldown timer on the event.

 

I will test on my end at some point.

 

If you're hardcore, gagged players shouldn't be able to trade anyway  

 

Various mods enforce that. Are you using one?

[gravediggers240]

On 7/15/2020 at 1:23 PM, Kimy said:

Oh, btw, you might be interested in this code I am going to add to the next DD version:
 

; returns if a given device has a manipulated lock
Bool Function IsLockManipulated(Actor a, Keyword kw)
    if a != PlayerRef || !a.WornHasKeyword(kw)
        return false
    EndIf
    If StorageUtil.GetIntValue(a, "zad_Equipped" + LookupDeviceType(kw) + "_ManipulatedStatus") == 1
        return true
    EndIf
    return false
EndFunction

; Not sure if that's useful or not? But it will mark the lock as manipulated, so the player can just remove it whenever she wants to.
Bool Function SetLockManipulated(Actor a, Keyword kw)
    if a != PlayerRef || !a.WornHasKeyword(kw)
        return false
    EndIf
    If StorageUtil.SetIntValue(a, "zad_Equipped" + LookupDeviceType(kw) + "_ManipulatedStatus", 1)
        return true
    EndIf
    return false
EndFunction

; Manipulated your lock? Well...it no longer is! The device now behaves as if the locks are fully engaged.
Bool Function SetLockUnManipulated(Actor a, Keyword kw)
    if a != PlayerRef || !a.WornHasKeyword(kw)
        return false
    EndIf
    If StorageUtil.SetIntValue(a, "zad_Equipped" + LookupDeviceType(kw) + "_ManipulatedStatus", 0)
        return true
    EndIf
    return false
EndFunction

 

Here's the bit you might be interested in Lupine. Any use to you? Figured you had her blocked, she posts this then you immediately talk about not being able to check if locks are manipulated.

I've got a couple questions about the latest 2.12.2 release, if you wouldn't mind answering them.
Is there any way to reduce follower boredom? Might just be my game, but nothing I've done has caused it to go down, which has left me in kind of a hard place.
The Gambling Game doesn't reduce required deals even though it is a game, is that intentional?

Love the mod so far, keep up the great work!

I am running the Forum 2.12.2 release, as I don't use spanking and wouldn't have benefited from the extra fix pushed in the mod page version.

[Lupine00]

5 hours ago, gravediggers240 said:

Here's the bit you might be interested in Lupine. Any use to you?

What a performance after all that stuff about corrupting the purity of the feature, and making the entire thing an MCM option, and so on and on.

 

I will clarify again that the "argument" that followed was not about this feature, but about deceptive claims about what I said, and bogus arguments constructed against things I never advocated.

 

I will care about this feature when it's rolled out in an official DD release, with a version number update that makes it possible to determine it's actually supported.

At that point it will be a nice addition; though simply exposing a property on the ObjectReference instead of hiding it in an internal variable, would have served when the feature was first added.

 

By the look of this, the manipulation status has been moved to StorageUtil, which avoids having to obtain the ObjectReference at all.

It's probably better this way, but I'm fairly neutral on it.

[Fruktoza]

11 hours ago, Lupine00 said:

Shouldn't repeat. There's a cooldown timer on the event.

 

I will test on my end at some point.

 

If you're hardcore, gagged players shouldn't be able to trade anyway  

 

Various mods enforce that. Are you using one?

I test DF of course on hardcore. The usual set is DCUR, DEC, and DF. So there may be situations when the character at a particular moment can be firmly "Packed", especially when the number of transactions with the follower increases. By the way progress quickly reached the straitjacket and the same picture is observed: the belt and gag block the quest. In the case of a straitjacket (a scene in a tavern), it obviously makes sense to remove the gag, otherwise the stage logic of logic is violated - the character must "work" with his mouth. ))

P.S. I must admit that even on the hardcore settings of DF, the character managed to hold out for a very long time (two game weeks) with a minimum of transactions (up to 6) before the irreversible consequences (DCUR, DCUR, damn his traps...) 

And one more thing: DCUR is perhaps the only mod whose events are gagged on a follower, thereby preventing dialogue with him (if the character is also gagged). But the EFF through the follower management menu gives a cheating opportunity to get into his inventory and remove any devices if there is a suitable key. Meanwhile, as long as the character and the follower are both gagged, debt accumulates despite the lack of notification of this, and there is no way to enter into dialogue with the follower about debt repayment. I think it would be nice to block the control menu of the EFF follower in such a situation, which should greatly complicate "life", stimulating the character to find ways to get rid of the constraints.

[valcon767]

12 hours ago, gravediggers240 said:

Is there any way to reduce follower boredom? Might just be my game, but nothing I've done has caused it to go down, which has left me in kind of a hard place.
The Gambling Game doesn't reduce required deals even though it is a game, is that intentional?
 

the 3 ways i have found to lower follower boredom

1 - switch follower (if you can)

2 - take deals 

3 - the easter egg games (like Jarl game) 

 

 

[Rolgar]

I am playing this mod and the one before for some time. What really takes me is the game between the follower and the main char. I assume that a lot of people are using other mods in addition to DFC. I use DCL. What I really would like to see is that the main char gets charged by the follower in case they are involved in any intentional or unintentional sexual act. For example a DCL Rape events occurred. Afterwards the follower approaches the main char and says something like "I didn't allow you to have fun and waste my time. This will cost you." You probably get the idea. This would be a kind of "loose, loose situation" for the main char. Which would fit perfectly in the atmosphere between follower and dragonborn. Well, at least for me it would fit.

[Lupine00]

@gravediggers240 spanking reduces boredom, as does taking deals and some other special events.

I can't remember right now, but I think may also have made being punished reduce boredom.

[gravediggers240]

Taking deals does? My game's probably bugged then, I'd have to test it again but as far as I remember taking deals does not reduce DF's boredom.

[rangydangy]

hey after upgrading from 2.11 to 2.12.2 i can no longer make a follower a devious follower. even with the debug option tunred on, the dialog option does not appear

[Monoman1]

Hi

I just noticed SLS status menu subverts DF by always displaying your debt. Is the condition where your follower will not reveal your debt simply 'Follower Lives <= 0' ?

 

Also just noticed something that might be a bit odd or might be intended. Backing out of the pay follower dialogue continues with payment anyway. This was particularly hard hitting when I had no gold left and she took all my stuff

My PC has basically no willpower right now so I thought maybe it's intended?