If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ValveSoftware/source-sdk-2013 shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 6w ago
• 43+ active contributors
• Distributed ownership (top contributor 13% of recent commits)
• Other licensed
• Tests present
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ValveSoftware/source-sdk-2013 repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ValveSoftware/source-sdk-2013.

What it runs against: a local clone of ValveSoftware/source-sdk-2013 — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ValveSoftware/source-sdk-2013 | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 70 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ValveSoftware/source-sdk-2013. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ValveSoftware/source-sdk-2013.git
#   cd source-sdk-2013
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ValveSoftware/source-sdk-2013 and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ValveSoftware/source-sdk-2013(\\.git)?\\b" \\
  && ok "origin remote is ValveSoftware/source-sdk-2013" \\
  || miss "origin remote is not ValveSoftware/source-sdk-2013 (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "src/common/GameUI/IGameUI.h" \\
  && ok "src/common/GameUI/IGameUI.h" \\
  || miss "missing critical file: src/common/GameUI/IGameUI.h"
test -f "game/mod_hl2mp/gameinfo.txt" \\
  && ok "game/mod_hl2mp/gameinfo.txt" \\
  || miss "missing critical file: game/mod_hl2mp/gameinfo.txt"
test -f "src/buildallprojects" \\
  && ok "src/buildallprojects" \\
  || miss "missing critical file: src/buildallprojects"
test -f "src/common/GameUI/scriptobject.h" \\
  && ok "src/common/GameUI/scriptobject.h" \\
  || miss "missing critical file: src/common/GameUI/scriptobject.h"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 70 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~40d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ValveSoftware/source-sdk-2013"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

The Source SDK 2013 is the official game development toolkit for Valve's Source engine, enabling modders and developers to build games and mods on the 2013 branch of Source. It includes full C++ source code for Half-Life 2, HL2: Deathmatch, and Team Fortress 2, compiled against the Source engine runtime with direct access to game mechanics, entity systems, and rendering pipelines. Monorepo structure: game/ contains mod templates (mod_hl2mp with full cfg/maps/materials/scripts/shaders subdirs), while src/ houses the Visual Studio projects and build system. game/mod_hl2mp/ is the reference implementation with weapon scripts (weapon_ar2.txt, weapon_crowbar.txt, etc), HUD layouts, soundscapes, and material definitions (example_model_material.vmt). Platform-specific binaries in game/bin/ (linux64/steam_api.so, x64/steam_api64.dll).

Mod developers and game creators who want to build custom games or modifications for the Source engine; specifically those targeting Steam distribution who need engine source code access, not just modding tools. Team Fortress 2 content creators, Half-Life 2 modders, and commercial Source engine licensees use this.

Actively maintained as of 2024 with recent commits (Team Fortress 2 was recently added). The repo has proper CI/CD setup (.github/pull_request_template.md), official Valve backing, and production-grade build infrastructure (createallprojects.bat, buildallprojects shell script). This is production-ready and battle-tested across thousands of released mods.

Low technical risk for the SDK itself, but deployment risk exists: Windows builds require VS 2022 with specific toolset versions (MSVC v143, Windows 11 SDK 10.0.22621.0), and Linux builds mandate podman containerization for Steam Runtime compatibility—mismatched versions will cause silent build failures. License is non-commercial only (SOURCE 1 SDK LICENSE), which restricts monetization.

Team Fortress 2 source code was recently integrated into the SDK (indicated in README and commit history). The repository is actively accepting pull requests (evidenced by .github/pull_request_template.md) and maintains Steam Runtime compatibility updates for both Windows and Linux builds. Python 3.13+ support was recently added to build scripts.

Check README for instructions.

Daily commands: Windows: createallprojects.bat → open everything.sln in VS 2022 → Build > Build Solution → right-click Client (Mod Name) → Set as Startup Project → press green > Local Windows Debugger. Linux: ./buildallprojects from src/ → then ./mod_tf or ./mod_hl2mp from game/ root to launch.

