WPS Dune Modder Kit

Copyright (c) 2026 Wasted Potential Studios. All rights reserved.

Build a Dune mod with reusable UI, appearance, animation, physics, game information and communication tools. This local reference covers Modder Kit 1.7.1, Framework 1.7.1 and Launcher 2.1.1 releases with UE4SS 1140. The Kit includes a local workbench, 22 ready-to-edit starters, searchable API definitions, command-line tools and Unreal author helpers. Use the matching release packages; the Launcher page continues to provide published author resources.

Choose the matching Framework 1.7.1 for inventory and storage mods; keep one Framework installed. Choose Framework 1.7.1 for the Creation Tools described here.

Create your own objects and definitions

Use the creation starter for a new construction definition with a stable saved ID, or composition for an owned arrangement of mesh objects attached to an actor. Both use Framework 1.7.1 and UE4SS 1140. The Kit validates Creation/defs.json, declares the separate Launcher and Framework requirements, and includes the file in your package. Read the creation guide for ownership, available assets, cleanup and save compatibility.

Get ready

Use the WPS Dune Launcher 2.1.1 to import and run your mod for your projects. If your starter uses the Framework, install its declared Framework dependency separately beside it. Examples marked 1.4.6 need that version or newer; an older installed Framework does not gain an API from this documentation. Select your installed game in the launcher, or browse to its game folder when it is not listed. Players need only the dependencies your mod declares; they do not need this kit, Python or Unreal Editor. The online documentation includes the full API reference and author guides.

Extract the entire kit into a short working path, such as C:\DuneKit. Keep kit and ue beside each other. Install Python 3.11 or later with Tkinter for the workbench. Install Lua 5.4 with its luac compiler for syntax checks and release packaging of Lua starters. Offline project tests use the lua interpreter. Put those commands on PATH or pass their locations on the command line. The kit does not install tools automatically.

Double-click Start.cmd. The workbench opens locally; it needs no account. Its commands never launch Dune or change your installed mods.

Its seven views are Create, Check & package, Environment, Reference, API lookup, Supported items, and Settings & support. Use API lookup to find an operation by feature, then read its exact arguments and target class before adding it to your mod.

WPS Dune Launcher 2.1.1 shows available updates beside each mod version.

Use the Launcher to manage the finished mod and its separate Framework dependency. Imported entries start disabled; enable the entries required for your test and sort dependencies.

Use the Launcher 2.1.1 when importing a mod with required files in a Content folder. Keep the complete author-supplied folder layout and matching companion files together. Do not remove required resources to work around an import error; update the Launcher and retry the intact package. This correction preserves an immediate Content resource folder inside a Lua or native mod; it does not allow one mod to be nested inside another. Game-loaded Pak companions still belong in Paks. Launcher 2.1.1 and the Framework 1.7.1 treat a differing game version as an advisory notice and allow launch. This does not certify a feature on an untested game version: retain the feature's actual capability checks and report unsupported behavior clearly. The public Framework API and starter formats remain compatible with their declared requirements.

Create your first Framework mod

1. Open Create. Enter a new project folder that does not already exist, such as C:\DuneMods\MyFeature.
2. Choose a permanent Mod ID, such as MyFeature. Use letters, digits, underscores or hyphens, starting with a letter. Use a name that will remain stable between releases.
3. Enter the display name, author and a short description of what players get.
4. Choose settings and the PC editions you plan to test. The default is both, for Steam and the Xbox app PC edition. Click Create project.
5. Open the new project in your editor. Edit Mods\MyFeature\Scripts\main.lua.

The settings starter loads a configurable welcome message and reports its status. It imports the installed Framework through its public API. The generated manifest declares the launcher, Framework and supported UE4SS runtime. It identifies your chosen PC editions without claiming that your new mod has been tested on a build or package version. Editor schema hints and check/package tasks are included for Visual Studio Code.

The Economy starter requests the ammunition category. The container starter uses scope='storage' for supported base chests and vehicle cargo; choose chests and cargo separately for independent multipliers. Use Framework 1.7.1 and Launcher 2.1.1. Retain each handle through acknowledged restoration and preserve occupied capacity.

