Devious Followers - Continued

[audhol]

6 hours ago, Lupine00 said:

it's ultimately DD that is distributing dozens of assets that have systemic problems.

If only there were a couple of super talented modders (with devious minds) a modeler and an animator they could probably make custom items and effects based on zaz keywords to use in DF/SLS and do away with dd dependency altogether. ??  

[Lupine00]

29 minutes ago, audhol said:

f only there were a couple of super talented modders (with devious minds) a modeler and an animator they could probably make custom items and effects based on zaz keywords to use in DF/SLS and do away with dd dependency altogether.

I believe it's possible to make a system that doesn't require the double-object mechanism of DD, and which would apply/remove items almost instantly, instead of taking several seconds, and between Zap devices and the available open-permission assets, there are plenty of models to work with ... but ... I'm not sure that's a good path to go down.

 

It would be a large amount of technical framework effort to produce yet another conflicting framework; though it could perhaps actually respect the keywords of Zap and DD in a way they do not respect each other. In the end, users simply wouldn't get enough value from that quality-of-life change.

 

There is more "fun" to be had making - and playing - content mods, prostitution, slavery, drugs, and wacky sexist survival perils.

[audhol]

52 minutes ago, Lupine00 said:

It would be a large amount of technical framework effort to produce yet another conflicting framework

I didn't mean to produce a whole conflicting framework, I just meant something new and unique to your mod. I find DD items dull and overused there's nothing new coming out in that framework and apart from treasure hunter whore I dont think anyones done anything original since SLAV with those items. How hard would it be to create a new item with unique effects?

[Lupine00]

3 hours ago, audhol said:

How hard would it be to create a new item with unique effects?

It depends on your definition of unique...

Just sticking some magic effects and perks as enchantments is easy enough...

Technically some setup might be unique, but not distinctive or creative.

 

I quite liked some of the stuff done on the Aradia armors where the enchantments (and other effects) were made conditional, so the armor had a variety of different features depending on whether you had keys or not, were aroused or not, etc.

 

There are some new items coming in the next version, but they aren't even devious, and they're not terribly exciting - they're for easy, level 1 or 2 deals. DF items don't need to be devious because you get punished for not wearing them anyway, and with DD's manipulate locks, there's no practical difference between a devious item the player adds and a completely ordinary item, apart from maybe the look of it.

 

It makes no sense to carry any of the burden of code for locking items if the player can just manipulate locks.

[Tron91]

22 minutes ago, Lupine00 said:

It depends on your definition of unique...

Just sticking some magic effects and perks as enchantments is easy enough...

Technically some setup might be unique, but not distinctive or creative.

 

I quite liked some of the stuff done on the Aradia armors where the enchantments (and other effects) were made conditional, so the armor had a variety of different features depending on whether you had keys or not, were aroused or not, etc.

 

There are some new items coming in the next version, but they aren't even devious, and they're not terribly exciting - they're for easy, level 1 or 2 deals. DF items don't need to be devious because you get punished for not wearing them anyway, and with DD's manipulate locks, there's no practical difference between a devious item the player adds and a completely ordinary item, apart from maybe the look of it.

 

It makes no sense to carry any of the burden of code for locking items if the player can just manipulate locks.

I liked the simple mechanism in trapped in rubber. simple script which activates on device unequipped and puts the outfit back on the player if the key is not there.

[Balgin]

 

2 hours ago, Lupine00 said:

It makes no sense to carry any of the burden of code for locking items if the player can just manipulate locks.

Perhaps the ability to manipulate the locks could be willpower based? Too low willpower = no option to manipulate the locks. That literally might not be possible depending on how the DD menu is set up.

[Kimy]

21 hours ago, Lupine00 said:

If there are fixes or patches (for HDT generally) that would help players not have these bad HDT experiences, DD is not promoting or disseminating them. 

 

Instead, it appears that DD distributes a number of problematic items that are presented in a superficial way as working perfectly, when they are not.

 

DD does not (for example) offer a global option to replace all HDT items with non-HDT equivalents. While the equivalents might not look as good, a lot of players would choose them, I think. While that might require replacing some long chains with short, stubby, ones, I could live with that.

 

DD places an awkward burden on mod-developers to be careful not to use the many DD items that have problems that include, but go beyond, HDT ... set up with bad slotting, unsatisfactory bodyslide data, poorly considered encumbrance values, or using HDT in ways that are almost always problematic.

 

