Add CS2Tracker Extension

[MuhammedResulBilkil]

CS2Tracker Extension

Adds a CS2Tracker button to Steam community profile pages and a small badge to each row of the friends, pending-invite and recently-played-with lists. Clicking through opens cs2tracker.gg/stats/{steamid64} for that player.

Each badge and button reads its own player's Steam ID from the page it sits on, so a friend-row badge opens that friend's stats rather than the profile owner's. Three toggles in the settings panel control the profile button, the friend-list badges, and whether links open in Steam's browser or the system one.

Repository: https://github.com/MuhammedResulBilkil/cs2tracker-extension
Pinned at f5e67bf, which is the v1.0.1 release.

v1.0.1 exists only to answer the review comment below: thumbnail and splash_image now point at the release tag rather than master, so the images the store renders are the images reviewed here. The rewrite happens in semantic-release's prepare step, so every future release re-pins itself and there is no manual step to forget. No functional change to the plugin.

Profile button
Friend list badge
Settings

How it differs from the plugins already on the store

leetify-extension and csstats-extension link out to Leetify and CSStats respectively; this one links to CS2Tracker, a different site. The profile button is deliberately styled to match the CSStats button's height, ground colour and wordmark treatment so that the three sit together as a row rather than competing visually — the screenshot above shows all three installed side by side.

The friend-list badges are the part I haven't seen elsewhere: a per-row link on the friends, pending-invite and recently-played-with lists, each resolving that row's own account.

There is also #209 (Profile Button Config) open in this queue, which lets a user define arbitrary profile buttons from a URL template. I don't think the two make each other redundant, and I'd rather say why than leave a reviewer to wonder: PBC is a general tool for profile pages, configured by the user; this is a zero-configuration plugin for one site that also covers the friends lists, which a profile-page button cannot reach. Someone who wants a button for an arbitrary site is better served by PBC. If the maintainers see it differently I'd genuinely rather hear it now than after a merge.

Task Checklist

Developer

• I am the original author or an authorized maintainer of this plugin.
• I have complied with all license requirements for the libraries used, including providing appropriate notices where necessary.
• My plugin is fully open source and does not depend on any external paid services, except for widely trusted and well-known platforms. Additionally, neither I nor anyone associated with me profits from any such services.

Plugin Functionality

• I have tested the plugin on both the Stable and Beta Steam update channels.
• My plugin is unique, or provides additional or alternative functionality to plugins already on the store.

Backend Configuration

• Yes: I use a standard Millennium lua backend in my plugin. — "backendType": "lua" in plugin.json. It requires logger, millennium and json, all of which Millennium preloads, and nothing else.
• No: I use custom binaries that or rely on other FOSS projects that aren't written directly using Millennium's lua backend. — no binaries, no bundled executables, no third-party runtime dependencies. The backend is a single 4.9 KB main.lua.

Community Contribution

• I have tested and left feedback on two other plugin pull requests.
• I have added links to those feedback comments in this PR.

Both were read against their pinned commit, then installed and run on Steam Stable with Millennium:

• Add CSST.at Extension #207 — CSST.at Extension: Add CSST.at Extension #207 (comment)
• Add CS Weekly Drop Reset #175 — CS Weekly Drop Reset: Add CS Weekly Drop Reset #175 (comment)

---

Testing Instructions

Install, restart Steam, enable under Millennium → Plugins, then:

1. Open any Steam community profile — a CS2TRACKER.GG button should appear in the right-hand column, below the persona block. Click it; the stats page should be for that player.
2. Open a /id/{vanity} profile as well. The Steam ID isn't in that URL, so this exercises a different resolution path.
3. Open your friends list — each row should carry a small CS2Tracker badge. Click badges on three different rows and confirm each opens that friend's stats rather than the page owner's.
4. Type in the friends search box and clear it a few times; newly rendered rows should still get badges.
5. In the settings panel, switch Show on friend lists off, then reopen the friends page — the badges should be gone. Settings are read once per page load by design, so an already-open page keeps its old state until reloaded.
6. Turn Open in external browser on, reopen a profile, and click the button — it should open your system browser rather than Steam's.
7. Disable the plugin and reopen a profile — no button, no badges, no leftover <style> element.