The stacks starter declares Framework 1.4.5 and the checked Steam profiles. Any author can request app:stack_limits{preset=2} with its own consumer ID. A same-preset handle:update{preset=2} requests one bounded revalidation of owned definitions and loaded item caches; inspect its acknowledged revision and state. Unready inventory work remains queued with capped retry delays. Idle reconciliation checks session, world and item-table identity without a recurring full inventory scan. Retain the handle during recovery and await stopped before closing the context.

Use Framework 1.7.1 with the pinned UE4SS 1140 runtime. On checked Steam builds, the chest service verifies exactly four chest definitions in BuildingSubsystem's authoritative CDT_PlaceableData composite, including equality with the game's cached row allocations. The runtime handles existing chest refresh and later creation notifications through the same public container_capacity API. Other instances of those four chest classes outside a player base can also receive the volume change. The candidate chest-definition catalogue covers Steam 25486029, 25611704 and 25690505 and Microsoft PC 2.0.10.0 and 2.0.12.0. Older Microsoft 2.0.8.0 and 2.0.9.0 profiles retain their checked player-base instance path. The API reference documents each profile and its limits.

The jobs example performs small planning steps and schedules a read-only session check. Keep individual engine closures short: the scheduler yields between calls and cannot interrupt a single engine call. app:close() cancels outstanding jobs.

The table starter inspects the existing vendor row without changing prices or stock. It then applies, verifies and rolls back a practice change to a private Lua record. Its separate transaction.lua helper shows how to connect the same mechanism to your own tested game accessors. The pak, native and hybrid starters intentionally fail publication checks until their real content or DLL is supplied.

The UI, material, animation, physics and environment examples begin with discovery and observation. Select an exact target you own and explicitly enable their change before expecting a visible effect. The communication example needs a second generated project with a different Mod ID to demonstrate a reply. These examples keep their own identities and do not modify the existing WPS mods.

Community mods can choose an independent Lua, native or pak starter. For this release, use Launcher 2.1.1 and the matching Framework 1.7.1 with your compatible gameplay packages. Economy 1.2.11 Beta uses the Framework with Creation Tools. Existing packages retain their declared dependency minimums; this storage update does not extend Stack, merchant or creation capability coverage. Keep author examples in their own test profile. The merchant example adds an offer rather than granting an item. Capacity examples request shared ownership, so leave overlapping capacity presets disabled during that test.

To find a supported schematic identifier for your merchant example, open Supported items and search by name or paste an exact identifier. The lookup shows the supported game build, CHOAM merchant and Solaris currency alongside the matching schematic IDs. It reads the supplied catalog and does not grant items.

Paste an exact identifier to check one schematic before adding it to your merchant example.

The same search from a terminal is python kit/wps.py items ornithopter --limit 20. The catalog contains identifiers, not game assets or item grants.

For shop stock, item categories, buyback changes and filters, use the current shared Economy API documented in the Dune merchant integration reference. The original schematic-offer API retains its validated schematic contract. The Framework coordinates the exact owned merchant offer and reports conflicting values before writing; a matching item ID alone does not establish ownership. Economy accepts bounded author-supplied contributions with explicit grade and price policy; see the reference for validation and ownership. Do not install or activate a second WPS Exchange native runtime alongside the shared Framework.

For those 484 schematics on the supported build, an offer's price is the baseline Solaris amount; the game can apply further pricing modifiers. Verify the displayed amount and a purchase. For controlled cleanup, stop a service handle and wait for its stopped acknowledgement before closing the mod context. app:close() alone does not confirm that the shared service has finished restoring game state.

The same creation step from a terminal in the kit directory is:

python kit/wps.py new C:\DuneMods\MyFeature --id MyFeature --name "My Feature" --author "Your Studio" --description "Describe the player benefit." --template settings

Choose and verify PC editions

New projects use manifest schema 2. The command line and workbench default to both PC editions; use --edition steam or --edition microsoft for one edition. The generated game section looks like this for both:

{
  "editions": [
    {"store": "steam", "steamAppId": "1172710"},
    {"store": "microsoft", "packageName": "FuncomOsloAS.ProjectSeabass"}
  ]
}

The stack starter declares Framework 1.4.5; backpack and scoped container starters declare Framework 1.4.3; Economy, merchant and event starters declare 1.4.6; other current Framework starters declare 1.4.0 separately from wps-launcher and the required UE4SS runtime. The generated Launcher declaration retains its 1.1.3 minimum; install Launcher 2.1.1 or newer for the complete current Framework package. Build-specific native examples declare only the editions and game profiles supported by their implementation; keep those declarations aligned with the generated manifest and your gameplay evidence. Independent Lua, native and pak projects retain their own requirements and do not acquire a Framework dependency.

After testing your feature on an edition, record the matching Steam build in supportedBuilds or Microsoft package version in supportedVersions. These optional lists contain 1–512 strings and provide an advisory when a player's version is unlisted. Steam build IDs and Microsoft package versions are separate identifiers. Package versions have four numeric components, each from 0 to 65535; leading zeroes normalize numerically.

Launcher 2.1.1 treats game editions, tested-version lists and minBuild/maxBuild or minVersion/maxVersion ranges as compatibility information. An unlisted edition, an unavailable version or a version outside a declared range does not exclude the mod or require a launch confirmation. Players can read the notes in the selected mod's details; author validation includes them in warnings. Keep declarations accurate, and enforce any required game interfaces inside the mod. Existing Framework checks remain unchanged and may leave a feature inactive. Dependency versions, wrong-game identities, malformed declarations, conflicts and package checks still apply. Schema 2 accepts tested lists alongside declared ranges. Run the Kit's lint check as well as the editor schema check: lint validates the declaration shape and numeric bounds.

A manual profile is an explicit author declaration: {"store":"manual","runtimeChecked":true}. Add it only after checking that installation route yourself. It does not supply a Steam build or Microsoft package identity and does not validate native offsets. The Kit's Create view still offers Steam, Microsoft or both; add any manual declaration deliberately in your manifest. Neither an edition entry nor folder selection proves that a mod works.

For Framework consumers, call app:compatibility() on the game thread to inspect installation identity, reflected support and the current checked Inventory layout. reflected.supported covers the core session signatures; every operation retains its own interface checks. app:gate() keeps the private-layout requirement, while app:gate('reflected') selects reflected session access. The Framework obtains Inventory proof from checked native function bodies when private support is requested, rather than accepting an edition or version label alone. Metadata-only startup does not perform that private proof. Stack and Water check their own profiles independently. A matching profile does not prove gameplay acceptance or authorize a custom offset. The API reference describes the returned fields and failure reasons.

Inventory layout and capacity setters may be matched independently only when their native profiles declare the same explicitly proven ABI group. Exact code checks remain mandatory. Launcher 2.1.1 updates a matching installed mod transactionally, keeps recognized saved-data settings, and retains the previous folder for recovery. Durable session records also support a moved launcher or missing local State folder while preserving unrecognized and externally changed files.

Check and test

Launcher 2.1.1 can validate the folder containing your mod folders against an installed game:

WPS_Dune.exe --validate "C:\DuneMods\Mods" --game "C:\Games\Dune Awakening" --report "C:\DuneReports\validation.json"

For a package check against a supplied Steam build, use --game-build instead of --game:

WPS_Dune.exe --validate "C:\DuneMods\Mods" --game-build 25611704 --report "C:\DuneReports\steam.json"

Both schema-1 and schema-2 packages support the supplied-build check. Unlisted editions or versions and versions outside the author's declared range produce advisory warnings, with a successful exit when no blocking package, identity or dependency error exists. The command does not inspect a game installation or establish runtime compatibility. Use --game for installation inspection, including Microsoft editions. Save each report to a new file outside the inspected game and Mods folders. Test the mod in-game before listing a build as tested.

Open Check & package, browse to your project, and choose Check project. This catches misspelled manifest fields, missing dependencies, mismatched folder IDs, absent entry points, unsupported files and nested archives. It only parses Lua syntax; it does not execute project code. Install Lua 5.4 with its luac compiler before the release check.

