Devious Followers Continued is finally in a place where I think I can take some time away from it, and so for May, I want to do some work on SLAX, and will finally get around to releasing various fixes and improvements.

The plan

May Release

• Known bug fixes - already done.
• Extend the keyword MCM to allow setting keywords on all slots.
• Extend the keyword MCM to support additional keywords.
• Add new factions and keywords to the ESP, so no need to hunt all over LL to find the latest ESP version - will also support new requests for SexLab Survival.
• API improvements to better support mods that make use of SLAX.

June Release

• Update of SLSO integration to ensure up-to-date and also to add some functionality.
• Improved update system for more responsive handling of nearby actors.
• Rapid arousal and orgasm fatigue.
• Denial tracking.
• Handling for some of the fetish factions (bondage, anal and creature most likely).

Given the list, it's expected that planned work will continue through June, but there should at least be a release later in May sometime with the bug fixes, ESP updates, and keyword MCM improvements. The June release will thus be near the end of the month, and bring some fresh features.

And maybe for July...

• My own SSE release with full functionality.
• Sex addiction.
• Diagnostic MCM so you can see what NPCs are being updated (and updating you).
• More fetish faction support (oral, cum, boobs, huge cocks).

Depending on how things go, it might take longer than planned, or some things might be done quickly... But I also want to slot some SLD and DFC work in from June onwards, so I won't be totally focused on SLAX after end of May.

Mod Event Generation and Handling

Some Interesting Globals that DFC Uses

Devious Follower Data via StorageUtil

Factions

Slavery Punishment Tracking via StorageUtil

Changes in 2.14.4 (2021-06-01):

Changes for 2.14.3 (2021-05-27):

Changes for 2.14.2 "Fixed" (2021-05-08):

Changes for 2.14.2 (2021-05-04):

Changes for 2.14.1 (2021-04-30):

Changes for 2.14.0 (2021-04-26):

Changes for 2.13.5 (2021-03-30)

Changes in 2.13.4: (2021-03-11)

Changes in 2.13.3: (2021-03-08)

Changes in 2.13.2: (2021-02-21)

Changes in 2.13.1 (2021-02-09)

Changes in 2.12.2 (2020-07-14)

Changes in 2.12 (2020-06-23)

Changes in 2.11 (2020-04-24)

Changes in 2.10 (2020-01-27)

Changes in 2.09 (2020-01-19)

Changes in 2.08 (2020-01-14)

Changes in 2.07 (2020-01-05)

Changes in 2.06 (2019-11-19)

Changes in 2.05 (2019-10-13)

First release 2.04 (2019-09-27)

I wanted to put this guide directly on the mod front page, but the LL page-size limit won't allow it.

Get a Follower

You will need a follower. Without a follower, DF won't do much.

A vanilla follower, such as Mjoll, or vanilla mercenary such as Janessa is fine, and the many hundreds of "standalone" follower mods you can find on LL or the Nexus will all work fine with DFC too.

Recruitment

Recruit the follower, and after a while they should say something like, "I hope you won't cheat me like other adventurers..."

After this, you can initiate a dialog and select the [Click Me] dialog. This will give you some DF tips and the mod will be enabled to work properly. After this you won't have to [Click Me] on any new followers. The [Click Me] is there so you know what you're getting into.

If a follower is slow to start, try talking to them. You should see a dialog like "Can I rely on you?" Clicking this will push follower registration along immediately.

Sometimes a follower just won't work. There is a feature in the MCM Debug menu to add reluctant followers. If a follower doesn't get the debug dialog after using the option to add followers in the debug menu, it's because they are not properly configured as a follower in Skyrim, and lack the vanilla follower factions. You can find how to fix this in any guide on how to make a follower.

You can also use an option in the Debug menu to stop a follower (under your crosshair) becoming devious. You can undo this just as easily if you change your mind. You can't stop a follower from being devious if they are already your follower though; you need to do that before you recruit them.

Pay per Day

Once your follower is recognized by the mod, they will periodically charge you money for their services. Their fees are priced "per day", but you can control how often they update what you owe in the MCM. That frequency won't change the costs (much), just how often they remind you about your debt and how incrementally it's added. Adding debt more often can result in slightly more interest accruing unless you are quick with making the payments. However, every time you pay your follower, you gain a little fatigue to your resistance, so paying less often may be better unless you want to end up under your follower's thumb faster.

Your devious follower is "essential" and cannot be killed. However, additional followers you hire are not. This is so you can't escape your debts through trivial murder - it would be far too easy.

If you don't want to pay your follower manually, you can use the gold control mode, and the follower will look after your money. You might regret this. Nothing comes for free. In some cases the follower will force you into this mode because of debt and low willpower. You cannot dismiss your follower while it is active.

If you don't pay your follower enough money, you will accrue debt, and also interest on your debt, and the follower will happily let you do this ... up to a point. Once your debt gets too much, the follower will take action to make you reduce the debt. This might involve forcing you into deals, or they might take items from your inventory, or in extreme cases, they may enslave you. You can configure the worst outcomes in the Punishments section of the MCM. In most cases, you will simply get forced into deals without a chance to refuse them. It's better to take the deals yourself once your debt gets high. If you do it proactively, you can refuse the worst deals instead of taking them, though this adds even more debt.

Deal Basics

One way to reduce your debt is to agree to deals with the follower. Deals may also be forced if you have low Willpower, or you simply owe a huge amount. When you take a deal, your debt is reduced. You must then follow the terms of the deal until you can pay it off. Initially, new deals are very expensive to pay off, but as their 'duration' elapses, they go down in price - you can configure this. The prices for debt relief, duration, and payout cost are configurable in the MCM, along with the penalty for early payout.

Many deals will require you to wear a devious device. You do not have to lock the device; the follower just needs to see you are wearing it. You may even be able to remove it, briefly, without the follower noticing. This is one way that you may manage to eat or drink while wearing a gag. If the follower catches you breaking the terms of the deal, they will add more debt to punish you. The device you wear isn't usually specific either. If you need to wear a corset or harness, any corset or harness will do, it doesn't have to be the one the follower gave you. There are exceptions to this like the circlet, amulet and ring deals, along with the chastity belt, the tape gag, also the items required if you are enslaved, and some others.

Paying off a deal is initially very expensive. Depending on how you configure, it may be much more than your final deal buyout value. As time passes, the cost to buy out of the deal will decrease until it reaches the configured buyout cost. It will not drop below that. However, it's possible for deal durations to be extended in some cases, which makes buyout expensive again.

You can configure it so that "punishment" will remove some deals, and it nearly always removes debt, but you can configure a minimum amount that is removed. The exact allowances will vary. If you're punished by being sold into Simple Slavery, all your deals and debt will be removed and your devious follower relationship is ended. If the follower sells you to another follower, it will use the configured values.

Dismissal

You should (only) be able to dismiss your follower if you pay off all your debt, have no deals, and are not in gold control mode. The exception to this is if you configure a minimum contract duration. If you do that you cannot dismiss your follower until you've been with the follower at least that long. If you use a follower framework, don't use its debug features to dismiss your DF - it will likely cause you problems. DFC tries to stop the follower frameworks from doing this, but it doesn't try too hard, as there are situations where you may need to do it to repair a broken game that the mod can't foresee. You can also set restrictions on dismissal, for example, so that it can only occur in sensible places and you can't dismiss a follower in a dungeon, or immediately after leaving town.

Willpower and Resistance

Willpower and Resistance measure how well you are able to resist the follower's demands and overbearing personality. Willpower directly determines how the follower treats you, and changes the responses and topics you have in dialogs. Willpower ranges from 10 (max) down to 0. If your willpower is below four or so, the follower will have considerable influence over your decisions, and you may have troubles refusing deals.

You regain willpower by sleeping at least six hours at a stretch. This also restores follower lives (see later). The more devices you are wearing when you sleep, the less willpower you recover. Having deals can also reduce willpower restoration. There are many options for willpower in the MCM.

Resistance is a value that is like lives for willpower. When distressing things happen, your resistance will be reduced. If it is reduced to zero, then you will lose a point of willpower, and then your resistance will be reset. How resistance varies with willpower can be configured in the MCM. You might want to stick with the defaults to start with, but if you use Spank that Ass or Sexlab Survival, those mods add many new ways to lose resistance, and you should probably increase the resistance per willpower value to about 30 to make up for it. You should probably also reduce the willpower lost in furniture a bit in the SLS MCM, especially if you have MME as well.

While SLS can quickly burn through your resistance if you end up being spanked in furniture, the fastest way to lose it is to be raped while wearing a lot of devices. This means that mods that set the victim flag when they should not make a lot of trouble for the player in DFC. It also means that deals that make you vulnerable to rapists you might have added via some other mod are especially dangerous.

With SLS, it's possible to lose a lot of willpower, and end up vulnerable to being forced to have a devious follower by a guard, if you're bound. Alternatively, SLS can inflict a devious follower on you if you're caught "without an escort". With SLS, a follower can be made mostly obligatory, and that will make it harder to avoid the complications that DF adds.

Your devious follower can manage your SLS licenses for you, which does some of the pressure off, but you're basically trading an immediate cash problem for a long-term debt problem. Sure, you can get reliable and easy access to licenses, which makes having a devious follower quite useful, but they will be adding more debt than you'd otherwise get. If a lot of expensive licenses come due at once you could find yourself in a difficult debt situation quite suddenly.

Follower Lives

Every time your follower is knocked into bleedout they lose a 'life'.

Lives are restored when the follower sleeps, but it is always assumed that if you sleep, your devious follower also sleeps.

They do not need to have a bed for this, as long as you can sleep, they can. Maybe they find one once you are sleeping? You can buy a bed for only the follower in an inn, in which case you do not sleep, and do not regain willpower, and have some time to kill. Normally, you would only do this if you can't afford a bed for yourself but are desperate to restore your follower's lives.

If you get a bed for yourself, you do not need to pay for the follower separately. The follower automatically sleeps when you sleep, even if you don't see it happen!

Followers who run out of lives don't die, but they do become grumpy and will not help you remove devices or play gambling games. They may be unhelpful in other ways too.

Your follower offers various benefits in return for the fees, beyond their regular follower capabilities. If they run out of lives, you cannot access those benefits, or even pay debt. Your DF can remove devious devices that you get trapped in - for a fee, and they can play a gambling game in which you can win cash, and another to win keys of various kinds. These are very useful when your willpower is good and you have plenty of money. They may become a financial trap for a PC who doesn't have sufficient earning capacity.

Games

If you find yourself in some devices, and your willpower is not good, the follower may decide you are happy to play a "game".

By game, they mean some humiliating sexual task that could involve giving the entire clientele of a tavern a blowjob, or it might be worse. In most cases you can simply add debt and skip the game, if you really don't want to play.

You can set the minimum time between games in the MCM. Don't make it too short, or you could find the games become too frequent and intrusive.

Most games won't activate unless you exceed at least half the configured enslavement debt.

Against Your Will

If you are without a follower, and your willpower is very low, and you are wearing devices, guards may decide you have the demeanor of a slave, and will demand you take them to your master. Pick a follower to "pretend" to be your master so the guard will release you. The follower will become a DF, with some debt added up-front as payment for helping your escape. You can disable this feature in the MCM if you don't want guards harassing you.

If your debt grows beyond a threshold you can set in the MCM, and your willpower is not high, you may be enslaved by the follower. In this case your deals are suspended. However, the follower will dress you in devices of their choosing, make you crawl, work as a cheap whore, and behave quite capriciously. You will need to pay off a certain amount of debt to escape slavery. It's also possible for the follower to sell you to other potential followers.

There is a mysterious "potion" deal you can configure in the MCM. Do not enable the forced version unless you know what you're doing. Normally, you can always refuse this deal. If you take it, all your deals will be paid off and your debt reset to zero, but the follower, or some random NPC, will have a lever to control you indefinitely. This doesn't mean you must do whatever they say, but ... don't mess with this deal unless you like to be inconvenienced for the rest of your game. Also, you can configure intervals between the bothersome parts of this, so it can be made relatively unobtrusive if you want, but it's still quite hazardous, as you'll see if you ever play with it.

More about Deals

Various deals impose daily obligations, to drink skooma, lactacid, be milked, offer sex, get spanked, and so on. You need to push the follower to progress these deals. If you do nothing, you will simply default and the follower will laugh and increase your debt. For all these deals to be enabled you will need to have the required mods installed.

The "key" deal is also similar to the daily deals, in that you have to act to avoid penalties. You must quickly use, or offer the follower any keys you find. If you are too slow to hand them over, they will search you and find them. If you are caught with keys, you will be punished with more debt. You can still play the key gambling game and get keys, but you will have to use them quickly. If you take too long the follower will take them back, and charge you for the privilege. When the key deal ends, the follower returns all the keys that were taken. You can also hide keys in containers and other places to keep them from the follower - for now at least. In many ways the key deal is quite mild, but it can be expensive if you don't pay attention. If you think it's too easy, post on the forum and I'll find a way to toughen it up!

Some deals involve being bound in town. You can usually ask the follower to remove the bindings once you are out of the safe guarded areas.

Over time, the follower may get bored with you, especially if you keep paying your debts on time and don't have lots of deals to keep them amused with your misfortunes. Follower boredom leads to them increasing their prices. Dismiss the follower and find a new one to reset boredom. If you take more deals, or play games, or suffer other indignities, the follower might stop being bored automatically.

When you pay your follower, it wears down your resistance. This manifests as resistance fatigue. this is an amount of resistance that is removed from you after you sleep and regain willpower (and resistance), effectively impairing your maximum resistance. If you have high resistance fatigue, it can exceed your natural willpower restoration from sleeping and start to destroy your willpower. You can get rid of it by making big donations to priests. It carries over between followers, so be careful. If you don't make enough donations to keep up your self-esteem, you will inevitably fall prey to your follower's schemes. Another way to remove fatigue is to pay off deals, and the longer you set deals to last for by default, the more effective this will be.