Good luck with raising that problem on the forum.

 

Despite my posting object IDs and specific problems, none were ever fixed, and there is no way to know if the posts were even read, let alone recorded as bugs to fix. Some modders, apparently, get so many hundreds of forum posts and PMs every day that they just don't have time to acknowledge bug reports with a simple one-line reply, or to keep a list of bugs they intend to fix in a public place, or say anything about what they're working on except in a pay-gated patreon post. I would fix these things myself, but as is well known, that is prohibited by the DD license: you may derive, but you may not patch. When asked if my patches would even be considered ... silence ... and complaints about the silence were followed by absurd claims that everyone was responded to, combined with self-contradictory remarks that there was no time or need to respond, and buttressed by the assertion that any contributions might be considered, maybe, if they feel like it and they're in a good mood, and the wind is blowing the right way, which to me reads as "don't bother, it will be ignored." I may be wrong on that inference, and others may have had a wonderful experience, but you have to look at who those people are.

 

Not sure if it ever occurred to you that I might simply have overlooked you mentioning issues with some items. I am just human, you know? A human having to keep on top of more and more busy mod support threads than pretty much anyone on LL. But hey, sure, keep on bashing, it seems to be a hobby of yours anyway. Other than HDT being an obvious issue for the SE port, I am not aware of any serious items or slot issues.

 

For the record: If you want to submit a patch for these items that doesn't break functionality (e.g. I can NOT substitute a HDT item with a non-HDT item using a -different- AA set), I am all ears. But yes, to avoid unnecessary frustration, I would suggest talking to me first, at least if the patch isn't purely a bugfix. As you correctly started, I reserve the right not to merge submissions. Like every other developer, I guess?

I am not a fan of substituting models during runtime, but I -would- consider offering an alternative for some items in the installer, particularly those not working well with SE. If someone makes them, and don't look at me. I mentioned a few times already that I no longer have a permanent modeller available to work on DD, and many asset related issues (assuming there are any) I am simply not qualified to fix. I have NO clue about Bodyslide and NO clue about HDT and NO clue about 3D modelling or animating in general, and said as much about 5,000 times in various places of this forum. I also would dare you finding me a quote of mine where I claimed to respond to each and every posting. I have explicitly said that I do NOT. Only that I (try to) read them all.

 

Why you think I am obliged to share with you or anyone else what new features and changes I am working on for the next versions of my mods is beyond me, though. I do so at my own discretion, thank you.

[Kimy]

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

Can stop bitching about this now, I guess?

[donttouchmethere]

I just like the HDT chains a lot, it would be a shame to remove those just because some ppl don't like them (or have a bad HDT setup) ?

Those prisoner chains and chain collars and chain&ball combos are all awesome. ⛓️

The prisoner chain stealing the collar slot is a problem sometimes tho ?

 

(if HDT fails on PC DD chains from ZAP or DD use in console "showracemenu" => this will reset the chain physics => same is true for other HDT items like tails/ears/outfits)

[audhol]

2 hours ago, Lupine00 said:

I quite liked some of the stuff done on the Aradia armors where the enchantments (and other effects) were made conditional

agreed valderius little helpers plugs from captured dreams where great too.

2 hours ago, Lupine00 said:

DF items don't need to be devious because you get punished for not wearing them anyway

I never though about it like that but your right it doesnt matter what the item is, it could be a banana on the head the point is your not stuck in it till you "find a key" your stuck with it untill your follower tells you you can take if off and without blowing up your papyrus logs.

[valcon767]

ran into a minor issue (and knowing my luck its probably just me as have seen no other posts about it).

 

maximum willpower available got lowered (as in it would not go higher then a number somewhere below 10)

normal maximum in my setup is 10 willpower and 20 resistance. 

4 times now it has suddenly had different numbers that it would not go above, and resetting the mod (debug page back to defaults) says i have 10 willpower

again but upon resting (for any amount of time) it drops to the lower number, and no amount of rest would get it above that number.

using the console nets the same results as using the debug page to reset the mod.

as the first 2 times i did not notice it for a while it did take some time to figure out when it was happening (much less a suspected cause).

(numbers it lowered to include 4 will 18 res, 6 will 5 res, 8 will 2 res, and lastly 9 will 15 res)

i have finally figured out when its happening (which gives me a suspected cause).  it happens when i upgrade the mod mid game to a newer version (2.12 or greater)