python kit/wps.py lint C:\DuneMods\MyFeature --require-syntax

You can run your own trusted Lua project against the included offline engine mocks:

python kit/wps.py test --project C:\DuneMods\MyFeature --framework C:\WPS_Dune\Mods\WPS_Framework --scenario solo
python kit/wps.py test --project C:\DuneMods\MyFeature --framework C:\WPS_Dune\Mods\WPS_Framework --scenario menu
python kit/wps.py test --project C:\DuneMods\MyFeature --framework C:\WPS_Dune\Mods\WPS_Framework --scenario wrong-build

These tests execute the project in a temporary copy using a Lua 5.4 interpreter. They exercise bounded callbacks and collect the mod's logs. They are development tests, not a security sandbox or a substitute for playing the mod. Extend the fixture for your own game objects as your project grows. Running python kit/wps.py test without a project runs the kit's own regression suite.

The basic offline fixture does not simulate a merchant purchase or a complete backpack. A service request can queue successfully while remaining unavailable in that fixture. Read handle:status() and verify the actual feature in Dune; a successful process exit is not proof that the service applied a game change. The API reference explains acknowledgement, conflicts and safe cleanup.

For the game test, close Dune, copy your finished Mods\MyFeature folder into the launcher's Mods directory, and enable its declared dependencies before your mod. Launch a local Singleplayer session through the launcher. Verify startup, world entry, your feature, save/load, object replacement and the combination of mods you intend to support. Restart the game when updating scripts. Keep existing Framework settings during updates.

The Environment tab checks the actual bundled runtime files and reads the selected PC installation's metadata. Choose the launcher folder and the game's installation root, Xbox Content folder or executable. Folder selection works without choosing a store; missing store details remain unknown. The Framework checks a native layout when a consumer requests the corresponding capability. A Steam manifest can supplement a matching Steam installation; it cannot supply a build number for an Xbox app installation. Protected Xbox executable content is reported as unreadable while available package metadata is preserved. This check does not launch the game or certify mod loading.

The bundled item and reference captures retain their original provenance: Steam build 25486029, with UE4SS 3.0.1-1140-gf58e8f84. Microsoft's 2.0.7.0 is a separate package identity. Test the actual feature on each selected edition before declaring its tested versions.

Edit settings

Open Settings & support and select your settings.schema.json, an existing settings JSON or the starter's settings.example.json, and a new output filename. Choose Open settings editor, change the values and save. Validation catches incorrect types and ranges; unknown setting keys survive.

A Framework settings file contains schemaVersion and values. Runtime settings live in the launcher at Mods\WPS_Framework\settings\<ModID>.json. The author editor writes a separate file so you can review it before replacing the runtime settings while the game is closed.

Reproduce a mod combination

Export an immutable test profile containing the selected mods, their order and file hashes:

python kit/wps.py profile export --mods C:\WPS_Dune\Mods --select WPS_Framework MyFeature --file C:\DuneTests\solo.json
python kit/wps.py profile import --mods C:\WPS_Dune\Mods --file C:\DuneTests\solo.json

Import checks the supplied local files and reports missing, additional or changed content. It does not install mods or alter launcher selections. The launcher remains responsible for dependency ordering and launch compatibility.

Declare the resources your mod touches in resources.json:

{"schemaVersion":1,"resources":[{"kind":"property","target":"asset:/Game/YourAsset#Row.Field","access":"write"}]}

Use the same resource identity in your Framework transaction or claim. Compare projects with python kit/wps.py overlap C:\DuneMods\First C:\DuneMods\Second. The report identifies possible overlap between declarations and any supplied pak-list.txt entries. Undeclared changes remain unknown; shared resources do not automatically mean two mods conflict.

Generic resource claims and the shared merchant/backpack services have separate ownership records. Use the service APIs to participate in their coordination. Declaring a resource or taking a generic claim does not automatically reserve a merchant offer or backpack service request.

Find useful Unreal information

Browse the maintained API

The searchable API definitions cover public Framework methods, named engine operation, game query group and supported event. Start with a feature such as weather, then select a result to see its exact call and requirements.