Multiple Followers

You can set up the additional cost for extra followers in the MCM. This is a simple percentage extra per follower after the first, which could be zero, or 100%, or even more if you like. This can dramatically increase your costs if you have a lot of followers, but you will need a follower framework installed to recruit them - DFC does not do that for you. It does patch the frameworks though, so make sure it's allowed to overwrite. Also, be wary of installing all the bells and whistles from NFF - only the more basic options have been tried and tested.

If you have multiple followers, only one will be your devious follower. The others are just normal followers in most respects and do not have the special dialogs. I always thought it would be cool if there were group games and things, but never had time to add them.  Also, as noted earlier, additional followers are not made essential, and may be killed as per normal if they aren't made essential by Skyrim, or some other mod.

Pausing Devious Followers Functionality

If something is going on in your game that just doesn't work with DFC. Maybe a Deviously Cursed Loot quest, or a quest that requires a certain follower who shouldn't be devious, then you can "pause" DFC and it will stop messing with your followers or accumulating debt. All your deals will be suspended and your follower will go back to being a completely normal follower. This will continue until you unpause the mod, if you ever do.

If you are enslaved into SD+ or some other mods, DFC can be set to auto-pause and unpause when you get your freedom.

Boredom and Punishments

Boredom is (for now) a simple mechanic that is intended to encourage you to take deals periodically.

• Boredom resets if you take a deal. (Follower likes this).
• Boredom is reset if you have more deals than expected deals. (Follower likes this).
• Boredom increases over time while you have less deals than expected deals.
• Also, it only increases (in most cases) if you have some amount of willpower left.
• Boredom means your daily rate is increased or your deal discount is offset (basically discount and boredom increase cost are combined and capped).
• The current caps are max discount 90% and max penalty 100%, so you won't be charged more than double due to boredom.

If you take even one deal, your boredom is reset to zero, and as long as you have enough deals, it won't go up, so it's easy to manage.

In future, it may become less generous, and the amount of boredom removed when you do something the follower likes could be limited and configurable.

The impact on your daily rate is already configurable. If you don't think it's severe enough, you can increase it in the MCM.

You won't be enslaved due to boredom (directly).

The mechanic that triggers a follower to take direct action is debt. Purely debt.

Boredom merely accelerates accrual of that debt.

• If you owe more than the debt limit, they will act to correct it.
• If you get too many deals they will enslave instead of adding more.
• If you owe more than half the debt limit, various games unlock.
• If you stay under half-debt-limit, the follower will not do much to trouble you.

However, there is also an enslavement mechanic based on having a lot of deals.

Get too many deals and a timer starts for enslavement. Make sure you pay off some deals before it happens.

You can configure these behaviors in the Punishment page, or adjust the enslavement amount in the main config page.

An event handler that takes too long handling those events can result in an overloaded script system that overflows its stack and gets suspended, with unpleasant results for your game.

Another kind of event that exhibits this problem is one generated by a cloak, and it follows that trigger box events can also cause similar overloads.

In all cases, the problem is the same, efficient handling of the events. While some will say "don't use cloaks ever", that's a gross over-statement that takes a dogmatic approach to cloaks. Problems have arisen because the pattern shown in the CK cloak tutorial is quite bad, and adding scripts with cloaks is generally a bad idea, but cloaks in general are no worse than any other event that can fire rapidly in bursts - probably less bad than an OnItemAdded running on the player.

The central problem with script in these handlers is the basic problem of taking too long to execute. This is caused simply by doing too much in the handler script. Scripts that go off and potentially do heavy work are almost certain to cause an issue unless additional measures are taken.

A favorite pattern is the "busy state", which uses Papyrus built-in states to avoid overload. In this pattern, after a successful call to the event handler, additional calls to the handler will do nothing unless the first call has completed.

The code looks something like this:

This approach is fine is you just want to know the event is being hit by something. It's good for situations like an OnHit event where you want to know the player is being hit in combat, but you don't need to handle every hit, just as many as you can - and the player won't really notice those hits you didn't process.

But, quite frequently, the reason you're running an event handler is because you need to get all the events. You really don't want to miss any. This is most likely with an OnItemAdd, where you're looking for a particular item.

An appropriate filter is the recommended solution to OnItemAdd performance risks, and that's great if you know exactly what items you are interested in, and the list is small. If the list is huge, or you don't know the items but simply that they have a certain keyword, or came from a certain mod, then filtering is probably unsuitable.

Nevertheless, where you can use a filter, that should be your first approach, as filters are very good at reducing the number of event calls, so you don't have to run a lot of code on irrelevant items at all.

But let's suppose a filter is not going to cut it. Imagine you are doing what I wanted to do recently, which is to detect every DD key the player obtains.

There are now many mods that create their own uniquely flavored DD keys, and so it's not enough just to check for the default DD keys any longer - if it ever was.

I could do this...

There are no states needed in this case. It's not ... terrible ... the work done in the handler is strictly bounded, and once the _DFKeyFound global gets set, further calls early-out and do nothing. Though, of course, a massive inventory flood coming from emptying Sanguine's chest in SD+, or the prison confiscation chest, or similar, probably wouldn't ever set that value, and the script would run a lot of times. Possibly a couple of hundred times in a single burst - but it's not such a huge script it would bring down your game - it would just take a while to clear. But ... if you then piled more load on top, it might become an issue.

So, the above code would probably be ok, but it's still a little worrying.

It could be better. We could do less. What is the minimum we could do?

One approach could be this:

FormListAdd is for all intents instantaneous compared to any Papyrus execution; the cost is entirely dominated by the Papyrus overhead.

Somewhere else there is a regular service routine that pulls everything out of the lists and deals with it. How that's done properly is a topic of its own, and I don't want to get stuck in that, so let's just pretend it's easy to iterate over each list and process the items. One list is mostly going to be full of "None".

This is the least we could reasonably do in a handler, and it won't miss any items.

The down side of this is that we absolutely must service those lists reliably or they will grow without bound, and probably cause a CTD.

That is also probably an unacceptable risk. What if the Papyrus servicing the lists fails?

Here's the compromise I came up with for DF:

In this case, if the list is overflowing, we back off and stop adding - items will be lost - but this is better than creating a massively bloated list that is going to lag in processing anyway.

In fact, with a limit of 1000, if we are skipping filling the list, it's almost certainly because the servicing routine has stopped running and is dead.

Also, I took a little Papyrus time to determine whether to handle as item or base. This is a less clear-cut whether it's the right approach, but it saves time later in processing the list later, that is for sure.

The alternative is to use the approach above and fill two lists (or the same list) with both inputs and discard all the None items later. Another approach is to discard non-uniques, which will filter out all the None items at the point of add - but those calls to StorageUtil are going to start using a bit more CPU if you do that. What's best? You'd need to profile in detail to know. I couldn't be bothered going that far this time.

So, there is no straight answer to any problem, and no perfect solution. But sometimes the "busy" state pattern is not going to do what you want, and you need something else.

Busy state invariably discards a lot of calls when you get a burst. It maintains performance, but the cost is lots of lost events.

States can result in some hierarchic resolution of the state declarations, so they are more costly than they look, but I suspect it's still negligible. The problem is really losing all those calls that you made the handler to catch in the first place.

Without detailed profile results it's hard to say exactly what would be the absolute best approach here; but profiling this sort of scenario in a meaningful way is not trivial. I can easily imagine some garbage profile results, but a useful measure might be how often we get a suspended stack.

DFC development is mostly paused this month (just some urgent bug fixes), as work on SLAX is long, long overdue.

2.14.3

• Reduce the number of licenses bought for slaves. (STARTED - just needs MCM?) Fix bugs around SLS enable/disable license options while licensing;
• Some kind of tweak to "follower sold my items" quest so it's not totally avoidable or exploitable. Possibly add a toggle to disable item removal entirely;
• Willpower-based payment reduction - the amount of debt reduction from paying the follower can be adjusted based on your willpower if it's low enough; configure max penalty at zero willpower in MCM; this means you must pay more gold to get the same debt reduction. Stacks with the slavery mechanic that reduces enslaved payment values;
• Eagerly forced deals mode - if you meet criteria (willpower, devices) then if debt exceeds deal value, you get a deal right away whether you want it or not (except in dungeons);
  • Refuse the deal and get two different deals instead?
  • Set threshold willpower with MCM slider;
  • Threshold adjustment for being naked (or equivalent);
  • Devices such as collar or heavy bondage bypass willpower requirement;
  • Boredom threshold + lack of expected deals may also trigger this;

2.14.X

• Guided deal path - alternative deal allocation mechanic - based on personality - see below for details;
• As a slave, follower will take and sell items that you purposely give them. Cash goes directly towards your debt;
• Eagerly forced gold control mode - if you meet criteria (willpower, devices, debt) you get put into gold control mode without having to exceed slavery threshold, or ask for it.
• Detect SLTR status and behave sensibly if the PC is enslaved into SLTR when it's also a DFC enslavement outcome;
• Dialog to ask for SLTR slavery pre-emptively;

What happens after 2.14.X will depend on poll results.

Small Items

• Get fed and watered by the follower when wearing a gag;
• Follower will escape from DDs (using lives, your key, etc) and pause DFC if they can't;
• More external slavery such as SD+;
• An alternative to being made to crawl when enslaved. Pony outfit perhaps?
• More improvements to chastity handling in sex;
• Magic-license collar awareness for SLS. (Still waiting on a proper non-beta SLS release for this);
• Chaos Mode option to only randomize on hire of a new (different) follower; possibly remembers settings from old followers;

