48 lines
5.6 KiB
Markdown
48 lines
5.6 KiB
Markdown
---
|
|
name: import-weapon-screenshot
|
|
description: Extract a Division Resurgence weapon from screenshots, match pictured talent icons to existing SHD.build talents, prepare its weapon image, collect missing tier and augmentation values, and enter the reviewed weapon through ISAC. Use when the user supplies weapon-detail, blueprint, crafting, talent-grid, or weapon-stat screenshots and asks to import, create, model, or enter the weapon.
|
|
---
|
|
|
|
# Import Weapon Screenshot
|
|
|
|
Create a complete weapon record from screenshots without guessing hidden configuration. Submit mutations to the authenticated ISAC server action so validation, relationships, and audit logging remain intact. Prefer direct requests over operating the editor UI.
|
|
|
|
## Workflow
|
|
|
|
1. Inspect every screenshot at original detail. Extract the weapon name, category, native tier, damage type, fixed handling values, visible damage range, talent icons, and augmentation evidence.
|
|
2. Search the Weapon registry by normalized name. Stop on a duplicate unless the user explicitly requests an update. Treat named variants such as `First Wave` as distinct weapons.
|
|
3. Reconcile screenshot labels with project vocabulary:
|
|
- `Piercing Damage` → `Pierce`
|
|
- `Blast Damage` → `Blast`
|
|
- `Shredding Damage` → `Shredding`
|
|
- Preserve the displayed native tier.
|
|
4. Ask directly for missing damage-range numbers for every tier at or above the native tier. Do not request extra screenshots when typed minimum and maximum values are faster.
|
|
5. Read each Talent 1 and Talent 2 grid as a complete, unordered set. These weapon screenshots show every available talent twice: once for Tier I and once for Tier II. Group identical icons across the entire grid, resolve each two-icon group against active talents in the corresponding ISAC slot, and store the matching talent once. Compare silhouettes and internal details only. Tier variants may appear in different rows, separated by other talents, or in any order; never use adjacency, sequence, or grid position to pair them.
|
|
6. For an ambiguous or unmatched talent icon, identify its slot and screenshot position and request a close-up showing that talent's icon, name, and description. After the user supplies it, invoke `import-talent-screenshot` to create and model the missing talent, then resume the weapon import.
|
|
7. Never infer talents that are cropped below the screenshot. Ask for another talent-grid screenshot when the visible grid may continue.
|
|
8. Ask the user to type Tactical Augmentation 01 as one or two `Attribute = value` pairs. Reuse exact active attributes and stop on ambiguous names.
|
|
9. Treat weapon mod slots as unknown unless the user supplies explicit evidence. Save the weapon with no mod-slot configuration; expect ISAC to display `CONFIG REQUIRED`. Do not borrow slots from a related weapon.
|
|
10. Extract the weapon render from the screenshot. Preserve the pictured model, attachments, materials, and proportions. Remove UI, cursor, text, and background; center the weapon on a transparent canvas with useful padding. Use the image-generation editing workflow only when a faithful crop and local cleanup are insufficient.
|
|
11. Search for every prerequisite before creating it. If the current schema or runtime cannot represent established weapon behavior, implement the smallest reusable capability, including validation, persistence, editor support, migrations, reference material, and tests. Follow database-preservation rules before applying schema changes.
|
|
12. Preview the extracted fields, resolved talents, unresolved evidence, and planned ISAC payload before the first mutation unless the user has already approved entry.
|
|
13. Build one `multipart/form-data` payload matching the current weapon form contract and submit it directly to the authenticated `/isac/weapons?/save` server action. Use browser-side `fetch` when the authenticated session is held by the browser; do not click through the editor merely to populate fields. Inspect the current route source before relying on a stale field name or action path.
|
|
14. Read the saved registry row back. Verify identity, category, native tier, damage type, fixed attributes, all required tier ranges, talent pools, augmentation effects, image, and expected configuration state. Confirm the `game_data` audit event when audit access is available.
|
|
|
|
## Guardrails
|
|
|
|
- Do not infer tier damage ranges by scaling another tier or related weapon.
|
|
- Do not match a talent from resemblance alone when more than one active icon is plausible.
|
|
- Every talent in these weapon talent grids appears twice, once per tier. Deduplicate identical icons across the complete slot grid into one weapon talent option, regardless of their order or position.
|
|
- Do not assume the screenshot shows the complete talent list when the panel continues beyond the frame.
|
|
- Do not infer weapon mod slots.
|
|
- Do not create a near-duplicate talent or attribute because of spelling, capitalization, or synonymous labels.
|
|
- Preserve numeric precision exactly as displayed or typed.
|
|
- Never write weapon, tier, talent-option, augmentation, mod-slot, image, or audit rows directly to the database. Never call lower-level persistence helpers to bypass the route action.
|
|
- Do not manually create an audit event. A successful server action must create it.
|
|
- Use the UI only when direct submission cannot preserve an authenticated session, file upload, or current form contract.
|
|
- Keep authored database data intact and preserve unrelated worktree changes.
|
|
|
|
## Project Reference
|
|
|
|
Read [references/shd-weapon-entry.md](references/shd-weapon-entry.md) before entering a weapon. Re-check the referenced source files when the editor or schema changes.
|