Author the attack once. It hits correctly everywhere.

Yes. This one is a hard requirement, not a recommendation. Every hit is reported as an FGameplayAbilityTargetDataHandle and the window drivers are UAbilityTask nodes. There is no non-GAS path, so if your project doesn't use GAS this plugin isn't usable as-is.

Not for the plugin itself. Profiles and targeting presets are data assets, the drivers are Blueprint ability-task nodes and an animation notify state, and the component's functions are all Blueprint-accessible; the trace selection task is even Blueprintable, so you can override its direction, length and swept dimensions in a Blueprint subclass. A couple of keyed-window entry points are C++-only, for callers like an animation notify that cannot hold a handle, and you won't call them directly. Pooling projectiles without CrimsonCore also takes C++, because the pool reclaims them through the native OnPoolReleaseRequested delegate. One honest catch is downstream of us: Crimson Filter: Affiliation asks the engine's IGenericTeamAgentInterface, and UGenericTeamAgentInterface is not Blueprintable, so the actors that get hit need a small C++ base class implementing it. Use Crimson Filter: Actor Class instead if you have no team system yet, or derive from CrimsonCore's ACrimsonCharacter, which already implements it.

No, deliberately. It outputs an FCrimsonHitReport and stops: it never builds or applies a UGameplayEffect and never executes a GameplayCue, it just carries the cue tag for you to fire. Effect specs get modified between construction and application by stat systems, augments and buffs; applying them from inside a detection system would silently bypass all of it and double-fire cues your own effect already carries.

Yes, and it's built that way from the start. Queries, filtering, dedup and target limits are server-only, nothing is client-initiated, and an unreliable multicast carries cosmetic impacts so hit feedback lands promptly everywhere. The cost is that feedback is delayed by roughly half a round trip.

No. It's declared as a dependency in the .uplugin, so enabling CrimsonHitDetection enables it too, even though Epic ships it disabled by default. It will show as enabled in Edit → Plugins without you having ticked it.

No. It is fully standalone and needs only engine plugins. With CrimsonCore, projectiles are pooled through CrimsonObjectPool automatically and pooled launch tasks are added; standalone, drive the projectile's pooling hooks from your own pool. Team filtering goes through the engine's IGenericTeamAgentInterface, so it works with CrimsonTeams or any team system that implements it, but read How-To: Filter By Team before shipping either way, because unresolved team data reads as Neutral and the filter allows Neutral by default. The failure mode is hitting your own allies, not an error.