• Offer sex without a deal to reduce boredom;
• Offer sex without a deal and get a discount if you aren't horny when you do it;
• Offer deals of your own choosing if your willpower is high enough;
• Follower will sometimes comment on things you haven't done today but should - such as offer sex, drink skooma/lactacid, give milk, etc;
• Better sleeping - bed deal, sleeping on the floor, etc.
• Talk to follower to auto-fit any items you need to comply with your deal rules (and get charged for any items you didn't have in your inventory);
• Prevent multiple DFC events occurring at the same time - should already work - needs fixes? Hasn't been reported for a while, but needs checking for games;
• BiS Awareness (mainly for the cum deal, you might be punished if you wash);
• Take a break mode - time away from follower.

Big rocks to move...

I don't know exactly where to fit these in, but some will probably replace other things in the lists, depending on what people most ask for and what's topical.

• See the big list of deals and other wish-list stuff below;
• Full DD5 support and LDC re-write;
• Ability for the follower to set (radiant) quest objectives for looting opportunities;
• Follower "familiarity";
• Better households.

New sex/bondage games are something that might be done in an external mod.

Though, when I say "another mod" that may be misleading. It may be in DFC and share the same ESP and MCM, but will be totally new code that doesn't require a Devious Follower. Or might not.

Guided Deal Path

Radiant Quests

BiS Awareness

Follower Familiarity

Full DD5 support

New deals and deal fixes

Better Households - Houses, Spouses and Housecarls

Take a break mode

Anunya's List of Interesting Follower Dismissal Enhancements

I thought it was so well put that I'd quote it here as a reminder...

Darklocq supporter 1,799 posts 56 kudos

As this was such a good question, I decided to make the answer into a blog post...

I would't expect it's necessary unless you want to make things much easier, or you had some mod reducing it that you want to override.

I'd generally advise not changing vendor reserves, and adjusting your game around the defaults, as otherwise you have too many things to adjust and it can become a constant circle of tweaks.

The gold limit forces you to do things like go to one town one day and a different town the next; to maximize how you use traders generally; to encourage spending precious perk points on otherwise useless speech perks; and to limit where you can buy out of slavery.

The default costs are set up with some awareness of vendor gold limitations, and the bother you need to go through to overcome that.

It's impossible for a default config to ever be perfect though. The new DF config is more workable than the old system, but it's not going to work for every game.

Some games will be cash poor, others will suffer more or less mid-game cash explosion, and may (or may not) suffer a serious slow-down in cash increase-rate in late game; so while you might be making more cash each level, the rate at which that changes is usually slow, then fast, then slow again, over a hundred level progression.

So, you can change your daily cost config in DF more easily than you can change vendor reserves, and you can adjust the curve on that.

Everything scales together (almost) so you can adjust the level one and level 101 costs and maybe the curve, and not have to worry about the other values.

That said, I recommend using some amount of Chaos Mode, as it adds considerable spice. Not all the values need to vary.

Personally, with the default vendor limits, I've rarely been in a situation where I couldn't vend everything over a couple of days, if I took the trouble to travel around enough ... but ... I'm limited in what I can carry.

But... If you aren't using any encumbrance mods, and have vanilla loot levels, you might be carrying a whole lot of loot that feels hard to get rid of.

I think in most cases you can still do it, but there are some things that have sale values above most vendor's base cash pool and you can't move them early-game unless you want to lose a lot on their value.

e.g. expensive enchanted armor or weapons that are valued well over 1000 even on resale.

That is a "feature" of vanilla, and it remains. Personally, I sell those items well below their "true" value and simple get whatever the vendor caps out on, because that's usually better than just letting them sit around unsold. If you don't do that, sometimes expensive items can end up sitting in a chest for a while before you can move them, but it's also good to have those "rainy day" items around for times when you might not be able to adventure because of hazards you introduce in your game.

A way to increase cash flow, but avoid raising vendor caps is to simply add more vendors. As there are various mods that add just one vendor, or vendors without big cash pools, you can exercise a lot of fine control that way, and balance out towns that otherwise seem lacking in vendor availability too. This has the benefit of giving you more reason to go to places. In vanilla, some towns are places you go, do some quests, and then avoid for the rest of the game.

One particular optional vendor, the Dollmaker in DCL, is a massive exploit, as she carries a huge cash reserve, and if you have the speech perk to sell anything to anyone, you can exploit it to sell her armor, weapons, scrolls, gems ... and so on ... I generally consider selling to the Dollmaker "cheating", but she hasn't been in my game for a long time now, and probably won't return until a new DCL content release if that ever happens.

As well as encumbrance mods to limit what I you carry, I would guess many people reduce their overall loot availability to some extent through scarcity mods. There are numerous scarcity mods. Some focus on gold in particular, while others will reduce gems, jewellery, or armor and weapons.

For a long time I played with patch of my own that reduced the base value of armor and weapons significantly, as well as sorting out a lot of modded items with crazy values (which it blocked from sale completely). I think that SLS nerfing my vendor exchange rates removed the need for that. I get a pittance for most items now, so vendor limits can actually be hard for me to hit.

There are so many ways to go at this, and changing vendor caps is probably the least preferable for me, but I don't think that choice is objective; it's a highly subjective choice and depends on how you're modding your game. For another player it might be the best choice. Up to you.

What I do recommend, is that you limit how many things you change. If you change everything at once, it becomes a shapeless mess. Pick one thing and adjust that until it works: DF costs, loot scarcity, vendor caps, vendor availability, vendor exchange rates, encumbrance limits, speech mechanics, taxes, food expenses, etc. It's best to do one thing at a time and see how that works before adjusting something else.

Recently, in a long post on the SexLab Survival forum, addressing amputation mechanics, I alluded to an "iceberg" that amputation mechanics were the tip of, but I never explained what iceberg I had in mind. The broader topic of punishment and reward mechanics was what I was referring to.

On reflection calling it an iceberg doesn't do it justice.

For brevity in future, we need a jargon term to describe the general class of mods I'm talking about. Some can probably guess right away: slavery mods, combat defeat outcomes, "sexist" mods that create continual penalties and hazards on female characters, with an emphasis on the sex part, and other disparity mods that try to create varying experiences for the PC, from pregnancy to running a brothel. The PC doesn't have to be female, but usually is. There's also usually some kind of intentional conflict between a submissive role being imposed on them, and the tasks that vanilla Skyrim makes available (or requires to progress).

I'm going to call this very broad category "oppressive" mods. Oppressive mods all have significant capacity to punish the PC.

Punishment and reward are at the heart of so many LL mods, particularly those with an emphasis on slavery, combat defeat, or bondage games.

In short, oppressive mods are about punishment and reward.

Punishment and reward are also at the heart of why so many of these mods don't work well together and why authors aren't inspired to make them work well together.

I will present an argument for why this is so.

I suspect that conflicts between punishment and reward are also the underlying reason for many players ultimately getting tired of this kind of mod and turning away from it. They're certainly the cause of many frustrations.

I will also try to argue why this is not simply an arbitrary claim.

Bondage and slavery mechanics add new and exciting ways to punish and reward the PC. Isn't that fun?

You may ask, "Why is there a problem?"

Let's take a step back...

Player character punishments and rewards are NOT player punishments and rewards

There are two ways of looking at punishment and reward, we can look at them impacting the PC - the character - or we can look at how they impact the player. The two are different things; potentially a world apart and often in direct conflict with each other.

For example, the player fails at combat and the PC is defeated. DCL combat defeat is enabled. The PC is raped (brutal punishment for the PC, but amusement for the player) and then gear may be taken (punishment for both PC and player), and the character may be teleported to some annoying place (punishment for both PC and player), and they may be left wearing devices (punishment mainly for the PC, because the player might enjoy this quite a bit).

In oppressive mods, there are many events that take place that are horrible for the PC, but amusing for the player. The kennel in SexLab Survival is a good example of the contrast, the conflict, and the confusion. It's typically an amusing event for the player, but it may well be awful for the poor PC. Unless she is deep into SLS cum-addiction, there is no upside for the PC to be raped by the kennel-keeper or his pets, and she probably isn't going to get a good night's sleep.

SLS is a great example of how things get complicated and ambiguous. Is being forced to drink cum a good thing or a bad thing? In SLS, is shifts from one to the other as the addiction increases and it becomes necessary to satisfy it. The player has limited options to prevent the onset of the addiction. Self-gagging might help a little, but it comes with numerous down-sides. The player's reaction to cum-addiction may vary considerably with where they are in their game. At early stages they may seek it out, but at later stages it may start to become a tiresome annoyance.

Not only do different mods have different ideas of what events are good or bad for the PC, but the same mod may change its idea as play progresses.

The player's idea of what is entertaining remains relatively constant, unless they're over-exposed to a repetitive event that turns what was once amusing into fatiguing boredom. Even this isn't a solid rule. As noted above, the player tends to start to drift away from the oppressive content as their character levels up, and clearing vanilla content (or vanilla-like content) often becomes more of a priority.

One thing that's deeply lacking in the majority of mods is any kind of alignment between PC and player punishment and reward. Combat defeat mods are supposed to be punishing the player, but often what they're offering is a lot of sex scenes - which players may find rewarding unless they grow boring - and it's only the character that is getting punished. Even when the PC's items are taken away, the player suffers a great deal less than the PC.

And what is the point of putting mechanics into mods that are intentionally boring? Even in a combat defeat mod? There is limited scope to punish the player, and such an approach needs to be used sparingly if players are not to grow disinterested. A certain amount of peril increases excitement, but inevitable failure and punishment are simply annoying and frustrating.

To what extent are modders thinking about their mechanics in these terms? Are they considering the difference between PC punishment/reward vs player punishment/reward?

Some may be doing this, but I suspect that most have not crystallized that distinction clearly in their minds (until reading this?) There's no doubt that modders are trying to create mechanics that are consistently fun for the player, but the design of existing mods and the way that their authors write about them suggests that they conflate almost everything their mod does with an attempt to deliver player reward, even if it's indirectly. For example, SLS amputations are, to in part, an attempt simply to deliver more excuses for kinky animal sex with a kind of sexual frisson from the underlying reluctance.

Only combat defeat mods have reason to seriously consider the topic of player punishment, which they deliver via a very limited toolkit: item theft, disruptive teleportation, and various other annoyances that amount to time-sinks. SD+, if considered as a combat defeat outcome, consists almost entirely of extremely tiresome time-sinking.

SexLab Adventures (seems to evidence thinking that the bounties for doing forbidden things are a punishment for both the player and the PC, but in practice they punish the PC far more than they punish the player. The player doesn't set up punishing bounties unless they think they are going to be fun somehow.

Loss of time is really the only punishment that can be inflicted on the player, and all other punishments are just indirect routes to this.

The things that are lost can almost always be regained with sufficient effort. Whether the PC is being robbed, fined, sent to an inconvenient location, locked in a cell, or chain-raped for two real hours straight, it's all just something that soaks up the player's time in a way that doesn't seem to offer any kind of satisfying progress. In some extreme cases, the punishment takes away from past progress. To what extent the player is genuinely troubled is another matter. After all, they are installing these mods because they like them, and as often as not, they rather enjoy having PoP suck up hours of play while their character is dragged around the countryside on a leash by NPCs who path badly and frequently get stuck.

Even when things the player has struggled for are taken away - fancy armors, money, titles, reputation, NPC relationships, levels or skills - it usually comes down to a measurement of time invested that was lost. The things themselves can always be replaced with other things, given more time.

What is Player Character Reward or Punishment?

How can a collection of data in your computer be punished or rewarded? Is it punishment when her simulation values are modified in a non-advantageous way? I don't believe so. That sort of thinking is nonsense with no reference point or connection to any meaningful context. Reducing the PC's health value is a negative simulation outcome, but without assigning a meaning to it, it is neither punishment or reward.

Only the player can assign meaning to these events. Does that mean that there's no such thing as PC punishment or reward?

The reference for what is a punishment for the PC is always the story of the PC. There are events that she, as a story character, is supposed to enjoy, and events she is supposed to hate. The player (whether they intend to or not) to some extent cannot help but have some empathy with the human-looking graphic on their screen. She is not just there to create a pornographic visual; if that were the aim then why play Skyrim at all? You could just run SexLab animations in a loop, and a SexLab theater would be the most popular mod around. Instead, there is only modest interest in such mods, and most of that is from people who really are only interested in screen archery - and many of those are still telling stories!

However, player empathy with the PC doesn't mean that they player feels misery when the PC is imagined to feel it. Often the PC relishes the horrors inflicted upon their character. There are many reasons for this, but they are topics applicable to media in general, and not Skyrim oppression mods in general.

Nevertheless, the determinant of PC punishment or reward is simply the resulting story that the player creates in their head to explain the events and how the character reacts to them.

So what's the problem with any of that?

The lack of alignment between PC and player punishment and reward leads to a weak and uninvolving experience, shallow immersion, and incoherent story events.

Take an example of the PC developing a sex-addiction. This might be simulated as a constantly high arousal value which either doesn't decrease after sex, or doesn't decrease much, and can only be reduced by extreme sexual encounters, or a fast increase in arousal whenever it's low, or both these approaches. In addition, one or more mods may impose stat or XP penalties for this continuing high arousal state. Such additions are generally seen as improving the simulation.

In addition, the constant sex events may lead to Wear&Tear on the PC, with additional penalties as a result, again this is seen as an improvement in the simulation.

XP penalties are supposed to be a punishment for the player, but they are an ineffectual one because leveling in Skyrim is not terribly important for the player.

The stat penalties are inconvenient, and quite likely to involve movement speed or something else that mildly irritates the player, but in many cases may not even be noticed, and may very likely be drowned out by some other mod doing something completely unrelated (needs mod tiredness, for example).

The issue here is that a sex-addicted PC is supposed to long for orgasms, but getting them makes almost no difference to the PC or to the player.

There is no alignment between the supposed situation - the story you're creating in your head - and the game events. Instead we have a questionable simulation of sex-addiction, with mechanics that are inspired by the simulation concepts. Various conflicting outcomes follow from the simulation, which itself is the product of multiple mods that were not written to produce any single clear outcome or with any special intent - they are essentially simulation rules - they are devoid of any compelling story.

We're supposed to believe that the PC is constantly distracted by her desire, leading to impaired learning. If there's a Wear&Tear mod, we are also (probably) supposed to understand that the PC is physically (and magically) impaired by pain resulting from past sexual activities and abuse.

None of this simulation exists, or makes any sense in the context of vanilla Skyrim, where healing spells and potions cure sword cuts and simple praying cures diseases.

Some players struggle with the contradictions, and add more mods in an attempt to resolve them: needs mods with harsh diseases, limitations on potions, or potion consumption, limitations on healing capacity and PC recovery, wounds mods that create lasting effects for combat injuries that can't simply be healed away. It's more complexity and more mods to solve a problem that was created by the original mod setting up a questionable simulation that was at odds with vanilla Skyrim.

Players typically take the position that vanilla Skyrim is inadequate to support and enhance their fantasies for the PC, so they impose extra perils and dangers upon her. She needs warm clothes and fires, she needs to eat and drink, she needs to get a good night's sleep, she needs to pee (and fart!)... it doesn't stop there... she needs to sleep in comfy clothes, she she needs to eat good food, she gets tired of camping, and she gets hurt and penalized by ... just about everything. Players add mods where the PC can get pregnant, or seems to easily submit to forced sex, mods where she can resist forced sex up to a point, they add mods where everyone wants to enslave and sell her, mods where she can be auctioned, mods where she is hurt by sex, and mods where she becomes addicted to it, or to sex with animals. There are even mods where you can become inseminated with GEMS by animals and give birth to ROCKS! And of course they add mods that tie her up. Lots and lots of those. I could digress into a discussion of what this means about the female gender role in society, but that sounds hazardously close to politics. 

The point is that the simulation rules we apply to the PC get ever more complex and perilous. They are profoundly weighted in favor of punishing, humiliating and terrorizing the poor PC. If there is something she is ever allowed to enjoy, you can be almost certain that it's some kind of destructive addiction or submissive mental break.

This is where player frustration can set in. A player initially believes that modding can deliver new and surprising experiences in their game. As time goes by, modding becomes more of a struggle to balance the conflicting ideas of reward and punishment in the web of mods that they've installed, or simply to get some beloved feature to work as they want it to. Frustration and exhaustion, combined with a loss of belief in the idea that oppressive punishment-oriented mods can deliver any substantially new content leads them to look to other genres, or to abandon the undertaking completely.

There's a real shortage of mods that emphasize PC enjoyment, fun or satisfaction. There is no mod where eating cakes gives the PC more happiness. There is no mod where she will pay a fortune to taste chocolate but not be addicted to it like a drug. There is no mod where she enjoys a smile from a child. I guess the majority of players don't want these things in their game for some reason. This isn't some political comment. It's just that game design has conventionally always been about peril and punishment, with the reward being from overcoming those hazards ... but there are games (like Candy Crush) that are composed only of rewards, albeit weak ones.

Problematic conflicts arise because each mod is trying to guess how their user-base feels about a certain scenario, and to provide events that are titillating. Each one envisages a slightly different scenario for the PC, then (usually) tries to produce it indirectly through simulation rules. Mods that are direct about the outcomes they want are less common, but the root conflicts begin with the stories. As the intended outcomes (stories) conflict, the simulation rules also interact at cross-purposes. There's no clear direction. Even if these mods can interoperate what would that interoperation look like when they have disparate concepts of a proper outcome?

Players tweak mods, put mods in, take mods out, and post on forums, over and over, seeking changes of one kind or another, so that they can get the outcome they imagine as perfect. However, for every modder there are numerous players (even for unpopular mods) who all have slightly different ideas in their heads. With only one modder and all those players, any mod can only please each player a certain amount, and the modder may not be pleased with what they delivered either. (I know I am never satisfied with what I make). Even among the most eager fans of a mod, there are different story expectations.

Conflicts Everywhere

The conflicts are not only between the mods and vanilla, but between each mod. These conflicts flow directly from different concepts of what is a player or PC punishment or reward. It's inevitably the case that two mods get in a fight over some stat that they both want to change in opposing ways, or some situation or scenario that they want to resolve in profoundly different ways.

Superficially, Estrus Chaurus (EC+) appears to be punishing the PC for sex with chaurus monsters, or from picking flowers, or (if you have certain patches or extensions) from collecting chaurus eggs. Of course that's not its true purpose. Its core reason for existence is to amuse the player with tentacle-sex and violation fantasies, then to pile a body-modification fetish on top of it, allowing the player to view their character distorted with huge breasts and belly due to a foul "pregnancy", a parasite infestation that can easily end in a horrid mess of skittering creatures.

EC+ punishes the PC but rewards the player. Its pregnancies conflict awkwardly with other pregnancy mods (which have equally complex internal intentions), including combat defeat mods. The EC+ encumbered PC is weakened in combat, suffers additional defeats, and additional indignities, but we're now slipping into territory where the player is ostensibly to be punished for letting their character become inflated with alien eggs to the point that she can barely waddle along.

This is a recurring pattern. A mod that offers player entertainment also adds penalties to the PC, and other mods interpret those penalties as an intent to punish the player. And in some cases, they act on that intent, amplifying the "punishment", or attempting to counteract of moderate it. The different mods had different outcomes in mind. EC+ seems to think that the pregnancy is more or less the end of the problem, but don't get caught too often or you'll end up inflated for good. OTOH, DiD thinks that tentacle-sex is both a way to lose trauma and also to gain it. I can't figure out what DiD's overall expected outcome is, but it's clearly different to the original intent of EC+ otherwise it wouldn't need to add any new simulation rules.

The first problem is that mod X has no way to tell whether the things mod Y were done to amuse the PC, or are supposed to be some kind of disincentive.

The second problem is that mod X and mod Y almost certainly have a different outcome in mind, even given the same set of preconditions.

Returning to the EC+ example, the mod itself is also internally conflicted. It does things that please the player, while also doing things to annoy them (such adding little scuttling creatures to areas). Of course, the player can control some of these decisions, but the player was always controlling them, from the very point that they installed EC+ they were superficially in control. However, because mods rarely deliver a coherent experience to the player, we see, again and again, the addition of more and more mods trying to resolve a nest of conflicts that can only grow as a result of this approach - and I don't mean script or ESP conflicts, but gameplay experience and immersion conflicts - it's a way of modding that creates an endless appetite for more and more mods and features.

Another conflict is that players wish to surrender control, while at the same time exercising it. They choose to add a mod that does things to the PC, but want to feel that the outcomes are beyond their control, or at least beyond the PC's control. They want the story of helplessness, or struggle. They want story events to take them by surprise ... but not too much surprise. They chose the mods they put in their game, and chose how to configure them, but then they want to play within the limits they've created for themselves, with the perils they have so carefully prepared.

This is a conflict over control rather than reward and punishment, but it manifests as reward and punishment. When mods go off the rails and break the game, or simply send it in an unwanted direction, the player (as well as the PC) is punished. Often enough, total success for the PC ends up being seen as failure by the player. Again, the mods didn't do the intended job.

Is Coherence Possible? (And would we want it?)

Is it even technically possible to create coherence between the PC experience and the player experience? Would this be better or worse?

It is possible for mods to agree on the nature of an experience, so they all augment it, instead of breaking it?

Now we're into more difficult territory. It took until now to crystallize the true nature of this problem, and I imagine that many readers are still not at all convinced there's anything here but a confusing web of points that they feel they have easy counter-arguments to. It's not easy to explain the network of ideas and realizations that have brought me to write this, and it will be a journey of its own for me to learn how to express those ideas clearly and succinctly. For now, the ideas are present, but they're still new. There's scope to improve and refine them, and even more scope to improve how to describe them.

But returning to the question at hand, I can offer some examples.

In the case of sex addiction, what if the player received increasing rewards for orgasms? The more extreme the addiction, or the longer the period of denial, the greater the player reward would be. Pay attention here, I'm talking about player reward, not PC reward. This could be applied to any addiction mechanic, but its most notable for sex-addiction, because orgasms are rarely a reward, even for the PC (not the player); instead loss of arousal is the reward, if it's even granted, and who that reward is aimed at is ambiguous. Is it the player, who is happy that her character is now better able to function? Or is it the PC, who is supposed to relish the reduction in danger that the sexual-satisfaction leads to? Or (as I suspect) some combination of the two. 

In the case of combat defeat, can we genuinely punish the player for losing? 

In the case of being caught without a license in SexLab Survival (SLS), there's a conflicted message. The player is supposed to be punished by losing access to items and abilities, but they may also be enjoying the peril that their character has been placed into. They may well get considerable enjoyment from their character being placed in punishment devices that are clearly intended to be a (story) punishment for the PC.

What if the sexist problems imposed by SLS were entirely punishing for the player, and overcoming them entirely rewarding? Is that even possible?

One thing is for sure, a mod that has an alignment between PC reward and player reward would be unlike the majority of mods we see, which have almost no consideration of PC reward, and are composed almost entirely of PC punishment.

Would alignment in PC and player reward help align mods together? I think it would, up to a point, because it immediately becomes clear what is supposed to be a player reward or punishment. In current mods, two mods that disagree are both trying to deliver player reward (and PC punishment).

It's impossible to intuit which player punishments are supposed to be producing player enjoyment, and which are trying to be player punishments.

But if the punishment and reward are simplistically objective, it's easier to get alignment between mods.

For example, Deviously Enchanted Chests likes to put the PC into bondage gear.

While this is somewhat a reward for the player, it's substantially supposed to be a punishment.

The goal is (ostensibly) to get out of the bondage gear as quickly as possible and return to business as usual.

Devious Training tries to mitigate the penalties of being in bondage gear long-term, while adding extra visual rewards (for body modification fetishists anyway).

It's a given you won't install DT unless you like the modification part, but the penalty mitigation is a bonus player reward.

DT is at odds with DEC in some areas, aligned in others.

However, if we have an objective way to know whether the PC likes being bound ... if the PC's rewards are aligned with the player's, then we also know whether the player wants the PC to be bound.

Given this data, a bondage mod no longer needs to guess what to do. The player wants mechanics that make being bound rewarding.

So, there's a light at the end of the tunnel ... we can potentially solve some problems by using data about the PC, or the player, and if we put the two into alignment we can create novel experiences, align mods together better, and store less data.

There's an updated SE version, but no matching LE version.

I took the ESP from the SE version and edited it so that it works in LE.

The main problem was water records in edited cells; SE has some water data that LE doesn't.

There were a few other little problems, but nothing significant.

When it came to the core content, there was no need to change anything at all.

The SE version works perfectly, apart from the ESP, and this fixes that.

Just install the SE version:

And then patch (overwrite) with this ESP:

SexLab More Creatures.esp

Installing this does require some assets for additional dog types and such, whether you're in SE or LE.

The dog model for the SE mod comes from Hentai Creatures SE. You could probably convert the SE mesh back to LE, but there's no need, the same model is also in the LE version of Hentai Creatures, which you can find in on the MNC SLAL edition (for LE) page https://www.loverslab.com/files/file/4130-more-nasty-critters-slal-edition/.

I didn't even enable the HC ESP, because I don't want all those HC spells cluttering up my game. I installed HC for LE and simply disabled the ESP.

This gave me the required dog mesh (it looks like an Alsatian).

If you're already using HC for LE, then you don't need to do anything extra.

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.

As the SexLab Disparity (SLD) main page is quite full already, I thought I'd put some supplementary information here.

Let's consider how morphs work vs node-values...

SLD reads node values from the skeleton using the NiO libraries. Node scale changes are used by some mods to crudely inflate the breasts, butt, or belly.

They were used by most mods for a long time. They don't look good if you put in large scale values, but for small values they look ok.

SLD does not write to any node values. It does not change the shape of your character. People ask for it, but it would be really confusing.

If I add it, it will be off by default (like everything in SLD), and I'd advise most players to stay away from it because of the potential to create feedback loops and unintended results.

SLD doesn't write to any morphs either, to be super-clear.

Morphs are animation files that change the shape of the character skin and operate at the vertex level. This allows highly customized results.

Bodyslide makes morphs for you (assuming you let it) that will allow your character to change shape.

The amount of each morph applied is set by a slider in Bodyslide (or Racemenu).

These can also be set in code by NiOverride, which is what mods with better shape-changing do. FM, MME, etc have built-in morphing.

SLIF also allows morphing. SLIF allows morphing from node changes too. Confused? Don't use SLIF then. It's not really necessary; the UI is confusing and has little to no tooltips and zero help given. SLIF needs a user-guide, and articles like this to explain it. It does not appear to have them. If there's information in the forums, it's buried in among a lot of other noise. It was because things on forums get lost that I put this information here in the first place.

SLD's breast/butt and belly modifier sets are driven by the node values for breasts, butt and belly, respectively.

The node value is the input. 

A value of 1.0 is normal, and anything else is ... not ... it means it's been changed by something.

Breast node values typically range up to 4.0 (for very large), Butt values up to 2.0 (after which it goes very wrong looking), and Belly values up to 6.0 or even 12.0, though it looks odd past about 4.0 using simple node scaling. Large breast node values create the unattractive "torpedo breast" look, though physics goes some way to making that go away by inducing sag.

With morphs, there are ways to make boobs huge without it looking like a fembot from Mars Attacks, and you can use the Pregnancy Belly morph to create a decent looking large belly, or modify the butt in various ways that do not look like the character has a nasty tumor.

SLD uses node values to figure what modifiers to apply to your character stats (not appearance).

So, how can it work with morphs?

This is what the "fake node values" are about...

The Morphs page allows you to generate a "made up" synthetic node value from the morph state, that is used to adjust or replace the actual node value that is input into the Breast/Butt/Belly pages. That is what "multiply" or "replace" mode means. It's how the node value is replaced by the morph value.

You can see the final value being used on the respective page for breasts/butt/belly.

Set your From and To values to work with the range that value takes, or that you care about modifying.

And for the morphs, say for breasts you decide to use a range of 0.0 to 4.0, where values less than 1.0 are tiny boobs.

You want to make your max morph slider produce an output of 4.0 ... that is the "fake node value".

It's not really a fake node value; it's never written to a node; it's just the input that SLD uses on the breasts page.

Following up some user questions on this...

Nazzzgul666 said:

If i got that right, neither me nor any (modern) mod should change nodes at all. Is that right?

I wouldn't say that exactly ... there are many nodes to change ... for example NiO High Heels ultimately applies a node modifier, just not a scale.

That's probably confusing.

To put is simply: for changing the look of your character the way Bodyslide does, morphs are usually best.

It you want longer arms or legs, you need to change a node, but if you do that will probably make all your SexLab animations look wrong; it's something you'd only do for screen-archery really.

The node values are the values in your skeleton, so by changing them, amputator can make your arm collapse entirely.

They are a blunt instrument for altering appearance.

They aren't exactly a "base", but your skeleton is pretty fundamental  so you can think of them like that, and the analogy will work in most cases.

Node scaling will certainly impact breast size and change how your breast morphs look, for example, so thinking of it as a base there is reasonable.

  Nazzzgul666 said:

why would i need to generate a made up node value? For what reason would i want to use something else than my actual base values?

Because what SLD is trying to allow you to do is convert your character's appearance changes into stat changes.

Your boobs get bigger and your archery goes down.

Your boobs get smaller and your magicka does down.

You belly gets bigger and you have a chance to stumble.

... stuff like that ...

It's simple if you only have one mod changing morphs, but if you have several, you're (probably) trying to get a value that matches what you see.

Matching the visually observed size is the most obvious thing to do.

There's no rule says you have to do that. You could do something else; it's up to you, but I'd guess that's what most people would prefer.

It does that by using some arbitrary input value.

One value it can look at is a node value. For example the breast value that older pregnancy mods change (EC+ for example).

How else could it know? It could somehow figure it out from the morphs you have applied.

But because the Breasts modifier page for SLD was written in terms of the Breast node, and because the breast node DOES impact how your breasts look, the intended use of the morphs support is to alter the node value to make it better match a sort of scaled up or down value of the node.

e.g. If back in olden days EC+ node size 4.0 boobs were the limit, and you set your From and To range up to work with that, then you probably want to think of an input range for your breasts page in a similar range ... actually there is no obligation to do so ... but if we don't pin some things down it becomes impossible to explain what to do to those who don't completely understand it all yet.

So as an example, what we might want to do is get a value from 0 to 4.0 by transforming the morph values.

If we're dealing with a BreastSSH morph that ranges from 0 to 0.5, then we can see that scaling that by 8.0 will do that.

That value is the 'fake node value' ... it's just an input to the breasts page in SLD. That's all.

It has no impact on your visual breast size, or your skeleton, and no mod but SLD knows anything about it.

It is just the input to the Breasts modifiers page, and its current computed value will be shown to you there, on that page.

That only updates each update tick, and you can change how often that happens on the first page of the MCM.

People are saying TiR is dead. I'm not sure why. It's just ... unmaintained. Has been for years.

The effort required to play it is minor compared to a Delzaron mod  

Nearly everything is still working about as well as it ever did.

Sure, there is a sad lack of support for features people take for granted now, such as needs, bathing, SLSO, modern-DD (+Lore), PoP, defeat mods, Simple Slavery, Slaverun Reloaded, rape mods, other slavery mods, and of course it fits poorly with newer mods like DF, SLS, or STA...

Most of the things it ignores were already around when TiR was peaking. Like CD, TiR assumes you're going to drop everything else from your LO, drink the CD/TiR koolaid and just play that for a while. You're supposed to build a LO around TiR, and that LO demands you pick your other SL mods carefully.

Assuming you don't introduce anything that conflicts too much, it mostly goes along smoothly.

So far, I've come across some scenes sticking for no obvious reason and some ever-so-slightly game-breaking device script bugs, and often as not, a vital NPC will lock themselves in an unreachable location (sigh), but that seems to be a -thing- with a few mods.

The slot conflicts are a major show-stopper, but they are easy to resolve once you hit them.

It is a long way from "every single quest is broken, every NPC is in the wrong place, nobody has a quest marker, the quest objectives are mostly confusing gibberish" Things in the Dark territory. 

For me, the biggest flaws in TiR are the oldest and deepest. It never created much atmosphere and it's focused on the external world, while the interesting genre-specific part is the internal world of the tower. So much of it is doing vanilla-style Skyrim quests while you just happen to be in a rubber suit, and that makes the whole TiR aspect nothing more than "playing Skyrim with no armor", which is like half-a-dozen naked-Skyrim mods. You might as well play SLAV for example. And later, you get armor - lots of armor - so even that disappears and you're just left with some quite familiar-feeling quests and a shiny outfit.

As quest mods go, it's still pretty good quality. Yes, there are loopholes and gaps, but it's not like you have to spend all your effort tip-toeing around them. There are some mods where the challenge is getting it to work at all, and TiR isn't like that. 

However, it never integrated well with DD content, and that's even worse now (probably). To the point you must disable all those things in your game, which makes it feel rather bare. TiR feels like there should be appropriate peril, risk of capture, enslavement, a sensation of being at the mercy of deranged masters and mistresses and trying to escape it, or being broken and remade so you can't cope without it. But TiR doesn't really do enough to fill those gaps. Sure, there are episodes that ought to fill those gaps, but they don't.

It ends up feeling like you're some tough super-spy rather than a slave being overwhelmed by rubber enclosure.

Time has not changed that. It's how it was then, and it's how it is now.

The Mistress feels inconsistent as a character, and that was always a flaw. On one hand she's preaching "mutual trust" but your entire enslavement is built on happenstance, trickery and deceit. In so far as she comes off as reliably insane and conflicted, she is consistent.

None of the deep issues with TiR are technical; it's the disconnect between the dialog and the events, and the emphasis. It goes for comedy where maybe nobody is really expecting comedy. The core story is, at heart, deeply non-comedic, so scenes like the Rubber School while wonderfully executed, don't meet audience expectation (unless you played it already and are used to it).

When things crank up, later in the story, the enemies are still buffoons, and are exactly like The Mistress: crazy as a sack of mutant monkeys. You can tell them this to their faces, but they don't care and it never matters. At the end of the story, you remain untouched by it all. The idea of picking the ending where you want to help the Mistress is ludicrous. There is never a point where the mod seriously sells you the idea that you owe her anything, or need her for anything. She is a parasite, a smug, over-capable parasite, but you're the one doing all the hard work. Any illusion that you could ever feel a connection to her is entirely the work of the player - wanting that and imagining it so - the mod does nothing to build it for you.

CD never made those mistakes. CD is thematically consistent and stays in-genre the whole time. Technically, it's less stable than TiR. CD was frequently extremely fragile, and required a lot of care and feeding to get it through an enslavement. The coherent feeling and strong atmosphere of CD was enough to make people forgive its technical foibles.

It seems to be the case that most slavery-related/BDSM mods can't do comic -relief- while staying on-theme and holding a stable tone. SLAV is all-over the place and it's only attempting pure comedy. What kind of comedy? It doesn't really know. Slaverun is undercut by deeply variable mood and tone, with a very mixed up approach. And DCL ... there's not much narrative there to start with. Dagonar is fairly bleak and brutal, but inherently stupid and ridiculous silly, while the Chloe line is played mainly for laughs but runs out of them about half-way through and ultimately becomes grind-heavy (there's a lot of walking long distances very slowly). The other Dollmaker quests feel like the eclectic set of random events that they are, as do the collars. DCL is not even trying to tell a story. It could, but it doesn't; it's completely episodic, and the order rarely matters.

As Kimy took great exception to my remarks about DCL here, I will clarify them. What I'm implying above is that I don't believe Dagonar is intended to be taken seriously; it is purposely silly. It is undeniable. That's not a criticism in itself; that choice to keep things light and silly is clearly popular and accessible. I enjoyed Dagonar, but it's not even attempting to be much of a story. Where I wish DCL had attempted more story, is with the Dollmaker, as a concept she hooks you in, but ultimately goes nowhere, figuratively speaking. Literally you go around and around quite a lot, but you end up back in Dawnstar, and nothing has really changed, and that is how all the other DCL episodes end: episode over, back to normal - an intentional design decision that makes DCL useful and flexible, but less of an immersive experience.

There are a lot of other mods that play it all for laughs (SLS for example), and that's fun and all, but it takes more than one flavor to make a good meal.

As a contrasting example, SD+ has ambition. It isn't unrelentingly bleak, but it tries to take itself a little seriously. That makes a nice change in a line-up of BDSM mods that seem to be saying "don't worry, nothing scary here, just fun". It doesn't throw up its hands at the first difficult moment, break the fourth wall and say "just kidding".

Sex Slaves (Dominant Andrew) hit a good balance on tone, but fell down on other areas (repetition, repetition, repetition) and of course, it's greatest failing was that one day the author just stopped and left it. Right at the point it seemed like you'd finally earned some payoff, it just stopped.

I guess the problem was that the target audience for Dominant Andrew either didn't exist, or wasn't vocal enough. Maybe it was just me?  

It didn't quite pull off its intentions, and I think the author set out to make a mod to please others rather than himself. I've written about that on its own forum, so no point going on about it here. 

There's a place for serious-ish mods with an appropriate amount of comic relief to prevent them feeling overly pretentious or bleak, but its hard to find mods that are like that. Arngrim's Apprentice maybe?

Imagine, just for a moment, a different TiR from the one that we were gifted with.

Imagine, a mod about a descent into a world of rubber. Where little by little, isolation from normality recalibrates your reality to the point where you struggle to exist outside that safe rubber haven. A mod where every trip out into the cold, bright outside world isn't a return to business-as-usual, but an reluctant foray into a place where you no longer belong and which feels increasingly alien as your rubber indoctrination splits you off from normal life. The same basic events of most of the TiR story might transpire, (albeit with a very different start), but with an entirely different perspective, and augmented with scenes from the inner world of the tower that completely refocus it all.

For example, instead of a pony race where you basically get an outfit and then run your first race...

Imagine, a series of fairly simple, (probably somewhat grindy) training scenes where it's a chore to eat as a pony, where it's a chore to drink as a pony, where it's a chore to walk the proper pony way. You learn to not use language, not just have a joke spell cast on you. You are forced to race around, and around, and around, practicing until you wonder if it will ever end. It doesn't have to go on too long, but just long enough to build the "feel" of it and make you never want to go back to it.

Also, a basic game-play feature for pony races is to add jumps, where if you fail to execute them correctly, you lose time getting out of the hole. Pony races without this are missing out on something Skyrim can give you "for free".

Imagine this as like operating like Rubber Waitress, where you need to build up a score to finish training. Each time you use human words, you lose points. Each time you fail to make a jump, you lose points, and at first it's set up so it's really easy to lose points, and hard to get them. Your trainer adds incentives as you fail, and they help you improve. Your human dialog options disappear one by one, replaced with pony options. Learn to use the right ones to get food, water, sleep, sex, practice time, etc. or just to please the trainer. You always have one option left to speak, but using it always costs points. Earlier on, you need the human options to get essentials. Later on, you can use the pony versions and gain, instead of lose, points. It's simple, but it's not really a game, it's just to build a feeling.

By the time you enter the first race, instead of it all being "no idea what I'm doing here, these people are nuts", you've spent the last three game weeks in full pony costume. You've forgotten what it was like to have arms, and the race is now the biggest most exciting thing you could possibly be doing. Your entire existence is focused on it. Finally, this pony thing is going somewhere? And in this version, you care deeply about pleasing The Mistress, desperately want to please her, because if you don't you can reasonably expect more hours of being a pony - which is awful. This woman has total control of your existence, and she can drive you insane. Maybe she already has? She tells you that if you don't win she's considering extra-intensive pony training for a month afterwards.

Maybe there's an option to go nuts and kick her until she's a bleeding mess on the floor and the other masters pull you off. I imagine you get punished pretty badly for that... You probably have to redo pony training and the race again if you take that path.

When you lose that race, you (as the player) should literally be in tears. No, no, no! No way. How did she get past me?

And you want to tell The Mistress that the other girl cheated, but you don't want to do it, because that would mean breaking character as a pony.

Of course, if you try to tell her, she should stop you and send you for punishment for that very reason, without hearing your explanation.

And so you go back to pony training, which has now been made even more unfair than before.

But of course, it's sorted out later and you're sent on some other job, because nobody really wants to spend twenty hours mining ore, or running circles in an armbinder. There comes a point where you need to stop doing that. Ideally, it comes before you get sick of the mod.

Players just want to feel like it was forever, when really they spent an hour on it, and half of that was one-handed.

When The Mistress takes you away from pony training, you would be genuinely grateful for the plot device, rather than simply feeling that it was all rigged from the start, you had no choices, and it was just a bit boring.

Imagine (once more), if TiR hadn't been a mod where you play regular Skyrim in a rubber outfit, but a mod about living in a rubber world and being forced to go outside it to deal with regular Skyrim? It could have made use of all the vanilla content/quests as stages that progress TiR. The Mistress sends you to Helgen, then to Whiterun, then to the Greybeards, and so on... TiR-plot-specific events fit in here and there. You're playing Skyrim, as normal, but you aren't, because your perspective is changed. It's not "Hey Balgruuf says I should see these Greybeard guys, so I'll slot it into my schedule", instead, you obediently return to The Mistress and report. She says that maybe one day you will be ready for something like that, but for now you're only one step up from a sex-slave, naked except for a rubber-suit, and she will let you know when you're ready, if you ever are. When you finally set off to climb those steps, perhaps she sends two rubber guards to look after you, who ensure you don't speak to anyone but the Greybeards (and pick up the Klimmek quest for you). Everything is changed. The illusion is that you have no agency at all, and in a way you don't because a lot of the time you have to complete Skyrim in the order The Mistress decides. If you go off-course, presumably the suit (or your minders) will set you back on the straight and narrow. Go to the wrong town, or take too long and your suit develops a habit or arm-binding you. Take too long away from the tower and end up crippled by hunger. Enter locations that are off limits and get blindfolded too. Not really for gameplay, but for atmosphere.

SLAV pretty much serves as the tech-demo on how to do all this, but SLAV is no slavery mod and its only atmosphere is relentless absurdity.

We can imagine...

The actual TiR is nothing like the above. Maybe most people are happier with it the way it is?

CD was intensely loaded with grind, and yet people loved it for the atmosphere.

Just being allowed to be a maid felt like a big achievement.

And then you spent so long in that mansion that any trip away from it started to feel special.

You spent so long "being" a maid, that doing anything else in Skyrim felt odd. The only other games that have the same impact are Beyond: Two Souls and things from the same creator.

And when you were sent on those courier jobs, the fear of failure was ... immense. So much tension. Incredible.

CD has a lot of fans. TiR did too, but CD made a much bigger impression I think.

I believe that's because it made you feel something different to normal Skyrim. It created a different world and took you there.

I would imagine that Trapped in Rubber isn't going to get any changes now. I doubt its creator would ever have been remotely interested in my perspective on it, even when they were actively working on it. It's been untouched for five years, so we can safely assume it isn't going to change, and realistically any work done now would likely be a few minimal bug-fixes to keep it playable. That's all that's needed. Anything like the mod I'm dreaming of would probably be best off as some completely fresh project.

Alas, for those seeking more than a regular Skyrim quest, Trapped in Rubber is not really about being trapped, or being in rubber. It's just some nifty Skyrim adventures with a bit of dress-up and a nod towards exhibitionism.

It makes a nice change from regular Skyrim adventures, but in the end, you can do much as you like. The "trap" is hardly any kind of trap at all.

In Skyrim, it's made from a tiny number of polygons and has a texture that alphas out at the edge where it meets the eye.

It looks ... pretty bad on the best of days, if you zoom in close. The number of polygons and the way the alpha ended up being drawn in most eye textures means it leaves a visible gap, and really does look like some floating polygons that are jammed in the corner of the eye to fill in the gap in the head mesh.

But on elves...

It's way worse. So much worse. The eyes are scaled up, and this little splotch is twisted and made bigger. It really shows off how poor it looks, but on top of that, you will often see a bit "missing" from it, as if cut out. 

Today I set out to track down what was causing this.

The root cause is that the eye also has a shadow for beneath the lid, and this is also a few badly aligned polygons with an alpha texture on.

It turns out that a great many eye textures do not create this alpha correctly - it's not quite zero, and doesn't fade early enough.

The result is that the shadow polygons go in the z-buffer and partially block rendering of the eye-corner polys.

The fix is to either move the eye-shadow polygons over a bit (this is quite tricky to do, but you can do it in racemenu sculpt, or NifSkope), or to adjust the alpha in the eye textures you are using so it fades out early enough.

It bugs me that there are no high-resolution eyes. Probably some issues to do with facial expressions there.

A job for another day is to import an existing eye mesh into Blender and properly adjust the vertices so that the shadow doesn't overlap the little corner piece at all, and both parts fit better.

Whether or not a proper high-resolution eye is possible, or blocked by morph limitations I don't know. I guess the existing morphs could be reverse engineered and recreated, but sounds tricky.

The idea is to create a very small, extremely minimal defeat handler, with outcomes as plugins that can be added by other mods.

Basically, to take ALL the consequence handling out of the core defeat mod and provide a way to register arbitrary defeat handlers.

The most basic defeat handler is thus, nothing. You die.

That's the final fallback outcome if all else fails.

The base mod would come with some simple handlers, and some library functionality to do common tasks.

Other mods can then register into it via an API.

When defeat occurs, the core mod detects it, and contrives for the handlers to deal with it.

Handlers are all given a chance to prioritize themselves, and then they are given a chance to handle - though not all handlers may get a chance to handle, all get a chance to establish their priority, situationally, based on the conditions of the defeat.

Each handler decides for itself if it will handle the situation.

The handle/don't-handle logic is not part of the defeat mod, it just tries them in priority order, and the priorities are also calculated.

If we imagine it at an abstract level...

We have a DefeatState, which is the known state of defeat, including all the actors in play, and what side we think they're on (ally, neutral, enemy).

We pass that DefeatState to all registered handlers in no particular order, and they return a priority - this is their "bid" to handle the defeat.

We then refresh the DefeatState and test each handler in priority order, and ask it if it will *actually* handle the defeat. 

The handlers check the DefeatState and make a final call on whether they will run.

If a handler runs, it can then terminate the defeat or let other handlers continue it, or it can re-open the bidding process and let handlers re-bid.

If the active handler allows continuation, lower bidding handlers may ALSO run, but they will not get a chance to do so until the current active handler is done.

Again, they will be handed a refreshed DefeatState at that point, and decide whether to skip, handle and terminate or handle and continue.

External mods can call a well defined API to register handlers, but the assumption is that you will quickly develop a reasonable set of handlers to do the basic stuff, like rapes, teleports, robberies etc.

For example, a handler might calm everything, giving you time to make a run for it. That handler would have a cooldown, so if you're defeated again, you fall back down the chain and get ... death.

And of course, there might be a rape handler, or several...

So, a given run might look something like this:

At the Papyrus level, how do you register a handler? How are they called?

Handlers are quests that share a common extension script.

The specific handler overrides the methods in this script.

To register, you cast your quest to the common extension type, and hand your quest object to the defeat mod. It puts you in a list, and can call the defined methods on the quest any time. It can also check if your quest is running or not. If your quest isn't running, it's always skipped. This allows handlers to be enabled/disabled in their own MCMs easily.

How do you detect defeat? Isn't that a complex problem?

Yes. And defeat detection also needs to work with plugins to some extent.

There are two ways to go about this.

In one case, the detection is entirely in another mod, and it simply calls a mod event to inform the defeat mod of it.

The more interesting case is where the defeat mod collects information about the ongoing combat and passes it to the registered defeat handlers to see if they think a defeat is in progress.

This is nothing more than another Function defined on the base quest type, that returns one of a defined set of defeat types, the first of which is "no defeat in progress".

The data used to detect defeats looks uncannily like the data used to handle them. It's the exact same defeat state, but without a cause: we have actor lists organised by disposition, and a curious mod can traverse these lists and decide whether to trigger a defeat, or possibly modify the actors somehow.

A mod that doesn't care about detecting defeats can simply return, which of course is what the base class implementation does.

Queen's Blade offers some ideas. It's a world where every important warrior seems to be a woman. In fact, it seems the word "warrior" is synonymous with females in the world of Queen's Blade. What if we could use Skyrim to create something a bit like that? Male guards and fighters aren't non-existent, but they do seem rather rare.

Replace many male NPCs with females.

Mods like SkyFem and "Female Ulfric" seem appropriate here. Perhaps Futanarium and Babes of Skyrim might be useful too.

It might need a bit of work to be TAWoBA aware though...

Then there is stat changes...

Goodbye to SLS-style disparity.

In QB most female warriors are near-indestructible tanks, but are easily defeated by humiliation or a crisis of confidence.

Sexist Guards might still be fine, though you might end up changing some of the dialogs.

Implement some mechanics to represent the super-power female warriors:

Female warriors (PC included) gain a huge HP buff, significant damage buff (melee and spell) and are set Essential.

Then, depending on the personality type, they have different weaknesses.

Each weakness triggered removes some of the base-HP-buff and damage bonus - weakening the character - but we start from a decently large buff. There's plenty of room to reduce it.

• Nakedness: if certain slots are not filled (i.e. no underwear worn).
• Devices: if certain DD devices are fitted (particularly plugs).
• Clothes: if humiliating clothes are worn.
• Arousal: if the character becomes aroused. (Two variants, shameful and lusty, work a little differently).
• Poisoned: special poisons can weaken a warrior.
• Controlled: special magic, particularly worn devices that aren't "bondage" may still serve to control and weaken the warrior. Effects may be turned on and off.
• Hungry: I guess it's a trope.
• Fighting someone who is supposed to be a friend or loved one.
• Fighting for the wrong reasons  - attacking the wrong sort of NPC, such as children, non-combatants, shopkeepers, etc.
• Verbal attacks: intimidation and seduction.
• Irrational fears: these could be various, each one a different vulnerability - ghosts, skeevers, chaurus, spiders, fire, electricity, etc.
• Lawful: cannot bring herself to resist guards and other officials
• Drunk: or not drunk, if you prefer a warrior who is only strong when drunk, weak when sober.

The more vulnerabilities you take, the bigger your base buffs. Basically each buff is worth a scaled amount of its max vulnerability value, then you add them up. Some vulnerabilities are (almost) universal (like poison), so most female warriors will get some bonus. All warriors should take "Arousal", but choose either the shameful or lusty variant. Lusty is a lower buff, but it means it's less of a vulnerability too.

If you want a harder game, adjust the base scale so you get less buff per vulnerability; then the vulnerabilities will hit harder, and you'll need more to make up a competitive bonus level.

Remember, NPCs will have these bonuses and weaknesses too - at least if they are female.

Also, unique female NPCs will be effectively immortal.

Regular grunts like female bandits, or guards, won't get these bonuses, or weaknesses, even if female, because they're not an elite "warrior".

As the uniques are immortal, all can be removed from the crime faction and otherwise tweaked so you can fight them freely in town and guards will simply stay out of it.

Throw into this mix, bikini armor as the only type of armor.

Replace all female vanilla armor with bikini armor, and Nini outfits (that break).

Give special "boss" enemies Melodic armor. You cannot loot or use it.

Plus... armor-break mechanics. You don't win fights by defeating your opponent, you win by destroying their clothes/armor/confidence, making them aroused, etc.

All armor and clothes are sufficiently fragile. However, it's not about cash, items should self-heal during down-time. Sleep eight hours and your bikini gear is all better?

Lost clothes might be a different matter.

Because the uniques can't die, it's all about surrenders. Keep them as slaves using your PaH setup, or if you're the one defeated, become their servant via DF with a few dialog tweaks.

(Some more brutal owners might go for SD+ instead).

The vulnerabilities give the "deals" and "punishments" some real teeth and the mercenary obsession is somewhat in genre.

SLD will let you implement a bunch of these mechanics without writing any new code.

I guess some further SLD extensions could help implement the others.

Other mods have already been mentioned. You can put some of this together right now without any new code.

This works nicely with scenarios where the PC is forced to fight as a servant, gladiator, champion, etc.

Even though the PC may be physically strong, there are those that know how to control that strength for their own benefit, or take it away if it threatens them.

You're always vulnerable, because vulnerabilities are built-in to the system.

It would also be fun to play a character that is super-tough, but turns to jelly at the sight of a spider - without a need to make spiders super-tough.

Imagine fighting super-tough "Nazeemi". No guards intervene, it's just you vs her. Once you've destroyed all her armor, she surrenders, begging you not to embarrass her further... But of course you do...

Ways of dealing with arousal and negotiating or forcing sex with NPCs would be important.

For characters with serious sex addiction, there would need to be work arounds, such as potions or gear that can block arousal.

However, it's "by design" that a sex addiction in this sort of game is going to be a problem that can really mess you up if you aren't careful.

One mechanic is that a very high level of arousal would be required to trigger the debuff, which would be highly granular.

.e.g, take a hit at 80, 90 and 100, with anything below that being ok.

Also, getting naked would need to be a requirement to induce arousal, so you wouldn't get it just from looking at NPCs, or arouse NPCs unnecessarily.

But once the clothing/armor starts coming off...

I could see some tweaks to SLAX could make that work.

I've mentioned this on several occasions, but I raised it again recently, in the context of a discussion about Skyrim economics:

This triggered a long response by @HexBolt8 that you can find here: https://www.loverslab.com/topic/130527-devious-followers-continued/?do=findComment&comment=2936344

I'll summarize that as:

On 3/21/2020 at 7:50 AM, HexBolt8 said:

What about adding something new to the game?

Which in this case refers to a class of loot object.

It's got pros and cons vs an existing item like soul gems.

I won't dig into HexBolt's "rare trinkets" idea here, because while it's an interesting idea, it seems more interesting as an augmentation to other mechanics rather than a true paradigm shift in follower payment.

As a concept it's just not visceral enough. It doesn't immediately resonate. It's not a strong basis for a relationship.

What bothers me is that ... it just feels manufactured ... and that's true of soul gems and the other objects too.

@Darkwing241 also made an interesting response, which got closer to my thinking, but addressed the issue more generally: https://www.loverslab.com/topic/99955-sexlab-survival/?do=findComment&comment=2936294

To clarify:

What I'm looking for is something that makes sense for a follower you are already connected to, such as a housecarl, or a spouse, a "something" that would justify them treating you like a slave if you don't deliver it. i.e. It's not for a new mod, it's a feature for Devious Followers, and it has to work with most of the existing dialogs.

That doesn't mean no dialog changes. I think some dialogs would swap based on the payment 'mode', but it would be too tiresome to make all of them conditional.

There would also likely be additions specific to the mode, and some little tweaks in some mechanics - such as device removal.

I think the best thing would be something you do, not something you have.

The key is to then make that 'thing you do' appropriate enough, interesting enough, time-consuming enough, and yet also troublesome enough, that it is lore-friendly, immersive, and good-gameplay.

I'll list those points again, and number them:

• appropriate (it just makes sense lore and RP wise) - feels like the basis for a strong relationship
• immersive - feels like an event, not just a mechanic
• interesting - sufficient complexity
• time-consuming - usually easy to adjust
• troublesome  - some effort required on the player's part, some risk of failure
• gameplay - choices have consequences, some risk of failure

The obvious first try candidate for this is sex.

It's appropriate and immersive, but it's not very interesting, and generally not troublesome or delivering any gameplay, without building a complex system around prostitution, addiction, etc.

The follower could expect sex with others, or just with the follower.

Their reaction to non-delivery could then be treated as either frustration that you aren't satisfying them, or a natural outcome of them acting like a pimp and treating you like a whore.

The core problem with sex is that it would require a lot of new mechanics to make it work well. There is no existing prostitution mod that does the job appropriately in this context.

Most of those mods lack any satisfying gameplay, or any real risk, and are just easy ways to get money if you don't mind watching SexLab scenes over and over again. Only ME ever went beyond this, and it's not compatible with anything else and had many bugs besides.

It also has some 'logic' problems. Why would a housecarl do this? Why would a spouse who locks you in a chastity belt also whore you out? It feels a bit awkward. You can make up answers but they won't suit everyone.

So, sex is a "maybe", but not really a great solution without a lot of extra work that would block delivering the DF feature.

The spouse scenario I keep coming back to is my "running joke" vegetable stall.

It's more like a grimly realistic alternate start than a solution for DF.

Nevertheless, the idea of a spouse follower (or even housecarl) seeing the PC as merely a support character (regardless of the actuality) and acting accordingly is really a common story-basis for DF scenarios. It's not the only story, but it's one story you can use to rationalize what's happening in DF.

In this setting, the follower demanding cash seems strange. If we turn on gold control, it makes sense that they no longer demand cash but simply control it. That still leaves a very loot oriented game, which can be boring, and doesn't quite fit with spouse followers.

What could a spouse reasonably expect, either item or action?

One possibility is the opposite of sex. The PC just needs not to have sex with others. This is appropriate, immersive, but not interesting, time-consuming, or necessarily good gameplay.

Maybe too easy if wearing a belt, and as the only involuntary sex mod that isn't a straight-out rape mod is HH, it's pretty limiting. Suffice to say, there's something there, but it would need a lot more work to make it viable.

Another possibility is that the spouse makes arbitrary and variable demands: a mixture of radiant quests and Submissive Lola type demands for items. This is probably achievable. It's pretty close to what @Darkwing241 suggested, and very, very close to what Sex Slaves - Mia's Lair - Dominant Andrew does. Andrew has a plotline and progression mixed into his radiant quests, but it really is the same thing. What Andrew does is perfect for a possessive spouse.

The downside of this mix-and-match approach is that it isn't an obvious replacement for cash. There is no easy way to create an exchange rate between these different actions and cash, though you could assign values to each one.

As this fits in with the radiant quest mechanics I was thinking of for enslavement, there's some efficiency there, on the downside, it makes the normal non-enslaved experience more like being enslaved, which reduces the variety of experience.

I suppose it may be possible to have similar mechanics yet still make it different enough.

This could be adopted with slightly different dialogs for a bossy housecarl, or other "involved" follower who isn't asking for money, but is making demands.

Maybe mixing in something like the soul-gem mechanic, and "ancient trinkets" as well could help vary it.

It's getting pretty nebulous as an idea. I was looking for a simple answer, and I guess there isn't one?

The only "obvious" action is sex, and the drawbacks with that approach are already noted.

It comes back to a handful of simple questions:

What would be interesting for your housecarl to demand you do?

Why would your housecarl think it's OK to try and enslave you?

What would be interesting for your spouse to demand you do or give them?

Why would your spouse think it's necessary/useful to enslave you?

It's a nice mod that makes those animations much more satisfying.

The original creator doesn't actually explain that this mod does a little more than just improving the collision, but it does.

I find it a must have.

However, it has a couple of little bugs that cause it to spam your log with nonsense rather frequently.

In some cases I found it's repetitive bug-spam made up about 30% of my log content!

This small patch fixes the broken attempts to use None values and silences the log spam.

Your HDT SexToys will run silky smooth...

Unzip and overwrite, or use your mod manager. There's no ESP change, this is just scripts.

HDT SexToys BugFix.7z

Also allows you (and NPCs) to back-off faster; makes enemy casters a bit more of a problem for heavy melee types, and makes non-stealth skirmishing archery more viable.MovementSpeedsReFixed.7z

You might see a bit more lag on heel height updates, but overall I don't notice any difference.

hdtHighHeel-performance-patch.7z

Overwrite files in your existing HDT HH to install.

Chargen Presets.7z

In most cases I managed to capture the presets tab in the screenshot. For a couple I forgot. For some a particular ESP is shown as missing - it may not be - I merged a lot of follower ESPs into one, so the data is still there even if the ESP isn't. For follower ESPs it's probably hair or eyes that were used, which will be from a well known pack anyway. I didn't use a face from a follower pack or anything like that; the follower packs were referenced "by accident". Any face that is showing a vanilla hair, except Dotti, has lost its real hair, but I think I have about 400 hairs installed. It's something I change during play, and the last thing I pick during chargen; I don't always save it into the preset. The shots of the giant boob bimbos look bad because of the outfit. They will look better in a high poly outfit, or even naked, assuming your body is relatively modern.

If there's any value here, it will be mainly in the face edits. Some faces I hand-edited the meshes, and they should be included.

Blonde Nord went through some subtle evolution, and I've used her with a lot of different hairs in dozens of games. She's blandly attractive, like a Hollywood extra. Chinless Nord tried to improve on that by making her face less averagely perfect. Chubby-faced Breton takes it further. In play I gave her a large amount of white-silver hair, and you can see her in one of the article headers, wearing a yoke. I might be mistaken, but Squinty Nord is the one in my profile pic. I was aiming for a more northern look with her, Finnish or Lapp maybe? But it's an idealized fantasy.

Red Nord was the basis character for one of those Hormones games, and alas, she ended up as Pink Bimbo. She got the facial tattoos spending time with the forsworn, first as a slave, and later as an ally.

Fjori and Elfish Breton were also PCs. Fjori is a variant of Chinless Nord again, but a little less beautified. Ginger Nord was my first "weak girl" PC and I wanted her to have an outsider feel despite being a Nord. Meden was for a Maria Eden based game. The pink variants were all made mid-game for games with Hormones and the Bimbo curse.

You won't find my latest "Pure Falmer" PC here. I'll give her a post of her own sometime.

I don't plan to start any of this stuff until later in the year. Not sure when, it could be as late as June/July, or it could be a lot sooner.

Here's the rough order/priority I'm looking at:

1. new deals;
2. new games;
3. follower archetypes/quirks - things like alcoholic follower, sex-mad follower, greedy follower, etc.;
4. ability for the follower to set (radiant) quest objectives for looting opportunities;
5. (radiant) quests to find devious devices that you can wear to please the follower;
6. a way to "pay" followers that doesn't involve cash - though I have no idea what that is yet.
7. minor slavery extensions

New deals:

New games:

Additional Possibilities

Unfortunately, it has a lot of bugs. The "modified" version fixes some of them, making it sort of playable.

Almost every quest in TitD is a broken progression blocker. Why does TitD have so many bugs?

Why does Delzaron consistently make mods that have so many faulty quests?

To be fair to Delzaron, he's not the only modder with this problem, he's just the most prolific. I could name a few other authors, with buggy mods, who script their quests in exactly the same way.

When trying to patch up my TitD so I could play through it some more, I started to see various common recurring problems, with how the quests were set up. I think TitD serves as a "how not to" guide on writing quests, and there are some cautionary lessons to be learned from it.

Most broken quests involved a simple mistake or typo, or some non-updated value, but those mistakes all have a common root cause: unnecessary complexity. The quests are not cookies, they are snowflakes, and this massively expands the effort required to write and test them, to the point where it is impossible. Because it was effectively impossible, Delzaron failed.

How can we ensure that quest development remains in the realm of possible, or better still easy? Rather than hard, or impossible?

As mentioned above, the complexity and hardness comes from a few oft-repeated mistakes.

As these common mistakes are so well established, and known to be flaws in so many mods, you'd think that we'd stop seeing them.

Skyrim quests aren't written in a world of automated testing and extensive QA, and they can not easily be continuously updated without upsetting players with running games. Mods get periodic releases, and those releases should be as robust as possible to avoid player angst; quest logic should be as defensive as possible. If it allows the player to cheat, it's better than a quest that easily becomes blocked.

• When you do multiple bad things, you compound the player's pain.
• When you do multiple good things, you reduce the risk of your mod breaking, even if you make a mistake somewhere else.
• The following practices combine together to help stop the root cause of numerous quest bugs that have a common form.

1) Quest stages should be self contained

What I mean by this, is if you do "setstage" on a quest, the quest should be set completely in the correct state. It shouldn't be possible to run setstage and have the quest go into an inconsistent or broken state.

For example, some player dialog becomes available at stage 50, if you have collected 10 mushrooms.

Choosing that dialog runs a fragment that sets another NPC's faction, sets that NPC's location, and puts a key in their inventory. Then it sets quest stage to 60.

What's wrong with this?

The problem is that if you want to test this quest, you cannot simply set the stage to 60, because the NPC won't be set up properly.

If this quest breaks, you cannot simply set the stage to 60, because, again, the NPC won't be set up properly.

How it should have worked is quite simple: the dialog fragment should have done ONE thing, set the quest stage to 60.

Then, the trigger script for stage 60 should have set up the NPC's faction, location and inventory.

In this case, you can test stage 60 of the quest without any additional preparation, the stage is "self contained".

Following this rule avoids so many problems.

The bad pattern occurs when the logic to set up the quest stage is hidden away somewhere in a different stage. This is not good modularity or encapsulation. Quest stages are a developer tool to help organize work, but many modders use them with no clear objective in mind, just because they think they should

2) Quest stages should serve a clear purpose

If you have quest stages that exist without objectives, alarm bells should probably go off. Why does that stage exist? What state is it representing?

In most cases, a quest stage should have a matching quest objective that the player can see, and the stage advances when that objective is met. Such quests are easy to understand as a player, or developer, and are easy to test.

The worst example of this is ping-pong quests that bounce quest stage updates between multiple quests, where none of the stages were strictly necessary, and served only to update a stage on a foreign quest that itself serves no purpose at all but to update back to the previous quest. Multiple quests become entangled for no reason.

However, there are legitimate reasons to have a stage with no objectives, particularly if the goal is to sequence events in a simple way.

A classic example of event sequencing is the multi-step dialog. The modder uses quest stages (without objectives) to make the player have a conversation with an NPC in a certain order. Each time the player addresses the correct topic, and gets down to the right branch, the quest steps forward, unlocking the next topic and disabling the old one. This is a reasonable way to turn the dialogs on and off, because it's easy to set the quest stage to test the dialogs, and the fragments that advance the dialog stages are simple owning-quest setstage calls. Additionally, testing a quest stage in a condition is quite efficient. 

This pattern is broken when the modder does strange, random things:

• The progression of stages is erratically numbered, or jumps back and forth between dialog on different quests in a way that makes following it in the CK extremely tiresome.
• The stages actually go down as well as up. Very confusing.
• The stages intermix variant ways to control the quest, sometimes stage number, sometimes a variable.

3) Dialog conditions that involve == on anything but a quest stage are fragile

