# quack. configuration dependencies

Confirmed with the robot builder on 2026-11-08. This file describes the configuration model; `rules.js` implements it. **Weights live only in `parts.csv` (or the replacement CSV loaded in the app).** Names are matched after trimming whitespace.

## Conventions

- `A → B` means **B requires A**, not that selecting A automatically adds B.
- A left/right part's CSV weight is for **one side**. Full-width pieces and the single vert bottom are counted once.
- Paired selections start linked: changing either side mirrors it to the other. Unlinking allows different parts per side; relinking copies the side edited last. Mixed materials are allowed wherever both sides independently satisfy the dependencies.
- Removing a prerequisite removes incompatible dependents. Required positions receive a valid default. The UI reports these changes; it does not silently keep invalid weight in the total.
- An optional item may be None. Required items may not.

## Always present

| Item | Quantity | Notes |
| --- | ---: | --- |
| Base Chassis 2 | 1 | Includes drive and base electronics; no battery or armor |
| Battery 3500mAh | 1 | Separate from the chassis |
| Weapon module | 0–1 | None (new builds) / Small Vert / Big Vert / Horizontal / Beater Bar |
| Module Pin | 4 | Every module except Horizontal; none without a module |
| Horizontal Pin | 4 | Horizontal only, replacing Module Pins |

## Required chassis plates

| Position | Allowed choices | Quantity |
| --- | --- | ---: |
| Top center | ¼″ Tegris Center / ⅛″ Tegris Top Center / ⅛″ CF Top Center | 1 |
| Bottom center | All top-center choices / Ti Center Plate Bottom | 1 |
| Top sides | ¼″ Tegris Side / ⅛″ Tegris Top Side / ⅛″ CF Top Side | 1 per side |
| Bottom sides | All top-side choices | 1 per side |

The CSV's `Top` names are reused for bottom positions; they do not imply a top-only restriction. Titanium center is bottom-only. A Titanium Side Brace is optional at each top/bottom left/right position (up to four), and requires that position's side plate, regardless of material.

## Base sides and side armor

- Per side: None / Alu Base Side (Bare) / UH Base Side. Base sides are **strongly recommended**, not required.
- Only an **aluminum** base side can carry side armor. Each side can use:
  1. UH Side Armor; **or**
  2. TPU Full Short Side; **or**
  3. TPU Side Back and/or a front: TPU Side Front (Light) **or** GF TPU Side Front.
- Back and front in option 3 can be used independently. The two front materials are exclusive.
- Full armor must be set to None to enable separate back/front pieces.

## Rear armor (optional)

- Each side: None / TPU ½ Rear (Light) / TPU ½ Rear (Heavy). Mixed light/heavy is allowed.
- One Aluminum Rear Plate occupies the whole rear and excludes **both** TPU halves.

## Chassis front slopes and Katana forks (optional)

- Either aluminum or UH base side → slope plate on that side.
- Per side: None / AR Front Slope Plate / AR Front Slope Plate Fork Mount.
- AR Front Slope Plate Fork Mount → Katana Fork on that side.
- Neither slope variant nor Katana forks can be used with Beater Bar.
- These chassis-mounted parts can coexist with vert-module forks.

## Gorilla forks (optional)

- Per side: None / Gorilla Fork (Heavy, 256.6 g) / Gorilla Fork (Light, 114 g). Weights are per side.
- Requires the **aluminum** base side on that side, and **no side armor** there (no UH Side Armor, TPU Full Short Side, TPU Side Back or TPU Side Front).
- Can run with the front slope plates and Katana forks, and with any module.
- Must run on **both sides** (heavy and light can mix). A single gorilla fork shows a warning.
- Chassis-mounted: counts toward total weight, not the weapon subtotal.

## Small Vert and Big Vert only

- **Required:** two fronts (one per side), each UH Front or TPU Front. Mixed materials allowed.
- **Required:** one bottom, Tegris Bottom or Aluminum Bottom.
- Either bottom → optional **one** AR Bottom Armor.
- Per side: optional Vert AR Fork Mount → None / UH Center Vert Fork / Long Vert AR Fork.
- Per side: TPU Front → optional Short Vert AR Fork. It bolts to the TPU front, needs no fork mount, and can run alongside a mount fork or the plow.
- Two Vert AR Fork Mounts → optional **one** Anti-Vert Plow. It occupies both mounts and excludes both individual forks.
- A mount may remain installed without a fork or plow.

