Library reference

All 36 modules in support.vl2, with the version and description from each file’s own directive header [support-script].

Versions are the ones in the pack as fetched; the pack has had multiple maintainers, so check the header in your copy rather than trusting this table for a version pin.

Core

callback.cs is the dependency almost everything else declares. See Callbacks and events.

Data structures

Worth knowing these exist. TorqueScript arrays are name-concatenation sugar with no length and no iteration protocol (see TorqueScript), so anything non-trivial benefits.

map.cs gained incrementValue(%key) / decrementValue(%key) and a faster ListMap::hasKey() in 2003 [support-script]. vector.cs and list.cs were changed so pop*() returns the popped value — a breaking change if you pinned an older version.

Game state trackers

Note what loadout.cs does: it reconstructs the player’s inventory from HUD updates, because the client is not told inventory directly — it receives clientCmdSetInventoryHud* calls. That is a neat illustration of the client/server split described in Client/server split, and of weapon_list.cs’s purpose — the wire protocol carries HUD slot numbers, not weapon names, so something must map them back. Slots come from $WeaponsHudData; see HUD.

Input

key_callbacks.cs is the input equivalent of callback.cs — several scripts binding the same key without clobbering each other. bind_manager.cs carries a keybind-remap fix and was corrected in 2003 to autoload so the fix actually loads [support-script].

Interface

launch_menu.cs is what puts the Script Browser into the launch menu — the in-game UI for viewing installed scripts and editing autoload.ini, referenced by the pack’s readme [support-script].

docking_tools.cs matters if you ship a HUD element: it is the community answer to HUD layout, and it predates the TribesNEXT patch’s aspect-aware repositioning by twenty years. Expect the two to interact — see HUD.

PJFontSelector will not see the TribesNEXT .sdft replacements as vanilla .gft fonts; the $Font::Substitute table redirects by name at a lower level. [inferred]

Utilities

file_tools.cs extends FileObject itself — relevant to the save() field-enumeration technique, since it is more FileObject capability already written.

date_support.cs is notable because vanilla gives you getSimTime() and getRealTime() and nothing else — no calendar functions at all. See Scheduling and events.

string_tools.cs carries a 2020-09-19 timestamp, the only file in the pack touched in the last two decades.

Recording

Extends vanilla’s demo system (startRecord / playDemo — see Console functions). flag_tracker.cs and team_tracker.cs were both modified in 2003 to work with demos recorded through it [support-script], so if you consume either during playback, that dependency is real.

Which autoload by default

Exactly two of the 36 modules carry #autoload as their first directive — which is what autoload::get_autoload() actually tests [support-script]:

support/PJEnhancedRecording.cs
support/bind_manager.cs

plus whatever autoload.ini lists. The rest are libraries — they load because a script that #includes them is loading, not on their own. That is the intended design: declaring #include = support/callback.cs is what pulls callback.cs in.

Dependency shape

flowchart TD
    CB["callback.cs<br/>the root dependency"]
    CB --> EV["events.cs"]
    CB --> KC["key_callbacks.cs"]
    CB --> KILL["kill_callbacks.cs"]
    EV --> TT["team_tracker.cs"]
    EV --> LO["loadout.cs"]
    TT --> FT["flag_tracker.cs"]
    KILL --> FT
    EV --> FT
    LO --> WL["weapon_list.cs"]
    TT --> SS["stat_support.cs"]

    YOURS["your script"] -.->|"#include"| CB
    YOURS -.->|"#include"| EV
    YOURS -.->|"#include"| FT

Reconstructed from the #include lines in each module’s header [support-script]. callback.cs sits under nearly everything; the trackers layer on events.cs.

Reading a module

Every module documents itself in its header comment block, usually including its callback list and data fields — flag_tracker.cs documents its five triggers and the %flagRef field set in the first 30 lines. Read the file. The original PDF documentation is gone, so those headers are the reference that survives.

Related

• The autoload system — how #include is resolved
• Callbacks and events — the core API
• Section overview — install, scope, credits