Neler değişti?

28 Tem 2026

BadgeAPIPlugin's avatar-decoration-sync patch (isAvatarDecorationAnimating:) correctly swaps in the real copied asset/skuId, but never touched the sibling canAnimate default in the same object literal - that default still reflects the CURRENT (faking) user's own real decoration state, which is usually "not animating" since most people copying someone else's Frame don't have a real animated one of their own. Discord's own decoration URL builder (and Decor's own getDecorAvatarDecorationURL, same logic) strips the asset's a_ prefix whenever canAnimate is falsy, so every viewer saw the right image frozen on frame 1 instead of playing. Added a 4th replacement to the existing patch group forcing canAnimate true whenever the synced override's asset starts with a_ (real animated-asset convention, same check Decor already uses), reusing declutter's already-proven match/anchor for this exact object literal shape (isAvatarDecorationAnimating:'s canAnimate sibling). Grouped patch, so if this regex ever stops matching a future Discord bundle, it fails closed (whole group undone, logged) rather than half-applying. Built and redeployed to %APPDATA%\HyperCord\dist for local testing - needs a full Discord restart (not just reload) to verify live.

28 Tem 2026

The three places framework code already knows exactly which plugin failed at the point an error is caught - patch application (patchWebpack.ts), a plugin's start() (PluginManager.startPlugin), and a plugin's flux event handler (PluginManager.subscribePluginFluxEvents) - now also report it via a new shared reportPluginError() alongside the existing console logging. This is a far more reliable signal than trying to reverse-engineer a plugin name out of a minified stack trace after the fact, which is what HyperCordTelemetry's existing generic window.onerror handler would otherwise be stuck doing. Same privacy rule as the existing usage ping: never reports a third-party userplugin's name, only HyperCord's own catalog plugins (checked via PluginMeta[plugin].userPlugin), and respects the same HyperCordTelemetry enabled/disabled toggle. Backend side (badge-api) now accepts and stores the optional plugin field and exposes an admin-only aggregate breakdown - separate change, same batch of work.

28 Tem 2026

Both are fully built and live: the Updater tab already has an "Automatically update" toggle backed by the (now-fixed) HTTP updater, and the Cloud tab already does full settings sync against cloud.hypercord.pro (enable/reauthorize/sync-direction/manual upload-download/erase). The roadmap blurb was undercutting what already ships. Only the plugin marketplace is still genuinely unbuilt, so that's the only thing left in "on the roadmap" now.

28 Tem 2026

28 Tem 2026

Covers main-process startup/updater console logs, the dev-build warning banner, a webpack lookup error, two SpotifyControls seek-error tags, and three plugin setting descriptions (MessageLoggerEnhanced, TranslatePlus, UserpluginInstaller). Left untouched on purpose: DataStore/settings keys, IPC channel names, the vencord:// protocol scheme, Vesktop build filenames, Vencord.Api.* patch-replace strings, and legacy MoreStickers migration keys — renaming any of those breaks existing user data, cross-process contracts, or the Vencord->HyperCord migration path itself. Also left alone: GPL header comments, the Vencord Backend/ Decor/ReviewDB/ShikiPluginAssets references (real third-party services), and the upstream attribution in README.

28 Tem 2026

Covers chat buttons menu label, command error bot username, settings backup/import strings, CSP permission dialog title, Monaco editor window title, and ThemeLibrary plugin description.

28 Tem 2026

HyperCord always ships injected into the real Discord client (copied into %APPDATA%\HyperCord\dist), which is never a live git checkout - the git-based updater's `git remote get-url origin`/`git fetch` calls always failed there, logging "Failed to retrieve repo" / "Failed to check for updates" on every single startup. The HTTP updater needs no local git: it already correctly compares against hypercordapp/hypercord's "DevBuild <hash>" GitHub release (published on every push) and would download patcher.js/preload.js/renderer.js/ renderer.css straight from its assets - verified this release already exists with exactly the right naming/asset format. Was gated behind IS_STANDALONE (a Vesktop-style-build flag, unrelated to whether a git checkout exists), which is false for our normal build - now used unconditionally regardless of that flag. Verified live: rebuilt, redeployed to %APPDATA%\HyperCord\dist, full Discord restart, called VencordNative.updater.getRepo()/getUpdates() directly via CDP - both now return successfully (repo resolves to the real GitHub URL, no pending updates since this build IS latest), and the startup console no longer logs any Updater error.