## Horizontal only

- Uses four Horizontal Pins, not Module Pins.
- Optional **one** Horizontal AR Plate.
- No vert or beater attachments.

## Beater Bar only

- **Required:** two fronts, one per side: Bent Front (Large) or Front (Small). Mixed sizes allowed.
- Front on a side → optional Beater Fork Mount on that side.
- Beater Fork Mount → optional Anti Drum Fork on that side (one or both sides allowed).
- Two Beater Fork Mounts → optional **one** Beater Bar Wedge, occupying both mounts and excluding both anti-drum forks.
- The fronts referred to earlier as “Bent Front Wedge (Heavy)” and “Front Wedge (Small)” map to the current CSV names above.

## Weapon-weight accounting

The 15 lb subtotal includes the selected module, its four pins, and these selected **module-mounted** pieces:

- Vert fronts, the single vert bottom, and AR Bottom Armor.
- Horizontal AR Plate.
- Beater fronts.
- Automatic CSV hardware on the pieces above.
- Manual hardware/extra-part quantities explicitly assigned to the weapon.
- The portion of the general allowance explicitly assigned to the weapon.

**Excluded from that subtotal:** forks, fork mounts, the Anti-Vert Plow and the Beater Bar Wedge **and their hardware**, plus chassis/battery, chassis plates/braces, chassis-mounted slopes and Katana forks, base sides/armor, and rear armor. All still count toward total robot weight. These are the builder-specified accounting rules, not an independently verified ruling from NHRL.

## Screws, hardware, and other add-ons

- Mounting hardware is automatic. Each part's CSV Min/Max sets its range, a global slider picks a level, and per-position typed counts override it. See the README for ID syntax.
- Hardware parts (`… (ID n)`) can also be added as manual whole-number quantities, initially zero. These are **in addition to** automatic hardware.
- New CSV part names not used by the topology appear as manual add-ons without a code change.
- Each add-on has total quantity and an “on weapon” subset, so weapon-mounted hardware can be counted accurately.
- Screw counts are never inferred beyond the CSV's Min/Max.
- Fastener/wiring/zip-tie allowance defaults to **0 oz**. Its weapon-assigned portion is a subset, not an additional allowance. Avoid counting the same hardware both explicitly and in the allowance.

## Requested weigh-in checks

Using full-precision gram totals (rounding for display only):

- Total ≤ 30.000 lb: within the specified robot-weight limit.
- 0 < excess ≤ 2.5 oz: **1 TKO point at weigh-in**.
- Excess > 2.5 oz: **immediate TKO**.
- Weapon subtotal > 15.000 lb: **weapon not allowed**.
- Exactly 30 lb, exactly 2.5 oz over, and exactly 15 lb are tested boundaries.

This is a planning calculator, not a scale reading or a complete competition inspection. It does not check other NHRL rules.

## CSV and saved configurations

- Supported headers: `Part,Weight (g)` (current file), `Part,Weight (oz)`, `Part,Weight (lb)`, or `Part,Weight,Unit` for mixed units.
- Supported units: g/gram/grams, oz/ounce/ounces, lb/lbs/pound/pounds (case-insensitive).
- Rejects missing/negative/nonfinite weights, duplicate names (ignoring case and surrounding whitespace), unknown units, malformed CSV, and missing topology part names.
- Keep the configured part names unchanged. Adding a new weight-only part works as an add-on; adding a new mutually exclusive module/material or changing mechanical dependencies requires changing `rules.js` too.
- Replacing the CSV updates all current/saved/comparison totals. A replacement is rejected if it would orphan an add-on referenced by a current or saved configuration.
- Configurations contain selections and quantities, **not copied weights**. JSON imports use the active CSV. IDs are regenerated on import so existing configurations are not overwritten.
- Local storage keeps the loaded CSV, working draft, and named configurations on this browser/origin. JSON exports contain configurations only; export the active CSV separately to preserve its weights elsewhere.