"Splits" window for tracking different goals for speed runners.

[jdm080]

A ways to go, but wanted to see if this is even something that might be wanted.

Adds a new built-in ToolboxWindow for tracking different speedrun's and their splits in Guild Wars. Features include:

• Split timer with real time and game time tracking
• Goal-based triggers: mission complete/bonus, map enter/exit, vanquish complete, reach level, reach title rank, manual
• Hard mode flag on mission/bonus triggers
• Batch goal pickers for missions, explorables, towns, and titles
• Personal best comparison (real or game time basis)
• Per-character run history saved to JSON
• Crash-protection resume on toolbox restart
• Configurable hotkeys for start, reset, and manual split
• Settings panel integrated into the standard Toolbox settings UI

[3vcloud]

@claude between this and the existing objective timer module, how would you approach having a single source of truth for tracking objectives in game without impacting the look and feel of the existing objective timer in toolbox? Could we enhance this version with what's missing to be a replacement of the existing module? We also already have a feature to host a websocket to host live splits, could this easily be integrated?

I'm conscious of how much code this module would add, and would like to merge functionality related to objective tracking

[claude]

Claude finished @3vcloud's task in 2m 7s —— View job

---

Analysis: Merging Splits with Objective Timer

• Read CLAUDE.md for repo guidelines
• Review the new Splits window code
• Review the existing Objective Timer module
• Review the existing live splits / websocket feature
• Analyze overlap and gaps between the modules
• Provide architectural recommendations

---

Where the two modules currently overlap

Both windows independently register their own GW event hooks for essentially the same underlying game events:

Concern	ObjectiveTimerWindow	SplitsWindow
Mission complete	StoC::MessageServer (pattern matching)	UI::kMissionComplete callback
Mission bonus	StoC::MessageServer	UI::kObjectiveComplete callback
Map transition	StoC::GameSrvTransfer + InstanceLoadInfo + InstanceTimer	polled each frame via GW::Map::GetMapID() diff
Vanquish	(none — ObjectiveTimer doesn't track this)	polled via GetFoesToKill()
Party defeated	StoC::PartyDefeated	(none — SplitsWindow never stops mid-run)

There are also 9 additional StoC hooks in ObjectiveTimer (DoorOpen, DoorClose, ServerMessage, DisplayDialogue, ObjectiveUpdateName, ObjectiveDone, AgentUpdateAllegiance, DoACompleteZone, DungeonReward) that SplitsWindow has no equivalent for — these are what drive the fine-grained FoW/UW/Deep/Urgoz/DoA tracking.

---

What's missing from SplitsWindow to be a full replacement

1. The rich sub-objective event system

GoalTrigger::Type covers course-grained triggers (MissionComplete, MapEnter, VanquishComplete, etc.) but not the fine-grained packet events (DoorOpen for specific door IDs, ServerMessage pattern matching, DisplayDialogue matching, AgentUpdateAllegiance) that are needed to replicate the per-room FoW/UW/Deep/Urgoz/DoA tracking. Without these, SplitsWindow can't express "Room 3 of Urgoz" or "Dhuum starts" as a goal trigger.

2. WebSocket / LiveSplit server

ObjectiveTimerWindow hosts a uWS::App server (GW Toolbox = server, LiveSplit = client). It sends "reset", "start", and "split" commands via the "objective_events" topic. SplitsWindow has zero websocket integration. Note: the existing ThreadedWebSocket utility is an outbound client — it's a different thing and isn't directly reusable here; the server pattern from ObjectiveTimer is what's needed.

3. Historical multi-run display

ObjectiveTimer renders all runs from the current day as collapsible headers with Start/End/Time columns for each individual objective. SplitsWindow only shows the live run against the personal best. The use cases are subtly different: ObjectiveTimer = "how did each objective compare across today's runs"; SplitsWindow = "am I on PB pace right now?"

4. Hierarchical objectives

ObjectiveTimer has parent/child indented objectives (e.g., DoA rooms inside a Foundry parent). SplitsWindow is a flat list. This is important for displaying sub-steps without counting each as a full split.

5. Auto /age on completion

Minor, but SplitsWindow has no equivalent to auto_send_age.

---

Recommended architecture: shared event bus

The cleanest path to a single source of truth without touching the Objectives window's UI is a dedicated ObjectiveEventDispatcher module that:

• Owns all the StoC and UI packet registrations currently duplicated across the two windows
• Exposes a typed subscription API so both windows listen to the same events
• Is a passive Toolbox module (no window, no settings pane)

Both ObjectiveTimerWindow and GoalEngine subscribe to the dispatcher rather than directly registering their own hooks. ObjectiveTimerWindow's look and feel is completely unchanged — it just receives events from a different source.

For GoalEngine to gain access to the richer event types (doors, server messages, etc.), GoalTrigger::Type would gain new variants corresponding to the ObjectiveTimerWindow::EventType cases that make sense for user-defined splits. The batch pickers in SplitsGoalListWindow would expose UI for configuring these.

---

WebSocket integration path

The websocket server logic in ObjectiveTimerWindow.cpp (lines ~181–253) is self-contained but embedded in an anonymous namespace. Extracting it into a small LiveSplitServer class (similar to how ThreadedWebSocket wraps the client) would let both windows call LiveSplitServer::Instance().Send("split"):

// New shared class (sketch)
class LiveSplitServer {
public:
    static LiveSplitServer& Instance();
    void Enable(int port, WebsocketMode mode);
    void Disable();
    void Send(std::string_view command); // "start" / "split" / "reset"
};

SplitsWindow would call Send("split") each time a goal fires (already happening in GoalEngine::FireGoal), and Send("reset") / Send("start") from StartRun() / ResetRun(). The settings checkbox currently in ObjectiveTimerWindow::DrawSettingsInternal would move to LiveSplitServer's own settings, or be duplicated in both windows.

---

What's practical to add now vs. long-term

Now (low effort, high value):

• Integrate the websocket server — extract EnableWebsocketServer / WebsocketSendMessage into a shared helper and wire it into GoalEngine::FireGoal and SplitsWindow::StartRun / ResetRun
• Add auto /age on run completion (1 line: call GW::Chat::SendChat('/', "age") in SaveCompletedRun)

Medium term:

• Extract ObjectiveEventDispatcher to eliminate the duplicate StoC registrations
• Expand GoalTrigger::Type with DoorOpen(id), ServerMessage(pattern), ObjectiveDone(id) so users can build FoW/UW splits manually

Long term (full replacement of ObjectiveTimer):

• Add preset goal lists for FoW, UW, Deep, Urgoz, DoA (essentially porting the AddFoWObjectiveSet etc. logic into JSON preset files)
• Add a hierarchical/nested display mode to SplitsGoalListWindow
• Add a "past runs" view alongside the live split view

The existing Objectives window and its data format don't need to change at all until you're confident the Splits window covers all its use cases — at which point it becomes a [Deprecated] toggle in settings.

---

Summary: The WebSocket integration is the most practical immediate addition and is straightforward to wire in. A proper single source of truth requires extracting an event bus module that both windows subscribe to, plus expanding GoalTrigger::Type to support the fine-grained events ObjectiveTimer relies on. Full replacement is feasible but would be a multi-stage effort; the two windows can coexist without redundancy once the event bus is in place.

[jdm080]

So as an overall direction, more integration with the current objective timer (full collapse into or via a shared bus). Webserver integration also.

[3vcloud]

So as an overall direction, more integration with the current objective timer (full collapse into or via a shared bus). Webserver integration also.

Yeh looks like it's a close fit to replace the objective timer to be honest, so with a few more tweaks I wouldn't have a problem using this instead