fix: apply naming pattern after parent linking in Export Gun listen channel

[WSG-ViViV]

Summary

The auto-import handler for the Export Gun listen channel (Form1.exportGun.cs → AsbServerDataSent) was applying the naming pattern and sending the generated name back to the game before the imported creature had its parents resolved and its generation recalculated.

As a consequence, every pattern token that depends on the pedigree depth — {gena}, {gen}, {nr_in_gen}, {nr_in_gen_sex}, and {genn} — was evaluated as if the creature had generation = 0. Users had to manually re-apply the naming pattern in ASB (Ctrl+A + Apply pattern) after each Export Gun shot to get the correct generation in the in-game name.

This PR reorders the import flow inside if (addCreature) to match the existing file-import flow in Form1.collection.cs (which already carries an explicit comment: "This can only be done after parent linking to get correct name pattern values related to parents").

What changed

In Form1.exportGun.cs → AsbServerDataSent:

Before

1. SetNameOfImportedCreature(...) — pattern evaluated with generation = 0
2. data.TaskNameGenerated?.SetResult(...) — sends back the wrong name
3. MergeCreatureList(...)
4. UpdateCreatureParentLinkingSort(...) — finally resolves parents

After

1. Capture alreadyExistingCreature (must happen before the merge, otherwise it ends up pointing at the freshly-added creature)
2. MergeCreatureList(...)
3. UpdateParents(new[] { creature }) — resolves creature.Mother / creature.Father (creates placeholders for unknown ancestors, consistent with the rest of the code). This is the primary unblocker: NamePattern.GenerateCreatureName has a fallback (generation <= 0 → Math.Max(Mother?.generation + 1, Father?.generation + 1)), so once parents are linked, the pattern can already compute the right generation tokens.
4. creature.RecalculateAncestorGenerations() — also sets creature.generation directly, matching the file-import flow and keeping the value consistent for any downstream consumer.
5. SetNameOfImportedCreature(...) — pattern evaluated with the right values
6. data.TaskNameGenerated?.SetResult(...) — sends the correctly-generated name
7. UpdateCreatureParentLinkingSort(...)

The else branch (addCreature == false) now also receives the captured alreadyExistingCreature for consistency.

Pre-requisite for the visible effect

The pattern is only applied when one of the auto-import settings is enabled (Settings → Auto Import):

• Apply name pattern on auto-import: always (applyNamePatternOnAutoImportAlways)
• Apply name pattern on auto-import: only for new creatures (applyNamePatternOnAutoImportForNewCreatures)
• Apply name pattern on auto-import: if creature has no name (applyNamePatternOnImportIfEmptyName)

Mentioning this for reviewer convenience — without one of these enabled, the fix's effect won't be visible during manual testing.

Test plan

• Build with .\build.ps1 — solution builds, 64/64 unit tests pass.
• Manual smoke test with live ARK session on our ASA cluster — fully functional end-to-end:
  • Auto-import setting applyNamePatternOnAutoImportAlways = true
  • Pattern uses {gena} as first token
  • Fire Export Gun on bred creatures whose parents are already in the library with gen > 0 → in-game name now contains the correct gena letter (B, C, D, ...) on the first shot, instead of always being A
  • Same with parents not yet in library → placeholders are created, gen = 1 produced as expected
  • Tamed (non-bred) creatures still produce gen = 0 / gena = A as expected
• Same scenario through the file-import path still behaves identically (no regression — the same logic was already there).

Related ideas (not in this PR, gauging interest)

Two ideas surfaced while debugging — sharing briefly in case they're of interest. Happy to open dedicated discussions before any implementation:

1. Opt-in auto bulk-rename when a species' top stat flips. Trigger a recalc + best-effort push of all in-game names for the affected species, with graceful fallback to a "pending rename" flag for cryopodded / offline creatures (the Export Gun mod can't reach a creature without an AActor reference).

2. Automatic server-rate retrieval via the Export Gun mod. The mod already supports a ServerHash payload — if it could push the current server multipliers (taming/breeding/XP/etc.) automatically on connect or hash change, players would get accurate stat extractions without having to ask the admin. Scope: only the rates the engine needs; naming pattern stays a per-user choice.

Happy to address review feedback or split this PR if preferred.

Disclaimer

First time contributing to ARK Smart Breeding — happy to align this PR with any project conventions (commit style, branching, formatting) if something doesn't match your usual workflow, and to lend a hand elsewhere if useful.

[cadon]

Hi, thanks for this fix!

Regarding the other suggestions:

1. I didn't know the Export gun can also rename other creatures, currently not aimed or interacted with. If that's possible, the idea sounds good. There might be rate or number limits for that kind of interaction that could be hit when having many creatures, but in general that sounds good.

2. AFAIK the export gun already exports the needed server settings when exporting a creature, but I have only tested the gun in local singleplayer. Did you experience issues with that, was it working different than expected or is something missing?

[coldino]

1. The export gun cannot do this. It just waits a short time for a rename response to a specific export, nothing more. There's actually no way to listen in general from the game. Bulk operations have been considered, but really only for exporting all the dinos from a cryofridge. It's rather complicated from a queuing/rate limiting perspective.

2. Yes, the export gun should be exporting server multipliers. The hash is calculated so we know when any values changed, causing the server data to be sent before the next creature export. You can find the server info on the filesystem in DinoExports\ASB\Servers with a name matching the hash, and it is also sent through the export server.

[WSG-ViViV]

Thanks both for the quick feedback!

On idea #1 (bulk rename): @coldino — understood, the mod doesn't have a general listen capability and the queuing/rate-limiting concerns are real. Putting that one on the shelf. Current workaround on our side is just re-firing the Export Gun on each dino — tedious but it works.

On idea #2 (server multipliers): @coldino's clarification was the missing piece — "the export gun should be exporting server multipliers ... it is also sent through the export server". That sent me to the ASB-side handling, and there's a regex off-by-one in Connection.cs that makes ServerHash come out empty for every event: server event. The empty hash then routes the multipliers JSON into the creature-import branch (Form1.exportGun.cs:173) where it fails silently (no BlueprintPath) and gets dropped.

So the mechanism is correct end-to-end — the push happens, the JSON arrives, ASB just wasn't parsing the hash. Verified on an ASA cluster: before the fix, Settings → Multipliers stayed at ASA Official defaults despite event: server events arriving in the log; after the fix, the cluster's actual rates (Taming 5x, EggHatch 5x, BabyMature 5x, etc.) auto-apply on the next push.

Fix is at #1407 — one character. Thanks again for the design context, it made finding the root cause much faster.

[coldino]

Interesting. Would prefer if you disclosed the AI use, however.

[WSG-ViViV]

Fair point, my apologies for not mentioning it upfront.

French speaker here, juggling several projects — I use AI assistance
for codebase navigation, drafting English-language messages and PR descriptions,
and as a sounding board during code investigation.

On these PRs specifically: bug observations on my ASA cluster, in-game
reproduction and validation, build.ps1 runs locally before each push, scope
decisions, and personal review of every change before sending were all on my
side. I don't ship anything I haven't walked through myself.

Will flag AI assistance on future contributions here as a matter of policy.
If you'd like the same note added retroactively to #1406 / #1407 descriptions,
just say the word.