# Anchor & Hint Tags

Use **tags** to semantically steer where things spawn without hard-coding positions. Tags live in two places:

* **WaveSpawnPoint.AnchorTags** – tags that describe *what kind* of placement the wave wants (e.g., `"Flank"`, `"Ambush"`).
* **EnemySpawnHintPoint.tags** – tags that describe *what kind* of spot this hint represents.

When a wave fires, the system tries to pick hint points whose tags overlap with the anchor’s tags.

***

## How matching works

* **Scope:** Tag matching is only used by *wave* spawns (because they have an anchor). Global/Region spawns don’t supply tags, so hints are chosen by distance/LOS/etc. only.
* **Logic:** It’s an **OR** match. If **any** tag on the anchor is equal to **any** tag on the hint, it’s a match.
* **Case/spacing:** **Exact string equality**, case-sensitive, no trimming. `"Flank"` ≠ `"flank"` and `"HighGround"` ≠ `"High Ground"`.
* **Pass order:**
  1. Prefer tag-matched hints inside the search radius.
  2. If none qualify, try **any** eligible hint in range.
  3. If still none and **Hint-Only** is **off**, fall back to sampler. If **Hint-Only** is **on**, the spawn is skipped.
* **Empty tags:**
  * Anchor has no tags → the “prefer tag” pass is skipped (any hint may be used).
  * Hint has no tags → it won’t match the tag-preferred pass, but can still be used in the “any eligible” pass.

***

## Authoring guidelines

* **Define a small vocabulary** and stick to it (e.g., `Flank`, `Ambush`, `HighGround`, `Close`, `Far`, `Street`, `Cave`).
* **Be consistent in casing** and spelling. Consider using constants in your team docs.
* **Tag intent, not location.** A point behind cover might be `Flank`, a balcony might be `HighGround`.
* **Generic anchors:** If a wave doesn’t care, leave **Anchor Tags** empty so any suitable hint can be used.
* **Specific anchors:** Add 1–3 tags max. Too many tags can unintentionally exclude hints.

***

## Where tags are used

* **Wave spawns:** Anchor → preferred hint tags → placement.
* **Global & Region spawns:** Tags are currently **not** used (no anchor context). Hints are still considered (if enabled) by distance/LOS/NavMesh rules.

***

## Example tag sets

* **Flank engagement:**
  * Anchor: `["Flank"]`
  * Hints: mark spots behind cover with `Flank`.
* **Ambush from alleys:**
  * Anchor: `["Ambush","Close"]`
  * Hints: tight corners/doorways tagged `Ambush`, nearby ones also `Close`.
* **Ranged pressure from above:**
  * Anchor: `["HighGround","Far"]`
  * Hints: balconies and rooftops with `HighGround`; distant roofs add `Far`.
* **Biome-aware waves:**
  * Anchor: `["Cave"]`
  * Hints: cave interiors tagged `Cave` so waves in that area bias correctly.

***

## Troubleshooting

* **“No suitable hint found” while Hint-Only is ON:**
  * Check **spelling/case** of tags on anchors and hints.
  * Ensure the hint is within the wave’s **search radius** (anchor range + padding).
  * Verify **Min/Max Player Distance** on the hint vs. player position.
  * If needed, enable **Ignore Spawner’s Global Min Range** in *Spawn Hint Settings*.
  * Turn on **debug logs** in settings to see which rule filtered out a hint.
* **Hints used but not the tagged ones:**
  * Anchor tags empty → no preference.
  * Tags don’t match exactly → fix casing/spacing.
  * Tag-matched hints failed other checks (LOS/NavMesh/reservations) → inspect logs/Gizmos.

***

## Quick checklist

* Anchor and hint tags spelled the same? (case-sensitive)
* Anchor range + padding reaches the hints?
* Hint’s min/max player distance compatible with your current player position?
* Hint-Only vs. fallback behavior set as intended?
* Debug logs enabled during setup to verify match decisions?