Table of Contents

What S1Interop does

Schedule I has two game backends that matter to modders:

  • the public none and beta Steam branches use IL2CPP;
  • the alternate and alternate-beta branches use Mono.

The same game class has a different C# shape on each backend. A Mono mod might use ScheduleOne.PlayerScripts.PlayerCamera; an IL2CPP mod sees an Il2CppInterop wrapper such as Il2CppScheduleOne.PlayerScripts.PlayerCamera. Casts, delegates, reflection, and Harmony targets can differ too.

S1Interop's stable early job is to help you see and validate that difference: project analysis, compile-time diagnostics, safe migration plans, rollbackable transformations, and explicit builds for both runtimes.

Generated backend-neutral facades can put selected differences behind generated code, but that path is experimental and fragile. It is opt-in, not the default scaffold or the primary promise.

When to use it

S1Interop is useful when you want to:

  • start a MelonLoader mod with explicit Mono and IL2CPP builds;
  • inspect an existing mod before adding IL2CPP support;
  • keep separate Mono and IL2CPP builds but catch unsafe code earlier;
  • experiment with generated type and member bindings after both explicit runtime builds are stable;
  • resolve a Harmony target on either backend;
  • try a migration in a temporary copy before touching the real project.

You can adopt one part. An existing mod can use only analyze and lint; it does not have to switch to generated facades.

What it does not do

S1Interop does not create items, NPCs, quests, phone apps, buildings, multiplayer rules, or save systems. Use a higher-level library when one already owns that job:

  • S1API for gameplay and content workflows;
  • MAPI for buildings, procedural meshes, and models;
  • SteamNetworkLib for higher-level multiplayer messaging and synchronization;
  • DedicatedServerMod APIs for server and client addon lifecycles.

S1Interop can sit beside those libraries when a mod still needs one direct game call or patch.

It also does not convert every mod automatically. Unsafe or ambiguous changes are reported for review. The tool does not redistribute game assemblies, generated IL2CPP wrappers, decompiled code, or game assets.

The CLI and the generator

S1Interop has two packages because they run at different times.

Package What it does When it runs
S1Interop Provides the s1interop command. It analyzes projects, creates scaffolds, plans and applies migrations, writes declarations, and verifies temporary copies. When you run a terminal command.
S1Interop.Generators Reads declarations and generates facades, runtime helpers, patch bindings, and compiler diagnostics inside the mod assembly. While the mod project builds.

The generator is a build dependency. Players do not install a separate S1Interop runtime DLL for a generated mod.

A small example

This declaration asks for a facade around one game type:

[assembly: S1Interop.S1InteropType("ScheduleOne.PlayerScripts.PlayerCamera")]

After a build, mod code can use the generated facade:

using S1Interop.ScheduleOne.PlayerScripts;

string runtimeTypeName = PlayerCamera.TypeName;

The facade keeps the mod source the same. Its runtime type name changes to match Mono or IL2CPP.

New modders should continue to Install S1Interop, then Build your first mod. Existing mod authors can go directly to Start here. Use the backend-neutral pages only after reading their experimental limitations.

Edit this page