[Titanic] Feature Request: Additions to Details View (specifically for debugging)

[mischlern]

For consideration. If there's anything I personally really want, it would be the first one: the ability to use the multiple terms in the state filter input. The rest seem like good ideas worth sharing, but please focus on what would be most helpful for your processes.

---

Multiple Searches / Filters on State Menu

For example, being able to type something like hrs|min|sec or hrs,min,sec into the search bar filter down and track multiple variables at once, in this case any that match either term. I'm thinking of #126 and #127 where it would have been nice to see all of the timer variables and see what actions affected the timer and how.

---

Have key key variables be fixed at the top of the state section

Specifically, remove #dbgSpine from the section's scroll so these variables are always visible. For issues like #89, I wanted to watch the props and the main states, but couldn't simultaneously.

---

Allow filter to also consider the state variable's type: prop and actor

Again, thinking of #89, where I wanted to filter down to all the props to watch them with the main states. However, if I currently filter by "prop", I get something like the following:

saveprops: 000001
saveprops1: 000000010
saveprops2: 11111101100111110

Rather than the desired:

prop bag: frank
prop door: notvis
prop invenhelp: notvis
prop light: on
prop map: frank
prop navtoggle: on
prop realneck: vlad
etc.

---

Player Inputs on Screen

An option to display game key inputs on screen. For keyboard, focus on what affects gameplay: left, forward, right, back (smokestack), spacebar (door open), and ESC. For mouse, some visual indication of a click action. Thinking of debug testing, recording videos, and wanting to make it clear to the developer what inputs are being done, like "ESC" for #171 or differentiating between tap and holding forward in the smokestack on #88.

Ideally this is a toggle option, like the state menu is. Here's a rough mockup of a small but readable input reader. Rings or some similar quick effect around the mouse pointer when it clicks on screen. Small, high contrast indicators over the HUD on the bottom side for clear visibility.

(Given what I've seen in the comments and pull requests, it seems like the tools involved may be able to read video pixels as data. If so, it could potentially use this data, assuming it can interpret it correctly.)

---

Input / Movement Log

I'm not sure this one is possible, but I'm imagining something like this:

...
[Forward] → deckbd2.set — Scene35 / View105
[Right] →  deckbd2.set — Scene35 / View106
[Right] →  deckbd2.set — Scene35 / View102
[Space] hotspot "door" → deckbd2.set — Scene35 / View102
[Forward] → wireless.set — Scene10 / View14
[Click] hotspot "wireless" → wireless.stg — wireless 1
[Click] region "tapper" → wireless.stg — wireless 3
[Click] region "ok" → wireless.stg — wireless 1
[Click] region "ok" → wireless.stg — Scene10 / View14
[Left] → wireless.set — Scene10 / View12
[Left] → wireless.set — Scene10 / View13
[Space] hotspot "door" → wireless.set — Scene10 / View13
[Forward] → deckbd2.set — Scene35 / View103
...

I've seen a few notes like this in the details log, specifically around clicks in movie files. Perhaps it can be generalized to include all inputs that result in an action (move, turn, click) and what the primary result it (new set, scene, view, flat, etc.) I could see this being integrated into the details log, to help reports potentially identify clear cause and effect between player input and errors. Alternatively, the input log could be in its own section (togglable like state), with both logs sharing a timestamp to help track event correlation/causation. (If a timestamp, perhaps counting from the start of the session as [hh:mm:ss.ms].)

[dhobi]

Four of the five are in taoot-v0.9.65 (#370). Leaving this open for the fifth — see the bottom.

Multiple terms in the state filter. hrs|min|sec and hrs,min,sec are the same three; both separators, since neither can occur in a variable name. Any-of, because a name cannot contain two of them. A trailing separator is treated as somebody mid-typing rather than as "match everything", and | on its own is no filter at all.

The spine is pinned out of the scroll — and the filter box with it, since scrolling away from the box you are typing in is the same complaint. The section is now a column with the scrollport inside it rather than a scrollport with everything in it, so the props and the main states really can be watched at once.

The filter considers the type. It matches the label a row will carry, so prop answers with the props. Your example was exactly right about what it used to answer with: saveprops, saveprops1 and saveprops2 are the three globals that encode the props, which is the last thing somebody looking for the props wants. actor likewise, and prop bag still means that one prop — a space stays inside a term. The owned props and actors now join the list under a filter as well as under all, by the rule the unmoved globals already followed: you have named what you want.

Input / movement log. It was possible, and it is on the inputs box beside state:

[+01:14.8] [Space]         hotspot "door" → deckbd2.set — Scene35 / View102
[+01:15.9] [Forward]       → wireless.set — Scene10 / View14
[+01:18.2] [Click 214,180] region "ok" → wireless — wireless 1
[+01:20.0] [Esc]           — nothing changed

In the details log rather than in a section of its own, which is the half of your suggestion I went with: the question is cause and effect, and in one stream the answer is the order — nothing has to be correlated by timestamp. It also means ⧉ Copy details and the Report bug button carry the trail already, so a reporter does not have to know they should attach it, and ?debug=1 turns it on along with the state list. The timestamp is there for the other direction: a video lined up against the log, counted from the start of the session as you suggested.

What it hits comes from the engine's own hit test, in the same priority order a click takes, so hotspot / region / actor / prop are the game's own answer rather than a second guess at it. Keys the page keeps (M, O, X, brightness) are not logged: what is logged is what the game was given.

The lines worth having are the ones where nothing happened. A press thrown away in the fade gap says DROPPED — the engine was not accepting; one filed behind a camera move says queued; and since you cited #171 — ESC at the ownership question now reads:

[+00:00.9] [Esc]           skipped the film · the Nightdive intro
[+00:02.4] [Esc]           IGNORED — the film carries no skip flag · the Nightdive intro

Not left in: Player Inputs on Screen. The speedrun workbench already has that display (the key panel beside the picture), so a second one on the play page was deliberately skipped for now — this issue stays open for it.

Two honest limits on the log. It records a gesture's primary result — where the game stood once the dispatch was answered — not a full chain of consequences; and a gesture the game is still working on after 200 ms gets its cause line at once and its result on a second line, because a press at a two-minute film must not have its line land after the film's.