Double-click an entry to read its full arguments, limits and cleanup behavior.

Open API lookup, choose a subject or catalog, and search by feature. Results include the method or operation ID, arguments, target class, return value and relevant limits. Select exact operation matching when checking a known ID.

python kit/wps.py api camera
python kit/wps.py api --key framework.request --source infrastructure
python kit/wps.py api animation --source engine

The engine catalog covers 47 operations and six actions across UI, meshes, materials, animation, physics, cameras, audio, lights, fog and landscape material access. Named query/change operations use engine_query and engine_change. Infrastructure and game entries are direct methods such as app:request() or app:player_snapshot(); their catalog IDs are not engine operation IDs.

The Dune adapters return copied information about the current player, vitals, training, equipment, vehicles, input, weather, crafting, knowledge, game settings, components and world queries. Supported observational events help a mod respond to game changes. The complete API reference lists each signature and what is available for the supported game build.

Framework 1.4.6 adds tech_points_changed, recipes_changed, crafting_item_changed and contracts_changed through the existing app:on_game() method. They observe checked local component handlers after execution. Their copied payload has phase='post' and no reflected parameters; read a supported snapshot when you need values:

local subscription, problem = app:on_game('recipes_changed', function(event)
    local page, why = app:crafting_snapshot{source='known', offset=0, limit=32}
    if page then
        app:log('info', tostring(page.total)..' known recipes in this source.')
    elseif why then
        app:log('warn', why.message)
    end
end)
if not subscription then app:log('warn', problem.message) end
-- Cancel the subscription when this feature is disabled.
-- Framework context cleanup also owns its hook cancellation.

These are function notifications, not a guarantee that a player action succeeded or that every native update path emitted a notification. Registration belongs to normal mod initialization; do not move app:on_game() or app:hook() registration into a game-thread timer. The game section of the API reference describes local-component filtering, replacement handling and verification limits. Generic app:hook() keeps pre-call behavior by default and accepts {kind='native', phase='post'} for a native post observation. Callback returns do not replace the game's return value.

For reusable mod logic, use watch_player for replacement transitions, every, debounce and throttle for controlled work, data for independent local stores, and keybind or command for managed input. Use subscribe/publish and provide/discover/request to exchange bounded plain data across Lua mods. Game objects and callbacks remain local to the mod that owns them.

Checked changes retain a cooperative claim until restoration. A later external edit or replaced object can prevent rollback; inspect the returned error instead of assuming a cancelled timer restored the change. Native actions such as playing an animation or applying an impulse have effects over time and do not return a restoration transaction. Details and examples are in the engine and infrastructure sections of the API reference.

Search your local reference exports

The Reference tab indexes your own text, header, JSON and CSV exports. Enter an export folder, a new database filename and its Steam build, then choose Create index. Enter a class, property, function or asset name and choose Search index. Keep your original exports and databases outside player packages.

python kit/wps.py ref import C:\DuneRefs\build25486029 --db C:\DuneRefs\25486029.db --build 25486029
python kit/wps.py ref search Backpack --db C:\DuneRefs\25486029.db
python kit/wps.py ref diff C:\DuneRefs\old.db C:\DuneRefs\new.db --report C:\DuneRefs\changes.json

The comparison removes common volatile memory addresses and reports text changes with source/build provenance. It helps you find changes after an update; it does not establish binary-layout compatibility.

The optional reflection probe creates an author-only mod that prints bounded class/member information when you press Ctrl+Alt+F8:

python ue/tool.py probe-init --out C:\DuneTests\WPS_Probe --class-name DunePlayerController

The probe uses the supported runtime's existing reflection and game-thread facilities. Remove it from your release. Upstream UE4SS also provides a Live Viewer and object/header/mapping dumpers. Those documents describe upstream capabilities; the Launcher documents its configured hook settings separately from the Framework wrapper. The kit's doctor reports the actual profile. Do not assume an upstream shortcut or a newly documented API is available in the pinned runtime.

Build Unreal content

Separate deployment from game acceptance

