First consumer of acdream's plugin automation surface, and the first slice of the VTank-class plugin milestone (docs/research/2026-07-29-vtank-plugin-automation-requirements.md). MossTank shows a panel with a Buff button; clicking it casts every self-buff the character is missing, skips what is already in force at an equal or higher tier, and refreshes what is nearly expired. The host/plugin line is the load-bearing decision here. The host publishes spell DATA -- family, tier, difficulty, mana, duration -- plus a cast primitive with a preflight gate. The plugin owns the POLICY. That is the architectural conclusion the requirements research reached: VTank's engine lived in plugin-land, built on Decal's primitives, and baking "best buff for skill X" into the host would start pulling the engine inward one convenience at a time. Why the plan is driven off the spellbook rather than off trained skills, which is the obvious reading of "buff every trained and specialised skill": the client cannot honestly make that mapping. The link between a spell and the stat it modifies arrives from the SERVER in the enchantment message and is absent from the client's own spell table. What the client does know is which spells the character has learned -- and a character only learns buffs for the skills they use, so the spellbook reaches the same set without inventing a mapping the client has no grounds for. Surface added, all BCL-only so Plugin.Abstractions keeps its zero project references: * ICharacterInfo, ISpellCatalog, IMagicCommands, grouped behind one IAutomationSurface so IPluginHost grows by one member rather than three. * IEvents.Tick. Automation is sequences, not single calls -- a buff pass casts several spells and must wait between them. Without a host tick a plugin would need its own timer thread re-entering the host off its update thread. * NoOpAutomationSurface for hosts with no live session, so a plugin keeps one code path and checks IsAvailable. Markup gained <button> and <label>; it previously supported only <meter>, with a comment promising the rest. Buttons bind onclick to an Action property and FAIL THE PANEL LOAD if it does not resolve -- a silently dead button is worse than a panel that refuses to load, because the user clicks and there is nothing to diagnose. Labels bind through a Func so a status line tracks its binding instead of freezing at build time. Enchantment reads use EnchantmentsInEffectSnapshot rather than the raw active set: retail leaves a weaker same-family enchantment in the registry while a stronger one is in force, and a plugin asking "am I buffed?" means in force. BuffPlan is a pure function of (known buffs, active enchantments) precisely so it can be tested without a session; 9 tests cover tier supersede, the family-0 no-stack bucket that must not be de-duplicated, expiry refresh, and plan stability across the rebuilds the tick loop performs. Solution builds clean; 14,421 tests pass on the standard hermetic lane filter, 0 failures. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
109 lines
4.2 KiB
C#
109 lines
4.2 KiB
C#
using AcDream.Plugin.Abstractions;
|
|
|
|
namespace AcDream.Plugins.MossTank;
|
|
|
|
/// <summary>
|
|
/// Decides which self-buffs are missing and in what order to cast them.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// <para>
|
|
/// Pure function of (known self-buffs, active enchantments). No host calls, no
|
|
/// state, no clock — so the buff policy can be reasoned about and tested
|
|
/// without a live session, which is the whole reason it lives here rather than
|
|
/// in the host.
|
|
/// </para>
|
|
/// <para>
|
|
/// <b>Why the spellbook is the source of truth.</b> The obvious reading of
|
|
/// "buff every trained and specialised skill" is to enumerate skills and map
|
|
/// each to its buff line. The client cannot do that honestly: the link between
|
|
/// a spell and the stat it modifies arrives from the <em>server</em>, in the
|
|
/// enchantment message, and is absent from the client's own spell table. What
|
|
/// the client does know is which spells the character has learned — and a
|
|
/// character only learns the buffs for the skills they actually use. Driving
|
|
/// from the spellbook reaches the same set without inventing a mapping the
|
|
/// client has no grounds for.
|
|
/// </para>
|
|
/// </remarks>
|
|
internal static class BuffPlan
|
|
{
|
|
/// <summary>
|
|
/// The strongest known buff per family that is not already in force at an
|
|
/// equal or higher tier, ordered so the plan is stable between passes.
|
|
/// </summary>
|
|
public static List<PluginSpellInfo> Build(
|
|
IReadOnlyList<PluginSpellInfo> knownSelfBuffs,
|
|
IReadOnlyList<PluginActiveEnchantment> active,
|
|
double refreshWhenUnderSeconds)
|
|
{
|
|
// Best known candidate per family. Family 0 is retail's "does not
|
|
// stack" bucket: those spells share no family identity, so collapsing
|
|
// them would drop all but one unrelated buff.
|
|
var bestByFamily = new Dictionary<uint, PluginSpellInfo>();
|
|
var unstackable = new List<PluginSpellInfo>();
|
|
|
|
foreach (PluginSpellInfo spell in knownSelfBuffs)
|
|
{
|
|
if (spell.Family == 0)
|
|
{
|
|
unstackable.Add(spell);
|
|
continue;
|
|
}
|
|
if (!bestByFamily.TryGetValue(spell.Family, out PluginSpellInfo held)
|
|
|| spell.Tier > held.Tier)
|
|
{
|
|
bestByFamily[spell.Family] = spell;
|
|
}
|
|
}
|
|
|
|
// Strongest in-force tier per family, and how long it has left.
|
|
var activeByFamily = new Dictionary<uint, (int Tier, double Seconds)>();
|
|
var activeSpellSeconds = new Dictionary<uint, double>();
|
|
foreach (PluginActiveEnchantment enchantment in active)
|
|
{
|
|
activeSpellSeconds[enchantment.SpellId] = enchantment.SecondsRemaining;
|
|
if (enchantment.Family == 0)
|
|
continue;
|
|
if (!activeByFamily.TryGetValue(enchantment.Family, out var held)
|
|
|| enchantment.Tier > held.Tier)
|
|
{
|
|
activeByFamily[enchantment.Family] =
|
|
(enchantment.Tier, enchantment.SecondsRemaining);
|
|
}
|
|
}
|
|
|
|
var plan = new List<PluginSpellInfo>();
|
|
|
|
foreach (PluginSpellInfo candidate in bestByFamily.Values)
|
|
{
|
|
if (!activeByFamily.TryGetValue(candidate.Family, out var inForce))
|
|
{
|
|
plan.Add(candidate);
|
|
continue;
|
|
}
|
|
// A weaker enchantment in force is still worth replacing: recasting
|
|
// at a higher tier supersedes it.
|
|
if (candidate.Tier > inForce.Tier
|
|
|| inForce.Seconds < refreshWhenUnderSeconds)
|
|
{
|
|
plan.Add(candidate);
|
|
}
|
|
}
|
|
|
|
foreach (PluginSpellInfo candidate in unstackable)
|
|
{
|
|
if (!activeSpellSeconds.TryGetValue(candidate.SpellId, out double seconds)
|
|
|| seconds < refreshWhenUnderSeconds)
|
|
{
|
|
plan.Add(candidate);
|
|
}
|
|
}
|
|
|
|
// Cheapest first: if mana runs out mid-pass, more buffs landed than if
|
|
// the expensive ones had gone first.
|
|
plan.Sort(static (a, b) =>
|
|
a.ManaCost != b.ManaCost
|
|
? a.ManaCost.CompareTo(b.ManaCost)
|
|
: a.SpellId.CompareTo(b.SpellId));
|
|
return plan;
|
|
}
|
|
}
|