More Manifesto: Follower Handling in Defeats and Slavery
We currently face to poor decisions that were made in Skyrim modding antiquity.
One of these is that defeat mods frequently attempt management of followers that effectively lie outside of their reach.
The other is that historically Simple Slavery has never removed followers prior to enslavement.
This latter issue is an obvious flaw, as it's obvious absurd for the followers to be handing around the pre-auction holding cell in SS, acting all loyal and followerish, when you're chained up and getting ready to be sold.
Things only get worse after you are sold, if the enslavement scenario didn't consider that you might bring some OP follower along.
And most "proper" slavery mods use the vanilla follower slot for the master/owner, which usually results in a problem of some kind.
Simple Slavery's decision to do the absolute minimum to implement the auction scenario is at the root of the follower problem.
The author didn't want to figure out how to remove followers from multiple follower frameworks, so instead did nothing and kicked the problem back onto the triggering mod.
And it's clear that the triggering mods didn't understand the full implications of what was required of them, or lacked the time or capability to implement a full solution.
We have a deceptive situation, where a modder thinks that using SS is as simple as calling "SSLV Entry" and letting SS do the rest.
This is not the real situation, because the calling mod must reliably remove all followers, which requires supporting four follower-frameworks plus vanilla!
This should never have happened. Only one mod needs to know how to dismiss followers in vanilla/UFO/AFT/EFF/NFF, and that is SS.
Making every auction initiator have to support follower removal itself was extremely unhelpful.
In practice, the Defeat mods that added SS as a defeat outcome did not fully support follower dismissal, and this shows up in various ways.
Defeat mods can't really get out of handling followers. Many of them create their own defeat scenarios that are broken by followers just as much as SS is.
DiD in particular, because it is a "stealth" slavery mod, has extended scenarios that can easily be ruined by a follower showing up uninvited and turning the whole thing into a comical scenario from The Sims. DiD tries to handle the followers, but its model for handling them is flawed. It doesn't support all the follower frameworks explicitly; it simply tries to keep them out of the way.
How is that going to work when you have Call of Tocatta? Or a summon followers feature on your EFF wheel menu?
The correct approach for a defeat mod that handles followers is to remove them all.
Unfortunately, this requires supporting all those follower frameworks, plus all the clever custom followers that don't even use the follower slot, Inigo, Sophia, Vilja, etc.
That's quite a chore for every single defeat mod to take on.
Obviously, it's never going to happen for SexLab Defeat, or DAYMOYL, which have not had an update in years.
And probably isn't going to happen for DiD "NEXT" or whatever it will be called, should it eventually appear.
That's because its a lot of work. Modders shouldn't have to duplicate this work.
There should probably be a mod that offers this as a service.
One possibility is for SS to offer it as a mod event, because SS needs to implement it anyway.
Another is for the mod to exist as a standalone feature.
And yet another is for it to be part of a Tiny Defeat ... though that does make the defeat substantially less tiny.
I like the standalone solution, but it would mean players would have to merge or lose an ESP slot.
Most defeat oriented players will have SS, so it remains a good place to put that functionality.
Maybe it's not obvious why a defeat mod needs to remove followers for any meaningful defeat scenario to work.
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.
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 in DCL, 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 - because Defeat itself is not maintained.
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 a defeat. And if you look at what I said above, even 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. Several slavery mod uses the vanilla follower slot.
The only exception I can think of is SD+; it's trying to handle all followers (with variable success) but has probably invested more code and effort into follower management than any other slavery mod I can think of.
Leaving followers slotted during defeats is a broken pattern, and this needs to be recognized and understood.
It is absurd to require every single defeat or Simple Slavery origin to re-implement follower removal for multiple follower frameworks; it should be in one place.
In short...
- follower removal should be a centralized service accessible via single mod event (and should fire a confirmation event).
- a defeat generating mod should remove all followers.
- A defeat outcome, such as slavery, should be able to assume that followers have been removed.
- If a defeat outcome needs to get hold of nearby followers, it can do so by potential follower faction, actually having been recruited wouldn't be relevant.
- A Simple Slavery initiator should simply be able to fire an event and have everything happen, it shouldn't have to clean up the PC for SS; SS should be self-contained and handle the things that break its scenarios.
- When SS hands the PC off to a defeat outcome, it should hand over a clean, follower-free PC, not a mess of worn devices and half-removed followers.
- Registration to SS shouldn't require code changes to SS.
The scope of Simple Slavery should be such that it takes in "dirty" PCs and cleans them before handing them to the destination.
SS should not contain set-up code for the destination (except in so far as some legacy cases need to be supported).
New mods should register to SS; SS should not be secretly adopting them as targets.
Anything required to induct the PC into a destination mod should be IN the destination mod, except in so far as the mod should be able to assume the PC is clean on entry.
15 Comments
Recommended Comments