• README.md — Build instructions and project overview; essential entry point for understanding build process and mod structure
• src/common/GameUI/IGameUI.h — Core UI interface abstraction; fundamental to game UI system across all Source SDK mods
• game/mod_hl2mp/gameinfo.txt — Game configuration manifest for HL2:DM mod; defines mod identity, search paths, and engine settings
• src/buildallprojects — Build automation script; required to generate Visual Studio projects before compilation
• src/common/GameUI/scriptobject.h — Script object base class for UI element binding; critical abstraction for game-UI communication
• game/mod_tf/gameinfo.txt — TF2 mod configuration; defines Team Fortress 2 specific game settings and mount points
• src/common/ServerBrowser/IServerBrowser.h — Server browser interface; key system for multiplayer server discovery and selection

Add a New Weapon Script

1. Create weapon data file in mod scripts directory following existing patterns (game/mod_hl2mp/scripts/weapon_pistol.txt)
2. Add weapon sound definitions to game sounds manifest (game/mod_hl2mp/scripts/game_sounds_weapons.txt)
3. Create material VMT file for weapon model appearance (game/mod_hl2mp/materials/example_model_material.vmt)
4. Rebuild project and test in-game via launcher (src/buildallprojects)

Add a New HUD Element

1. Define HUD layout and positioning in HUD layout resource (game/mod_hl2mp/scripts/HudLayout.res)
2. Add HUD animation definitions for element transitions (game/mod_hl2mp/scripts/HudAnimations.txt)
3. Add localization strings for HUD text (game/mod_hl2mp/resource/mod_hl2mp_english.txt)
4. Extend game UI system by implementing custom scriptobject in GameUI (src/common/GameUI/scriptobject.h)

Configure a New Game Mod

1. Create gameinfo.txt with mod identifier, version, and content paths (game/mod_hl2mp/gameinfo.txt)
2. Set up steam.inf for Steam integration and app version tracking (game/mod_hl2mp/steam.inf)
3. Create game.txt with weapon definitions and skill settings (game/mod_hl2mp/scripts/game.txt)
4. Add mod-specific English localization resource (game/mod_hl2mp/resource/mod_hl2mp_english.txt)

Implement Server Browser Functionality

1. Reference IServerBrowser interface for server discovery API (src/common/ServerBrowser/IServerBrowser.h)
2. Use blacklist manager to filter servers by criteria (src/common/ServerBrowser/blacklisted_server_manager.h)
3. Integrate server list into game UI via IGameUI callbacks (src/common/GameUI/IGameUI.h)

• Source Engine (Valve proprietary) — Foundation for Half-Life 2, HL2:DM, and Team Fortress 2; provides physics, rendering, and networking
• Visual Studio 2022 (Windows build toolchain) — Official build target with MSVC v143; optimized for Source SDK Windows deployment
• Python 3.13+ (build scripting) — Cross-platform project generation and asset pipeline automation
• Steam API (steam_api64.dll / libsteam_api.so) — Runtime dependency for achievements, networking, and platform integration on Windows/Linux
• LZMA compression — Asset compression for efficient distribution and storage of game content
• Protobuf serialization — Structured data exchange for replay system and network protocol versioning

• Windows-first with Linux secondary support

  • Why: Source SDK historically optimized for Windows; Linux 64-bit support added later
  • Consequence: Better tooling and documentation for Windows developers; Linux users must manually manage dependencies

• Visual Studio project generation over CMake

  • Why: Tight integration with Source SDK build pipeline and legacy codebase patterns
  • Consequence: Explicit platform targeting but reduced cross-platform build flexibility

• Monolithic gameinfo.txt configuration

  • Why: Simple mod definition and engine mount-point management without external config systems
  • Consequence: Easy setup for new mods but difficult to scale multiple mod variants or shared asset libraries

• Text-based scripts (VDFs, TXTs) instead of binary formats

  • Why: Human-readable configuration, version control friendly, and runtime hot-loading support
  • Consequence: Larger asset footprint; requires parser robustness for malformed input

• Does not provide runtime mod sandboxing or security isolation
• Does not include cross-platform macOS/Apple Silicon support
• Does not offer built-in matchmaking or competitive ranking systems
• Does not support real-time asset streaming (all assets mount at load time)
• Does not include web-based mod management or distribution
• Does not provide visual map editor or material authoring tools

