The hotbar problem, solved once, for every kind of thing a player can put on a key.

No, and that's deliberate. CrimsonActionBar is the data, input and state layer; you build slot widgets on whatever UI framework you already use and bind them to the component's delegates. How-To: Bind a Slot Widget walks a complete widget (icon, keybind, cooldown sweep, count badge, gray-out, click, drag-out, drop-in) in both Blueprint and C++. CrimsonCore (free to download, compiles only with all Crimson plugins installed) shows a finished HUD built on it, whose slot widget you can subclass if you want the plumbing but not the look.

Only for ability slots. The shipped Gameplay Abilities provider drives a UAbilitySystemComponent, so ability slots need GAS. Bars, pages, the store, the object provider and the sequence provider all work without it: a consumables strip or a macro bar needs no ability system at all. On a stock ASC, ability slots activate by gameplay event or TryActivateAbility, and the engine's CheckCost grays out what the player cannot afford. With CrimsonAbilitySystem and CrimsonCore, slots also get icons from display data, Tap/Hold/Toggle routing, charges and a modeled global cooldown.

No. Both components are addable in Blueprint, the layout is a data asset, and the delegates, edit calls, snapshot reads and provider helpers are Blueprint-callable. You can even write a provider as a Blueprint subclass. C++ comes in for the optional extras: the provider adapters (Tap/Hold/Toggle routing, charges, item use), the static FCrimsonActionBarIntegrationHooks that place bar widgets and customize keybind text, and making a controller a ModularGameplay receiver for the game feature action. A Blueprint-only project sets the layout on the component and puts the bar widgets in its own HUD.

Layouts are server-authoritative and replicate owner-only, per layout, as deltas. Client writes are requests the server validates. Snapshots, polling and input run on the owning client only, so another player's bars are inert proxies. Execution goes through the provider's own path, and abilities keep normal GAS prediction. One gotcha the docs are explicit about: automatic pages read replicated owner tags, so grant a stance tag with a gameplay effect, because a plain loose tag flips the page on the server only. The wiki's Concept: Multiplayer lists what was verified on a dedicated server with two clients, including persistence across a full restart.

No. It builds and runs standalone with only engine plugins, and it owns the slot binding store, the providers and the bridge interfaces. Implement ICrimsonSlotBindingPresentable on your abilities and items and ICrimsonSlotBindingObjectResolver on your container, and subclass the provider adapters for your ability system, and slots light up with real names, icons, charges, costs, stock counts and Tap/Hold/Toggle semantics. Implement none and it falls back to stock GAS and stock Enhanced Input, and shows less. CrimsonCore, the free full-suite integration layer (it requires every Crimson plugin), wires all of this automatically for CrimsonAbilitySystem, CrimsonInventory, CrimsonInput chord keybinds and CrimsonUI extension points. Owning another Crimson plugin without CrimsonCore connects nothing by itself.

Yes. The store owns the bindings, not the bar, so any view pointed at the same LayoutId reads the same bindings. The drop path is not bar-specific either: give your drag operation one FCrimsonSlotBinding field and the same slot widget accepts drops from a picker or a spellbook. CrimsonUI's radial wheel keeps its own bindings; with CrimsonCore it can offer this plugin's providers as wheel entries.