Two things from MrZzzzzzzzzzzzz's feedback.

Adding or removing a mod forces a fresh analysis, and that was throwing away
everything you had already decided: unticked changes, values you edited by
hand, and conflicts you had resolved. All of it is kept now. If the mod that
won a conflict is removed, that conflict simply goes back to unresolved.

The mod list can now show which tables a mod actually contains - click
"Tables" on any mod. The changes list only shows tables that differ from the
base game, so until now there was no way to see the full contents of a pak.

Worth pointing out, because it is easy to miss: the Conflicts page already has
a button per mod that gives that mod every conflict at once. If you want one
mod to win across the board, you do not have to click through them one by one.

And to be clear about the earlier problem: tables going missing from your merge
was the bug fixed in 0.3.12, not something you were doing wrong. You do not
need to add clean copies of the other tables to keep them - the merge keeps
every table the mods bring.

Two merge bugs are fixed, both found from a report by MrZzzzzzzzzzzzz who sent
in his mod and merge report - thanks for that.

If you ever saw "does not round-trip faithfully" and a table being left out of
the merge, that was this. Two separate causes, both fixed:

- When a mod CLEARS a name field that the game table had filled in, that empty
value was written in a form the serializer does not read back the same way.
The table was built with a wrong value, failed verification, and was dropped.

- Some game tables store an enum as a numbered internal name. Stellar Tool
could read those but not write them back, so the table could not be rebuilt
at all - it failed even with no mod changes applied to it.

On the reported merge, this is the difference: SkillActiveStepTable went from
excluded to 647 changes applied, CharacterStanceTable from excluded to 24, and
the merge now finishes with every table included and verified. Checked against
the untouched game files, the merged tables are identical to vanilla except for
the mods' own changes.

Also: the warning shown when a table is excluded now states the real reason
instead of claiming none of its changes could be written.

If a table still gets excluded after this, send me the merge_report.txt - that
is a case worth investigating, not a dead end.

- Fixed the bug behind "SkillResultTable ... does not round-trip faithfully".
When a mod CLEARS a name field that the vanilla table had set, that empty
value was written in a form UAssetGUI does not read back the same way: the
table was generated with a different value, failed verification and was
dropped from the merge. Empty name fields are now written as "None", the
only form that survives the write/read cycle intact. Reported by
MrZzzzzzzzzzzzz with a merge of Scarlet Moveset and EVE Ultimate Version.
- Same fix applies to tables that were failing silently while being generated:
SkillActiveStepTable now merges completely instead of being excluded.
- The warning shown when a table is excluded now matches the actual reason.
A table that failed verification no longer reports "none of its changes
could be written"; it says the generated table did not pass verification and
asks for the merge_report.txt.

Note: if a table still gets excluded, that is UAssetGUI refusing to rebuild
that specific table, not the merge. The rest of the tables are still packaged
and verified, and the source mod stays in charge of the excluded one - keep it
enabled.

- A DataTable that fails the UAsset round-trip check no longer aborts the whole
merge. Its partial files are removed, the exact failure is written to
merge_report.txt, and Stellar Tool tells you to keep the source mod enabled
for that excluded table. Other verified tables are still packaged safely.
- Improved the Changes toolbar layout so the page title can no longer cover
the search field at narrower window sizes.
- Improved long conflict titles and mod names so they wrap or elide instead of
covering candidate values.
- Kept the visible dark-theme All/None controls and per-row conflict updates
introduced in v0.3.4.

- Zen mods can now add complete DataTable rows. Nested empty FName values are
normalized safely and all new names are registered before serialization.
- Scalar arrays can now be populated when the vanilla array is empty. Element
wrappers are reconstructed from the ArrayType metadata.
- Zen mods can now remove rows intentionally. A safety guard blocks removals
when one mod unexpectedly loses more than 25% of a vanilla table, preventing
a truncated export from becoming a destructive merge.
- Added regression coverage for new rows, empty-base arrays, normal row
removals and suspicious mass row loss.
- Updated the Nexus documentation to reflect the expanded Zen write-back
support.

Fixed — mods silently not loading (important)
Adding several mods at once only ever loaded the first one. Dropping a batch on the drop zone, or multi-selecting files, fired the imports faster than they could run and the rest were discarded with no error at all. Imports are now queued and processed one by one, and the Add buttons stay usable while one is running. If you ever wondered why a mod "didn't show up", this was why — please re-check your setup.

Fixed — merges failing with no explanation