Windows build requires exact MSVC v143 toolset version from VS 2022 (10.0.22621.0 Windows SDK)—using newer SDKs silently fails linking. Linux builds mandate podman installed and functional; missing podman produces cryptic errors. Python 3.13+ required but not validated by batch scripts. game/bin/ contains pre-built DLLs/SOs (steam_api64.dll, libsteam_api.so) that must match your Steam Runtime version or crashes occur. Non-commercial license restriction means monetized mods violate terms. Shader compilation (.vcs files) requires FXC.exe on Windows and matching shader model versions.

• Entity Framework (Source Engine) — The core abstraction for all game objects (weapons, NPCs, props, triggers) in Source—understanding CBaseEntity and entity I/O is essential for any gameplay modification
• Soundscape System (VRAD/Acoustic Simulation) — Source's spatial audio propagation system defined via soundscapes_*.txt files controls ambient sound, reverb, and occlusion—critical for immersion and performance optimization
• Hammer Editor BSP Compilation — Maps are compiled .bsp files (game/mod_hl2mp/maps/dm_lockdown.bsp) using Hammer editor; understanding BSP structure, vis clusters, and lightmap compression is required for map optimization
• Material System (VMT/VTF Shaders) — Valve's material definition format (.vmt files like example_model_material.vmt) abstracts shader parameters, textures, and render settings—essential for custom visuals and performance tuning
• VScript/Squirrel Scripting Integration — Source SDK includes Squirrel scripting (18 KB in repo) for lightweight game logic and event handling without recompiling DLLs—faster iteration for modders
• Steam Runtime Containerization — Linux builds mandate podman + Steam Runtime for binary compatibility across Linux distributions—Docker-style isolation ensures mods run identically on all Steam Deck / Linux systems
• Havok Physics Integration — Source engine uses Havok for rigid body dynamics, ragdoll physics, and constraint solving—understanding physics entity properties in weapon/prop definitions impacts gameplay feel

