Ship menus and HUDs on a complete CommonUI foundation. The boot assets are already built.

Not anymore. The plugin ships a working reference implementation: a pre-assigned UI policy and root layout, a fully wired HUD layout with escape menu and controller-disconnect screen, confirmation dialogs, all three context-menu presentations, a complete radial wheel and a player-editable one with its binding picker, button bases with CommonUI styles, tab lists, a bound-action bar, perf-stat blocks, a layered pool bar, slider materials, and preset CommonUI input data. Use them as-is to get running, then duplicate or subclass to make them yours.

No. The whole Quick Start, and every task page after it, has a Blueprint path. The policy, layouts, widget bases, dialogs, context menus, ViewModels, indicators, radial wheels and touch widgets are all subclassable in Blueprint, and the shipped assets are Blueprints you can open and study. A short list of accessors is C++-only (the UI manager's root-layout lookup, GetPrimaryGameLayout, the messaging subsystem's direct calls, the context-menu confirm interceptor), and the everyday paths have Blueprint equivalents: the push API on UCrimsonUIExtensions, the async push and confirmation nodes, and the Project Settings panel. For a Blueprint project, ticking the plugin in Edit → Plugins is the entire install.

No. CrimsonUI builds and runs on its own with only engine plugins: CommonUI / CommonInput, UMG, Enhanced Input, ModelViewViewModel (MVVM), GameFeatures, ModularGameplay, and GameplayAbilities (for ASC tag reads). Cross-plugin extras come from CrimsonCore, the free integration layer from the Crimson Discord: chord modifier glyphs from CrimsonInput, ability and item wheel entries from CrimsonActionBar, wheel saving through CrimsonSaveSystem, and inventory and interaction context actions. Standalone, each has a public hook you can bind yourself.

Yes. CrimsonUI is free, so any project can start from a working CommonUI stack at no cost.

A few settings and one push: the Crimson viewport client class; the shipped CommonUI input data plus an input mapping context for its Click and Back actions; any layer tags beyond the native UI.Layer.* set; and the HUD push itself, from your PlayerController, GameMode or your own GameFeature action. The policy, root layout, dialogs and context menus are pre-assigned in Crimson UI settings, and your existing game instance and local player classes stay as they are. The plugin ships an asset for every piece; the work is pointing at them, not building them.

Yes. The Touch widgets, UCrimsonJoystickWidget and UCrimsonTouchRegion, inject synthetic Enhanced Input values through the standard injection API, so a virtual stick or button fires the same UInputAction your gamepad and keyboard do. Your gameplay code doesn't need to know touch exists, and nothing about the injection replicates; the server sees the resulting movement and abilities through the normal channels.