Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/facepunch/sbox-public/llms.txt

Use this file to discover all available pages before exploring further.

Contributing to s&box covers everything from filing a detailed bug report to opening a pull request with a code fix. This page explains the guidelines for each type of contribution so your changes are easy to review and merge.

​
Reporting bugs

Use the sbox-public issues tracker to report bugs and crashes in the engine.
Do not report bugs in games or add-ons here — those should go to the game’s author instead.
Follow these guidelines when filing a bug report:
  • Be thorough. Include your OS, engine version, and any relevant log output.
  • Include reproduction steps. If you can reproduce the bug, provide a clear step-by-step sequence.
  • Check for duplicates. Search existing issues before opening a new one.

​
Proton compatibility issues

For Linux compatibility issues running through Proton, refer to the upstream Proton issue rather than filing a new report here.

​
Requesting features

Open a feature request on the issues tracker and include:
  • Why you need it — describe the problem the feature solves.
  • What it adds — explain the expected behavior.
  • What you’ve tried — include any workarounds you’ve already explored.
  • Check for duplicates — search existing requests before posting.

​
Security vulnerabilities

Do not report security vulnerabilities in the public issue tracker. Visit facepunch.com/security to disclose them privately.

​
Making changes

​
Adding new features

Before implementing a new feature, confirm it is something the community wants. Open a proposal issue first and let the discussion reach a conclusion before writing code.

​
Fixing bugs

When fixing a bug:
  • Reference the relevant issue number(s) in your pull request.
  • Explain what the root cause was and how your fix addresses it.
  • Add unit tests where applicable.

​
Pull request guidelines

Keep these points in mind to make review as smooth as possible:
Keep pull requests focused. Avoid bundling unrelated changes together — each PR should address one thing.
  • Group related changes into a single commit when it makes sense.
  • Write a concise commit message that explains what the commit does.
  • Add a longer body if additional context is needed.
  • Remove unnecessary commits and squash where appropriate before opening the PR.
Your code must match the style defined in .editorconfig. Key rules for C# files:
  • Indentation: tabs, size 4
  • Line endings: CRLF
  • Files must end with a newline
  • PascalCase for types, methods, properties, and public fields
  • camelCase for local variables and parameters
  • _camelCase prefix for private instance fields
  • s_camelCase prefix for private static fields
  • Interfaces prefixed with I (e.g., IMyInterface)
Run dotnet format to auto-apply formatting before committing:
dotnet format

​
Next steps

Building from source

Set up a local build of s&box to test your changes.

Scripting basics

Understand how C# components work before making engine-level changes.

Build docs developers (and LLMs) love

Get started for freeTalk to us