docs: the Windows plugin dir is ProgramData, not the config dir #2

Merged
jknapp merged 1 commits from docs/windows-plugin-path into main 2026-09-09 23:44:21 +00:00
+13 -4
View File
@@ -161,10 +161,19 @@ build/package/licenses/...
``` ```
That is exactly the layout OBS searches on Linux and Windows — That is exactly the layout OBS searches on Linux and Windows —
`<config>/obs-studio/plugins/<name>/bin/64bit` plus a sibling `data/`, per `<base>/obs-studio/plugins/<name>/bin/64bit` plus a sibling `data/`, per
`AddExtraModulePaths()` in obs-studio's `UI/window-basic-main.cpp` — so `AddExtraModulePaths()` in obs-studio (`UI/window-basic-main.cpp` in 30.x,
`build/package/` is a straight drop-in. The module resolves the LiveKit `frontend/widgets/OBSBasic.cpp` in 32.x) — so `build/package/` is a straight
libraries from `$ORIGIN` (verified: `ldd` on the staged copy resolves both drop-in. **`<base>` is NOT the same directory on every platform**, and getting
this wrong is silent: OBS logs nothing at all for a plugin it never finds.
Linux uses the user config dir (`GetAppConfigPath``~/.config`), but Windows
uses `GetProgramDataPath` (`CSIDL_COMMON_APPDATA`) — i.e.
`C:\ProgramData\obs-studio\plugins\`, **not** `%APPDATA%\obs-studio\`
(`CSIDL_APPDATA`), which on Windows holds OBS's config and is never scanned for
plugins. This bit a director on 2026-09-09: a correctly-shaped install under
`AppData\Roaming` produced a log with zero mention of the module.
The module resolves the LiveKit libraries from `$ORIGIN` (verified: `ldd` on the staged copy resolves both
to `bin/64bit/`), not from the build tree. macOS is not this shape; see the to `bin/64bit/`), not from the build tree. macOS is not this shape; see the
macOS packaging gap under CI. macOS packaging gap under CI.