1.0.12

Fixed

• Delete Excess Units no longer produces an unreadable saved game. The tidied .vsav was written directly to the destination path, so if the write was interrupted — e.g. the window was closed during the several-second save of a large game — a truncated file was left behind, and VASSAL rejected it with "… is not a VASSAL saved game or log." The tidied game is now written to a temporary file and atomically moved into place, so the destination only ever holds a complete file (the original is still never touched). The operation also runs behind a modal progress dialog so it is clearly working and cannot be closed mid-write, and deobfuscation/obfuscation now use bulk/chunked I/O — a ~465 MB game is rewritten in a few seconds instead of ~30.

Added

• Excess Units. A new toolbar button (and Tools → Find Excess Units in Saved Game…) loads a VASSAL saved game (.vsav) and reports the game pieces in it that are missing from the module (left panel) and its active extensions — the pieces that make VASSAL log "Bad Data in Module … Image not found" / "No such map" on load and "Unable to match piece … by name" on Refresh Counters. A piece is flagged only when it matches no active PieceSlot by either GPID or name (VASSAL's own "unmatchable" condition), so run-time markers and refresh-repairable pieces are never touched. Pieces recoverable from an inactive extension are shown greyed with that extension's name in braces (activating it is an alternative to deleting). Delete Excess Units removes all listed pieces and saves the tidied game under a new name, leaving the original file unchanged. The saved game is rewritten byte-exactly (surviving commands copied verbatim, metadata preserved). See docs/vsav-excess-units.md.
• Saved-game format documentation. docs/vsav-format.md documents the .vsav container, the !VCSK obfuscation, and the command-log grammar.
• Show Extensions. A new toolbar button lists the extensions available for the module in the left panel — both active ones (the *.vmdx files in the module's _ext directory) and deactivated ones (those in the _ext/inactive/ subdirectory, which VASSAL ignores). Entries are listed alphabetically; inactive ones are shown in grey with an "(Inactive)" marker. Selecting an extension lets you either Activate/Deactivate it — moving its .vmdx file into or out of the inactive/ subdirectory — or Edit Extension, which opens it into the right panel (double-click does the same).

1.0.9

Register app icon in hicolor theme so KDE picks up icon changes

The .deb/.rpm shipped the app icon only as an absolute-path file under /opt referenced directly by the .desktop Icon= field, and the postinst never touched any icon cache. On an upgrade over a version that had no icon, KDE Plasma's cached "no icon" was never invalidated, so the menu entry kept showing the placeholder even though the correct icon was on disk.

Register the icon in the freedesktop hicolor theme via xdg-icon-resource install/uninstall (postinst/prerm, and the rpm .spec %post/%postun), which runs gtk-update-icon-cache -- the signal desktops use to invalidate their icon caches -- and reference the icon by NAME in the .desktop file so it resolves from the theme. This matches how the sibling vassal package handles its icon, and makes icon changes show up automatically on future installs and upgrades.

1.0.8

Add Edit Extension Properties dialog

Mirror VASSAL's ModuleExtension editor so users can edit an extension's Version, Description, and "Allow loading with any module" flag, with the Extension ID shown read-only. Available only for an extension.

The properties are persisted exactly the way VASSAL stores them — in both places: the version/description/anyModule attributes on the ModuleExtension root of buildFile.xml, and the matching // values in the regenerated extensiondata metadata entry. extensionId, module name/version, and the recorded vassalVersion are left untouched.

1.0.7

Display extensions as the reconstructed module tree, greying inherited nodes

An extension panel previously showed each grafted component as a flat "Extension Element -> target/path/..." row. It now reconstructs the module hierarchy the targets describe: path segments become greyed inherited nodes (shared prefixes merged) and each wrapper's real component subtree hangs beneath its target as normal black nodes, matching the VASSAL editor.

• ComponentNode: add a synthetic-node constructor (className+configureName, no DOM element) with isInherited()/getClassName(); share display-name formatting between real and synthetic nodes.
• ArchivePanel: buildExtensionTree/graftInto reconstructs the tree; decodeTarget /seqDecode is a faithful port of VASSAL's SequenceEncoder.Decoder (exact inverse of the encoder). Nested wrappers (double-wrap bug) re-graft from the root so even damaged files display correctly. InheritedAwareRenderer paints inherited nodes grey. State preservation generalized to keyOf (Element for real nodes, structural path for synthetic).
• MainWindow: reject inherited nodes as Move/Copy/Delete sources; allow a selected inherited node as a graft destination (syntheticTargetPath); clean up emptied ExtensionElement wrappers after deleting a grafted component.
• Bump version to 1.0.7.

1.0.6

Fix double-wrapped ExtensionElements when copying between extensions

Selecting an ExtensionElement wrapper node as the copy/move source and grafting it into another extension re-wrapped it in a spurious outer ExtensionElement with an empty target (moduleTargetPath returns "" since the source wrapper's parent is the extension root). VASSAL loads the result but the module editor cannot edit such a doubly-wrapped component.

• performTransfer: when the source element is itself an ExtensionElement graft it directly onto the destination extension root instead of re-wrapping it.
• Add Tools > Repair Double-Wrapped Extension Elements (left/right) to collapse existing target="" wrappers into their inner wrapper.
• Bump version to 1.0.6.

1.0.5

When a module (or extension) is first loaded, the tree now expands only its root and leaves every top-level folder closed, so you open just the branches you need.

1.0.3

VASSAL Extension Utility 1.0.3

Fixed

• Copying trees between modules and extensions now copies the entire tree not just the root.
• New extension inherit the parent module's version number.
• Linux and Windows packaging fixes.

Release 1.0.1

VASSAL Extension Utility 1.0.1

A maintenance release that fixes data loss and image-display problems when moving components into extensions, plus a small release-tooling addition.

Fixed

• Moving multiple components into an extension no longer drops any of them. When several components were transferred to the same location in an extension (for example three boards under World Maps → Map Boards), they were all packed into a single ExtensionElement. VASSAL only reads the first component of an ExtensionElement, so it silently kept the first and discarded the rest — and permanently deleted them if the extension was later re-saved in the module editor. The utility now writes one ExtensionElement per component, exactly as the VASSAL editor does, so every moved/copied component is preserved.
• This was also the real cause of the "a moved board image won't display in VASSAL" reports: the board that owned the image was one of the discarded components, so nothing referenced the image. (The image data and generated tiles were always correct.)
• Image modification times are now preserved when saving. Previously every save stamped all entries with the current time, which invalidated VASSAL's image‑tile cache and forced large board images to be re‑tiled on the next load. Moved and copied images now keep their original timestamps.

Added

• make version-bump — bumps the patch version by 0.0.1 (e.g. 1.0.0 → 1.0.1), updating both the Makefile and pom.xml in one step.

Documentation

• Added docs/image-display-and-tiling.md, a detailed explanation of how VASSAL tiles and renders large board images, why a structurally‑incorrect extension can leave a board blank, and how to diagnose it from VASSAL's errorLog.
• Updated AGENTS.md and docs/vmdx-format.md to document that an ExtensionElement holds exactly one component.

Upgrade note

Extensions produced with 1.0.0 by moving or copying more than one component to the same target location are incomplete — VASSAL discarded all but the first component when it loaded them. Recreate those extensions with 1.0.1: start from the original (pre‑move) module and redo the transfer. Extensions where only a single component was grafted per location are unaffected.

Initial Release 1.0.0

Initial release after adding packaging details and instructions to Makefile.