The Launcher can import and stage compatible Pak and IoStore files. Its package checks cover folder layout, metadata and companion filenames; they do not ask Dune to mount the files or verify an asset replacement. A successful offline package listing is also separate from game acceptance. Framework registration, a WPS.cat publisher catalog and Windows Artifact Signing do not supply Dune's container format or game cryptographic signature.

The retained Steam 25611704 container investigation found a concrete format requirement: Dune's version-11 Pak reader uses a 261-byte custom footer, including stored magic 0xa590ed1e, while a standard Unreal version-11 Pak uses a 221-byte footer. The submitted standard-format texture Pak could not satisfy that reader. Two installed stock Paks agreed with the game's custom layout. An empty Pak file listing is not by itself this defect; the footer/layout must agree with Dune.

The full game-specific layout, index data, checksums, cooked packages and applicable signing requirements must agree. Changing only a magic value or adding footer bytes is not an established conversion method. The Kit includes the checked Dune container writer and signature verifier, plus a signing builder for the supported uncompressed, unencrypted, single-partition profile. Verification authenticated shipped game containers. The signing builder requires an authorized RSA private key matching the game’s public key; no matching game private key was found in the examined WPS configuration. Its test-key roundtrip verifies the builder without claiming a game-trusted authored signature.

Cooking remains a separate authoring step. The container tools do not convert arbitrary stock UnrealPak output into compatible cooked assets or certify their loading and gameplay. The general cooking and packing commands retain their own saved executable profile; the retained container profile and signing tools are separately checked for Steam 25611704. Read ue-contract.md in the Kit for exact commands, supported formats and verification boundaries.

An installable folder and manifest example

This example demonstrates the Launcher package structure and schema-2 metadata. The container filenames are placeholders for an author's compatible built payload; the example does not include or certify working content:

Mods/
  MyTexture/
    mod.json
    Paks/
      MyTexture_P.pak
      MyTexture_P.utoc
      MyTexture_P.ucas

{
  "schemaVersion": 2,
  "id": "MyTexture",
  "name": "My Texture",
  "version": "0.1.0",
  "author": "Your Studio",
  "description": "Author's texture replacement.",
  "type": "pak",
  "game": {
    "editions": [{"store": "steam", "steamAppId": "1172710"}]
  },
  "requires": [{"id": "wps-launcher", "minVersion": "1.1.3"}],
  "copyright": "Copyright (c) 2026 Your Studio. All rights reserved."
}

Place MyTexture directly inside the Launcher's Mods folder, or ZIP the Mods/MyTexture tree for import. Keep matching .utoc and .ucas companions together. If an author supplies a .sig, retain its matching Pak basename; a filename match does not validate its signature. Do not add Framework or UE4SS dependencies to a pure Pak solely to make the Launcher recognize it. A Lua or native companion declares the runtime dependencies it actually uses.

The Steam edition entry is a declaration, not a tested-build claim. Add supportedBuilds only after the actual mod is exercised on those builds. Game-version ranges describe author coverage in Launcher 2.1.1; check required runtime interfaces inside the mod. An asset override must match the intended mounted cooked package and object identity, not just a similarly named file. Newly namespaced content needs a separately verified way to be loaded and used. Test mounting, the intended texture or material, normal streaming and save/reload behavior before advertising game support.

Author, cook and inspect

Use Unreal Engine 5.2.1 for the audited game profile. First discover what is actually installed:

python ue/tool.py discover --plugins
python ue/tool.py content-init --id MyContent --out C:\DuneMods\MyContent

Add your own assets inside the generated project's Content\MyContent folder. The project enables unlimited bone influences. Open the project in the compatible editor and prepare the content, then cook and package it:

For a first practice asset, python ue/tool.py content-sample --project C:\DuneMods\MyContent --engine C:\Epic\UE_5.2 uses the installed editor's Python tools to create a namespaced purple material inside the project. This is authored sample content; seeing it cook successfully does not make it appear in the game automatically.

python ue/tool.py content-cook --project C:\DuneMods\MyContent --engine C:\Epic\UE_5.2 --game "C:\Games\Dune Awakening"
python ue/tool.py content-pack --project C:\DuneMods\MyContent --engine C:\Epic\UE_5.2 --game "C:\Games\Dune Awakening" --out C:\DuneReleases\MyContent

