Epic gives you GAS. This gives you a combat system.

It helps, but the plugin removes the parts that make GAS hard to start: the ASC setup, input plumbing, cooldown/cost boilerplate, and replication patterns are done. The Quick Start gets a working ability running end to end, and the Concept pages teach the mental model as you go.

Yes, for a small but unavoidable part: attribute sets are C++ only. Blueprint cannot declare FGameplayAttributeData, which is a GAS constraint rather than a plugin one, so defining health, stamina or mana means one C++ class, and the Quick Start walks through the complete file. Two smaller things are also native-only: assigning a tag relationship mapping (SetTagRelationshipMapping is not Blueprint-callable and the property is not editable in Class Defaults, so a Blueprint-only project needs one small C++ base class to call it once; the mapping asset is fully data-authored), and the combo system's optional input providers, Set Move Input Provider and Set Modifier State Provider (direction-agnostic combos work without either; key modifiers work standalone, and named tag modifiers come through a hook that CrimsonCore binds for you). A custom UCrimsonGameplayAbilityExtension (a HUD slot or pawn facing without CrimsonCore) is a C++ subclass too. Everything downstream is Blueprint: abilities, augments, contracts, combo graphs, phase abilities, costs, clamping via effects, tooltips, and binding UI to attribute changes.

Not end to end, and it would be dishonest to say otherwise. You need a C++ module for at least the attribute set, because GAS itself requires it. After that a designer can work entirely in Blueprint and data assets. If your team has no C++ at all, budget for one engineer to write that one class (plus a Player State that creates it as a subobject) before the rest of the plugin is usable.

Yes. It's built for a dedicated server plus clients, and the docs state where every piece runs rather than leaving you to guess. Granting abilities, effects and attribute sets is server-side; activation uses standard GAS client prediction; augment equipping replicates as registered subobjects; combo transitions are client-predicted and server-validated with a ping-leniency window; game phases are authority-only. The ASC lives on the Player State so state survives pawn respawns.

One line, and it matters: you must register the plugin's globals class in Config/DefaultGame.ini (AbilitySystemGlobalsClassName=/Script/CrimsonAbilitySystem.CrimsonAbilitySystemGlobals). Without it MakeEffectContext returns the engine context instead of FCrimsonGameplayEffectContext and every feature that reads Crimson context data breaks. It's step 1 of the Quick Start.

No. It's optional and off by default, gated behind a single bEnableComboSystem switch in Project Settings. The ASC, ability shapes, costs, augments, contracts, effect components and game phases all work without ever turning it on.

No. It builds and runs standalone with only engine plugins (GameplayAbilities, EnhancedInput, GameFeatures, ModularGameplay), and it owns its ability sets, tag stacks and input router. CrimsonCore, the free full-suite integration layer (it requires every Crimson plugin), adds the cross-plugin extras: camera modes and lock-on from abilities, pawn facing and fixed HUD slots as ability extensions, named combo modifiers from CrimsonInput, and one shared use-item ability. Standalone, you write those as your own UCrimsonGameplayAbilityExtension or bind the plugin's hooks.

No. CrimsonCommon is an optional toolbox that nothing depends on. The ability sets, the input router and the ability-system owner interface it used to hold now live in this plugin, and every event (ability progress, failures, combo state) is a delegate on the ASC or the combo controller rather than a message-bus broadcast.