A merged value that introduced a new text or enum name could make the write step fail and produce nothing. This was behind several "UAssetGUI no produjo el uasset esperado" reports.
Those tools never printed their errors, which is why failures looked silent. The real message is now recovered and shown, plus a diagnostic log in %LOCALAPPDATA%\StellarTool\logs\. If you hit an error, attach the newest log — it now says what actually went wrong.
Fixed — Conflicts and Changes UI

Picking a winner no longer scrolls the list back to the top (same for the All/None buttons on Changes).
The lists have visible scrollbars now — with dozens of conflicts there was no hint anything was below the fold.
With mods loaded but not analyzed, both pages say so and offer the Analyze changes button right there.
Also
Bulk edit, TOML import/export and the mappings downloader are translated in all 10 languages.

Thanks to MrZzzzzzzzzzzzz for reporting the conflicts UI issues.

Fixed (important)

• "UAssetGUI no produjo el uasset esperado" on merge: the tool was telling UAssetGUI which mappings to use by name, which only works if the .usmap sits in a specific UAssetGUI folder (%LOCALAPPDATA%\UAssetGUI\Mappings) — and the tool installed it elsewhere. So the mappings resolved to nothing, the DataTable couldn't be written back, and the merge failed. It now passes the mapping file directly, with no folder dependency. You no longer need to open UAssetGUI or set anything up manually — merging works out of the box.

If you previously fixed this by opening UAssetGUI and configuring Stellar Blade mappings yourself: that was a valid workaround, and it's no longer necessary in 0.2.5.

Included from recent updates (0.2.2–0.2.4)

• Fixed C: drive filling up when reading Zen mods (stages on the game's drive using hard links).
• DataTables detected even when their filename doesn't contain "Table".
• Diagnostic logs written to %LOCALAPPDATA%\StellarTool\logs\ on tool failures, for easier bug reports.
• Settings → Mappings: load an updated StellarBlade.usmap after a game patch without waiting for a release.

Thanks to the users who reported details and workarounds — it made pinning this down possible.

Improved

Diagnostic logs for UAssetGUI failures: UAssetGUI can fail silently (exit without writing the file and without printing an error), which left you with a blank "no produjo el uasset" message. The tool now writes a diagnostic log to %LOCALAPPDATA%\StellarTool\logs\ on any failure — including the command, exit code, and any output — and shows the log path in the error. For write-back failures it also saves the input JSON next to the log.
If you hit an error, please attach the newest uassetgui_*.log (and the *.input.json beside it) when reporting — it makes the problem diagnosable instead of guesswork.
Included from recent updates

Fixed C: drive filling up when reading Zen mods (now stages on the game's drive with hard links).
DataTables are detected even when their filename doesn't contain "Table".
Settings → Mappings: load an updated StellarBlade.usmap after a game patch without waiting for a release.

Fixes

• Disk space (important): reading Zen/IoStore mods no longer copies the game's multi-GB global container to your C: drive. It now stages on the game's own drive using hard links, so imports take virtually no extra space. If an older version left a big folder behind, you can safely delete %LOCALAPPDATA%\StellarTool\work.
• DataTables not named "Table": the importer used to skip a mod's tables if their filename didn't contain "Table". It now reads all of the mod's assets and detects DataTables regardless of name — so more table mods import correctly.
• Clearer errors: CUE4Parse / UAssetGUI failures now include the tool's real output and a hint instead of a generic message, making problems much easier to diagnose.

New

• Custom mappings (.usmap): added Settings → Mappings, where you can load an updated StellarBlade.usmap after a game patch without waiting for a new release.

If you still hit errors after a game update: try loading a fresh StellarBlade.usmap in Settings, and paste the full error text — it now includes the detail needed to diagnose it.

Fixes

• Disk space: reading Zen/IoStore mods no longer copies the game's multi-GB global container to your C: drive. It now uses hard links on the game's own drive, so imports take virtually no extra space. (Fixes reports of C: running out of space.) If you have a large leftover folder from an older version, you can safely delete %LOCALAPPDATA%\StellarTool\work.
• Clearer errors: the "no exportó ninguna tabla" (CUE4Parse) and "no produjo el uasset/JSON" (UAssetGUI) errors now include the tool's actual output and a hint, instead of a generic message — so failures are much easier to diagnose.

New

• Custom mappings (.usmap): added Settings → Mappings where you can load an updated StellarBlade.usmap after a game patch, without waiting for a new release. Handy when a game update breaks reading/writing of assets.

Notes

• If you hit "no produjo" / "no exportó" errors after a game update, try loading a fresh StellarBlade.usmap in Settings.