The rider to this is: counter values can advance unpredictably.

The corollary of this is that dialog conditions that use == on a quest stage are a good thing, but on counters that go up, probably bad, and on values that take on non-integral values, disastrous.

How many mods have you played where you collected one flower too many and the quest become impossible to finish?

Jobs of Skyrim, I'm looking at you!

Things in the Dark has the same problem. Press the button that advances your slave ranking, and you'll skip past ranking 8, never hit the magic slave-ranking value in the dialog conditions and never be able to transition from Daithe to Hashep. Worse, you can't just setstage to start the Hashep quest-line because this quest violates rule (1) above.

The solution to most of these counter bugs is to test >= instead of ==, then if something unexpected happens, your quest can still progress.

And by always using a dialog condition with a stage check that asserts the correct stage, the game won't end up polluted with dialogs that should have gone away because they'd done their job.

Counter values are particularly unreliable in Skyrim, due to threading, and slow Papyrus, and the player's ability to mess things around, you are asking for trouble when you expect counters to take on exact values. You never know whether you will see every counter value that is set, sometimes you might miss several. If you test for 20 petals, the odds of the player being able to get 22 before your check runs are decent. Just because you never see that case in testing doesn't mean it can't happen.

But if the player has to go through a certain dialog to advance the quest, and that dialog only shows up for the exact stage that needs it, that's a good thing, stick to that pattern.