28 Tem 2026

Display Name Style is a fourth real Nitro cosmetic (font/effect/colors, no skuId - distinct shape from decoration/nameplate/profile effect) synced through the same per-cosmetic backend pattern and applied via the same direct-mutation approach already proven for decoration/nameplate. HyperCordTelemetry now also reports which official (non-userplugin, non-required) plugins are currently enabled, powering hypercord.pro's real "most used plugins" list instead of a static heuristic. Still opt-out via the same toggle, disclosure text updated to say so. Also drops the temporary decoration/nameplate diagnostic logging now that cross-viewer sync is confirmed working.

27 Tem 2026

Nitro and Boost were still each one shared priority covering all 8-9 tenure tiers, so within that single sort key their relative order came from array-concatenation order rather than Discord's real order - same underlying problem as the previous fix, just one level more granular. Every catalog key (including every individual Nitro/Boost tier and Certified Moderator, previously uncovered) now maps to its own exact numeric slot. Real Nitro/Boost ids can't be reliably decoded into which specific tenure tier they represent (id patterns for that aren't verified here), but that's provably fine: a single profile only ever has one real Nitro and/or one real Boost badge at a time, so pinning both to their block's base slot (Nitro, Boost1) sorts identically to picking any other slot in the same block - only cross-block position matters, and that's exact. Certified Moderator gets its own real-id pattern and priority now instead of falling to Unknown.

27 Tem 2026

The old weighting only split badges into 4 buckets (Custom/Nitro/Boost/ Other), so every non-Nitro/Boost category (Staff, Partner, HypeSquad Events, Bug Hunter, HypeSquad Houses, Early Supporter, Active Developer, Verified Bot Developer, Quest) shared one "Other" weight. Since sort is stable, their relative order was decided by array-concatenation order (all fake picks before all real badges of that shared weight), not by Discord's actual category order - so a picked fake Early Supporter badge, say, would always land ahead of a real Partner/Active Developer badge regardless of which should actually come first. Replaced with one BadgePriority enum giving every named category its own exact slot (1-12), matched by catalog key for fake picks and by Discord's real badge id for real ones, with anything unmatched deliberately falling to Unknown (99) rather than guessed into a slot - Quest's real id in particular isn't verified against a live badge object, so it's left unmatched on purpose. Also reverses the Nitro/Boost dedup rule: a real Nitro/Boost the user genuinely holds now wins over a FakeProfile tier pick for the same slot (previously the fake one won), since showing both is a contradiction and the real one is the truth.

27 Tem 2026

Caught by CI's simple-import-sort/imports rule after an unrelated push - pre-existing, not touched by the decoration/nameplate fix.

27 Tem 2026

fetchUserProfile() returned its UserProfileStore cache entry for an id unconditionally once one existed, skipping the REST fetch entirely - but that fetch's USER_UPDATE dispatch is the only thing that ever pushes a source user's current avatarDecorationData/collectibles into UserStore. Once any caller (including a plain profile popout view) had cached an id even once, FakeProfile's syncCosmeticFromUser calling fetchUserProfile again on every reconnect/retry became a permanent no-op: decoration and nameplate stayed frozen at whatever they were the first time, while profileEffect (read straight off the stale-but-present cached profile) happened to still look right. This is what broke cross-viewer decoration/ nameplate sync while profileEffect worked, despite all three going through the same extract pattern. Added an explicit force param to bypass the cache, used only by FakeProfile's source-user fetch (the one call site that genuinely needs live data every time) - the other two callers (ContributorModal, fakeProfileThemes) keep the existing cache-friendly behavior. Also removes the now-unnecessary temporary diagnostic log at the extract call site now that the actual root cause is fixed.

27 Tem 2026

This is the plugin that adds the titlebar button housing every plugin's toolboxActions (like FakeProfile's "Reapply Fake Profile") - it was opt-in, so a fresh install has zero UI surface for any toolbox action at all, they're just silently unreachable. Turned on by default since there's no other way to discover/use them. Also renamed the display name away from "Vencord" branding.