Replace the engine and game paths with your actual installation paths. Cooking requires real source assets. content-pack builds a matching .pak, .utoc and .ucas set in Mods\MyContent. It rechecks the cooked files and package-store metadata, tests the pak and verifies that the IoStore listing contains the authored packages. Keep all three files together. Generated global containers and registries remain in the author project and are excluded from the mod.

The general Unreal tools create source assets, cook them with Unreal Engine 5.2.1, build matching stock Pak and IoStore containers, and inspect their package contents. Those construction checks used the captured Steam build 25486029, where the live test rejected the unsigned authored sample. Their saved executable profile remains separate from the current Economy profile. For the retained Steam 25611704 evidence, native inspection confirms IoStore signature enforcement, and the Kit's independent verifier authenticated shipped game signatures and payloads. The signing builder is checked with test keys and requires a matching authorized game private key to produce game-trusted signatures. The Kit supplies no such key. Cooking, format verification and signing checks each have distinct coverage; acceptance of an author's actual assets still requires a game test. Lua and native author workflows have separate validation results. Epic's cooking documentation explains the cook process.

For the supplied Lua-and-content starter, use content-init --hybrid. That generated companion imports the Framework and declares it as a dependency. Pure pak mods require only the launcher; an independently written Lua companion need not adopt the Framework.

Build a native UE4SS mod

Native authoring uses the exact supported UE4SS SDK and an x64 MSVC toolchain. Use sdk-prepare with your local source checkouts and runtime DLL to assemble the pinned headers/import library; python ue/tool.py sdk-prepare --help lists the required paths. Original dependency notices remain part of the prepared SDK.

python ue/tool.py native-init --id MyNative --out C:\DuneMods\MyNative
python ue/tool.py native-build --project C:\DuneMods\MyNative --sdk C:\DuneSdk --runtime C:\WPS_Dune\Runtime\ue4ss\UE4SS.dll

The starter implements the native lifecycle and the builder checks the resulting exports. Native mods load before Lua, so they declare the launcher and UE4SS requirements without depending on the Lua Framework. A successful build needs a separate in-game lifecycle test.

Advanced asset inspection is available through assets-build, assets-index and assets-export. These use your supplied CUE4Parse libraries and Oodle DLL to inspect the audited game build without modifying it. Use each command's --help; exported game data is local reference material and is not part of the kit or your player download.

Inspect a native interface with Ghidra

The optional helper in ue/research inspects five inventory functions in the exact supported game executable. It checks the installation and executable fingerprint, runs a bounded Ghidra analysis, and writes a factual report plus local decompilation output to a new folder. It does not launch Dune or change its executable. The tested tools are Ghidra 11.4.2 and JDK 21; supply your own installations.

python ue/research/focus.py --game "C:\Games\DuneAwakening" --ghidra "C:\Tools\Ghidra" --out "C:\DuneRefs\inventory-native"

The generated report records the inspected build, reflected signatures, calling boundaries and research evidence. Research addresses are not a stable cross-version API. The Framework supplies its own checked native inventory adapter through the shared capacity services. Use those public services for supported changes; new native interfaces still require their own calling-convention, lifetime and gameplay validation. A matching executable or clean build alone does not establish that work.

For an MCP-capable development client, python ue/research/mcp.py exposes the same operation as the stdio tool wps_ghidra_inventory, with game, ghidra and out arguments. Adapt ue/research/mcp.example.json to your client's configuration and kit path, and allow more than 300 seconds for the tool timeout. Registration is optional and manual; the kit does not change global integration settings. Analysis creates local files. Keep the output's local directory, imported game data and game binaries out of public packages.

Prepare a clean release

Set your version and final description in mod.json. List the launcher and any additional dependencies your mod actually uses on its Nexus page. Use real feature screenshots and a clear player description. State the game build and what you actually tested.