4) Use a coherent numbering scheme and keep stages ordered

When quest stages are numbered 0, 10, 20, 50, 53, 54, 55, 67, 90, 100, and three of those stages are not even used, it's harder to work on that quest and keep it aligned with other quests and dialog conditions than if it used sensible numbering.

It's even worse if a quest's stage numbers differ wildly from its objective numbers.

In the cleanest case, objectives and stages have the same numbering, so you don't have to flip back and forth between stages and objectives to figure out what is being done.

There is no reason not to start with quest stages rising in 100s. This allows you to use a pattern of steps of 5 for cases where you are doing simple dialog sequencing. Then, when you see a value other than a round hundred, you immediately know it's dialog sequencing.

Of course, sometimes you need to add a stage to an established quest, but this really should be a last resort. Using steps of 100 makes this a lot less likely to run into a blockage though. In such cases, you should still strive to always keep objective numbers lined up with quest stages - there's no reason not to do that and not doing it can be enormously confusing.

5) NPCs can move - cope with it

Things in the Dark, and Deadly Pleasures are frequently upset by an NPC being in the wrong place. NPCs walk off and start doing odd things, but the quest demands them to be in a certain room or near a certain marker. In some cases, TitD ports Frabbi out of the city, totally blocking your progression - it's not really what I'm talking about here though - the most obvious issue is NPCs that you have a talk objective with, who will not talk. That said, all kinds of misplaced NPC issue should be considered.

