Content Guidelines

Effective Date: August 26, 2025
Last Updated: August 26, 2025

1. Overview

These Content Guidelines establish the technical and quality standards for all files, mods, and content submitted to The Forge. Following these guidelines ensures a consistent, professional experience for all users and maintains the integrity of our modding platform.

What These Guidelines Cover:

File submission requirements and technical standards
Mod versioning standards for consistency and compatibility
Content licensing and permissions
Special requirements for different content types

2. General Submission Requirements

2.1 File Format Standards

Archive Requirements:

The Forge maintains strict archive standards to ensure consistency and ease of installation across all submitted content. These requirements help prevent compatibility issues and streamline the user experience.

All mods must be packaged in 7-Zip format (.7z only) to ensure consistent compression and extraction behavior across different operating systems and by different tooling
Archives must contain all necessary files for mod functionality, ensuring users receive complete packages without missing external dependencies
Password-protected archives are prohibited to prevent access issues and maintain security transparency

File Structure:

The file structure within archives must provide an installation-ready layout that matches SPT directory conventions. Users should be able to extract the archive contents and place them directly into their SPT root directory without requiring additional folder manipulation or reorganization. This approach minimizes installation complexity and reduces support requests related to improper file placement.

Description Requirements:

Every submission must include clear installation instructions presented in step-by-step format and basic usage instructions or configuration guidance. Any required dependencies must be added to each mod version submission. These requirements ensure that users can successfully install and configure mods regardless of their technical expertise.

2.2 Mod Types and Requirements

Client Mods (BepInEx Plugins):

Client-side modifications require additional scrutiny due to their direct interaction with game code. The following requirements ensure code quality and maintainability while enabling proper compatibility tracking.

A link to the source code is required
Compiled files must be included and ready for immediate use without requiring users to build from source
The [BepInPlugin] attribute must be present on the class that extends BaseUnityPlugin with the following properties:
- GUID ("com.username.modname"): Must match the GUID entered when uploading to The Forge and the GUID in the server mod (if one exists) to ensure proper mod identification
- Mod Name ("Username-ModName"): Must start with your username, followed by a dash, followed by the mod name, with only letters, numbers, and a single dash allowed for consistent naming conventions
- Version ("1.2.3"): Must be a valid semantic version and match the version in the server mod (if one exists) to maintain synchronization
```
[BepInPlugin("com.username.modname", "Username-ModName", "1.2.3")]
```

Server Mods (SPT v3.x and below - Node.js):

Server modifications for legacy SPT versions must follow established Node.js conventions while maintaining compatibility with the SPT server architecture. These requirements ensure proper integration and prevent conflicts with core SPT functionality.

Files must be properly packaged as JavaScript or TypeScript following SPT server mod structure and conventions
Modifications should alter data in memory during runtime rather than directly editing core SPT files to maintain system stability
The package.json file must include required properties:
- version: Must be a valid semantic version and match the client mod version (if one exists) to ensure compatibility
- sptVersion: Semantic version constraint specifying SPT compatibility range for automatic compatibility checking
```
{
  "version": "1.2.3",
  "sptVersion": "~3.11"
}
```
See mod examples for more information

