Ink Page Interactor

Ink Page Interactor (UInkPageInteractorComponent) is the demo “look at a page, press a key, read it” interaction. It line-traces from the player’s view for an actor carrying an Ink Page Display component, raises a focus event you can drive a “Press E to read” prompt from, and drives an Ink Page Reader to snap the page into view.

​

What one component gets you

Add Ink Page Interactor to your player pawn from the Add Component menu (category Inkwell). At Begin Play it assembles a complete setup:

• A reader. It looks for an Ink Page Reader on the same actor and reuses it if there is one, so any reader settings you tuned are respected. If there is none it creates one, named InkPageReader, and notes it in a verbose LogInkwell message. Get Reader returns whichever one it is driving, so you can change the fit properties or the input locks at runtime.
• Focus tracing. Every Focus Check Interval seconds it traces from the player’s view and tracks which page display, if any, is under the crosshair.
• Default keys. With Enable Default Input on, it binds a small set of keys on the owning pawn so the whole loop works with nothing wired. The keys themselves are editable properties.

The component is spawnable but not Blueprintable: add it to an actor, do not subclass it. Everything it does is available as Blueprint functions instead. The showroom’s demo character (AInkwellReaderCharacter) carries one, which is why the showroom reads with no setup.

​

The focus line trace

The trace starts at the player’s view point — the possessing controller’s view point when the owner is a pawn (the same resolution the reader uses), or the actor’s eyes otherwise — and runs along the view direction for Interaction Distance centimeters.

• It is a single line trace by channel on Trace Channel, against simple collision, ignoring the owning actor.
• Whatever actor the first blocking hit returns is asked for an Ink Page Display component. A wall between the player and the page means no focus.
• A display whose Can Be Picked Up is off is scenery — the showroom’s wall poster, a shop sign. It renders normally, but for focus purposes the trace hit nothing: no prompt, and Interact never sees it.
• On Focus Changed broadcasts once per transition, not once per trace. A focused page that is destroyed counts as a focus loss, so listeners still get their “prompt off” broadcast with a null page.
• While a page is being read there is no world focus: it is cleared the instant reading starts, so the prompt hides immediately, and tracing pauses until the page is put back.

​

Debugging the trace

Turn on Draw Debug Trace to see every focus trace: the line is green when it lands on a readable page and red otherwise, with a small ring laid flat against the surface at the impact point. Each line lives one focus interval plus a little slack, so it never flickers out between traces. Debug drawing has no effect in Shipping or Test builds.

​

Properties

All properties live under Inkwell → Interaction, are editable per instance, and are readable and writable from Blueprint.

​

Default key bindings

With Enable Default Input on, these bindings land on the owning pawn’s input component: The mouse-wheel bindings are always added alongside the two page keys; they are not separately configurable. Flipping a page over is not this component’s key: the reader binds its own Flip Key (default F) under its separate Bind Flip Key toggle, because flipping is a reader operation — see Ink Page Reader. How the bindings behave:

• They are plain key bindings, which still fire under Enhanced Input’s player input — no input actions or mapping contexts required to try the plugin.
• None of them consume input, so movement, look and your own bindings on the same keys pass through untouched.
• A pawn usually gets its input component after this component’s Begin Play, so the interactor retries the binding from its tick until the pawn has one. The keys are bound at most once.

​

Moving to your own input

Turn Enable Default Input off the moment you bind your own — otherwise both fire. Then call the functions below from your own input events. The plugin ships example Enhanced Input assets for exactly this, under /Inkwell/Examples/Input/: IMC_InkwellDefault in the same folder is a ready-made mapping context binding them to E, Q, Right/wheel up and Left/wheel down. Add it (or your own context) to your character, bind the actions in the Event Graph, and route each to the matching function.

​

Events

Drive your prompt from it: show the prompt when New Focus is valid, hide it when it is null. That single event is all a reticle prompt needs. The bundled prompt widget /Inkwell/Examples/UI/WBP_InkwellReadPrompt — demo-only, like this component — is a working example. It is parented to the C++ base UInkwellReadPromptBase, which finds the interactor and reader on the owning player pawn and composes its prompt line from what the page actually is: E : Read while a page is focused, then while one is up a line built per page — multipage documents get “Turn page” and a page counter, a single sheet with an authored back gets “Flip over” (or “Flip back”), and a plain single sheet gets no turning prompt at all. An Inkwell Exhibit component on the page’s actor can override the line per exhibit. Create it and add it to the viewport from your HUD or character; it needs no configuration, but it does assume the default keys.

​

Blueprint API

​

Relationship to the reader

The interactor does none of the snap-into-view work. Everything you can see and feel — the float-up blend, the fit-to-view framing, the flip, Follow Camera, the movement and look locks, the physics and collision capture — belongs to the Ink Page Reader and is configured there. That split is what makes leaving the demo component cheap. To move off it:

​

Next