Changing things

"I want to change…" → do this

A label, or a translation

tablet.ts

Which buttons exist

tablet.ts (the BUTTONS table) + one <pk-button id> in index.html

An icon

drop a file in public/icons/ and point ICONS at it

Colours, sizes, the whole look

CSS custom properties — --pk-accent, --pk-radius, --pk-control-min-height, … See Using the library directly in README.md

The layout

app.css and index.html; the components do not care where they sit

Which languages are offered

AvailableLocales on the PromethistLink component, in Unreal

What a command does

your project’s Blueprint, on On Tablet Command

The look while out of service

On Blackout Changed, in your project

What the tablet asks the visitor

prompts.ts

How sharp the streamed picture is

EncoderMaxQuality in Config/DefaultGame.ini — see Picture quality

Everything (own framework, own markup)

import { KioskClient } from '@promethist/kiosk-tablet/core' and draw whatever you like — it pulls in no UI framework

Wiring your own command

One event in, and a handful of functions out. All are on PromethistLink; a graph never touches the subsystem owning the socket.

The name your handler matches What runs on the True branch

"myAction"

Do the thing, and stop. Nothing goes back to the tablet — the button was a one-shot.

"myToggle"

Do the thing, then Set Tablet State Bool ("myToggle", bNowOn). A switch has to be told where it ended up, or it springs back to where it was.
Blueprint graph where On Tablet Command’s Command pin feeds a string equality test against houseLights
Figure 1. The same shape in a graph, for a command named houseLights: compare the incoming name, and publish the key back on a match. Your own work goes on that same True branch.

This comparison matters: On Tablet Command fires for every command, so a handler skipping the name check also runs on pause and volume.

Two rules are the whole model:

  • A flip button needs its state key published on BeginPlay as well. A tablet cannot know which way an unpublished toggle will move, so it keeps the button disabled rather than guessing. A graph publishing the key only upon a press therefore ships a control that can never be pressed. Nothing logs this.

  • On Tablet Command fires for every command, including those the plugin answered itself, letting you react to pause or volume without owning them.

Optionally, telling the tablet your command exists

Register Tablet Command declares a command within the handshake the kiosk sends every connecting tablet: its name, what kind of value it carries, and the state key confirming it landed.

Blueprint graph showing Register Tablet Command and Set Tablet State Bool
Figure 2. Registering a command and publishing its key with a starting value

This is discoverability, not permission. An unregistered command dispatches exactly the same, so nothing breaks if you skip it. Registration simply lets a tablet — or somebody writing their own — see what the kiosk accepts without reading your source. Practically, it catches buttons sending unhandled names while building, rather than on site.

Two things to know if you write a client against the handshake:

  • A command list that is absent is not an empty one. Absence means the kiosk does not say, not that it accepts nothing.

  • Do not assume a command is named after the state key it affects. Several of ours deliberately differ, which is why registration names the reflected key separately.

Publish the key on BeginPlay regardless of registration, for the reason in the first rule above.