Assumptions that NPCs will be where you expect are highly likely to be wrong - unless you have immediate (short term) measures to get them in place.

If the PC needs to talk to a certain NPC, don't constrain that conversation to only taking place in a specific location. Constrain it by quest stage. That is enough.

It will be easier to test, and work better for the player.

Unless you have a really good reason, and proper mechanics around it, stopping the player from having a conversation just because they're in the wrong room is infuriating, and leads to player confusion again and again. They have no idea why they can't progress the quest, and why the dialog is missing.

They have a quest objective to talk to NPC X, but NPC X has nothing to say!

Avoid that pattern. It's a cause of woe.

When dealing with mods like AI Overhaul, NPCs will walk off to all kinds of odd places. If an NPC must stay put, you  need a special "priority 100" quest and AI package to lock them in place.

Even that may not be enough. You may need a way for the PC to summon the NPC "in game".

For example, if your quest requires Frabbi to be in the ruined dwemer pumping station, then port her there at the stage start.

But if the player enters the station, check to see if Frabbi is there. If she is not there, port Frabbi outside the (only) exit of the pumping station, so when the frustrated player leaves, he bumps right into Frabbi and can have the conversation.

Another thing that follows from this is quest markers - if the goal is an NPC, make sure the NPC is the target, not the location that they may not be at. In DP you can arrive at the quest location, but nine times out of ten, the NPC isn't there. As you don't know who you have to speak to, there's no easy workaround.