27 Tem 2026

If the source account's decoration/nameplate/profile effect are themselves synced HyperCord fakes (not real Discord data), reading them back on a different client depended on that client's own BadgeAPIPlugin poll (every 3 minutes) already having caught up - if you copy from someone right after they set theirs up, you could read stale/empty data. Now forces a refetchBadges() right before extracting, so the copy always sees current data regardless of poll timing.

27 Tem 2026

Backend data confirmed correct via direct API checks (both /profiles and /profiles/:id serve the right decoration/nameplate for the source account), yet a second tester's client only picked up profileEffect, not decoration/nameplate, despite all three going through the same fetchUserProfile + extract pattern. Adding temporary logging around applyCosmeticOverrides and the extract() call to see exactly where the two diverge, since static analysis alone hasn't found it. Remove once resolved.

27 Tem 2026

Logger.ts's console output still said "Vencord" - changed to HyperCord. Also removed the guessed nameplateOverride/ profileEffectOverride webpack patch group in BadgeAPIPlugin - a real user's console confirmed it was undone ("had no effect"), so it's been dead weight/noise since it was added; nameplate/profile effect are applied via FakeProfile's own store patches instead, which is what's actually confirmed working.

27 Tem 2026

The authorization popup never appearing for a second tester pointed to a stale/invalid cached secret (shared across badges/banner/decoration/ nameplate/profile effect) being reused instead of re-triggering OAuth, with the resulting 401 completely silent - no way to recover without manually clearing local storage. Now: any non-ok/non-409/non-400 response gets a toast, and specifically on 401 the cached secret is cleared via the new clearBadgeAuth() so the next attempt actually re-prompts for authorization.

27 Tem 2026

Checked the backend data directly - a second tester's account has zero synced cosmetic data despite entering a source ID, meaning their sync never reached the server at all. The likely cause: the one-time Discord authorization popup was dismissed or never completed, and that failure was completely silent - no toast, no log, indistinguishable from "nothing configured." Now shows a clear failure toast whenever there's actually a sourceUserId set but auth couldn't be obtained.

27 Tem 2026

Profile Effect (direct mutation of the UserProfileStore object) has been confirmed working cross-viewer across multiple tests; Frame/ Nameplate (previously applied via virtualMerge, which wraps a NEW Proxy object rather than touching the real one) has not, despite several attempts at other explanations. Switched to the same direct mutation of avatarDecorationData/collectibles on the real, cached User record - Discord's own avatarDecoration/nameplate getters read off those exact fields via `this`, so mutating in place means the getter reflects it naturally without needing virtualMerge's Proxy-receiver trick to work correctly. GuildMemberStore path (guild-context nameplate/decoration) left untouched this round - the previous edit there caused a crash and was reverted; isolating this change to the UserStore path only to keep the two risks separate.

27 Tem 2026

This reverts commit 934d31fa56077a78e5e2809e8d06cd63ee895148.

27 Tem 2026

discord-types shows GuildMember.avatarDecoration as a plain string, unlike the base User class where avatarDecoration/avatarDecorationData is an {asset,skuId,...} object - was assigning the whole object there, likely silently ignored or type-coerced wrong. Now assigns just the asset string. Profile Effect already confirmed working cross-viewer; this targets why Frame/Nameplate still weren't for another tester.

27 Tem 2026

