Request For Comment: OSF Scene Framework (Sex Framework Base)

[ozooma10]

RFC: OSF - Native Scene Framework for Starfield

A native, data-driven animation and scene runtime for Starfield

 

 

I am working on OSF, a WIP native animation and scene framework for Starfield.

The goal is to provide a shared runtime for running scenes: coordinated multi-actor sequences with actor placement, synced animation playback, stage transitions, timed effects, callbacks/events, matchmaking, and reliable cleanup.

 

The full RFC is here: https://gist.github.com/ozooma10/49420d81804b2240a0b77a6c732f844c

 

This thread is mainly for discussion and feedback... trying to gathers others thoughts/opinions to shape the initial release.

 

The RFC is much more detailed and much better explaining the intention behind things. Trying to paraphrase ideas for the rest of this LL post... Really fighting the formatting 😬

 

The core idea

An animation moves bones.

A scene coordinates actors, timing, world state, effects, navigation, events, and cleanup.

 

A real scene often needs to:

• bind actors into named roles;
• place and anchor those actors together;
• play synchronized animations on one shared clock;
• advance through stages or branches;
• run timed side effects like camera hold, fade, control lock, equipment changes, sound, etc.;
• notify other mods when specific moments happen;
• stop safely if interrupted;
• restore whatever state it changed.

 

Currently, most of that has to be rebuilt per mod. Usually that means Papyrus orchestration, polling, ad-hoc cleanup, and a lot of scene-specific glue code.

OSF tries to make that infrastructure shared, native, data-driven, and reusable.

 

 

What OSF is trying to be

OSF is meant to be a native scene runtime, not just another animation player.

At a high level:

• Animation authors ship animation clips plus JSON metadata.
• Scene authors compose animations into staged, looping, or branching scenes.
• Quest/content mods start scenes directly or ask OSF to find a matching scene by tags.
• Integrator mods listen for scene events and define their own custom actions.
• Users get a more consistent scene ecosystem with fewer one-off controllers fighting each other.
  

 

 

How it relates to NAFSF / SAF

NAFSF and SAF are primarily playback/sync frameworks. They move and sync the rig.

OSF uses the same broad native playback idea, but is trying to own the scene lifecycle above playback:

• actor-role binding;
• world anchoring;
• shared scene clock;
• stage and graph navigation;
• timed actions;
• scene events/callbacks;
• animation and scene matchmaking;
• deterministic cleanup;
• built-in reversible mechanics.
  

 

OSF is planned to have a SAF compatibility shim so it works as a drop-in replacement.

 

 

How it relates to SexLab / OStim / AAF

SexLab, OStim, and AAF proved that shared scene ecosystems matter.

The useful lessons are things like:

• shared scene infrastructure;
• tags and metadata;
• matchmaking;
• scene events;
• data-driven authoring;
• stage/graph navigation;
• reliable cleanup.
  

But directly porting one of those frameworks would also port engine-specific assumptions from Skyrim or Fallout: Papyrus contracts, skeleton assumptions, actor handling, slot systems, event timing, and legacy compatibility layers.

OSF is trying to take the useful ideas and design the contracts around Starfield/SFSE from the start.

 

 

Core design goals

• Native playback where native playback matters - per-frame animation work should not be Papyrus-driven.
• Scenes as the unit of control - playback is one component; the scene lifecycle is the framework.
• Data-first content - animation packs and scene definitions should be JSON-driven.
• Content-neutral core - OSF core should know actors, roles, animations, tags, actions, events, and cleanup; it should not hardcode adult policy.
• Adult-facing wrapper - adult use cases still need convenience: stripping defaults, camera/control defaults, furniture rules, role conventions, tag conventions, etc.
• Extensible actions - built-in actions use `osf.*`; other mods can define actions like `yourmod.spawnProp`.
• Deterministic cleanup - anything OSF changes, OSF should be able to undo.
• Good diagnostics - authors should know why a pack or scene failed to load.
  

 

 

Example authoring

A simple scene should ideally be close to this:

{
  "id": "author.scene.example",
  "tags": ["pair", "standing"],
  "roles": [
    { "name": "actorA", "gender": "any" },
    { "name": "actorB", "gender": "any" }
  ],
  "stages": [
    { "id": "start", "anim": "author.anim.start" },
    { "id": "loop",  "anim": "author.anim.loop", "duration": 15, "loop": true },
    { "id": "end",   "anim": "author.anim.end" }
  ]
}

The adult wrapper could make common linear scenes even simpler by applying defaults for things like camera, fade, control lock, stripping policy, and ending behavior.

More advanced scenes would be graph-based: nodes, edges, cues, actions, sound, camera tracks, and branchable navigation.

 

 

Custom actions / integration idea

OSF reserves `osf.*` for built-in mechanics:

• osf.control.lock
• osf.fade.out
• osf.equipment.hide
• osf.weapon.sheathe
• camera states
• sound/voice playback
  

Other mods can define their own namespaced actions:

{
  "at": 0.5,
  "type": "yourmod.spawnProp",
  "role": "host",
  "data": "YourMod.esm|0x801"
}

 

OSF would not need to understand that action. It would emit a scene event, and the receiving mod decides what to do with it.

This keeps the core generic while still allowing custom integration.

 

 

Known v1 constraints

These are current planned constraints, not necessarily permanent:

• Scenes do not resume after save/load. On load, active scenes stop and handles die.
• One actor, one scene. Starting a scene with a busy actor fails cleanly.
• Custom actions are notifications. They do not currently block scene progress or report success/failure.
• JSON is not a scripting language. OSF can run known built-in mechanics and emit custom events, but it will not execute arbitrary code from JSON.
  

 

Where I specifically want feedback

The full RFC has more detail, but these are the questions I most want comments on.

 

For animation and scene authors

1. Is the simple scene shorthand enough for common linear scenes?
2. What metadata do animation packs need on day one?
3. What tags should be standardized early so matchmaking works across packs?
4. Are filters like gender, race, and keyword enough, or do you need faction, relationship rank, level, equipped item, distance, voice type, body type, furniture, or location type?
5. Should scene authors hand-author camera/control/fade/stripping actions, or should an adult wrapper handle those as defaults?
6. Do you prefer semantic role names like `dominant`, `receiver`, `speaker`, `listener`, or neutral names like `actorA`, `actorB`, `role0`, `role1`?
   

 

For quest/content modders

1. Would you rather start exact scenes by ID, or mostly ask the matchmaker for content by tags?
2. Should scenes expose available navigation edges so a mod can wire them into dialogue or UI menus?
3. What information do you need before starting a scene: actor count, tags, duration, furniture requirements, role names, required features, author, priority?
4. Should the matchmaker return only the best match, or should callers be able to inspect a ranked list?
5. Should a caller be able to require authored scenes only, raw animations only, or either?
   

 

For integrator mods

1. Is an opaque `data` string enough for custom actions, or do you need structured JSON fields?
2. Should OSF resolve form references for custom actions, or should the receiving mod parse and resolve them?
3. Do custom actions need to block scene progress, or is fire-and-forget enough?
4. Do custom actions need acknowledgement/failure reporting?
5. Should custom verbs be able to declare soft dependencies, so diagnostics can say “this scene expects YourMod, but it is not installed”?
   

 

For users and pack maintainers

1. Is it acceptable that scenes do not resume after save/load in v1?
2. What failure modes are most important to report clearly?
3. Should users control individual mechanics, like “never allow equipment hiding,” or should control happen through higher-level scene tags/content filters?
4. Should OSF or the adult wrapper provide a shared tag registry to reduce fragmentation?
   

 

 

Why I am asking now

The main things I want to avoid are:

• a schema that is too verbose for normal authors;
• a matchmaker that cannot express what content mods actually need;
• custom integrations that are too weak to be useful;
• adult-specific policy leaking too deeply into the reusable core;
• compatibility promises that are unrealistic;
• cleanup behavior that causes broken saves or stuck player state.
  

 

So the feedback I am looking for along the lines of:

• what does the schema need to express?
• what should OSF core own?
• what should the adult wrapper own?
• what guarantees do other mods need from the runtime?
• what tags/metadata need to be standardized early?
• what compatibility behavior actually matters?
  

 

 

Full RFC / latest draft again

 

Thanks for reading!

[gthat1118]

It's good to see that someone is still working on this. Starfield is not well blessed with mods to make it more enjoyable, but much of the framework is being put in place.

 

For example:

Slavers Rule the Universe

Non-Lethal Framework

SAF

NSS

SAF Surrender

SAF Seduce

 

If you can produce a consistent and reliable means of playing scenes and animations, this just may give the NSFW modding community the boost it needs.

 

I'm sorry that I'm not knowledgeable enough to give an intelligent review, but I can give some encouragement and a bump at least.

[DocClox]

Interesting post. I need to give your RFC a careful read, but off the top of my head...

 

First of all, making the scenes data driven with a native framework is an excellent idea. I liked SexLab's sequences, but defining them in Papyrus was a pain. AAF's XML is ... well, I'm not a huge fan of XML. SLAL works better, and using a JSON format for the data seems like the best approach.

 

As a modder, I'm mainly interested in how this interacts with Papurys. I assume there will be functions to start a scene from a script. I'd also want to see some user events generated. The SexLab ones are decent: Start & End of Sex, Start and end of an Animation, Start and End of Orgasm. 

 

I'd like some control at the papyrus level of the looping. If Spacer Barry is raping Starborn Sally and he hasn't climaxed when we get to the end of the animation, I'd like to go back a stage and carry on until he's had his fun. Not sure how best to expose that from SFSE but I'm sure there are ways.

 

Which raises another question: arousal and orgasm. The default sexlab approach of everyone cums at the end of the scene is fine as a default, but I'd want to be able to customize that. Either as a slave trainer trying to keep his victim edged so as to hasten submission, or as the victim trying to hasten the climax of her captor without surrendering too much of herself in the process. Do you want to track that, or have it managed externally? Whatever you do, people will want to override the default.

 

Arousal is another topic, of course. Do you want to track how horny the world at large is like SexLabAroused et al? My feeling is "no, it's outside the scope of the project", but that raises questions about how to allow arousal to influence the animation.

 

Another orgasm point: separate orgasms would be nice. So one party or another can inflict multiples on the other. SexLab Separate Orgasms is a good example. It's maybe not something that your framework should handle, but I think it should be something supported, if that makes sense.

 

OK. Brain dump done. I may try this again when I've had a chance to mull things over a bit. 

[jaam]

I would also add event at start and end of handling clothing/toys. Both as each animation starts/end, but also when a group of animation starts and end.

[DocClox]

1 hour ago, jaam said:

I would also add event at start and end of handling clothing/toys. Both as each animation starts/end, but also when a group of animation starts and end.

 

Good point. Stripping, NoStrip flags, requipping ... that's all part of the problem space

[skateguy79]

So I've played around with this a little bit and I have a couple of questions and a couple of suggestions... First, is it possible to set up multiple scenes at once? For example, if I wanted to go into Astral Lounge and turn the place into a huge orgy. So far it seems like I can't start a second scene without stopping the first scene, but I might be missing something. Also is it possible to mix and match different positions in like a playlist? Like, if I wanted a scene to start with oral, then doggystyle, then cowgirl, etc., without having to switch positions manually.

 

As for suggestions, having an icon or an M or F next to the names in the npc list to signify male or female would be helpful when setting up multi-partner scenes with unnamed npcs. And an option to automatically switch to fly cam when the scene is running would be nice.

 

A couple of bugs I've encountered so far- when using any of the gergel animations, female characters' breasts and face get stretched out and distorted. I'm using SFF body for female and Robert male, with SF extended skeleton. Also when I tried to run a scene at Wolf Den the camera went kind of haywire, moving outside the station and flickering all over the place. Then when I stopped the animation everything was tinted dark red.

 

Otherwise the mod is great and I see a lot of potential to build on this. With some tweaks and improvements and other mods to work off of this I could see this becoming THE sex framework for Starfield, like AAF for Fallout 4 and Sexlab for Skyrim.

