EUPL-1.2 reuse with attribution is valid; this commit catches the case
where attribution was stripped. Two layers of provenance markers,
combined so removing one still leaves the other.
Layer 1 (subtle, kopier-resistent):
- DalamudLogger.Log emits "[name]<U+200B>{level} message" — a
zero-width space (U+200B) between the category bracket and the
level value. Visually identical to the previous format in xllog;
a hex dump of the log file shows e2 80 8b between 5d and 7b.
Survives 1:1 code copies. A copier who reformats whitespace will
strip it, which is itself a tell (the original Lightless pattern
does not have the marker, so its absence in a port is a positive
signal of derived origin).
Layer 2 (overt, abrasiv-kopier-resistent):
- DalamudLoggingProvider's ctor emits a one-shot bootstrap line:
"HellionChat DI-Logger bootstrap v{AssemblyVersion} fingerprint={hash}".
Visible in xllog as the first plugin INFO line. Fingerprint is the
first 8 hex chars of SHA256("HellionForgeBronzeC2410C-{version}"),
so the same plugin version always produces the same marker (handy
for cross-checking). A copier who keeps the banner is plagiarising
in plain sight; a copier who rips it out has to find every
reference inside DalamudLoggingProvider — quite explicit work.
Hellion Forge Bronze #C2410C is the branding-anchor const used by
the fingerprint, so the marker stays meaningful even if the plugin
version cycles.
Slice D shrinks vs the original plan: three of the six files cannot
take an ILogger ctor arg without breaking external contracts.
Migrated (8 LogProxy sites across 4 files):
- Commands: 2 sites (Warning, Error). New ctor takes ILogger<Commands>.
- Themes/ThemeRegistry: 1 site (Debug). ILogger<ThemeRegistry>? is
optional (default null) so the existing Build-Suite tests that
construct `new ThemeRegistry()` parameterless keep working without
changes. _logger?.LogDebug guards the call site.
- PayloadHandler: 3 sites (Error, Warning, Error). New ctor takes
ILogger<PayloadHandler>. ChatLogWindow's two `new PayloadHandler(this)`
sites (the direct field and the Lender lambda) now hand a fresh
CreateLogger<PayloadHandler>() from the existing _loggerFactory.
Not migrated (5 sites stay on Plugin.LogProxy, plan drifts D12-D14):
- D12 - Configuration (1 site): IPluginConfiguration, instantiated by
Dalamud's Interface.GetPluginConfig() via reflection on the
parameterless ctor. Adding an ILogger arg would break GetPluginConfig.
- D13 - Message (4 sites): partial data class with two ctor overloads,
mass-instantiated across 3 plugin sites plus Newtonsoft JSON
deserialisation. Ctor extension would be invasive across ~20 call
sites with low payoff (data-class logger is unusual).
- D14 - FontManager (2 sites): both Plugin.LogProxy calls live in
static methods (TryGetHellionFontBytes, AddFontWithFallback) that
cannot reach an instance _logger. Same root cause as D8 in
GameFunctions. FontManager joins the static-bucket alongside
EmoteCache et al.; the ctor + _logger field added mid-Slice-D were
rolled back to keep the class clean.
Plugin.LogProxy surface after C9 (8 file buckets, ~12 sites total):
- 4 originally-static consumers: EmoteCache, AutoTranslate,
MemoryUtil, WrapperUtil
- 3 cannot-take-ctor-arg consumers: Configuration, Message, FontManager
- 1 single-static-method consumer: GameFunctions.TryOpenAdventurerPlate
(D8 from Slice B)
Smoke 2 is now due.
Six UI files shift from Plugin.LogProxy to ILogger<T> via
constructor injection.
Container singletons (each takes a typed ILogger plus, where it owns
nested allocations, an ILoggerFactory to spawn child loggers):
- Ui/ChatLogWindow (15 sites, plus an ILoggerFactory for the
Popout new-call at Ui/ChatLogWindow.cs:2417)
- Ui/Settings (SettingsWindow): no own sites, but takes an
ILoggerFactory so it can hand typed loggers to its three migrated
settings tabs (General, the other six tabs stay unchanged)
- Ui/DbViewer (3 sites)
Nested instances allocated by parent containers:
- Ui/Popout (7 sites, ILogger<Popout> as the new 4th ctor arg passed
from ChatLogWindow)
- Ui/SettingsTabs/ThemeAndLayout (1 site)
- Ui/SettingsTabs/FontsAndColours (1 site)
- Ui/SettingsTabs/DataManagement (15 sites)
PluginHostFactory factory lambdas updated for ChatLogWindow,
SettingsWindow and DbViewer to resolve the new logger args.
Seven services across Integrations/, Ipc/ and GameFunctions/ shift
from Plugin.LogProxy to Microsoft.Extensions.Logging.ILogger<T>.
Files with live LogProxy sites (10 in total):
- Ipc/ExtraChat (1)
- GameFunctions/Chat (6)
- GameFunctions/GameFunctions (2)
- GameFunctions/KeybindManager (1)
Foundation-touch files (no current sites, ctor takes ILogger<T> as
seed for the v1.5.7-11 Plugin-Integrations wave):
- Integrations/HonorificService (also drops the local IPluginLog
_log field in favour of ILogger<HonorificService> _logger; the
three _log.* calls there are migrated as a bonus since the field
had to change anyway)
- IpcManager
- Ipc/TypingIpc
GameFunctions takes ILoggerFactory as an extra ctor arg so it can
hand a typed logger to its nested Chat and KeybindManager (same
pattern MessageStore + MessageEnumerator use in Slice A).
PluginHostFactory factory lambdas updated for all five Slice B
services that need extra resolves.
Plan drift D8: GameFunctions.TryOpenAdventurerPlate is an internal
static method whose only Warning call cannot reach the instance
_logger. The one site stays on Plugin.LogProxy with an inline note;
promoting it to instance + PayloadHandler.cs:814 call-site update is
a v1.5.1+ cleanup, out of DI-4 Slice B scope.
MessageStore, MessageEnumerator, MessageManager, AutoTellTabsService
move from Plugin.LogProxy / IPluginLogProxy onto
Microsoft.Extensions.Logging.ILogger<T> via constructor injection.
MessageStore additionally takes ILoggerFactory so it can build a
per-instance ILogger<MessageEnumerator> at each of the five reader-
spawning sites; the enumerator is not a container singleton.
PluginHostFactory's MessageManager and AutoTellTabsService factory
lambdas grow to resolve the new logger args; everything else stays in
place.
Site-level migration in the four files:
- MessageStore: 12 calls, _logger field IPluginLogProxy -> ILogger<MessageStore>
- MessageManager: 7 Plugin.LogProxy.* sites, new _logger field
- AutoTellTabsService: 9 Plugin.LogProxy.* sites, new _logger field
Plus a pre-existing template bug surfaced by CA2017: a LogDebug call
in AutoTellTabsService used "{tab.Name}" with no `$` prefix, which
landed in xllog as literal text under Plugin.LogProxy; ILogger now
reads that as a structured placeholder, so the call was promoted to
proper structured logging with tab.Name passed as a parameter.
C3's Phase-1 bridge in Plugin.ctor already pulls IPlatformUtil and
IPluginLogProxy out of the container right after the host builds, so
the manual `new DalamudPlatformUtil()` / `new DalamudPluginLogProxy`
assignments in Phase-0 were just allocating throwaway instances that
got overwritten a few lines later.
Phase-0 helpers that run before the container build
(MigrateFromChatTwoLayout, LanguageChanged, ImGuiUtil.Initialize) do
not touch Plugin.PlatformUtil or Plugin.LogProxy, so the brief
null-window between the schema gate and the container build is safe.
The DalamudPlatformUtil and DalamudPluginLogProxy wrapper classes
themselves stay in the code; DI-4 (logger migration to ILogger<T>)
will eventually retire the proxy for new sites but EmoteCache,
AutoTranslate, MemoryUtil and WrapperUtil keep using it.
Smoke 1 of C3 surfaced MessageManager.DisposeAsync throwing on unload:
Plugin.DisposeAsync ran the manual MessageManager teardown (CTS
cancel + dispose at MessageManager.cs:84-99), then awaited
_lifecycle.DisposeAsync which routed Host.Dispose through the
container, which hit MessageManager.DisposeAsync a second time and
threw ObjectDisposedException on the already-disposed CTS.
Plugin.DisposeAsync now drops every manual service dispose - the
container owns those singletons end-to-end. The framework-thread block
keeps the three calls the container has no handle on
(TearDownCommands, GameFunctions.SetChatInteractable,
WindowSystem.RemoveAllWindows), plus the static-class cleanups
(EmoteCache.Dispose, InputHistoryService.Reset) stay outside the
container entirely.
This changes the teardown order versus v1.4.10: the container disposes
in reverse-registration order, which puts Windows ahead of IPC
services. The v1.4.10 ordering ("IPC before Windows so a final IPC
event cannot hit a half-torn ChatLogWindow") is no longer enforced.
Host.Dispose runs synchronously on the framework thread, so no
Framework.Update or Draw event fires during teardown; the remaining
risk is an external IPC plugin invoking a subscriber mid-dispose,
which is not something v1.4.10 actually prevented either.
C3 bootstrap throws "A suitable constructor for type
HellionChat.Ipc.ExtraChat could not be located" because
Microsoft.Extensions.DependencyInjection's ActivatorUtilities only
binds to PUBLIC constructors via reflection. ExtraChat is a public
class with an internal ctor; Commands and StatusBar are internal
classes whose implicit default ctor inherits class accessibility
(internal); every IHostedService adapter is `internal sealed class
X(deps)` with a primary ctor that is also internal.
The fix routes all eight singletons and all seven hosted-service
adapters through factory lambdas. `new T(...)` inside the
PluginHostFactory namespace sees the internal surface, so the
container never has to reflect over internal ctors.
Flips the container live. Plugin.ctor now builds the host after the
schema gate clears, pulls PluginLifecycle out of the container, and
backfills the Plugin.X static surface plus the instance properties
(11 services + 8 windows) so existing consumers reach the same
instances the container holds.
Plugin.LoadAsync gets thinner: service and window allocations are gone
(the container owns them), BuildFonts / Switch / FilterAllTabsAsync /
Initialize moved to their hosted-service adapters inside
Host.StartAsync, WindowSystem.AddWindow moved into
PluginLifecycle.LoadAsync on the framework thread. Plugin-internal
init (SelfTestRegistry, FirstRunWizard, SetupCommands +
Commands.Initialise, RetentionSweep, EmoteCache.LoadData, FTS5 rebuild
worker, UiBuilder.Disable*UiHide, AutoTranslate.PreloadCache,
Framework / Draw / LanguageChanged subscribes) stays in Plugin.LoadAsync
because each step reaches Plugin-private members or fields.
Plugin.DisposeAsync keeps the manual teardown for ordering (IPC before
windows, hooks first) and awaits _lifecycle.DisposeAsync at the end to
stop the host and dispose the container on the framework thread.
Double-disposes against container singletons are no-ops for the
services that hold real resources (Dispose idempotency is the standard
pattern).
PluginLifecycle takes Plugin as a constructor arg so it can iterate
the Window properties and call WindowSystem.AddWindow on the framework
thread; v1.4.9 Stage-2 verified that AddWindow's backing List<> is
not thread-safe.
Plan drift D4 noted: Plugin.cs ends at 1050 lines instead of the
150-220 vision because helper methods (MigrateFromChatTwoLayout,
SeedExampleThemeIfEmpty, RunRetentionSweepIfDue, FrameworkUpdate,
Draw, LanguageChanged, SetupCommands, slash handlers, FTS worker)
stay in Plugin.cs. Extracting them is DI-2b or a dedicated service
refactor in v1.5.1+. C3 still hits the DI-2a goal: bootstrap is
container-driven and LoadAsync is allocation-free.
PlatformUtil and LogProxy keep the manual `new` for now; C5 (DI-3)
removes those once C3 stabilises in the smoke test.
Lays down the DI foundation that v1.5.x will run on top of, without
flipping the switch on Plugin.cs yet (that move follows in C3). The new
files compile alongside the existing bootstrap but no caller resolves
the host, so the live behaviour is byte-identical to v1.4.10.
What's new:
- PluginHostFactory.cs: HostBuilder.Build(plugin, dependencies)
registers ~46 services across Block A (21 Dalamud singletons), Block
B (14 HellionChat services plus FileDialogManager), Block C (8
windows), plus Plugin and PluginLifecycle. Service-class bodies are
untouched - Plugin-backref ctors go through factory lambdas.
- PluginLifecycle.cs: thin IAsyncDisposable wrapping the host's
StartAsync/StopAsync, with idempotent dispose and framework-thread
Host.Dispose. The Host is assigned via a property setter from
Plugin.ctor; HellionChat deviates from Lightless' Func-delegate
pattern because the schema gate must run before Build.
- Infrastructure/Logging/{DalamudLogger, DalamudLoggingProvider,
DalamudLoggingProviderExtensions}.cs: ILogger<T> -> IPluginLog
bridge, ported from Lightless without the mod-sync hasModifiedGameFiles
flag and without the LightlessConfigService log-level coupling.
- Infrastructure/Hosting/InitHostedServices.cs: seven IHostedService
adapters around the existing init methods (FontManager.BuildFonts,
ThemeRegistry warmup+switch, IpcManager/TypingIpc/ExtraChat eager
resolve, MessageManager.FilterAllTabsAsync, AutoTellTabsService
.Initialize). Adapter style rather than inlining ": IHostedService"
on the service classes per the DI-2a "service bodies untouched"
constraint.
Plan drift noted for cycle closure: MessageStore stays inside
MessageManager.ctor (not a standalone container singleton) because
MessageManager.ctor allocates it directly today; promoting it would
double-construct the SQLite handle. AutoTellTabsService reads it via
MessageManager.Store inside its factory lambda.
Prepares the v1.5.0 DI-container adoption (Lightless pattern) by adding
four MS.Extensions packages as direct closed-range references:
- Microsoft.Extensions.Hosting (IHost, HostBuilder)
- Microsoft.Extensions.DependencyInjection (IServiceCollection)
- Microsoft.Extensions.Logging (ILogger<T> for DI-4 logger migration)
- Microsoft.Extensions.Options (transitive used by Hosting + future config)
Closed-range [10.0.7, 11.0.0) matches the existing pinning style for
MessagePack/Pidgin/ImageSharp and locks the major version while letting
Renovate roll minor and patch updates. Lock file regenerated.
Cherry-pick from ChatTwo upstream ee7768ac (Infiziert90, 2026-05-16):
when args.AddIfNotPresent or args.Input starts with '/', replace the
chat input instead of appending. Fixes the Friend-List "/tell" path
where existing text like "test" would otherwise concatenate to
"test/tell user@world" before the receiver and channel resolve.
Variable drift versus upstream: HellionChat uses local 'Chat' where
ChatTwo uses InputHandler.ChatInput; logic is 1:1.
The Block C check used `jq -r '.[0].Changelog' | grep -qE ...` to spot
the **vX.Y.Z** marker. With `set -o pipefail`, grep -q closing stdin on
the first match makes jq trip SIGPIPE on the rest of the multi-KB
Changelog string, which the script then surfaces as a false-positive
"Changelog missing **vX.Y.Z** subblock" failure. Interactive shells
sometimes raced through fast enough to hide the issue, but the pre-push
runner hit it reliably (saw it on the v1.4.10 release-cut push attempt).
Switched the pipe to a process substitution so jq writes into a FIFO
and SIGPIPE never enters the picture. Both directions of the marker
check now stay deterministic.
Forge-Post is required in the tagged tree so forge-announce.yml can read
it during the release-pipeline run. Plus a csharpier reflow on two files
(SymbolPicker.cs, ChatLogWindow.cs) that preflight Block E flagged after
the cycle's comment-tightening sweep — purely whitespace, no behaviour
change.
Five trim spots from the cycle's earlier commits — none change behaviour,
just drop redundant phrasing and stale references per the HellionChat
comment-style convention (1-3 lines default, link "same as X" instead of
repeating, file:line refs only where they aid navigation).
SymbolPicker:
- BmpWhitelist header consolidated to source + filter ranges
- ImRaii.Popup pattern links the established ChatLogWindow popup idiom
instead of citing three call-sites
- ToIconString comment drops the "discoverability" footnote that the
code already telegraphs
- Manually-wrapping comment drops the "same modern idiom" tail that
duplicated the preceding sentence
MessageStore:
- Merge the stale pre-v1.4.10 sqlScanLimit comment with the new
v1.4.10 commentary; the cap mention now describes the historical
reason rather than a parameter that no longer exists
PreloadHistory had a hardcoded 500-row SQL scan window that capped the
per-partner history pull regardless of the AutoTellTabsHistoryPreload
setting. For active users with many tell partners, the scan window
filled up with chatter from other partners and pushed less-frequent
partners' history off the back end — pinned tabs reloaded empty even
though the messages were still in the database.
Drops the hardcoded scan cap. The (Receiver, Date) index keeps SQL fast
on the now-unbounded read, and the client-side loop still breaks as
soon as the configured per-tab limit is hit, so decode cost stays
proportional to the depth at which `limit` matches accumulate (typically
shallow even for chatty users).
Adds a Configuration property, defaulted to enabled, and a checkbox in
the Chat settings tab's Behaviour section. Strings live in HellionStrings
so DE/EN stays in sync. Defaults aligned with our 'discoverable by
default, hidden by user choice' convention. Schema stays at v17 — the
new boolean is additive, the default constructor covers existing configs.
Second tab exposes the server-verified BMP whitelist (round-tripped via
/echo and /say in the v1.4.10 preflight). Recent-used row at the top
floats the user's last sixteen picks across both tabs, move-to-front
on reuse. Recents stay session-only by design — no Configuration touch,
schema unchanged.
New popup attached to the chat input lets the user browse and insert
Dalamud SeIconChar glyphs (161 PUA codepoints, server-safe by design).
Search field filters by enum name. Multi-insert keeps the popup open
until the user clicks elsewhere. BMP tab follows in the next commit.
TearDownCommands attached the same instance via re-Register with identical
args, which was functionally a no-op but masked a latent bug if Description
or ShowInHelp ever diverged between Setup and Teardown. Hold the wrapper
instances as nullable fields so Teardown can detach the live registration
directly. Mirrors the cached-wrapper pattern in ChatLogWindow.
Adds a "ChatTwo IPC compatibility layer" bullet across all six
release-note surfaces so the new behaviour from commits 8c4afaa and
655c903 is visible to users via the manifest installer, the Gitea
release page, the README project-status section, the changelog/roadmap
docs and the Forge-Discord announcement.
Files touched:
- HellionChat/HellionChat.yaml: bullet added inside the v1.4.9
changelog block, preserved order so the regression-tripwire line
still comes before the migration-stays line.
- repo.json: Changelog field kept synchronous (JSON-escaped newlines).
- README.md: project-status paragraph extended with a one-sentence
recap of the IPC mirror and the conflict-detection caveat.
- docs/CHANGELOG.md: bullet inserted between the profiling-logs and
migration-stays bullets, code-fenced gate names.
- docs/ROADMAP.md: v1.4.9-released section gets the same recap so the
cycle history stays self-describing.
- .github/forge-posts/v1.4.9.md: German-only bullet for the Discord
embed, slotted before the migration-v17 bullet. Char-cap holds —
preflight Block C reports the embed total well under 5500 chars.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Extends commit 8c4afaa: the TypingIpc mirror covered only two of the six
ChatTwo IPC slots. Third-party plugins like Artisan and AllaganTools
subscribe to a different ChatTwo IPC surface — the context-menu
integration (ChatTwo.Register / Unregister / Available / Invoke) that
lets them push item-links into the chat. Smoke test against the
deployed v1.4.9 build showed Artisan logging "Chat2 is not available"
because those four gates were not yet mirrored.
This commit adds the missing four ChatTwo-prefixed provider gates in
IpcManager.cs:
- ChatTwo.Register (Func<string>) — bound to the existing Register()
backing method, so plugins that subscribe via either namespace land
in the same Registered list.
- ChatTwo.Unregister (Action<string>) — bound to the existing
Unregister() backing method, same shared-state rationale.
- ChatTwo.Available (Action<>) — SendMessage() fires from the ctor right
after AvailableGate.SendMessage(), so any subscriber waiting on the
"Chat 2 became available" signal sees both events.
- ChatTwo.Invoke (Action<string, PlayerPayload?, ulong, Payload?,
SeString?, SeString?>) — Invoke() fans the context-menu event out to
both InvokeGate and ChatTwoInvokeGate in lockstep. Subscribers compare
on the registration ID they got back from Register, so the
shared-backing approach keeps that contract intact regardless of which
namespace they subscribed under.
Dispose() unregisters all four ChatTwo gates plus the four existing
HellionChat gates. The conflict-detection that prevents ChatTwo from
loading alongside HellionChat guarantees no slot collision at runtime.
With this commit the full ChatTwo IPC surface (6 of 6 slots) is mirrored:
- ChatTwo.GetChatInputState (TypingIpc, commit 8c4afaa)
- ChatTwo.ChatInputStateChanged (TypingIpc, commit 8c4afaa)
- ChatTwo.Register (IpcManager, this commit)
- ChatTwo.Unregister (IpcManager, this commit)
- ChatTwo.Available (IpcManager, this commit)
- ChatTwo.Invoke (IpcManager, this commit)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
HellionChat replaces ChatTwo (conflict detection prevents parallel loading)
but third-party plugins with a no-fork policy keep subscribing only to the
ChatTwo.*-prefixed IPC gates. Mirroring the two TypingIpc provider slots
under the ChatTwo namespace lets those plugins keep working without code
changes on their side.
Mirrored slots:
- ChatTwo.GetChatInputState ←→ HellionChat.GetChatInputState
- ChatTwo.ChatInputStateChanged ←→ HellionChat.ChatInputStateChanged
Implementation:
- Two additional ICallGateProvider fields (ChatTwoStateQueryGate +
ChatTwoStateChangedGate) with the identical ChatInputState tuple
signature. The tuple's underlying types match ChatTwo's surface byte-
for-byte (bool/bool/bool/bool/int/ushort — ChatType is `ushort` in both
repos), so Dalamud's IPC marshalling matches across plugin boundaries
even when the subscribing plugin defines its own copy of the ChatType
enum.
- ctor registers the new provider gates and binds RegisterFunc(GetState)
to ChatTwoStateQueryGate so query calls route to the same backing path.
- Update() pushes the state to both ChatTwoStateChangedGate and the
existing StateChangedGate in lockstep.
- Dispose() unregisters both query gates.
Ipc/ExtraChat.cs is intentionally unchanged — it is a subscriber on
ExtraChat's own IPC, not a provider, so no compatibility mirror applies.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Synchronises the v1.4.9 changelog across the manifest sources that the
Dalamud plugin installer, the gitea repo.json feed and the Forge auto-
announce workflow read at release-tag time.
Files touched:
- HellionChat/HellionChat.yaml: v1.4.9 block inserted at the top of the
changelog: literal. v1.4.5 dropped to keep the slim-rule at 4 subblocks
(preflight Block C enforces YAML_VERSIONS <= 4). Current set is
v1.4.9/v1.4.8/v1.4.7/v1.4.6.
- repo.json: Changelog field kept synchronous with the yaml — v1.4.9
block prepended, v1.4.5 substring removed, JSON-escaped newlines.
- .github/forge-posts/v1.4.9.md: new file with frontmatter (subtitle
"Plugin-Load Render Polish", versionsnatur "Performance-Patch") and
a German-only body. The English half of the eventual Discord embed
is pulled automatically from the yaml changelog at tag-push time by
.gitea/workflows/forge-announce.yml — same workflow as v1.4.4
onwards, the post file does not carry an English block.
Char-cap pre-check passes (title 46 + description ~2700 + footer 33 =
~2800 chars, well under the 5500-char Discord embed total cap).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Manifest version bump for the v1.4.9 release cut. Schema-required v16
stays unchanged (R1/R2/R3 are all config-neutral refactors).
Files touched:
- HellionChat/HellionChat.csproj: <Version> 1.4.8 -> 1.4.9
- HellionChat/Plugin.cs: schema-migration error string self-reference
(v1.4.8 -> v1.4.9, required schema v16 stays)
- repo.json: AssemblyVersion, TestingAssemblyVersion, 3x DownloadLink*
URLs all bumped to 1.4.9 / v1.4.9. Changelog field is still on v1.4.8;
the v1.4.9 block plus v1.4.5 slim-drop land in the next commit.
- README.md: shield badge, version header in lead paragraph, project-
status block rewritten for v1.4.9 (Plugin-Load Render Polish).
- docs/CHANGELOG.md: v1.4.9 block inserted above v1.4.8.
- docs/ROADMAP.md: v1.4.9 moved into the released-versions list,
"Next Cycle" header now targets v1.4.10 (Render Clipper + Symbol
Picker reserves carried over from the v1.4.9 plan).
yaml changelog block and repo.json Changelog field follow in the
docs commit so the slim-drop of v1.4.5 stays atomic with the v1.4.9
block insert.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Cut first-frame HITCH from ~127ms median down to ~76ms median (4-reload
sample, threshold lowered to 1ms for measurement) — comfortably under
Dalamud's 100ms warning threshold. ChatTwo upstream sits at ~63ms median
for comparison; the remaining ~13ms gap is the cost of HellionChat-only
features (Sidebar tab view, custom StatusBar, Honorific integration).
Mechanism: a single `_firstFrameDone` flag (flipped in Draw's finally
block) gates six sections that don't need to render on frame 0:
- StatusBar.Draw (~12ms): the bottom status bar
- DrawChannelName chunks (~17ms): SeString-Renderer layout, replaced
with a plain-text fallback (activeTab.Name) for frame 0
- PositionReset/BoundsCheck (~10ms): EnsureWindowOnScreen viewport
iteration, only matters once the user notices a mispositioned window
- DrawV061HintBannerIfNeeded (~3-5ms): v0.6.1 migration notice
- DrawAutoComplete (~6ms): renders nothing until the user types a command
- InputPreview.CalculatePreview (~3-5ms): triggers InputPreview first-
frame lazy init, user-typing-driven anyway
Frame 1 then renders all of them in ~40ms (still well under the warning
threshold), and frames 2+ stay at 0ms as before. User sees the deferred
sections ~17ms (60fps) later than before — invisible inside the ~2.5s
Atlas-Build window after every plugin reload.
Hypothesis triage from the R2-profiling pass:
- (a) Atlas-Sync-Fallback: falsified. xllog shows the Atlas-Complete
line always lands ~2.5s before the HITCH frame.
- (b) Theme-Apply ABGR-Cache-Init: not dominant. PushGlobal is 5ms.
- (c) Multiple-Window-Render: falsified in v1.4.9 Stage-2-Lazy-Init
diagnose (deferred 4 windows, no measurable delta).
- (d) DrawList-Setup-Cost per Window: actual root cause. Layout cost
distributes evenly across ~10 ImGui sections inside ChatLogWindow
(5-20ms each). No single hot-spot to optimise — the six selective
skips above are the pragmatic fix.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pull the four user-triggered slash-commands (/hellion, /hellionView,
/hellionDebugger, /hellionSeString) plus the two Plugin-Manager
UiBuilder hooks (OpenConfigUi, OpenMainUi) out of their window
constructors and into a central Plugin.SetupCommands method so they
work before their target window has been opened the first time. A
matching TearDownCommands runs as the first CaptureFailure inside the
framework-thread teardown lambda. /hellion and /hellionSeString stay
under the same #if DEBUG guard SeStringDebugger had before. The four
window classes keep their public Dispose method signatures so the
existing Plugin.DisposeAsync method-group binding still resolves —
the bodies are now empty pointers to TearDownCommands. The pre-v1.4.9
`OpenMainUi` body that flipped SettingsWindow.IsOpen and the three
private Toggle(string, string) method-group wrappers are gone since
the central handlers call SettingsWindow.Toggle() / DbViewer.Toggle()
etc. directly.
The properties stay eager in stage 1 — the lazy-init switch lands in
stage 2 with the matching `_lazyWindowLock` guard around AddWindow
and RemoveAllWindows. Doing it in two commits keeps the slash-command
correctness verifiable on its own.
Smoke (release build): /hellion, /hellionView, /hellionDebugger,
/clearhellion plus Plugin-Manager Settings and Open buttons all
toggle their target window. /hellionSeString remains DEBUG-only as
before.
Bump AutoTranslate-warmup and FilterAllTabs log-level from Debug to
Information so the xllog tail surfaces them without a Debug filter.
Wrap MessageStore.Connect and MessageStore.Migrate in Stopwatches so
the SQLite open and migration-chain costs are visible too.
Sub-Task 3.4 Befund on v1.4.8-baseline (4 reloads, medians):
- MessageStore.Connect: 50.5 ms
- MessageStore.Migrate: 2 ms
- MessageManager.FilterAllTabs: 68.5 ms
- AutoTranslate warmup: 108 ms
- UiBuilder HITCH: 108.9 ms
Outcome D — none of the three dominates the 200 ms threshold. The
ChatTwo "300 ms" comment for AutoTranslate is falsified at ~108 ms;
SQLite is not the bottleneck (52.5 ms total); FilterAllTabs runs on
the worker thread and only competes for CPU slots. The HITCH is left
unexplained by these probes, which keeps Hypothesis c (multi-window
WindowSystem.Draw initial pass) as the main R2 suspect to be
validated by the R1 lazy-window refactor.
Logs stay in as belt-and-suspenders for future plugin-load
regressions.
FullTextSearch + LoadByGuids could stall the draw thread for 100-300 ms
on large databases with a popular search term. The two hot trigger sites
(FTS toggle, search input) now route via TriggerFilterRefresh, which
dispatches the FTS path to Task.Run; the in-memory page-filter path
stays inline because it is sub-ms on the loaded page array.
_ftsFilterSeq is bumped per trigger so a late worker recognises itself
as stale and drops its result instead of overwriting a newer one. The
date/channel and history workers already lived on Task.Run and are
untouched.
Surfaced during the v1.4.8 pre-tag review.
- HellionChat.yaml: v1.4.8 changelog block above v1.4.7, v1.4.4
dropped per slim-rule (verify-changelog-sync enforces max 4).
- repo.json: Changelog field synchronised with yaml, same slim-drop.
- .github/forge-posts/v1.4.8.md: bilingual announcement post (DE
body, EN block resolved from yaml at workflow time). Frontmatter
subtitle 32/60 chars, versionsnatur 12/40 chars, embed total
~2787/5500 chars.
- csproj <Version>, Plugin.cs schema-gate self-reference, repo.json
(AssemblyVersion, TestingAssemblyVersion, 3x DownloadLink URLs).
- README.md shield badge, version header, Project Status body.
- docs/CHANGELOG.md gains a v1.4.8 section above v1.4.7.
- docs/ROADMAP.md flips Next Cycle to v1.4.9 (Plugin-Load Render
Polish), v1.4.8 moves into the released history above v1.4.7.
- Config schema stays at v17, Migration v17 stays additive.
repo.json Changelog field and HellionChat.yaml changelog block plus
the new forge-posts/v1.4.8.md follow in a separate commit (slim-drop
of v1.4.4 happens there).
messages.Id is declared BLOB but stored as TEXT because Microsoft.Data.Sqlite
binds Guid parameters as UUID strings (UpsertMessage uses AddWithValue with
a Guid). RebuildFtsIndex cast reader.GetValue(0) to byte[] and threw
InvalidCastException at the first row. LoadByGuids bound byte[] params
against the TEXT-stored Id and would have returned no rows once the index
had built.
- RebuildFtsIndex reads via GetGuid and stores ToString() in
messages_fts.message_guid.
- LoadByGuids parses incoming UUID strings and binds them as Guid so
Microsoft.Data.Sqlite re-serialises to TEXT, matching the messages.Id
storage form.
- DbViewer caller variable renamed hexIds -> guidHits for clarity.
Retention sweep no longer blocks for ~194ms on Framework.Run().Wait().
The clear+refilter pair is now scheduled on the next framework tick, so
it still runs on the framework thread (keeping the Tabs-list mutation
serialisation invariant -- Plugin.Config.Tabs is plain List<Tab> and
AutoTellTabsService can mutate it from background paths) but does not
block the sweep thread while the framework finishes the current frame.
A new _isDisposing volatile bool is set as the first statement in
DisposeAsync so a deferred tick that fires after teardown bails before
it touches MessageManager / Log / static fields the dispose path has
already cleared. The retention worker is IsBackground=true so plugin
unload can race against a still-pending tick.
The existing RetentionSweepLock / RetentionSweepRunning serialisation
covers the not-two-sweeps-at-once invariant; we don't add a CTS here
because RunOnTick is fire-and-forget and the framework service owns
the tick lifecycle.
v1.4.8 B3. Coverage via in-game smoke (frame-time trace during a
retention sweep run) in Task 9 -- no Build-Suite test because the
suite has no FakeFramework fixture and the change is a schedule-form
swap rather than new behaviour.
When the user edits their active custom theme JSON in an external editor
and saves, the change now propagates to HellionChat within ~1 second
without re-selecting the theme in the picker.
RefreshActiveIfStale runs from Plugin.Draw on every frame but the actual
File.GetLastWriteTimeUtc stat is 1Hz-throttled -- 60fps would otherwise
mean 3600 stats/min, more on Wine. Built-in themes short-circuit on the
IsBuiltIn check; custom themes without a captured source path (Switch
fell to default) short-circuit on the null check.
Switch() now captures the source path of custom themes via an out-param
on LoadCustomBySlug, which now reverse-looks-up against the existing
_customCache (no re-parse, no extra disk IO). Plugin.LoadAsync warms the
cache via AllCustom() once before the first Switch so a Config.Theme
pointing at a custom slug does not fall through to the built-in default
on a cold registry.
Switch's lookup order is now built-in-first to match Get(slug), so a
user-authored JSON that declares a built-in slug is consistently
ignored in both code paths.
Pure-helper ThemeStampDiff isolates the stamp-diff rules for the
Build-Suite (covers DateTime.MinValue hold-the-line semantics).
v1.4.8 B2.
Replace the fixed 22px const Height with a computed property that bakes
in the ImGui font line height plus a GlobalScale-rounded 2px spacer.
The constant clipped the bottom bar on Windows display-scaling >100%
because ImGui rendered the actual font taller than 22px; the bar then
got pushed off the window edge.
ChatLogWindow.cs:423 reservation drops the explicit +2 because the
spacer now lives inside Height. Same idiom as the v1.4.6 F7.2 underline
pill in ChatLogWindow.cs:1639-1653.
v1.4.8 B1. Coverage via in-game smoke on Windows (Jin) and Linux/Wayland
in Task 9 -- DrawList-coupled, no Build-Suite test.
New UseFullTextSearch transient UI bool flips DbViewer.Filter() between
the existing local page filter (default) and the FTS5 MATCH path across
the whole database. ImRaii.Disabled blocks the toggle while the bulk-insert
worker is still building the index; the HelpMarker swaps between two
hints, one for the indexing state and one for the phrase-match advisory
once the index is ready.
Three new HellionStrings entries cover EN + DE + the Designer accessor:
- DbViewer_FullTextToggle (label)
- DbViewer_FullTextToggle_Hint_Indexing (tooltip while indexing)
- DbViewer_FullTextToggle_Hint_PhraseMode (tooltip once ready, warns
multi-word terms match as phrases and how to opt into raw MATCH syntax)
Filter() short-circuits to the local fallback if the toggle is on but
ftsReady has flipped back to false -- defensive against a mid-session
Dispose-and-reopen during indexing.
v1.4.8 H2 Sub-Task 4.4.
Two new public query methods plus an internal EscapeFtsTerm helper:
- FullTextSearch(term, limit) runs MATCH against messages_fts and returns
hex-encoded GUIDs sorted by FTS5 rank. Empty/whitespace short-circuits
to an empty list so callers can fall back to the local page filter.
- LoadByGuids(hexIds) resolves the hex GUIDs back to Message rows via
WHERE Id IN (...). Chunked at 500 to stay below SQLite's 999-parameter
cap, and the BLOB-PK autoindex means the join is O(log n) per id.
- EscapeFtsTerm wraps user input in double-quotes so multi-word queries
match as a phrase, not as per-word AND. Users opt into raw MATCH
syntax by writing their own quotes.
Plus _readLock serialises every Connection-touching internal method
(UpsertMessage, MessageCount, all readers, retention writers, etc.).
The DbViewer filter worker now runs FullTextSearch on a Task.Run thread
while the PendingMessageThread keeps calling UpsertMessage; SqliteConnection
is not safe for concurrent use, so this single lock is the minimal
architecture change that closes the race. The Lazy-Enumerator methods
(StreamForExport, GetDateRange, GetPagedDateRange) hold the lock only
through command-setup + ExecuteReader; v1.4.8 doc-notes the caveat for
the v1.5.x DI cycle to address with a snapshot-to-list or connection pool.
RebuildFtsIndex stays outside the lock -- it owns its own SqliteConnection
via OpenSecondaryConnection.
Adds the worker that fills the messages_fts virtual table after Migrate4.
The bulk-insert runs off the framework thread on its own SqliteConnection
opened via OpenSecondaryConnection -- WAL lets the live UpsertMessage
path on the primary Connection keep flowing, and the worker's writer
lock yields every 500 rows with a 5ms breather so PendingMessageThread
does not hit "database is locked" after DefaultTimeout=5s.
InitFtsReadyCache runs in the ctor and short-circuits to ready=true when
the index is already populated or when the messages table is empty. The
DbViewer (Task 4.4) reads IsFtsIndexBuilt per frame as a single volatile
field read.
Plugin.cs LoadAsync kicks the worker after FilterAllTabsAsync, gated on
IsFtsIndexBuilt and a CancellationTokenSource that DisposeAsync cancels
before MessageManager tears down. Progress reports back via IActiveNotification,
marshalled onto the framework thread via Framework.RunOnTick. Success path
finishes the notification as Success with a 5s linger; cancellation
dismisses it; an error swaps the type to Error with a fallback hint.
Pre-step for the v1.4.8 FTS5 bulk-insert worker. The worker opens its
own secondary SqliteConnection on the same db path so the WAL journal
lets parallel reads/writes through, and it has to apply the exact same
connection-string options and PRAGMAs as Connect() -- otherwise the
worker connection drifts the moment Connect grows a new pragma.
Splitting BuildConnectionString + ApplyPragmas out lets both Connect()
and the upcoming OpenSecondaryConnection() share the same source of
truth instead of duplicating the body. No behaviour change.
Lays down a messages_fts virtual table with message_guid (UNINDEXED, hex
TEXT of the BLOB primary key), sender_text and content_text columns
using the unicode61 tokenizer with diacritic folding. Standalone FTS5
without content='messages' linking, because messages.Id is BLOB and
FTS5's content_rowid contract requires an INTEGER rowid alias.
LoadByGuids (Task 4.3) will resolve the hex GUIDs back to messages rows
via WHERE Id IN (...) joins. Schema step only -- the bulk-insert worker
that fills the index lives in Task 4.2.
Internal Connection property exposure plus a HasMessagesFtsTable helper
let the Build-Suite verify Migrate4 without raw PRAGMA glue in each test.
v1.4.8 H2 Sub-Task 4.1.
Pure deserialisation helper that pulls one row from the current reader
position into a Message. The MessageEnumerator load path delegates to
it, and the upcoming FTS-join LoadByGuids (Task 4.3) will share the
same code so both stay in lockstep when the column layout shifts.
Pre-step for v1.4.8 H2 FTS5 full-text search.
Smoke-test round 4 surfaced a clean reproducer: a Party or Linkshell
tab with channel /p, then Settings → Save, popped the input back to
/tell <pinned-partner> on the next interaction. Two bugs combined:
1. Configuration.UpdateFrom captured only Messages+LastSendUnread from
the live state during the persistent-tab merge. CurrentChannel was
not preserved, so a Settings save overwrote the runtime channel
state with the settings-time snapshot. If the user switched channel
in-game between Settings-open and Settings-save, that switch was
lost. Live CurrentChannel now joins Messages and LastSendUnread in
the per-Identifier preservation tuple.
2. TabSwitched seeded a new tab's CurrentChannel from previousTab via
reference copy (`newTab.CurrentChannel = previousTab.CurrentChannel`).
That left both tabs sharing the same UsedChannel instance, so a
later mutation on one bled into the other — exactly the path that
carried a pinned tell-target onto Party. Switched to a deep clone
(UsedChannel.Clone(), same Cherry-Pick-Patch-B pattern from v1.4.6)
plus a Debug log so the next smoke can confirm at a glance which
previous tab donated its channel state.
Pre-existing ChatTwo upstream pattern; v1.4.7 just made it visible
because pinned tabs are now the kind of long-lived tell-target that
sticks around for the seed path to grab.
Smoke-test round 3 feedback from Jin:
- Sidebar now groups tabs into three sections rendered in this order:
persistent → pinned TempTabs → unpinned TempTabs. Each TempTab
section carries its own divider header ("Angepinnt (n)" / "Aktive
Tells (n)"). Plugin.Config.Tabs order is untouched — only the
display order changes, so tabI still mirrors the real index and
LastTab/WantedTab stay consistent.
- The thumbtack glyph overlay on a pinned tab dropped from accent
colour at full alpha to TextMuted at ~47% alpha. The section header
is now the primary discoverability cue; the glyph is just a per-tab
confirmation hint.
- Sidebar width is now a Config field (default 44, range 44-160).
Slider lives in Theme & Layout under the existing Sidebar-Tab-View
toggle. The icon button inside each row stretches with the width so
a widened sidebar doesn't leave the icon floating in dead space.
Smoke-test round 2 feedback from Jin:
- Promote-to-permanent label "Dauerhaft behalten" was indistinguishable
from Pin in German, leading to misclicks that dropped the tell-target.
Removed the menu entry from TempTabs entirely — Promote stays as a
service method for future use, but the user-facing path is gone. Anyone
who wants a regular tab can still create one via the existing
"neuen Tab anlegen" flow.
- No visual confirmation that pin took effect. Added a FontAwesome
thumbtack overlay top-left of the sidebar icon, accent-coloured, and
appended a "Pinned — survives relog" line to the hover tooltip.
- Pinned tabs came back empty after a full disable/enable cycle because
Tab.Messages is NonSerialized. RehydratePinnedTabs now also runs the
same MessageStore-backed PreloadHistory the spawn path uses, so the
recent conversation window reappears alongside the rehydrated
TellTarget.
Diagnose-logging on TryPin/Unpin/Promote/Rehydrate stays in so the next
smoke can confirm at a glance which path fired from the Dalamud console.
JonKazama-Hellion