Network behaviour, if you want to check it: the plugin makes exactly one request of its own, to steamcommunity.com for the current page's ?xml=1 view, and only when the profile's Steam ID isn't already available from the URL or the page's own globals. Everything else is a link the user clicks.

• Verified by a third party on Steam Client Stable.
• Verified by a third party on Steam Client Beta.

[Copilot]

Pull request overview

Adds a new Millennium plugin to the plugin database as a git submodule: CS2Tracker Extension, which injects CS2Tracker profile links into Steam community profile pages and friends-related lists.

Changes:

• Register plugins/cs2tracker-extension as a new git submodule pointing to https://github.com/MuhammedResulBilkil/cs2tracker-extension.
• Pin the submodule to commit 9be073a7cdfaf91a3ad52ba1db86e8c0c1b4d492 (tag v1.0.0).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
.gitmodules	Adds the cs2tracker-extension submodule entry (path + upstream URL).
plugins/cs2tracker-extension	Adds the submodule gitlink pinned to the referenced upstream commit.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[MuhammedResulBilkil]

Fair point, and I'd rather answer it than leave it sitting.

The principle is right: master is a mutable ref, so the images the store renders after a merge aren't necessarily the images anyone reviewed. Pinning would fix that, and I've checked that it's a clean swap — all the referenced assets already resolve at the v1.0.0 tag, so it's a two-line change to plugin.json and a submodule bump here, nothing has to move.

What makes it awkward rather than automatic is the release pipeline. Releases here are cut by semantic-release, which decides the version number at release time and writes it into plugin.json itself. So a URL naming v1.0.1 has to be committed before the tooling has decided the release is v1.0.1, which means hand-holding a value the pipeline otherwise owns, on every release, forever, or the images silently keep pointing at the previous tag.

So: I'd rather do this properly at the next release, where I can wire the asset URLs into the same substitution semantic-release already performs on the version field, than bolt a hardcoded tag on now and quietly create a step that gets forgotten. If a maintainer would prefer it pinned before merge, say so and I'll cut a 1.0.1 for it — I just don't think a bot-flagged nit is worth a release on its own, and I'd rather ask than assume.

Worth noting for whoever picks this up: no other plugin currently in the database sets thumbnail or splash_image at all, so there's no house convention here either way. If the project does want pinned asset refs as a rule, that's a template or docs change rather than something to settle in one submission's thread, and I'm happy to be the first to follow it.

[MuhammedResulBilkil]

Done — this is fixed rather than deferred. Thanks for the flag; it was a fair one.

The submodule now points at f5e67bf (v1.0.1), whose plugin.json reads:

"thumbnail":    ".../cs2tracker-extension/v1.0.1/assets/thumbnail.png",
"splash_image": ".../cs2tracker-extension/v1.0.1/assets/splash.png"

I said earlier I'd rather not hardcode a tag, because that fights semantic-release — it owns the version field — and adds a release step to forget. That objection turned out to be answerable rather than blocking: the rewrite now happens inside the prepare step that already syncs the version, so the tag in these URLs is derived from the release being cut, not typed by hand. @semantic-release/git commits plugin.json during prepare and semantic-release tags that commit, so the tag the URLs name is the tag they're committed under, and assets/ exists there. The apparent chicken-and-egg isn't one. Every future release re-pins itself.

The --check mode CI already runs gained the matching assertion, so a hand-edit back onto a branch ref now fails the build:

sync-version: plugin.json "thumbnail" is pinned to "master", not "v1.0.0"

$schema is deliberately left on Millennium's main so editor hints track the schema as it changes; the test suite asserts that exclusion so the rule can't later be widened to "every raw URL" and freeze it by accident.

v1.0.1 contains no functional change — it exists only to carry this. Both pinned URLs return 200 at the tag.

One note for whoever reviews, unchanged from before: no other plugin in the database sets thumbnail or splash_image at all, so there's still no house convention here. If the project wants pinned asset refs as a rule, that's a template or docs change rather than something to settle per-submission — happy to have been the first to follow it either way.