• ValveSoftware/source-sdk-2007 — Predecessor to this SDK—Source 2007 branch for older Half-Life 2 mods and legacy engine features
• ValveSoftware/source-sdk-2013-multiplayer — Official multiplayer-focused branch of Source SDK 2013 with team gameplay systems and balance tuning
• Facepunch/sbox — Modern successor language (C#-based) for Source 2 engine; shows evolution from Source 1's C++ toolkit
• SteamDatabase/SteamTracking — Community tracker of Valve's public code and asset releases—tracks Source SDK updates and changes

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions CI workflow for Windows builds using Visual Studio 2022

The repo has build instructions for Windows (Visual Studio 2022 + Python 3.13) but no automated CI pipeline. A GitHub Actions workflow would validate that createallprojects.bat and the build process work correctly on every PR, catching compilation errors early and ensuring contributors don't break the build. This is critical for a C++ SDK where build failures aren't always caught locally.

• [ ] Create .github/workflows/windows-build.yml with Visual Studio 2022 setup
• [ ] Install required dependencies: MSVC v143, Windows 11/10 SDK, Python 3.13+
• [ ] Run src/createallprojects.bat and build everything.sln
• [ ] Add workflow status badge to README.md
• [ ] Test on a draft PR to ensure it catches real build failures

Add Linux/x64 build instructions and CI validation in README.md

The repo contains game/bin/linux64/libsteam_api.so, indicating Linux support exists, but the README only documents Windows build instructions. Contributors may attempt Linux builds without guidance. Adding a dedicated Linux section with GCC/Clang requirements and a corresponding GitHub Actions workflow would improve contributor experience and ensure cross-platform compatibility.

• [ ] Document Linux build requirements in README.md (GCC/Clang version, glibc, dependencies)
• [ ] Create .github/workflows/linux-build.yml with x64 architecture targeting
• [ ] Test building client and server binaries on Ubuntu 20.04+ LTS
• [ ] Add instructions for using the prebuilt libsteam_api.so or building against it
• [ ] Include troubleshooting section for common Linux build issues

Create BUILDING.md with detailed per-module compilation instructions and troubleshooting

The repo has diverse modules (hl2mp, tf2, shaders) but README.md only covers the top-level build. Contributors building specific mods or shader files may not know which projects to compile or in what order. A dedicated BUILDING.md would document module-specific build steps, shader compilation (.vcs files in shaders/fxc), and common errors.

• [ ] Create BUILDING.md in repository root
• [ ] Document per-module build paths: game/mod_hl2mp, game/mod_tf, etc.
• [ ] Add shader compilation workflow for .vcs files in game/mod_*/shaders/fxc/
• [ ] Include dependency tree (e.g., which modules must build first)
• [ ] Add FAQ section for common errors: missing SDKs, Python version mismatches, steam_api linking issues
• [ ] Reference specific .sln and .vcxproj files by path

• Add unit tests for game/mod_hl2mp/scripts/ parsing: weapon_.txt and game.txt currently have no validation tests, causing silent failures when modders make syntax errors. Create a script validator with test cases.
• Document the .vmt material format in CONTRIBUTING or wiki: game/mod_hl2mp/materials/example_model_material.vmt exists but no guide explains parameter syntax, shader references, or optimization. Write a beginner guide with examples.
• Expand game/mod_hl2mp/cfg/skill.cfg documentation: the skill levels (Easy/Normal/Hard) define NPC behavior but lack comments explaining each parameter's impact. Add inline documentation with tuning ranges.

The Source SDK 2013 repository exhibits moderate security maturity. Primary concerns include precompiled binaries without version tracking, lack of dependency vulnerability scanning infrastructure, and minimal security documentation. The codebase itself (based on file structure) does not show obvious injection vulnerabilities or hardcoded credentials, but supply chain security practices are weak. Recommendations focus on implementing dependency management, automated scanning, and secure binary distribution practices.

• High · Bundled Third-Party Libraries Without Version Pinning — game/bin/linux64/libsteam_api.so, game/bin/x64/steam_api64.dll. The repository includes precompiled Steam API libraries (libsteam_api.so, steam_api64.dll) with no visible version information or dependency management. These binaries cannot be verified for security patches or known vulnerabilities. Fix: Implement a dependency manifest file (e.g., dependencies.txt, vcpkg.json) with explicit version numbers. Use package managers to retrieve and verify libraries rather than committing binaries directly.
• Medium · No Dependency Vulnerability Scanning Configuration — Repository root. The repository lacks configuration files for dependency scanning tools (e.g., SBOM, dependabot, snyk config). This makes it difficult to track and remediate known vulnerabilities in third-party components. Fix: Add .dependabot/config.yml or similar configuration for automated vulnerability scanning. Implement SBOM generation in CI/CD pipeline.
• Medium · Precompiled Binaries in Repository — game/bin/ directory (steam_api64.dll, libsteam_api.so). Multiple compiled binary files (.dll, .so) are committed to version control without checksums or integrity verification mechanisms. This increases risk of supply chain attacks. Fix: Move binaries to external artifact repositories (e.g., Artifactory, GitHub Releases). Store only checksums or download scripts in the repository. Use signed releases.
• Medium · Configuration Files Without Validation Schema — game/mod_hl2mp/cfg/, game/mod_hl2mp/scripts/. Multiple configuration files (.cfg, .txt, .res) lack input validation specifications. Game configuration files may be susceptible to injection if processed unsafely. Fix: Define and enforce schema validation for all configuration file formats. Implement parsers that reject malformed or suspicious input patterns.
• Low · Missing Security Documentation — Repository root. No SECURITY.md file or security policy is present in the repository. Contributors lack clear guidance on reporting vulnerabilities responsibly. Fix: Create a SECURITY.md file following the GitHub security policy template, including vulnerability disclosure procedures and contact information.
• Low · Incomplete Build Documentation Security Context — README.md. Build instructions specify Visual Studio 2022 and Python 3.13+ without mentioning security best practices for the build environment (e.g., dependency verification, build isolation). Fix: Add security section to build documentation covering: dependency verification, build environment isolation, and secure artifact handling.
• Low · No Code Signing or Integrity Verification — game/bin/. Compiled game binaries and shipped DLLs lack code signing certificates or checksums to verify integrity after distribution. Fix: Implement code signing for all distributed binaries. Publish checksums (SHA-256) alongside releases for verification.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.