sco-core documentation

Catalogue snapshot — development preview

SDK 2.4.0 · game pack 0.8.0 · source d16f013c629797275e40124184b261da54cce0ef Published release: sdk-v2.4.0-rc.1 (release candidate 1, attested assets; the final signed release follows; this development preview is not an approved release). Source-backed inventory is not a runtime or in-game verification claim.

Consumer agent workflows cover extension authoring, debugging, packaging, upgrades and SDK gap reports using the existing public contracts.

Curated guides by audience, not an exhaustive inventory of historical records. For the project overview, start with the root README. For where the SDK is going and how to contribute, read the roadmap.

New plugin author — Start a plugin

1. Start your first plugin: choose language/archive, prerequisites, published download/checksum, copy/rename/build/check, Windows deployment and diagnostics in one path.
2. SDK archive reference, plugin.ini and plugin rules: packaging, manifests and trust.
3. Your language: C ABI, C++, C#, Lua or data packs.
4. Designing modular plugins: one feature per plugin, versioned service tables, requires, clean unload and anti-patterns, with a provider and consumer example pair.
5. Community plugin directory: plugins in their authors’ own repositories with reported SDK compatibility, the listing rules and how to request a listing. Not an endorsement; nothing there is verified in game.

Plugin API consumer — Use the API safely

1. Plugin API v1: exports/root table, ABI compatibility, whole-member and non-null checks, capabilities, commands, events, raw handlers and threads. Stability says which service tables are Stable or Experimental across SDK 2.x, separately from availability and evidence.
2. Public contract catalogue and reading rules, backed by machine-readable records: per-method semantics, buffers, failures, ownership, callback/service lifetime and unspecified guarantees. Declarations come from sco_api.h; the signature-row page game/contracts.md is not this contract authority.
3. Plugin lifetime/fault/reload rules and native trust rules: quiescence, Stop/unload and restart boundaries. C++, C# and Lua explain language-specific exposure and limits.
4. Neutral services: storage, UI, IPC, network messages and network wire.
5. Optional extension: DataCore, game services and current evidence/status. Availability is not gameplay proof.

SDK integrator / host — Embed a host

1. Kernel source kit versus checkout build: platform/toolchain and neutral/game boundaries.
2. Host/internal C++ API: include/sco/, Platform, Start/Tick/Stop; this is not the plugin C++ wrapper reference.
3. Architecture: layers, startup, scheduling and limits.
4. Plugin loader and Lua runtime host: dependency ordering, discovery, reload and native trust.
5. Host controls: storage, UI, IPC, network, DataCore, game-pack opt-in.
6. Host simulator and focused tests in building/testing; host lessons.

Game-pack contributor — Check or update a game build

1. Game pack and service/capability evidence: pack/version, checked signatures, pending runtime diagnostics and game acceptance.
2. Sigcheck: setup, output, exit codes and patch-day workflow.
3. Adding signatures: row ownership, uniqueness and guards.
4. Feature inventories: ASOP/hangar/ATC, world, contracts, actors, entities, events, creative, mining, product features, offline patches.
5. Game service integration: product opt-in and runtime limits. Signature resolution, service presence and in-game correctness are separate evidence.

Agent / IDE user — Discover the SDK via MCP

1. Agent and IDE integration: kit-first setup (download and verify the kit, the two tool profiles, Claude Code, Codex, Cursor, VS Code and Copilot CLI configuration, verification and common failures), then the source-checkout form for maintainers.
2. SDK to MCP to plugin: discover a contract, request a scaffold, validate manifest/widgets and run the native checker.
3. MCP server authority: six default tools (minimal profile), six opt-in discovery tools (the SDK developer profile of twelve, including guide search with search_guides and get_guide_section) and three opt-in development tools, allowlist, provenance, limits and separate administrator-owned runner settings.
4. Reference snapshots: bind discovery/examples to exact source/archive inputs; development previews are not approved releases.

MCP is static discovery by default; the opt-in development tools build and check plugins on this machine only, never a host or the game. Client-specific instructions live in the integration guide, not in this index.

Maintainer — Build, contribute, release

1. Contributing and building/testing: source policy, named tests, CI and product adoption.
2. Changelog, SDK 2.4.0 notes and the SDK 2.4.0 release candidate 1 (the repository’s latest and only SDK release; the final signed sdk-v2.4.0 follows): keep SDK/package, plugin ABI and game-pack version coordinates distinct.
3. Release checklist and release decisions: candidate versus signed approval versus actual publication; releases are maintainer acts.
4. Documentation site: curated public inputs, generation, checks and existing Pages publication workflow.
5. IP policy, third-party notices and dependency inventory.
6. Design: opt-in runtime MCP: separate implemented default-off metadata launcher, historical decisions and outstanding Windows/manual acceptance.

Historical designs and evidence

These are dated plans/audits, not substitutes for current contracts: framework plan, service safety, service-table lifetime audit, game services, game-world spikes, multiplayer/bridges, VFS/DataCore, release-hardening baseline and plugin-licensing options.