6) Scenes are your friend - don't make them an enemy

Slaverun has a mechanism for using scenes that allowed Kenjoka to write massive amounts of story content without much in the way of bugs. In comparison, TitD has a small amount of story, and it fails to advance it correctly at almost every single step. 

Why did Kenjoka have no problems with this issue in Slaverun Reloaded, but Delzaron hits an iceberg on almost every single quest in Things in the Dark? It's not because one of them is simply a genius who keeps it all straight in his head, it's because Slaverun has a high-level system for triggering scenes, and that system is used over and over again to run the story content. This allows the story content to be tested simply by triggering those scenes at the high level.

In contrast, every story segment in TitD and DP is a hand-crafted snowflake, built out of quest stages, gated dialog, forcegreets, and AI behaviors.

Anything that uses Skyrim AI is inherently fragile. It's mostly fine when you have it working right, but only mostly, and it's hard to get right in the first place. AI sometimes fails for no obvious reason, and the CK mechanism for editing it is extremely fragile. Edit working AI, change nothing, and it suddenly stops and will never run again. At all. As for sharing AI ... it's hazardous.

Scenes require no AI behaviors. All you have to do is ensure the participants are present, then start the scene.

If the scene has the PC in it, you probably have to move the camera to a dummy and lock their controls while it's running. If you have a scene management system you only need to write that code once.

Where scenes go wrong (and alas, Devious Followers is the archetype for this) is when they bind scripting into the scene stages, ad-hoc, possibly even advancing various quests as they go.

This is terribly hard to maintain, because you have to know exactly which scene steps have script buried inside them. There are so many places you can hide a script away in a scene. For example, on the dialog lines instead of on the stage that fires them. There is too much freedom, and if you abuse it, you'll never untangle the mess that results.

If you're going to run a script on a scene, stick to one script, run at the finish. At most two (one at the start, and one at the finish). You should need very special reasons to run scripting mid scene, and if you do, it shouldn't advance quests or make changes to internal state that advance quests, it should be purely to help the NPCs "act" during the scene.

7) SexLab can fail

Don't assume that a SexLab scene will start and run to completion just because you try to start it.

If your quest progression is controlled by an animation end handler for SexLab, one missing animation blocks your quest.

This is a very simple mistake, and it's simple to fix. Never advance quests (directly) based on a SexLab animation end.

If you want to run a pre-defined SexLab scene - create a high-level manager to ensure that shared logic for SexLab scenes is written once and tested many times, not different and unique for each use case.