In Check & package, enter a new ZIP filename outside your mod payload and choose Build release ZIP. The ZIP contains Mods\<ModID>\... and no nested ZIPs. Local logs, saves, tests, runtime binaries and development folders are excluded or rejected. The adjacent *.files.json records the package and file hashes.

Package checks follow the launcher's import limits: at most 10,000 files and folders, including parent folders implied by file paths; at most 24 path components, including Mods and the Mod ID; at most 2 GiB per file and 4 GiB of expanded files. Names must be valid Windows names, without device names, alternate streams, trailing spaces or dots, or paths that collide when capitalization is ignored. Keep paths short. The launcher checks the complete destination path on each player's machine; the Kit cannot predict that installation location.

The Kit streams payloads into a standard ZIP, verifies the archive's CRC and records file hashes. ZIP64 output is not supported by the launcher. If the Python ZIP writer reports that ZIP64 is required, divide the release into smaller independently installable mod downloads. Keep screenshots, illustrated guides and author tools on the website or in the optional Kit; include only required runtime resources and notices in a player download.

python kit/wps.py package C:\DuneMods\MyFeature --out C:\DuneReleases\MyFeature_1.0.0.zip --require-syntax

Packaging does not sign a release or scan it for malware. Use your own signing identity if you sign binaries or catalogs, scan the final unchanged files with Microsoft Defender, and upload the player ZIP directly. Keep the optional author kit separate. Make each release's test claims match its evidence.

Install and replace a test package

1. Close Dune before changing installed mods. If Windows marks a downloaded ZIP as blocked, right-click it, choose Properties, select Unblock, and choose Apply. A locally generated ZIP may not have an Unblock option.
2. Drop the ZIP onto the launcher's Drop mod ZIP here or click to browse area, or click that area and select the ZIP. Keep its Mods/<ModID>/ layout intact. The launcher stages and checks the package before adding its mod folders to the list. The Modder Kit and launcher downloads are separate tools, not installable mod ZIPs.
3. New imports start disabled. Review the imported entry, its version and any requirements or conflicts. Enable the mod and its required dependencies, adjust its order when needed, then launch your gameplay test. Both folder and ZIP pickers use the last confirmed import directory.

If that mod folder is already installed, back up settings stored inside it and note its enabled state and load order before replacing it. Highlight the old entry, choose Delete mod, and confirm the displayed name and folder. This moves the entire installed folder, including its local settings, to the Recycle Bin. It leaves the original downloaded ZIP unchanged and does not remove other mods. Import the new ZIP, restore only settings compatible with the new version, and review the replacement's selection and order. An unresolved dependency must be corrected before launching.

For testing directly from a project, Add mod folder copies the selected extracted mod folder into the launcher. It does not link the launcher to your source tree. Repackage or reimport after changing sources, and restart the game to load updated scripts.

To request help, select only relevant text logs in Settings & support and choose Prepare support report. The kit removes common credentials, email/IP/account identifiers and user paths, then writes a local JSON file. Read it before sharing; add any project-specific secrets using the command line's repeatable --redact option. Reports are never uploaded automatically.

Built-in WPS container writer

The Kit includes the source and iostore-pack command for the same WPS writer used inside Launcher 2.1.1. It writes uncompressed UE 5.2 IoStore companions from prepared Zen package data. Read ue-contract.md in the Kit for the exact specification, bounds and limitations. This author command does not convert arbitrary legacy assets or cook source content. The player Launcher writes its selected Economy assets internally before game launch; players need no packing executable, Python or author compiler.

Framework hooks and independent UE4SS mods

The Framework's app:hook wrapper observes loaded native UFunctions only; its capability flags describe Framework services. Independent mods can use UE4SS directly without a Framework dependency. Launcher 2.1.1 retains UE4SS 3.0.1-1140-gf58e8f84. The Launcher enables all 14 upstream hook settings for every selected mod and supplies Dune's checked virtual-table mappings: ProcessEvent 85, ProcessConsoleExec 88 and LoadMap 169. These settings are independent of WPS feature selections. The standalone Steam 25690505 test verified Blueprint/native callback delivery and unregistration; Microsoft PC 2.0.10.0 has static mapping evidence only. See the verification scope before declaring a feature tested.