Server Mods (SPT v4.0+ - C#):

Modern SPT server mods utilize C# and require additional metadata for proper integration with the new modding framework. These requirements ensure compatibility with SPT's enhanced mod management system.

Source code links are required for security review and community development
Compiled files must be included and ready for use without requiring compilation
Modifications should follow SPT server mod structure and conventions, modifying data in memory during runtime rather than editing core SPT files directly

Mod version must be specified in two locations for consistency:

.csproj file: <Version>1.2.3</Version> tag for build system integration

AbstractModMetadata properties for runtime identification:

// Must match the GUID entered when uploading to The Forge and the GUID in the client mod (if one exists):
public override string ModGuid { get; init; } = "com.sp-tarkov.examples.editdatabase";

// Only include letters and numbers in the Name and Author properties:
public override string Name { get; init; } = "EditDatabaseExample";
public override string Author { get; init; } = "SPTarkov";

// Define your mod version here:
public override SemanticVersioning.Version Version { get; } = new("1.2.3");

// Semantic version constraint for SPT compatibility:
public override SemanticVersioning.Version SptVersion { get; } = new("4.0.0");

See mod examples for more information

Configuration Presets:

Configuration modifications represent significant changes to game behavior and require careful documentation to ensure users understand their impact and can troubleshoot issues effectively.

Files may include JSON, XML, or other configuration formats with significant modifications to default settings
Submissions must include clear descriptions of all changes made and their expected effects on gameplay
Base game version and mod dependencies must be specified to prevent compatibility issues
Special installation requirements must be documented with step-by-step instructions for proper setup
Uninstallation procedures must be provided to help users revert changes if needed

Tools and Utilities:

Standalone tools and utilities extend SPT functionality beyond traditional mods and require additional verification to ensure they operate safely within the SPT ecosystem.

Executable files (.exe, .cmd, .bat, etc.) must be provided in ready-to-use format
Source code links are required for security verification and transparency
Special installation requirements must be thoroughly documented with clear instructions
Removal procedures must be provided to help users cleanly uninstall tools when no longer needed

3. Semantic Versioning Requirements

3.1 Understanding Semantic Versioning

All mods submitted to The Forge must use Semantic Versioning (SemVer) for version numbering. SemVer is a widely-adopted standard that provides clear meaning to version numbers and helps users understand the nature of changes between releases. The complete specification is available at semver.org.

Basic SemVer Format: MAJOR.MINOR.PATCH

Each component serves a specific purpose in communicating the type of changes included in a release. The MAJOR version increments for incompatible changes that break existing functionality or require user intervention. The MINOR version increments when new functionality is added in a backward-compatible manner. The PATCH version increments for backward-compatible bug fixes and minor improvements.

Examples of properly formatted semantic versions include 1.0.0 for an initial stable release, 2.1.3 for a version with significant features and multiple patches, or 0.8.2 for pre-release development versions. Pre-release versions may include additional identifiers such as 1.0.0-beta.1 or 2.0.0-rc.2.

When to Increment Version Components:

Increment the MAJOR version when making incompatible changes that require users to modify their configurations, when removing features or functionality that existing users depend on, when changing mod dependencies in ways that break existing installations, or when restructuring the mod in ways that affect how users install or configure it.

Increment the MINOR version when adding new features that maintain compatibility with existing configurations, when introducing new configuration options that have sensible defaults, when adding optional dependencies that enhance but do not require existing functionality, or when making significant improvements that do not break existing usage patterns.

Increment the PATCH version when fixing bugs without changing functionality, when making performance optimizations, when updating documentation or help text, when making internal code improvements that do not affect user experience, or when addressing security issues that do not change the mod's interface.

3.2 Semantic Version Constraints

A semantic version constraint defines which versions of a dependency are acceptable for your mod to function correctly. Constraints are expressions that specify compatibility ranges rather than exact version matches, allowing for automatic updates within safe boundaries while preventing incompatible versions from being used.

Common Constraint Patterns:

The tilde constraint (~1.2.3) allows patch-level changes within the same minor version, meaning it accepts 1.2.3, 1.2.4, and 1.2.15 but rejects 1.3.0. This constraint is useful when you want to receive bug fixes but avoid new features that might introduce compatibility issues.

The caret constraint (^1.2.3) allows minor and patch-level changes within the same major version, accepting 1.2.3, 1.3.0, and 1.9.5 but rejecting 2.0.0. This constraint is appropriate when you can handle new features but not breaking changes.

Exact version matching (1.2.3) requires precisely that version and no other. This approach provides maximum stability but prevents users from receiving any updates, including critical bug fixes. Range constraints (>=1.2.0 <2.0.0) offer more flexibility by specifying minimum and maximum acceptable versions.

Practical Application in Mod Development:

When specifying SPT compatibility, use constraints that reflect the actual compatibility testing you have performed. If your mod has been tested with SPT 3.11 and you expect it to work with future patch releases, use ~3.11.0. If your mod uses features introduced in SPT 4.0 but should work with future minor releases, use ^4.0.0.

For mod dependencies, consider the stability and development practices of the dependencies you rely on. Well-maintained mods with consistent APIs may safely use caret constraints, while experimental or rapidly-changing dependencies may require more restrictive constraints.

3.3 Implementation Requirements

Version Declaration Consistency:

All version numbers declared within a single mod must match exactly. Client-side plugins, server-side modules, and any associated configuration files must declare identical version numbers. This consistency ensures that users can clearly identify complete mod packages and ensures that automatic tooling can reliably select mods based on their version.

SPT Compatibility Constraints:

Every server mod must declare its SPT version compatibility using appropriate constraint syntax. Server mods for SPT v3.x must include the sptVersion field in their package.json file. Server mods for SPT v4.0+ must specify the SptVersion property in their metadata class. These constraints should reflect actual testing and validation performed by the mod author.

Version Validation:

The Forge automatically validates semantic version format compliance during the submission process. Improperly formatted versions will be rejected. Pre-release versions are acceptable for beta or experimental content but must follow the SemVer pre-release specification exactly.

4. Content Quality Standards

4.1 Functional Requirements

Testing Standards:

Mod authors must thoroughly test their submissions using a fresh SPT installation (with all documented dependencies properly installed) to ensure compatibility and stability before making them available to the community. All advertised features must work as described. The mod must load without errors, and without causing unintended changes to base SPT functionality. Testing should verify that the mod functions correctly in standard user environments without requiring undocumented system configurations or additional modifications.

Performance Requirements:

Mods should not cause significant, unintended performance degradation during normal gameplay or system operation. Memory leaks and excessive resource usage are strictly prohibited as they negatively impact user experience and system stability. Loading times should remain reasonable compared to base SPT performance, and mods must not contain infinite loops or blocking operations that could cause system freezes or unresponsive behavior.

Error Handling:

Error handling must be implemented gracefully to manage missing dependencies without causing system crashes or data corruption. Clear error messages should be provided for configuration issues to help users identify and resolve problems independently. Fallback behavior should be implemented when possible to maintain basic functionality even when optimal conditions are not met. Logging systems should be designed to help users troubleshoot problems by providing relevant diagnostic information without overwhelming them with excessive technical detail.

Logging Standards:

Logging functionality should provide pertinent information to end users while maintaining clean, readable console and file output. Excessive or inappropriate logging can impede users' ability to identify genuine errors or warnings among unnecessary output, degrading the overall user experience and making troubleshooting more difficult.

Restricted logging practices include any form of ASCII or Unicode art or logos that clutter console output, multi-line mod author or team credits that should be reserved for documentation rather than runtime logs, and advertising of external links that serves no diagnostic purpose. Log messages should focus exclusively on operational status, configuration information, error reporting, and debugging data that helps users understand mod behavior and resolve issues effectively.

4.2 Code Quality Standards

Security Requirements:

No obfuscated code may be present in executable files, as this prevents proper security review and violates transparency standards. Source code must be available for review through publicly accessible repositories that contain the exact code used to generate submitted binaries. No unauthorized network connections or data collection may be implemented without explicit user consent and clear documentation of the purpose and scope of such activities. Modifications to system files outside the SPT directory are prohibited to prevent system instability and security risks.

AI-Generated Content Policy:

The Forge does not accept mods that have been substantially or entirely written by AI coding agents. AI models have not been trained on the specific codebase and security requirements necessary to safely modify SPT client and server code. This limitation creates significant risks for code stability, security vulnerabilities, and compatibility issues that AI-generated code cannot adequately address.

Mod authors must fully understand their code's functionality, implementation details, and potential security implications because they are responsible for how their modifications affect other users' systems and gameplay experience. When users download a mod, they trust that the author has thoroughly reviewed, tested, and validated every aspect of the code's behavior.

Using AI tools for basic code completion, syntax assistance, or generating small utility functions is acceptable when the author reviews, understands, and takes full responsibility for the generated code. However, using AI to write entire features, complex game modifications, or substantial portions of mod functionality is prohibited. The distinction lies in whether the author maintains complete understanding and control over their code versus relying on AI to generate logic they cannot fully comprehend or validate.

Authors must be prepared to explain any part of their submitted code, debug issues that arise, and modify functionality as needed. This level of ownership is impossible when AI generates significant portions of the codebase without the author's deep understanding of the implementation details.

5. Executable Files and Security

5.1 Executable Content Requirements

Mandatory Requirements:

Executable content presents the highest security risk and requires comprehensive verification to protect users from malicious software. These requirements ensure transparency and enable proper security review of all executable components.

All .dll, .exe, and compiled binary files must include a link to publicly accessible source code
Source code must be available through established platforms (GitHub, GitLab, etc.) that provide proper version control and transparency
Repositories must contain the exact code used to build the executable, with no hidden or proprietary components
Build instructions must be provided in the repository to enable independent verification of the compilation process

Security Verification:

VirusTotal scan links are required for all executable content to provide initial security screening
False positives (1-2 detections) are evaluated on a case-by-case basis considering the detection engines and threat classifications
VirusTotal links must be updated for each version released to ensure current security assessment
Staff reserves the right to request additional security verification through alternative scanning services or manual review

Prohibited Executable Behavior:

Code obfuscation or anti-debugging techniques are prohibited as they prevent proper security analysis
Unauthorized system modifications outside the SPT directory are forbidden to maintain system integrity
Data collection or network communication without disclosure violates user privacy expectations
Installation of additional software or drivers is prohibited to prevent system compromise

5.2 Network Communication

Allowed Network Activity:

Network communication capabilities must be transparent and serve legitimate purposes that benefit users. All network activity requires clear disclosure and appropriate user consent mechanisms.

Update checks are permitted with user consent and clear disclosure of what information is transmitted
Crash reporting is allowed when anonymized and implemented with user consent and opt-out options
API calls essential for mod functionality are acceptable when clearly documented and disclosed in advance

Required Disclosure:

All network activity must be documented in detail, including destination servers and data transmitted
Privacy implications must be clearly explained in language that non-technical users can understand
Opt-out options must be provided where technically feasible to respect user privacy preferences

Prohibited Network Activity:

Unauthorized data collection or telemetry violates user privacy and trust
Communication with unknown or undisclosed servers presents security risks
Automatic downloading of additional content without consent can introduce malware or unwanted modifications
User tracking or analytics without explicit consent violates privacy expectations

6. Content Licensing and Permissions

6.1 License Requirements

Acceptable Licenses:

Content licensing ensures legal compliance and clarifies usage rights for both creators and users. The Forge accepts standard open-source and creative licenses that provide appropriate legal frameworks.

MIT, Apache 2.0, GPL, BSD, and other OSI-approved licenses provide established legal frameworks for code distribution
Creative Commons licenses are appropriate for non-code content including documentation, artwork, and media files
Public domain dedication is acceptable for content where authors wish to relinquish all rights

License Documentation:

License files must be included in mod archives to ensure users understand their rights and obligations
Third-party component licenses must be respected and documented to maintain legal compliance
Authors must understand the implications of their chosen license, particularly regarding commercial use and derivative works

6.2 Attribution Requirements

Obtaining Permission:

Building upon or modifying existing community content requires explicit permission from original creators to respect their intellectual property rights and creative contributions. These requirements protect creators while enabling collaborative development within appropriate boundaries.

Submission of existing user-contributed content without obtaining permission from the original authors is strictly prohibited. This applies regardless of whether modifications have been made or if the content is being redistributed as-is. The burden of obtaining proper authorization rests entirely with the person submitting derivative or redistributed content.

Proper credit to original authors must be provided unless the authors have explicitly specified that attribution is not necessary. However, providing attribution alone does not substitute for receiving explicit permission to upload or modify someone else's work. Permission and attribution serve different purposes and both requirements must be satisfied independently.

When Using Others' Work:

Proper attribution protects original creators' rights while enabling collaborative development. These requirements ensure credit is given appropriately while maintaining legal compliance.

Clear credit must be provided to original authors using their preferred attribution format
Original source links should be included when possible to enable users to find upstream versions
Specific attribution requirements from original licenses must be respected and implemented correctly
License information for third-party components must be included to maintain legal compliance

7. Special Content Categories

7.1 Adult Content Policy

Prohibited Content:

The Forge maintains family-friendly content standards while allowing mature themes appropriate to the source game. These restrictions ensure broad accessibility while respecting community standards.

Nudity or sexual content of any kind is prohibited to maintain appropriate content standards
Suggestive or sexually provocative material is not acceptable regardless of context
Content that sexualizes characters or game elements violates community standards
References to adult websites or services are prohibited to maintain appropriate boundaries

Mature Themes:

Violence and combat modifications are generally acceptable given the tactical nature of the base game
Realistic tactical or military themes are allowed when appropriate to the game context
Dark or serious storylines are permitted if appropriate and clearly marked in descriptions
Language and mature themes should be noted in descriptions to help users make informed choices

7.2 Anti-Cheat and Exploit Policy

Prohibited Modifications:

The Forge strictly prohibits content that could be used to gain unfair advantages in multiplayer environments or that resembles traditional cheating tools, even when designed for single-player use.

Any mod usable in live Escape From Tarkov multiplayer is prohibited to prevent cheating migration
Traditional "hacks" like ESP, wallhacks, and aimbots are forbidden regardless of stated purpose
Mods that appear to be cheating tools are prohibited even if designed exclusively for SPT use
Exploits that could be adapted for multiplayer use present unacceptable risks

Allowed Development Tools:

Debug overlays and development menus are acceptable when clearly labelled as development tools
Testing utilities that require developer mode or special setup serve legitimate development purposes
Educational tools that demonstrate game mechanics provide valuable learning opportunities
Diagnostic tools for troubleshooting mod conflicts help maintain a healthy modding ecosystem

7.3 Compilation and Collection Guidelines

Prohibited Content:

Mod compilations, collections, and modpacks are not permitted on The Forge. While these packages may appear to offer convenience by bundling multiple mods together, they create significant and ongoing maintenance challenges that cannot be sustainably managed.

Permission tracking becomes unmanageable as compilations require explicit consent from every included mod author. Compatibility maintenance is equally problematic since individual mods within a compilation update independently, often breaking compatibility with other included components. Version synchronization across multiple mods with different release schedules creates constant conflicts that require continuous manual intervention.

The Forge encourages users to install individual mods directly from their original creators to ensure they receive proper updates, support, and compatibility verification. This approach guarantees that users get the most current versions while supporting mod authors directly and maintaining clear accountability for each component.

8. File Hosting and Distribution

8.1 Download Link Requirements

Direct Download Links (DDL) Required:

All download links must be direct download links that immediately begin downloading the file when visited. This requirement ensures the best user experience and enables automated tooling to download mods without user interaction.

Links must initiate the download immediately
The download link must confirm that the file is a 7-zip archive (.7z) as required by our archive standards
Links must remain accessible indefinitely to ensure long-term availability

Prohibited Link Types:

Any download link that does not meet the direct download requirement is prohibited. This includes but is not limited to file sharing services with landing pages, ad-supported download sites, services requiring user interaction, temporary file sharing platforms, and any link that redirects users through multiple pages before downloading.

Recommended Hosting:

GitHub releases provide reliable direct download links with proper version control integration and meet all requirements for direct downloads of 7-zip archives.

9. Violation Consequences and Appeals

9.1 Guideline Violations

Minor Violations:

Minor violations typically result from oversight or misunderstanding rather than malicious intent and can usually be corrected through collaboration with content creators.

Missing documentation or improper formatting issues can usually be resolved quickly
Incomplete version information represents administrative oversights rather than fundamental problems
Minor licensing issues often stem from misunderstanding rather than intentional violation

Consequences: Requests for corrections with guidance, temporary content hiding until issues are resolved

Major Violations:

Major violations present significant risks to user safety or legal compliance and require immediate intervention to protect the community.

Security risks or malicious code present immediate threats to user systems
Copyright infringement creates legal liability for both creators and the platform
Prohibited content types violate fundamental community standards

Consequences: Immediate content removal, account restrictions proportional to violation severity, possible permanent ban for egregious violations

9.2 Appeals Process

Content Removal Appeals:

The appeals process provides creators with opportunities to address violations while maintaining platform security and compliance standards.

Contact [email protected] with specific details about the content and circumstances
Provide evidence demonstrating that content complies with current guidelines
Staff review is completed within 10 business days of receiving complete appeal information
Decision is communicated with clear reasoning explaining the outcome

Improvement Opportunities:

Guidance is provided for bringing content into compliance with current standards
Re-submission is allowed after corrections are made and verified
Educational resources are provided to help creators avoid common issues in future submissions