willpower and resistance still work just fine (other than the maximum being lowered) when this happens mid game.

willpower/resistance does go up and down normally (other than the cap being lower).

even doing a "clean save" if updating mid game it still is affected by the lower maximum (remove mod, make a hard save, clean new hard save with fallrim tools/resaver,

add mod back in and start it again), which i find strange. 

 

did a limited amount of testing, and the new lower number is exactly what i had at the time of upgrading mid game.  tried 3 separate times and got the same results.

clean save or not made no difference to the "lower" maximum.

 

having said that however starting a new game it works great (i want to say flawlessly).  

 

don't know if its a bug or just something with my setup when upgrading mid game. figured i would post here as a just in case someone else hits the same problem.

 

as far as i know, there is no action necessary (other than on players part, and only if someone hits the same issue).

 

anyway thanks again for all the hard work you do.

 

[Lupine00]

6 hours ago, Balgin said:

Perhaps the ability to manipulate the locks could be willpower based? Too low willpower = no option to manipulate the locks. That literally might not be possible depending on how the DD menu is set up.

That is not possible on the existing items. You could make a custom item that worked that way, but it's not possible to customize existing items, nor does the DD MCM allow you to enable or disable manipulation, let alone allow some other mod to put conditions on it. That very topic was the cause of a huge blow-up on the DD forum.

 

I offered to do the work to put that kind of capability in the MCM, and allow mods to tamper with the manipulation status, if that was enabled in the MCM, so a mod NPC could "check your locks" and change the manipulation status without having to remove, then re-fit the item blindly, and with no way to know if it's been manipulated.

 

As has happened in the past, that offer was simply ghosted - it was not even accepted as a desirable outcome.

 

I don't know if DD will ever change in that area, but the story so far is that blocking mods from being able to see the manipulation status is a deliberate policy, and blocking mods from being able to alter the manipulation status is thus also a deliberate policy, and the lack of any user options to control that is also intended, as such options are felt to be unnecessary or even (somehow) a cause of problems.

 

To work around this, a mod would need to make duplicates of every item, and even then other mods could still be adding the old items that wouldn't work. The suggestion that a mod can fix this for itself was disingenuous indeed; it cannot.

[Lupine00]

3 hours ago, valcon767 said:

maximum willpower available got lowered (as in it would not go higher then a number somewhere below 10)

Do you, by any chance, have resistance fatigue?

 

It is shown in the main stats page.

 

I suspect your resets and re-installs reset your resistance configuration, and causes the fatigue to manifest different impacts on max willpower.

Nevertheless, that would still be the fatigue working as intended.

 

However, firing and then hiring a new follower should reset the fatigue.

You can also reduce it through the donations mechanism.

[valcon767]

5 hours ago, Lupine00 said:

Do you, by any chance, have resistance fatigue?

 

It is shown in the main stats page.

 

I suspect your resets and re-installs reset your resistance configuration, and causes the fatigue to manifest different impacts on max willpower.

Nevertheless, that would still be the fatigue working as intended.

 

However, firing and then hiring a new follower should reset the fatigue.

You can also reduce it through the donations mechanism.

i will recheck this on current game (9/15 max current) but as i pay off follower then fire before resetting mod i don't think that was the cause.

if i have resistance fatigue i will try both methods and see if either work to let willpower max out again.

 

