ASF - Autonomous Sex Framework 2.0.4 RC

ASF makes it easy to add sexual autonomy to NPCs, and handles all of the common pitfalls for you. If you have ever implemented sex between randomly paired NPCs, you know how deep of a rabbit hole this endeavor is. It can take hundreds of gameplay hours to find all of the edge cases, which interrupt ongoing quests/scenes. At times these edge cases break immersion, other times they break player quests. Either way they frustrate the player. This framework's goal is to handle as much of that for you as possible, while being far more performant and responsive than your typical actor search. It builds on my knowledge maintaining an autonomous sex mod, and then finding and patching edge cases.

 

ASF starts by creating a list of relevant actors, it distributes a keyword to them (ASF_ActorBase_Included) using SPID. This step filters out children, mannequins, etc. All before the main menu has loaded. It also allows for user preference, where some users might tweak their SPID to filter out beast races, elderly females, that sort of thing. The vast majority of actors will end up completely ignored by ASF, because they are not relevant to this type of mod.

 

The actors that receive that keyword will be given a spell. The spell effect starts when an actor enters the same area as the player. That spell listens for OnPackageChange. It then checks to see if the current package can be safely interrupted by a sex scene. If it is safe to interrupt, the actor is dynamically given the ASF_PackageValid keyword. If they can not be interrupted, the keyword is temporarily removed.

 

Thus when you enter an area, all actors who are currently relevant to autonomous sex will have a keyword assigned to them. Using the function FindAllReferencesWithKeyword we can instantly get a list of nearby prevalidated actors. ASF provides a convenient set of functions that are internally powered by the above. These functions will honor user MCM options, and help you avoid additional pitfalls.

 

ASF breaks actors out into two groups. Those who initiate sex, and the actors they can have sex with. Initiators and Recipients. An actor can be in both groups. But you might opt to restrict some actors to just one of the two, for example slaves will commonly be recipients only. If you want to find a valid initiator to start a sex scene, you can use the ASF function FindActors_Initiator(). If you then want to find a valid recipient for them, you can use the function FindActors_Recipient(Initiator=ActorYouJustFound).

 

Initiators are different from recipients in a few ways. For example, the default MCM settings will not mark an initiator as valid if they are sleeping. But a recipient would still be a valid target for someone's sexual interest, even if they are sleeping. So a sleeping actor might continue being a valid recipient once they go to bed, but they will stop initiating sex scenes since they are asleep.

 

ASF's FindActor functions will do additional last minute filtration on actors, ensuring that they are not engaged in temporary actions that we should not interrupt. It filters them out using Condition Functions, so the performance rivals alias fills. But you do not need to build complex sets of aliases yourself, ASF provides you that level of performance via a simple API instead. It further handles distance in a realistic way, preferring to pair together actors who are closer together, and stopping as soon as a valid pair is found.

 

ASF can optionally be provided a SexLab Thread, which it will populate with valid actors. If an actor can not be added, it continues searching for the next closest match. It can optionally reserve a thread when a valid actor is found, which can notably reduce how much work SexLab has to do for autonomous sex. The function StartRandomScene() provides a great demonstration of how to use all of the above functionality. And it might be the only function your mod uses, depending on how straight forward your needs are.

 

ASF is extremely flexible. Each function in the API is documented in the code, in the same manner that SexLab documented its functions. Just open ASF_API.psc to get started.

Some additional features

• The search functions can return multiple actors, making it easy to start group sex scenes.
• On each PackageChange ASF adds the following keywords to an actor, if they pass the relevant conditions:
  • ASF_PackageValid_Initiator — Current package indicates that they are a valid initiator. If the SLA integration is installed, then this actor is also currently aroused.
  • ASF_PackageValid_Recipient — Currently valid recipient.
  • ASF_PackageValid — Is either a valid initiator, recipient, or both.
  • ASF_ActorGroup_PlayerTeam — Actor is a follower, includes temporary followers from quests. Also includes player.
  • ASF_ActorGroup_Guard — Actor is a guard.
• You can mark actors as Initiators or Recipients by giving them keywords.
  • The keywords:
    • ASF_Initiator_Included
    • ASF_Initiator_Excluded - Takes precedence over the Included keyword.
    • ASF_Recipient_Included
    • ASF_Recipient_Excluded - Takes precedence over the Included keyword.
  • These keywords can be directly assigned to the NPC_ via your plugin, or SPID.
  • Can be assigned to a clothing item. While an actor wears that clothing they will inherit the keywords effects.
  • Can be added to a MagicEffect. When this effect is active on an actor they will inherit the effects of the keyword. This is especially useful for temporary exclusions. You can create a spell (or copy one from ASF) that temporarily excludes an actor. Cast it on the actor, and then dispel it when you no longer need to exclude the actor. It is not recommended to directly cast the ASF exclusions spells on actors, because these might get dispelled by ASF itself or by another mod. Instead create your own spell by duplicating an ASF one. Cast the duplicate, No other mod will dispel it because it is your spell.
• You can distribute the keyword ASF_ActorBase_Included directly to any actor that your mod needs to be included in ASF. Assigning this keyword directly will override user preference; which is beneficial in cases where user preference could break your mod. For example your story quest might expect a specific Argonian NPC to have sex, but user preference causes ASF to ignore all Argonians. On the other hand you can distribute the keyword ASF_ActorBase_Excluded to anyone who should always be ignored by ASF.
• You can distribute custom keywords to actors via any convenient means: using a plugin, SPID, or given dynamically at run time. Then search for those actors using ASF FindActor functions. You can pass these functions multiple keywords. Give it your keyword to limit results to your actors, and pass an additional PackageValid keyword to further narrow the result to only valid actors

Extra advanced features

• Can create your own custom Condition Functions for the last minute validation, and use that in your searches. The primary use case for this would be if you wanted to further filter actors beyond the SexLab valid checks that ASF does.
  • Say you want to quickly find valid recipients that are currently under the influence of a calm spell. You can accomplish that by copying the recipient valid condition list, and then adding your extra checks.
  • Before diving this deep into ASF's flexibility, you should first familiarize yourself with the EvaluateConditionList() function that powers it.
    • Each condition list is a MGEF, which ASF internally refers to as Evaluators.
    • ASF passes an Evaluator MGEF to the above function, along with a subject actor to evaluate.
    • Optionally ASF can even be told who this actor will pair with, in which case they will be made the target in the Condition Functions. The currently evaluated actor remains the subject.
    • The condition list evaluates the subject and optional target. If the subject passes all of the conditions, they are included in the returned list of actors. If they fail to pass they are excluded from your search.
• You can have ASF add/remove keywords to actors during certain events, based on whether the actor fails or passes the conditions you specify. You just need to add your custom Evaluator to the appropriate FormList. Assign your Evaluator the keyword that you want ASF to manage. Inspect the following FormLists to better understand how this works.
  • ASF_FLST_Evaluators_Enduring — Evaluators in this list will run once, when the actor enters the currently loaded area. This list is useful for conditions that are unlikely to change very often. For example, whether or not the actor is part of the Guard faction.
  • ASF_FLST_Evaluators_Package — Evaluators in this list will rerun every time the actor switches packages. Like the above, keywords will be added/removed based on whether the actor passes the condition.