isOwnId called UserStore.getCurrentUser(), which (after the previous commit removed the isOwnId gate from getUser/getCurrentUser's wrapper) is the PATCHED version that calls buildFakeUser, which for the current user calls isOwnId again - unbounded recursion, stack overflow, crashed the client badly enough that even Ctrl+R couldn't recover. Fixed by routing isOwnId through the captured originalGetCurrentUser reference instead of the live (patched) UserStore.getCurrentUser.

27 Tem 2026

The three cosmetics were gated behind isOwnId in UserStore/ UserProfileStore/GuildMemberStore, which only made them show on your own client - defeating the point of syncing them to the backend at all. Removed that gate for these three (kept it for username/ globalName/accentColor/themeColors, which stay self-only local fakes). buildFakeUser's single-slot cache (cachedRealUser/cachedFakeUser) only ever handled one user at a time by design - now that getUser runs this for every user rendered, not just self, switched to a WeakMap keyed by the real object so per-user results are cached independently.

27 Tem 2026

Confirmed with the user: "Frame" is just Discord's current settings-UI name for what discord-types calls avatarDecorationData - the ring around the avatar - grouped in Discord's own UI under "Profile Effect & Frame" but a genuinely different cosmetic from Profile Effect itself. Added displayName to all three settings so they show up titled "Avatar Decoration (Frame)" / "Nameplate" / "Profile Effect" in the settings UI instead of the auto-generated camelCase key name, and reworded the about text/description to spell out that these are three separate real Discord cosmetics.

27 Tem 2026

Reverted the shared fakeCosmeticsFromUserId back into three independent settings (fakeAvatarDecorationFromUserId, fakeNameplateFromUserId, fakeProfileEffectFromUserId) per feedback - each cosmetic copies from its own friend, not all three from one ID.

27 Tem 2026

Avatar decoration only had the BadgeAPIPlugin cross-viewer webpack patch, no direct self-view override - same gap class as nameplate had (DM/global context covered, guild-member context wasn't). Adds avatarDecorationData/avatarDecoration overrides in buildFakeUser and GuildMemberStore's avatarDecoration field, mirroring the nameplate fix.

27 Tem 2026

Found the actual gap: profileSets' own getCurrentProfile shows nameplate specifically branches isGuildProfile ? guildMember : user for its source, unlike every other field (profileEffect, accentColor, etc.) which always reads the same store regardless of context. Viewing yourself inside any actual server reads nameplate from GuildMemberStore, which was never patched - only the DM sidebar/global profile path (UserStore) was. Also stopped relying solely on virtualMerge's Proxy-receiver forwarding for the computed `real.nameplate` getter (uncertain whether it correctly re-enters the proxy) and set the override directly as well - belt and suspenders.

27 Tem 2026

The BadgeAPIPlugin cross-viewer patch for these two is unverified and possibly a no-op (wpsearch found neither nameplateOverride nor profileEffectOverride, and even avatarDecorationOverride didn't show up - likely because the relevant chunk just wasn't loaded yet, not that the strings don't exist). This adds a second, independent path that doesn't depend on guessing Discord's internals at all: inject the synced nameplate/profileEffect directly onto your own User/UserProfile record via the exact same isOwnId-scoped UserStore/UserProfileStore patch that already makes accentColor/themeColors work today. Guaranteed to show up on your own client (profile popout, settings) regardless of whether the other patch ever matches anything for other viewers.

27 Tem 2026

Reverted the friend picker UI per feedback - just type a Discord user ID directly again. Also credits HyperCordTeam as a BadgeAPI author alongside the original Vencord credits (Megu/Ven/TheSun), which was missing despite this session's decoration/nameplate/profile-effect work landing in that file.

27 Tem 2026

Collapses the 3 separate decoration/nameplate/profile-effect pickers into a single fakeCosmeticsFromUserId setting - one friend pick syncs whichever of the three they actually have equipped in one go, instead of picking a possibly-different friend per cosmetic type.