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!