Multi-step navigation (Welcome → Privacy → Power Settings → Done)
with a nested WizardState holding nullable Pending* fields. Profile
picker becomes a 2x2 grid covering all four privacy profiles
(PrivacyFirst, Casual ★ recommended, Roleplay new, FullHistory).
Power-settings step surfaces six previously-hidden Configuration
fields (LoadPreviousSession, FilterIncludePreviousSessions,
AutoTellTabsHistoryPreload, UseCompactDensity, PrettierTimestamps,
Theme) without introducing new ones. ApplyRoleplay mirrors the
existing Apply* methods, CommitPending writes only the non-null
fields back so skipping a step preserves existing config. OnClose
docstring updated to reflect the actual code path (both Decide-Later
and Finish set FirstRunCompleted = true, the wizard does not reopen).
Thirty-two new bilingual resource keys covering all four wizard
steps: titles, section headings, control labels, navigation, the
new Roleplay profile, the staged-summary template strings, the
'Decide later' multi-step skip label plus its dedicated tooltip.
Existing Wizard_Cancel_Label and Wizard_Cancel_Tooltip stay
untouched for legacy reopen paths.
Adds RoleplayWhitelist (PrivacyFirst + Say + both emote types) and
RoleplayRetentionOverrides (Say 30d, emotes 90d). Shout/Yell and
Novice Network stay out — public-distance noise from strangers
is not story content. Whitelist + overrides are IReadOnlySet /
IReadOnlyDictionary with pure-helper type footprint, so the Build
Suite can pin them without touching Dalamud.
- csproj <Version> 1.5.0 to 1.5.1; <None Include="images\**"> now
excludes the source-only ASCII study folder so the deploy stays
clean
- yaml + repo.json changelog block prepended with the v1.5.1 entry,
v1.4.8 trimmed out per the slim rule (three to four versions in
the manifest cache, older history lives on the Gitea release page)
- repo.json AssemblyVersion + TestingAssemblyVersion bumped to
1.5.1.0, three DownloadLink* URLs point at v1.5.1
- docs/CHANGELOG and docs/ROADMAP gain the v1.5.1 entry; ROADMAP
Next-Cycle slot moves to v1.5.2 First-Run-Wizard rework
- README status sections updated, the previous v1.5.0 paragraph
kept under a "Project status (pre-v1.5.1, kept for context)"
heading
- Forge-post .github/forge-posts/v1.5.1.md added, DE body honest
about the HITCH-win miss
- yamllint config ignores the plugin manifest yaml because it
follows DalamudPackager's 4-space indent convention rather than
yamllint's default 2
Changelogs are honest about the cross-plugin HITCH target from
v1.5.0 not landing this cycle.
Move the four leftover ASCII variants from the repo root into
HellionChat/images/ascii/ and add a README that explains which two
files are embedded in the plugin DLL versus which ones stay as study
material. The original paw file was split into a stipple version and
an outline version because the two paws were stacked in one source.
Attribution:
- fox-*.txt files are by Julia Moon, drawn for Hellion Chat, free to
use without attribution
- wolf-head-blazejkozlowski.txt is by Blazej Kozlowski, originally
published on asciiart.eu, kept as a style reference
Pulls the four-line fox-mini ASCII out of the embedded branding
resources and writes each line through IPluginLog before the existing
bootstrap line, so an /xllog reader sees the Hellion Forge mark on
every plugin load. The text provenance ("by Julia Moon - Hellion
Forge") follows the silhouette, then the version + fingerprint line
stays where it was.
Empty lines from the resource are skipped so the log stays compact.
Ship two ASCII variants as embedded resources under HellionChat.Branding:
- fox-banner.txt — full silhouette with "Hellion Forge" set inside the
body, rendered in the first-run wizard and the Settings Information
tab as a folded "about the makers" anchor
- fox-mini.txt — compact fox-head + curly-tail used by the DI-logger
bootstrap banner
A small HellionForgeAscii helper lazy-loads both strings; the wizard
and information-tab render them in a collapsed TreeNode using the
UiBuilder MonoFontHandle so the stipple-art lands pixel-aligned.
Both art files are self-made (Julia Moon, free to use) and travel with
the plugin DLL so a partial deploy can't lose them.
Two new self-test steps for the hybrid FontManager:
- FontManagerCtorSmokeStep proves all five handles land on the manager
after Phase-1 resolve (ItalicFont nullable per Config.ItalicEnabled)
and that no atlas-load exception is sitting on any of them
- FontPushSmokeStep proves IFontHandle.Push() returns without throwing
for the two main delegate handles right after plugin load
Both steps run on the framework thread via the xlperf self-test path
and are registered alongside the existing theme-switch step in
SelfTestRegistry.
Pull in the refreshed linter and tooling configs (editorconfig,
gitignore, gitattributes, prettierignore, prettierrc, markdownlint,
yamllint, env.example, dotnet-tools) and run prettier and markdownlint
in --fix / --write mode across the repo so the existing tree matches
the new rules.
- prettier 2-space indent on yaml/yml and json overrides, asterisk
strong, underscore emphasis, proseWrap always
- markdownlint MD007 indent aligned to 2 and MD049 to underscore so
prettier output stays passing
- preflight Block F also ignores CLAUDE.md (gitignored personal file)
- prettierignore extended to keep HellionChat.yaml manifest and the
NuGet packages.lock.json out of the formatter
No semantic content changed; csharpier, build, full build-suite
(729/729) and the new prettier/markdownlint/yamllint checks all green.
Drop the custom NewDelegateFontHandle that built our own FontAwesome
atlas slot and reuse Dalamud's UiBuilder.IconFontFixedWidthHandle
instead. One less delegate-build step in the ctor, and the handle is
host-managed so Dispose() leaves it alone.
The pre-cycle icon inventory verified that every site we push the
FontAwesome font for renders an icon that is present in the host's
fixed-width handle glyph range, so no rendering site changes.
Move font handle creation from BuildFonts() into the FontManager ctor
inside a single atlas.SuppressAutoRebuild() block. Axis, AxisItalic and
FontAwesome become init-only IFontHandle properties; RegularFont and
ItalicFont stay mutable so the live font-settings rebuild path keeps
working without a plugin reload.
- BuildFonts() renamed to RebuildDelegateFonts(), scope reduced to the
delegate fonts only
- BuildFontsAsync() removed; Task.Run had no purpose with ctor-init
- FontManagerInitHostedService deleted; PluginHostFactory drops the
matching AddHostedService registration
- PluginHostFactory FontManager registration takes IDalamudPluginInterface
via factory lambda
- Settings save path now calls RebuildDelegateFonts() instead of
BuildFonts()
- Plugin.Draw push site gets a null-forgiving for the nullable
RegularFont with a one-line WHY
Version strings bumped across all eight tracked surfaces:
- HellionChat/HellionChat.csproj <Version>1.5.0</Version>
- repo.json AssemblyVersion + TestingAssemblyVersion = 1.5.0.0
- repo.json three DownloadLink* URLs -> /v1.5.0/latest.zip
- repo.json Changelog field synced with yaml
- HellionChat/HellionChat.yaml new v1.5.0 changelog block on top; v1.4.7
drops out per the four-block slim rule
- docs/CHANGELOG.md v1.5.0 entry prepended
- docs/ROADMAP.md Next Cycle pointer moves to v1.5.1, v1.5.0
joins the released-cycle archive block
- README.md three status surfaces (badge, header,
Project Status long-form) on v1.5.0
- .github/forge-posts/v1.5.0.md Discord announcement body (German)
Preflight blocks A-F all green. Changelog embed total 2050 / 5500 chars
(four subblocks), forge-post frontmatter inside the 60/40 char caps.
Tag, push, merge are reserved for Flo.
Code comments were drifting into plan-internal shorthand (DI-2a,
Slice B, "see plan §9") that nobody outside the cycle authors can
decode. They also tended toward AI-generated paragraph blocks where a
two-line WHY would have done.
This commit tightens the comment surface from the v1.5.0 work:
- IPluginLogProxy header lists the consumer buckets without naming
the cycle items that decided them.
- DalamudLogger / DalamudLoggingProvider provenance markers explain
themselves in two lines each; the long EUPL-rationale paragraph
moves to the commit message.
- PluginHostFactory block headers shrink to one line each, ASCII
dividers come out, plan-internal codes go.
- Plugin.cs field doc and Phase-1 / DisposeAsync comments lose the
cycle-name references; the file gains nothing from "C3 surfaced X"
in code.
- FontManager / GameFunctions static-method notes shrink to one
sentence each.
- InitHostedServices class header keeps the eager-resolve WHY in
three lines, drops the constraint label.
Csharpier reformatted the .csproj layout (long PackageReference
multi-lined). No functional change, no behavior change.
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.
JonKazama-Hellion