[ozooma10]

5 hours ago, skateguy79 said:

So I've played around with this a little bit and I have a couple of questions and a couple of suggestions... First, is it possible to set up multiple scenes at once? For example, if I wanted to go into Astral Lounge and turn the place into a huge orgy. So far it seems like I can't start a second scene without stopping the first scene, but I might be missing something. Also is it possible to mix and match different positions in like a playlist? Like, if I wanted a scene to start with oral, then doggystyle, then cowgirl, etc., without having to switch positions manually.

 

As for suggestions, having an icon or an M or F next to the names in the npc list to signify male or female would be helpful when setting up multi-partner scenes with unnamed npcs. And an option to automatically switch to fly cam when the scene is running would be nice.

 

A couple of bugs I've encountered so far- when using any of the gergel animations, female characters' breasts and face get stretched out and distorted. I'm using SFF body for female and Robert male, with SF extended skeleton. Also when I tried to run a scene at Wolf Den the camera went kind of haywire, moving outside the station and flickering all over the place. Then when I stopped the animation everything was tinted dark red.

 

Otherwise the mod is great and I see a lot of potential to build on this. With some tweaks and improvements and other mods to work off of this I could see this becoming THE sex framework for Starfield, like AAF for Fallout 4 and Sexlab for Skyrim.

 

 

Yeah the base framework itself Lets you start arbitrary number of scenes as you please (but requires something to actually initiate them).

 

The "Animation Browser" provided is definately rough and lots of room for improvement. You should be able to start many NPC scenes, unfortunately scenes with player kind of get force stopped when leaving browser. Main issue is some scenes will stop and not loop (based off config), so need better controls within the browser to have scenes loop.

 

and yeah lots of metadata like gender would help since its a pita right now.

 

 

I think ideally there will be a "Builder" tool that let you create/edit sequences of individual "stages" (basically the individual animations) so you can create arbitrary sequences. Right now the browser just plays defined sequences and you cant edit them outside the json files themselves. The cool thing is since its "just data" should be able to create/save/export/import those sequences...

 

And yeah lots of skeleton/mesh/camera bugs to work out (especially with existing animations 

[DocClox]

23 hours ago, skateguy79 said:

So I've played around with this a little bit and I have a couple of questions and a couple of suggestions

 

Wait, is there a download for this? I seem to have missed that in the top post.

[ozooma10]

51 minutes ago, DocClox said:

 

Wait, is there a download for this? I seem to have missed that in the top post.

Yeah initial versions have been released https://www.nexusmods.com/starfield/mods/17457

 

docs and "other people actually being able to use" is still in a rough place, need to spend some time on tooling now that foundation is in better place

[sen4mi]

I would like to make sure I understand this concept of "scene events".

 

Are these meant to be events which are triggered during the progress of the scene?

 

Or are these meant to be events driven by the user and/or papyrus which can modify the scene?

 

(Or both?)

 

I am particularly interested in making events from the user a part of the scene. These could be "struggle events" or they could be something elaborate (perhaps choosing between various alternatives and/or something like switching to a different scene). But I am worried that that's not what the RFC is talking about.

 

(Of course, these things are already somewhat complicated because of the limitations of the animation mechanisms - though perhaps physics and/or keyframe interpolation could make that pain bearable?).

[skateguy79]

On 7/24/2026 at 3:18 PM, ozooma10 said:

Yeah the base framework itself Lets you start arbitrary number of scenes as you please (but requires something to actually initiate them).

 

I actually figured out how to do it (start a scene, open browser, deselect actors, select new actors, then launch a new scene- the first scene continues after the new one starts- in case anyone else reading this wanted to know how) but have noticed that sometimes the first scene freezes when starting the second scene. Opening the OSF browser back up and relaunching the scenes usually fixes it.

 

Another thing I'd suggest is a way to control where the scenes happen, other than just furniture (the furniture placement for scenes is a little buggy too). Like AAF gives you options to choose a nearby piece of furniture, player's location, npc's location, or 10 ft in front of player, which helps avoid characters clipping through walls and furniture during animations.