Diablo grid, Skyrim weight, MMO slots. One replicated component.

No. For a Blueprint project, ticking the plugin in Edit → Plugins is the entire install; there is no .uproject or .Build.cs to edit. Layouts, item definitions, fragments, constraints and capacity values are all authored in the editor, and custom rules are a Blueprint child of UCrimsonInventoryConstraint overriding CanAcceptItem. Two things are C++-only today: a brand-new layout topology, and the personal-container accessors on the routing component (per-player containers call those for you). One trap worth knowing: a Blueprint constraint's rule variables are not replicated unless you tick Replicated on each one, and without that the client's placement preview disagrees with the server.

Yes: it is fully replicated by design. Entries live in a FastArray keyed by a stable EntryId that survives reorders and sorting; item instances, state fragments, constraints and currency handlers are all registered replicated subobjects; capacity tags replicate as their own fast arrays; and every mutator on the manager is authority-only. The routing component provides the client-to-server path, so you never write inventory RPCs. And because a failed request changes no state and would replicate nothing, the server always answers the requesting client through OnOperationResult, success or failure.

No. It ships no widgets and no game content, deliberately, so it carries no dependency on any UI plugin. What it gives a UI is the data layer: flat entry, capacity and currency views built from replicated state, layout groups to draw one panel per bag, a client-side PreviewPlacement for drag validity, and a delegate per kind of change. CrimsonCore ships a complete inventory screen with drag-and-drop, tooltips and a context menu on top of this plugin; it is free to download, but compiles only with all Crimson plugins installed.

No. It builds and runs standalone with only engine plugins (GameplayAbilities, GameFeatures, ModularGameplay), and it owns its item-host and usable-object interfaces and its tag stacks. On its own it does not talk to other Crimson plugins: wire your own through ItemInstanceClass, SetEntryEquipped, ICrimsonItemHost, ICrimsonUsableObject and its delegates. CrimsonCore, the free full-suite integration layer (it requires every Crimson plugin), adds item context menus, the equip flow with CrimsonEquipment, action-bar binding, interactable containers and the shared use ability. There is deliberately no save-system dependency either: save data is plain structs.

No. CrimsonCommon is an optional toolbox that nothing depends on. The item-host and usable-object contracts it used to hold now live in this plugin, and every event is a delegate on the inventory's own components rather than a message-bus broadcast.

Yes. Layout is chosen per component, so every inventory in your game picks its own topology, and caps come from each component's capacity tags rather than the layout asset. UI binds by EntryId regardless of topology, and moving items between them is one TransferItem call on the routing component, which carries a bag and its contents with it as a subtree.

Only if the asset manager knows about them. Item definitions are reached by id at runtime, which the cooker does not follow, so add the folders holding them to Item Definition Scan Paths in Project Settings and the plugin registers them as AlwaysCook primary assets. An item outside a scanned path that nothing hard-references is cooked out of a packaged build: it works perfectly in the editor and is simply missing in the shipped game, so the docs include a page on verifying this before you ship.