Design the high-level manager so it ensures all participants are present before trying to start the scene, starts the expected scene, and returns, or raises a mod event on animation end. If you know the animation failed to start, handle that immediately in the manager (spit out a Debug.Notify and act as if it ran). In the event of no animation end, use a timeout to catch it. No matter what goes wrong, when the manager determines the scene ended cleanly, or didn't start, or crashed, the caller can safely advance the quest.

If there's a debug notification that the player can see in the event the scene doesn't run properly, all the better.

If the manager crashes and takes down the control flow, you're still hosed. You can defend against this, but it adds complexity.

A high-level scene manager that ensures participant presence solves a lot of problems. I'd rather have an NPC appear from nowhere for a scene, than the entire quest sequence block forever because they weren't in the right place at the magic moment.

In most cases, a well written manager will not crash, even with missing animations - that should be a tested case.

Deadly Pleasures requires the player to have a special "Patreon contributors only" animation pack. It says it works with the free version, but that's not true at all. Because it doesn't handle missing animations well, and because using the free animation pack leads to many missing animations, this results in broken quest progression on numerous occasions.

I would suggest that this is not a good development pattern, unless you want players to start avoiding your mods due to a consistent expectation of nothing but broken quests.

8 ) Branching within Quests

Skyrim quests, as designed by Bethesda, are not really intended to support branching within a quest.

If you look at vanilla quests, they rarely introduce optional content. If they do it's usually a stage you can progress by either method (a), or method (b), or a stage with an optional step (c). Most quests progress with simple AND conditions. If you meet all the requirements, you go on to the next major stage.

The flow of vanilla quests is typically sequential, (often) with no stages skipped, and stages only advancing. Some quests let you skip a stage here or there, or provide a basic OR in how you can progress. When they want to start a genuine branch, they usually launch a new quest to do it.

The quest system is designed to support this model, and becomes awkward if used for other models.

Quest stages can only get set to higher values. Stages have a concept of completion. Code is run on stage start, and on completion do nothing other than a SetStage().

Usually, new stages clean up the objectives of old ones. It's quite simplistic.

While we have a function that is run on stage entry, there is no equivalent for stage exit (which is a serious flaw, and is probably why so many sloppily made quests don't clean-up objectives properly).

There's an interesting bug/feature here ... if you SetStage to a LOWER stage number, the set will not change the stage, but the stage entry script will still execute! This can lead to modder confusion.

You can definitely create more sophisticated logic, but Skyrim does nothing special to help you. Quests are designed to work the simple way I suggest above, and that's it.

That is how the journal objective system is designed to work: do steps, in order, finish quest, success, get reward.

There aren't many branches in Skyrim vanilla. There are some exclusive choices, but they're usually done by starting two quests and failing one of them when you finish the other. Civil War does this for Storm Cloaks vs Imperials vs Broker Peace.

Using that model, it can launch a new quest any time, and have that quest shut-down competing branches.

If you want to make vanilla-style quests, you should design like this. It's not a huge benefit, but it's a benefit. The alternative is that you have to write a quest system of your own in script.

Misapprehension of this pattern leads to Delzaron coming unstuck sometimes, but most of his quests are linear and fit this model perfectly.

Fish seems to "get" it, but still gets sloppy with objective clean-up.

Sex Slaves permits branching, so it launches "competing" quests, but you can't complete them all successfully.

While you can build multiple paths into a single quest, it's not really the intended pattern and it makes objective clean-up harder; there are ways to be rigorous about it, but Beth just don't bother; it's probably easier and cleaner to make a new quest.

e.g.

10 Learn you must find the maguffin

20 Magguffin found - sets objectives "give maguffin to a Ulfric or Balgruuf"

30 Maguffin given to Balgruuf - start new quest Balgruuf's Maguffin

40 Maguffin given to Ulfric - start new quest Ulfric's Maguffin

50 Clean up objectives ... Completion

vs

10 Learn you must find the maguffin

20 Magguffin found - sets objectives "give maguffin to a Ulfric or Balgruuf"

30 Maguffin given to Balgruuf - go to stage 100

40 Maguffin given to Ulfric - go to stage 200

100 Clean up common objectives from 10-40

110 Do stuff with Balguuf's maguffin... Go to stage 300

... (various stages)

150 Complete Balgruff's maguffin quest-line

200 Clean up common objectives from 10-40

210 Do stuff with Ulfric's maguffin...

... (various stages)

260 Complete Ulfric's maguffin...  Go to stage 300

300 Completion

And if you want to unify clean-up ...

10 Learn you must find the maguffin

20 Magguffin found - sets objectives "give maguffin to a Ulfric or Balgruuf"

30 Maguffin given to Balgruuf - set Balgruuf flag - go to stage 50

40 Maguffin given to Ulfric - clear Balgruuf flag - go to stage 50

50 Clean up objectives from before (unified clean-up), branch on Balgruuf flag, go to stage if true 100 or 200 if false

100 Do stuff with Balguuf's maguffin...

... (various stages)

150 Complete Balgruff's maguffin quest-line... Clean up Balgruuf objectives ... Go to stage 300

200 Do stuff with Ulfric's maguffin...

... (various stages)

260 Complete Ulfric's maguffin... Clean up Ulfric objectives ... Go to stage 300

300 Clean up common objectives ... Completion

See how much simpler it is if you don't do branches within the quest?

Often, we'll see quest authors mush their stages together, performing multiple activities per stage to get around this.

This muddy thinking often leads to them getting muddled about what a stage should do, or having poor stage planning and design.

It also leads to "objective clean up in completion code" which then creates broken objectives when players SetStage from the console.

Last Words

A smart person learns from their mistakes. A really smart person learns from the mistakes of others.

I know this seems like a hatchet job on poor Delzaron. I used his mods as an example, but he's not alone in doing this. I love what he's trying to do. I admire his persistence. His mods are consistently interesting, and raise all kinds of provoking possibilities. However, his scripting is a tail of tears, and I think it's worth examining why, so that others don't go down that same road and fall straight into the same potholes.

There are other good/bad habits I didn't mention.

Maybe you've come across some quest patterns you'd like to never see again?

Often, the problems only manifest when three or more mods are involved.

The way to avoid these problems completely is quite simple. The problem is created by a handful of bad patterns, and there is nothing mysterious or magical about it.

There is a solid reason for why it happens, and why it can sometimes be quite complex to reproduce, or for a player to fix when setting up a new LO.

In most cases, the cause of problems is a mod that has code to call some foreign mod in a quest script that auto-starts, and it doesn't check whether the ESP is present, it simply calls Game.GetFormFromFile and if it gets a None, it assumes the mod is missing. USLEEP does this FFS! It is the root cause of all that stupid spam it spews on every single game start.

This pattern is toxic. Do not ever do this:

Form foo = Game.GetFormFromFile(0x00123456, "Foreign Mod.esp")

If foo != None

    TypeFromSomeOtherMod realFoo = foo As TypeFromSomeOtherMod

    ... do something with realFoo

EndIf

So what should you do?

Follow the five rules to avoid ever referencing types that don't necessarily exist, and your mod should be much more stable with respect to soft-dependencies, even if you rely on a mod that is a confluence of trouble, such as SLIF.

The Rules

1) Put all the mod interactions for a single foreign mod into a single global function. Do not (ever) mix mod interactions between different mods in the same file!

2) Do not interact with a type from a foreign mod in any function other than a global function.

3) Do not access a global function that performs an interaction with a foreign mod without first confirming that its ESP is present.

4) Do not access foreign mods during first start-up of the game.

5) Avoid access to foreign mods during OnLoad and equivalent events.

You can see this pattern followed properly in Deviously Cursed Loot.

SLD doesn't follow these patterns properly; there are several errors that need to be fixed.

It seems to get away with it anyway, but it's better to be safe than sorry with Skyrim.

But why?

Quite simply, if you reference a type from a script file that doesn't exist, Skyrim doesn't know how to handle it. The type is garbage. It will either CTD, or - if you are lucky - the type will be incompatible with all objects and never take a value apart from None.

To be sure we don't reference types that don't exist, we must make sure those types are not present anywhere in a script we might execute when that type's defining script doesn't exist.

And if that defining type is bound to an ESP, it will also need that ESP, so we should check that exists first.

The type only properly exists when its script files are present, and the best rule we have for determining the presence of the script files, is the presence of the ESP.

This is important for other reasons too, because we need the ESP to populate pre-defined properties on foreign types.

Clearly both ESP and script need to exist, but checking both creates an absurdly tight binding, and is busywork that requires special Papyrus extensions anyway.

It's good enough to check for the ESP. It's not good enough to skip that check, because an object script without its ESP may be parsed but will still break your game because its an orphan: a class that has no possible instances.

Only global scripts can operate properly without their parent ESP or ESM, because a global script cannot be instanced.

By putting the interactions in a global function in a script that contains only global functions, we can be sure that our mod will never try to reference those types unless we explicitly call the global.

The same is not the case for a script attached to a quest. If you attach a script to a quest, its papyrus instance will be created when the quest is started.

If the quest is auto-start, that will be on first load of the game.

So, if you reference a foreign type - even if due to control flow, you do not execute that reference - it is still processed by Skyrim when the potential calling script is loaded.

Skyrim must know the type's signature, and to do that it instantiates the type, and to do that, requires an ESP.

Using global scripts stops this, because they are not pre-instantiated, and they are only instantiated when executed, and executed when explicitly called.

But we must be sure not to call those globals at sensitive times, of if the scripts (and types) they rely on do not exist, or cannot be instantiated.

Thus, we check the ESP of the foreign mod exists before trying to call the globals, and we only call the globals from "safe" functions that will not run on first game startup.

I'm simplifying a bit. It's really only an issue with scripts that are bound to objects, but those are the most common soft-dependency. Any other kind of script would be a global, and would have no persistent internal state and no properties. For such scripts the mere existence of the script object is enough. If it's missing, your game will not explode. Though the code that tries to call it won't work and will crash, merely having a reference to it in your own quest won't cause an issue at all, beyond the crashing of your script that is.

Why must we avoid first game startup?

This is important because the foreign types we want to reference may not even be loaded, even if the ESP exists.

Skyrim loads the types when the ESP loads, and normally that happens in strict load order.

But if we reference a type in our script, it will cause the script that defines that type to be loaded before the ESP that instances it.

This is not well supported in Skyrim. 

Either way, we don't know the load order, and whether the other mods have loaded yet. This is why changing load order can sometimes fix issues.

If your mod is not following the pattern cleanly, but loads really late, it might get away with it anyway.

OnLoad is an edge case.  OnLoad doesn't run on first load (strange, I know, but I believe this is on purpose so OnLoad can rely on initialization).

So, mods that reference foreign mods in their OnLoad should be safe? They are. Mostly.

In some cases, a player adds a mod during play. That mod may then get picked up by a "naughty" soft-depending mod that checks for soft-deps OnLoad, but the mod just added by the player might not have properly loaded. This is why checking in OnLoad is hazardous. If you don't add mods mid-play, it will be fine. And if you do, you may get away with it if the mod gets properly loaded before the OnLoad for the depending mod runs. SLD seems to get away with it in practice, but you shouldn't push your luck; I see the SLD behavior as a bug that needs to be fixed.

Practical Examples

So, where should we check for foreign mods? I believe the correct answer is in an OnUpdate handler.

When OnLoad runs, it should set an int "checkSoftDeps" variable to 1.

It should also set the presence of ALL soft-dep mods to false - keep a boolean flag for each one.

When OnUpdate runs, it has a branch that runs if checkSoftDeps > 0

Inside that branch it increments checkSoftDeps

If checkSoftDeps > 2, then run the handling code to check for soft deps, then reset checkSoftDeps to 0.

This makes it impossible to run the checks prematurely, but only requires one variable.

Inside the soft-dep check handler, we need to see if the ESPs are present.

If the ESP index is not 255, then it is, and we can set the presence flag to true.

e.g.

In OnLoad:

    checkSoftDeps = 1

    slifPresent = False

    aproposPresent = False

In OnUpdate:

    If checkSoftDeps > 0

        checkSoftDeps += 1

        If checkSoftDeps > 2

            slifPresent = 255 != Game.GetModByName("Sexlab Inflation Framework.esp")

            aproposPresent = 255 != Game.GetModByName("Apropos2.esp")

            checkSoftDeps = 0

        EndIf

    EndIf

In code that uses apropos:

    If aproposPresent && 255 != Game.GetModByName("Apropos2.esp")

        Actor aproposActor = MyModAproposShim.GetAproposActor()

        ...

    EndIf

In the Global function file MyModAproposShim:

Actor Function GetAproposActor() Global

    Apropos2Actors actorLibrary = Game.GetFormFromFile(0x0002902C, "Apropos2.esp")

    ....

    Return foundActor

EndFunction

Note how at the point of use, the mod ESP is checked again, even though we have the boolean? That's because the boolean may not get reset fast enough via OnLoad, but it saves us checking GetModByName over and over if the mod is never present.

Note how only the global function, safe in its own file contains an actual TYPE from Apropos2: Apropos2Actors.

When I wrote SLD, I was under the misapprehension that simply not using a type was enough. That is wrong.

If the type is not loaded, and you load a script that references it, you can break the game. Not necessarily though, and that is where the complex results that Monoman wrote about originate. See my comments in the spoiler on first and second consumers.

This topic has actually been written about by engine experts, but the posts are hard to find.

Essentially, if you reference the type, and the mod isn't loaded, you will cause the type to be loaded if it can be. If that goes ok, then your mod may not cause a problem, but you may have now caused a type to load outside of the normal order of load ordering ... consequences of this can result in the type itself breaking, but if it ends up trying to load references to ANOTHER type that is itself later in the LO, and that's where things can go bad. If you start this chain, and any type is missing, Skyrim fails to instantiate the type, and code - in some other mod - may then try to use it anyway, and CTD.

Thus if you follow the pattern, you stop other mods that aren't well-behaved, from breaking the game.

Some things to think about...