hmm thinking about it a little more if it was resistance fatigue, do you have to actually hire a new follower for it to reset? (as both times it was staying below 7 i 

did pay off then fire follower, then reset and it still didn't go any higher)..... ah well i will check that route also if i do in fact have resistance fatigue in current game.

which is entirely possible.   will post again in a day or so when i have checked and tested more.

 

thanks for your time

 

edit

did check and i do have some resistance fatigue. 

tried paying off follower, then resting for 8 hours. no change

hired new follower (waited till comment so i was sure DFC was properly engaged), no change

rested 8 hours again, no change.

reset mod by debug page, no change.

agreed to deal, and bought out of it.  resistance fatigue lowered by 3 per time done.

only thing that actually lowered resistance fatigue was agreeing to a deal, then later buying out of it.

will check again on a new game and see if resistance fatigue resets properly there (when i next start a new game).

 

[aspirine2]

after pc is sold to slavery ...

-simple slavery and it's variable results ...why is the devious follower still there ..is there a console command to end the deals and set free the follower ..!? 

[Lupine00]

8 hours ago, valcon767 said:

will check again on a new game and see if resistance fatigue resets properly there (when i next start a new game).

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.

 

2 hours ago, aspirine2 said:

after pc is sold to slavery ...

-simple slavery and it's variable results ...why is the devious follower still there ..is there a console command to end the deals and set free the follower ..!? 

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.

[Monoman1]

15 hours ago, Kimy said:

Can stop bitching about this now, I guess?

Thanks. Now I can check cursed collars on toll exit. 

[aspirine2]

Just now, 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.

SS plus plus 

[HexBolt8]

50 minutes ago, aspirine2 said:

SS plus plus 

SS++ does not dismiss followers.  Neither did SS+.

[Lupine00]

1 hour ago, Monoman1 said:

17 hours ago, Kimy said:

Can stop bitching about this now, I guess?

Thanks. Now I can check cursed collars on toll exit. 

??? A bitter and begrudging text from Kimy? Could have been posted years ago. Needs more context.

 

From the comment on collars, maybe you can now inspect the state of device manipulation?

No new DD release seems to have occurred. Maybe a beta? I'm not even going to navigate to that page.

50/50 she introduces it without updating the internally reported version number.

[Lupine00]

18 minutes ago, HexBolt8 said:

SS++ does not dismiss followers.  Neither did SS+.

Correction: SS fires a mod event "SSLV Entry", which DF listens for, and it causes DF to dump the follower.

 

 

These are the options:

 

SS fired it, DF responded, but for some reason failed to remove the follower.

SS fired it and DF didn't respond.

SS didn't fire it.

 

I think SS+ did fire it reliably.

I'm fairly sure I see followers removed before entering SS auction.

[HexBolt8]

9 minutes ago, Lupine00 said:

SS fires a mod event "SSLV Entry", which DF listens for, and it causes DF to dump the follower.

I didn't change how that works in SS++.  In either version (+ or ++) there's only one place in the script that does SendModEvent("SSLV Entry").  It's right after this:

 

            Debug.MessageBox("You blackout for a second.\n You vision clears, you realize your back at the auction house!\nYou were free no... how?... those spells they used on you.\n They must of enchanted you to teleport back here once you removed those devices.")
 

I don't ever recall seeing that message myself.  It doesn't look like SS+ would have been sending SSLV Entry very often.

 

Coming at this a different way, wouldn't it make sense to just go ahead and dismiss the DF before sending the PC to SS?  If the DF is selling you, wouldn't you part ways right then? 

[Lupine00]

39 minutes ago, HexBolt8 said:

Coming at this a different way, wouldn't it make sense to just go ahead and dismiss the DF before sending the PC to SS?  If the DF is selling you, wouldn't you part ways right then? 

It does, by firing a DF-RemoveFollower event first.

 

 

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 on SS entry.

It's extremely trivial, so if it fails, your DF install is already broken anyway.

 

I don't think there's any doubt that SSLV Entry is the event you're supposed to call to get into SS; even SS does it for its Defeat integration.

 

 

I see this code in SS:

Spoiler

 

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.

 

As DF listens for it, 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.

 

 

If ... however ... SS crashes while handling the event, and before DF gets it, the DF handler will likely not get triggered.

 

So here's on_new_slave ... could it crash?

Spoiler

 

event on_new_slave(string eventName, string arg_s, float argNum, form sender)
    debug.trace("received new slave Mod Event")
    Game.Getplayer().moveto(SSLV_CageMark2)
   
    Armor a = Game.Getplayer().GetWornForm(0x00000002) as Armor ; Stripping player
    Armor b = Game.Getplayer().GetWornForm(0x00000004) as Armor
    Armor c = Game.Getplayer().GetWornForm(0x00000008) as Armor
    Armor d = Game.Getplayer().GetWornForm(0x00000080) as Armor
    
    Game.GetPlayer().UnequipItem(Game.GetPlayer().GetEquippedWeapon(),false,true)
    Game.GetPlayer().UnequipItem(Game.GetPlayer().GetEquippedWeapon(true),false,true)
    Game.GetPlayer().UnequipSpell(Game.GetPlayer().GetEquippedSpell(0),0)
    Game.GetPlayer().UnequipSpell(Game.GetPlayer().GetEquippedSpell(1),1)
    Game.GetPlayer().UnequipSpell(Game.GetPlayer().GetEquippedSpell(2),2)
    
    Outfit()
    If (a.HasKeywordString("ArmorClothing")||a.HasKeywordString("ArmorHeavy")||a.HasKeywordString("ArmorLight"))&&!a.HasKeywordString("zad_Lockable")
        Game.Getplayer().UnequipItem(a,false,true)
    endif

    If (c.HasKeywordString("ArmorClothing")||c.HasKeywordString("ArmorHeavy")||c.HasKeywordString("ArmorLight"))&&!c.HasKeywordString("zad_Lockable")
        Game.Getplayer().UnequipItem(c,false,true)
    endif

    If (d.HasKeywordString("ArmorClothing")||d.HasKeywordString("ArmorHeavy")||d.HasKeywordString("ArmorLight"))&&!d.HasKeywordString("zad_Lockable")
        Game.Getplayer().UnequipItem(d,false,true)
    endif

    If (b.HasKeywordString("ArmorClothing")||b.HasKeywordString("ArmorHeavy")||b.HasKeywordString("ArmorLight"))&&!b.HasKeywordString("zad_Lockable")
        Game.Getplayer().UnequipItem(b,false,true)
    endif
    ; end of stripping player
        
        
        ; Obsolete
        SendModEvent("dhlp-Suspend")
        int Timer = 0
        int Stage = 0
        ;While Timer < 10
        ;  Utility.Wait(3)
        ;  Timer += 1
        ;  if getStage() >= 10
        ;  timer = 100
        ;  endif
        ;EndWhile
    

endevent

 

 

 

This will generate log-spam from casting None returns from the worn form to Armor. That was a bug in DF ... now I see this code it looks to me like Lozeak cut+pasted from SS.

Then equipped weapons or spells are unequipped without checking they are not None.

Then a function call to Outfit()

If no Zap_Lockable items the player is completely stripped, then equipped with a random slave outfit.

 

THEN the items found at the start have methods called on them then are unequipped without testing if they are None. (OUCH!)

And after equipping a slave outfit and stripping the player in another function.

 

Then dhlp-Suspend is called (why now, why not at the start?)

And some timer and state states are reset.

But this is commented Obsolete, with no futher remarks... OK...

There was a timer wait loop, I'm guessing it was waiting for the quest stage to go to something >= 10, but that's gone now (probably for the best).

 

This train-wreck code makes baby Jesus cry!

 

I wouldn't be terribly surprised if one of the attempts to cast or dereference a null causes this to abort in a nasty way and stop further event processing.

 

 

I had some vague recollection that SS was bad, but I'd forgotten just how bad it really is.

 

Later on at stage 25, it aborts slavery if you're wearing a block generic; I feel this is wrong and SS is allowed to remove it in this case...

Spoiler

To quote the DD script:

 

6. Items marked with zad_BlockGeneric should NOT be removed by third party mods via trivial means of escape (e.g. blacksmith dialogues) or without compelling reason. They can be removed -when necessary-, to be replaced with quest items (and these only!), or temporarily, if required to run a scene etc. In the latter case, the removing mod is expected to equip back the item after completing the scene.

 

1. Enslavement is not a trivial means of escape.
2. Enslavement is a compelling reason.
3. You can upgrade them to quest items.
4. You can remove them briefly and then replace them without having to produce any special justifications.

 

I raised this for clarification back on the DD-dev forum during a spate of masochism, and though questioning the clarity of her glorious words irked Kimy, she appeared to concede that the intent here was to allow BlockGeneric items to be removed if the means of escape was not "trivial".

So SS may reasonably remove BlockGenerics to perform enslavement...

But not quest items.

[HexBolt8]

Expanding on SSLV Entry a bit, 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.

 

From what I'm seeing, that bit of code about blacking out was in place to prevent an escape by the player after being placed on the auction platform.  SS then sent SendModEvent("SSLV Entry") to send the player right back to the start in the SS holding cell.  It doesn't seem to have served any other purpose.  And it shouldn't be possible to escape with controls disabled, so SS (+ or ++) should never be sending SSLV Entry. 

 

Now it's certainly to be expected that other mods would send that mod event.  Defeat, DEC, SL Adventures, and others do so to send the PC to SS.  If DF is listening for that event, it would be coming from them:  you get defeated, SL Defeat sends PC to SS, and DF responds by dismissing the follower when it detects the event.  

[HexBolt8]

13 minutes ago, Lupine00 said:

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.

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