Skip to main content

Crate source_sdk_2013

Crate source_sdk_2013 

Source
Expand description

Safer access to a running Source SDK 2013 server from a plugin.

§Entry point

Everything starts from a Server, which Server::new creates from the engine’s and game server’s interface factories for the duration of one callback. Its safety contract covers what every other type relies on, and each interface is then a safe accessor away, such as Server::valve_engine or Server::server_game_dll. Operations with additional requirements, such as entity spawning or schema-dependent attribute writes, document their own unsafe contracts.

§Features and build inputs

Use nightly Rust on x86_64-pc-windows-msvc or x86_64-unknown-linux-gnu. Ordinary builds use pre-generated bindings; Valve’s C++ SDK and libclang are needed only for intentional regeneration.

  • tf2 enables the game-specific wrappers in tf2.
  • tf2_loadout enables tf2 and the loadout re-applier in tf2::loadout.
  • _test-support exposes doc-hidden fakes for tests only.

§Handles and aliasing

The engine and game own their objects and mutate them through their own pointers at any time, including in the middle of calls made from Rust. A Rust reference into such an object would promise an immutability (&T) or exclusivity (&mut T) that Rust cannot guarantee, so this crate never creates one. Engine objects are reached through handles instead, which store the pointer the engine returned and access the object only through virtual calls and raw reads and writes, like a Cell:

  • Handles are Copy, and their methods take self. Sharing a handle is like sharing &Cell<T>: exclusivity would protect nothing, since the engine keeps its own pointers.
  • Handles carry the scope lifetime of the Server they came from, so none outlives the callback in which the engine keeps the object alive.
  • Handles are !Send and !Sync: access through them is restricted to the server’s main thread, even when the engine does other work on workers.
  • Data read out of the engine is copied unless it stays unchanged for the whole scope, such as class names or static strings.

Uniqueness is reserved for what the plugin owns: an OwnedGameEvent is freed exactly once, and a GameEventListener is registered by pinned reference and is !Unpin, since the engine keeps its address.

Re-exports§

pub use server::Game;
pub use server::InterfaceError;
pub use server::InterfaceFactory;
pub use server::Module;
pub use server::Server;
pub use server::ServerBinding;
pub use sdk_raw as raw;
pub use sys;

Modules§

ambient_sounds
Ambient sounds: the sounds ambient_generic entities play, such as the hum of machinery, apart from soundscapes.
bitbuf
Source’s bit buffers, as bf_write and bf_read in tier1/bitbuf.cpp encode them.
commands
Console commands and variables implemented in Rust.
datatables
Networked class descriptions (public/server_class.h, public/dt_send.h) and access to the variables they describe.
edicts
The engine’s edict table, which pairs each networked entity with an index.
entities
Entities in the server’s entity list.
inputs
Entity I/O: sending inputs to entities, as map outputs, ent_fire, and VScript’s AcceptInput do.
interfaces
Handles to the interfaces a server plugin can request from the engine and game server, each obtained from a Server.
key_values
Key values the engine or game made (KeyValues), such as the commands clients send as key values, read by name, along with the key values they hold and their string values.
math
The engine’s vector, angle, and color types, convertible to and from their sys bindings.
net
Clients’ net channels, and the messages the server sends through them.
players
Identifiers for the clients connected to the server, and the players in the game.
precache
Precaching models, generic files and decals, which clients load as they connect, through the engine’s own precache tables.
send_proxies
Overriding what clients receive of networked variables, by replacing the send proxies the engine encodes them through.
server
The crate’s entry point, through which every other interface is reached.
soundscapes
Soundscapes: the ambient sound sets that env_soundscape entities choose for each player.
spew
Watching the console output of the whole process, line by line, as it is printed.
steam
The Steam Game Coordinator (GC), Valve’s backend for items and matchmaking, as the game server reaches it through Steam.
tf2tf2
Team Fortress 2: the parts of its game and engine that other Source SDK 2013 games do not share.
user_cmd
Player commands (CUserCmd): what a player’s client sends the server each time it samples the player’s input, which the server runs as the player’s movement, attacks and weapon switches.
user_messages
User messages: the game’s messages to clients’ HUDs and screen effects, such as fades, shakes, and chat.