tehAon’s Drone Automation Kit – Junk Drones Do Your Chores

1. Scan center moved from the drone to the player (SalvageCore, HarvestCore, RepairCore, PlantCore). Every block module used DroneWorld.CollectParents(_world, _drone.position, ...); now it's _owner.position. The drone hovers a few meters off your side and drifts, so its bubble often didn't cover what you were standing next to — this is the fix for the truck-wreck bug you reported. RepairCore.Tick and PlantCore.Tick gained an EntityPlayer _owner parameter to make this possible, and DronePatch now passes owner into them. Auto-Loot (VacuumCore) is untouched — its reach was already wide.
2. Auto-Salvage will no longer destroy uncollected loot. New HoldsUnlootedContents() guard: it skips any block whose tile entity is lootable and is either untouched, non-empty, or player storage. This is the one change that removes capability — Auto-Salvage will now refuse to wrench a lootable object (tilt truck, cabinet, safe) until you've emptied it. That's deliberate; previously it was silently destroying loot, and untouched world containers read as empty while still being able to pay out.
3. Traders can now actually stock the drone modules, as a consequence of the xpath fix. Rolls on restock; can't disturb existing trader inventories.

The page was still serving 0.4.2, so this release carries everything since: Auto-Defense, module quality on crafted modules, and settings that survive an update.
**0.7.0 — 2026-08-01**
- **Your settings now live in `droneautomation.local.xml`.** Drop a file of that name beside
`droneautomation.xml` holding only the values you want different, and the mod folds it over its own
config at load. Attributes are matched by element name plus `name=`, so overriding the second of
several same-named blocks cannot silently edit the first. Nothing is written back to the file the
mod ships, so a mod update or a Nexus re-extract can no longer wipe what you changed. No local file
is shipped in the release zip — it is yours, and it stays yours.
- Build-only: `SkipDeploy=true` stops the post-build copy into the live `Mods` folder, so a release
can be cut while the game is running. Mono keeps the deployed assembly mapped for as long as the
client is up, and overwriting it under a live game risks a SIGBUS.
- The release zip now carries the verified game version in its name (`_gameV3.0.0`), matching the
other tehAon mods — `ModInfo.xml` has no field for it, so the file name is the only place it fits.
---
**0.6.0**
- **New module — Auto-Defense (`modRoboticDroneAutoDefenseMod`): the drone becomes a bodyguard.** It
fires its own machine gun at the nearest hostile as it follows you, or stands sentry over the spot
where you park it (the vanilla "stay" command). Kills are credited to you (XP and quests), and it
never targets you, your allies, party members or traders. Server-side only, EAC-safe, and vanilla
clients see the muzzle flash with nothing installed.
- This reuses combat the junk drone has always carried but never used: `EntityDrone` ships a full
weapon rig (`MachineGunWeapon`, an `Attack` state, an `attackMode`) that The Fun Pimps left
disconnected — `attackState()` is empty and the gun is never instantiated. The module drives that
real gun, so the drone's own hitscan, damage and …

- **Fixed: v0.7.3 could not run on game 3.0.0, which it claimed to support.** If you are on 3.0.0,
Auto-Loot — the module most people install this for — threw the first time the drone tried to put
something in a bag, and kept throwing. Every other module that stores an item was in the same
boat. 3.0.1 and 3.1 were unaffected.
Nothing in the source was wrong. The released DLL was compiled against a newer game than the
oldest one on its label, and that is enough on its own. 3.0.1 introduced `InventoryBase` as a base
class above the inventory types and moved `AddItem` and `TryStackItem` up onto it, so a build made
against 3.0.1 or later points those calls at `InventoryBase` — a type 3.0.0 has never heard of.
The direction matters and it is worth stating plainly, because it is the part that is easy to get
backwards. A reference made against a *derived* type still resolves on newer builds, because the
runtime walks up the hierarchy to find the member. A reference made against a *base* type that was
introduced later resolves on nothing older, because the type itself is missing. So the build has
to be made against the **oldest** version claimed, not the newest.
What makes this worth a release note rather than a one-line fix is that every check passed. The
build succeeded. `refcheck.py` against 3.1 passed — it was only ever run against the newest build.
A live 3.1 dedicated server booted the mod cleanly. None of it could see the version that broke.
- **`package.sh` now refuses to build a zip whose label it cannot back up.** New
`tools/check_game_versions.py` reads `GAME_VERSIONS`, locates a game build for each version named,
and resolves every external reference in the DLL against all of them. A claimed version with no
build available fails too, rather than quietly passing — an unverified claim is the whole bug.
`GAME_BUILDS` says where the builds live (default `~/7dtd-servers`); `SKIP_REF_CHECK=1` skips it
for anyone packaging without them.
- **`BUILD.md` now records whic…

- **Fixed: Auto-Harvest minted a free seed every time it reaped a crop.** A crop's harvest drops
include its own young stage — `plantedCorn3HarvestPlayer` lists
`<drop event="Harvest" name="plantedCorn1" tag="farmerBonusSeed"/>` — and the module banked that
seed in the drone's bag *and* separately planted a fresh one in the empty plot. Two seeds where the
crop produced one.
That is not what harvesting by hand does. Vanilla leaves a reaped plot **bare**: crops ship with
`DowngradeBlock` commented out, and a block with no `DowngradeBlock` resolves to air
(`Block.cs:1789`, and the downgrade path at `Block.cs:2461` only runs when it is not air). The seed
the crop hands you is the one you are meant to spend putting the plot back. So a drone farm quietly
produced a spare seed per crop per cycle — on a 27-plot field, 27 seeds a cycle, compounding into
more plots.
Auto-Harvest now pays for the replant with the seed it just reaped. `EmitDrops` takes an optional
`_payOne`, withholding a **single unit** of that one item from the payout, so perk-boosted seed
drops still hand over the surplus — only the one seed the drone plants on your behalf is consumed.
Produce is untouched.
- **Auto-Harvest now says why it reaped nothing.** With `Debug="1"` a pass that harvests nothing
prints the numbers behind the decision instead of a flat "nothing in range":
```
harvest: anchor (666,61,907) r=9.6/6.4 q6: 2201 blocks, 27 grown crops,
0 outside your claim, 27 with no replant
```
Each figure points at a different cause — out of reach, wrong claim, or no replant — and the anchor
and post-quality radius are printed because for a *following* drone the scan is centred on the
**owner**, not the drone, which is its own easy misread. "Nothing in range" is not a useful thing to
tell someone standing in a field of corn.
This came out of a playtest where Auto-Harvest appeared dead. It was not: the field had been spawned
with the **wild** crop blocks (`plantedCorn3Harvest`), which carry produce …

- **Switch a module off without pulling it out of the drone.** Hold **E** on the drone → **Talk** →
**Automation modules…** and every automation function gets a row reading `Auto-Loot: ON - switch it
off` (or `OFF - switch it on`). Clicking it flips the switch; the module stays in its slot and keeps
its quality, it just stops acting. A **Switch every module back on** row clears the lot. The setting
survives relogs and server restarts.
Asked for as a hotkey, which this mod cannot do. Key bindings are client config and the radial wheel
is client code — `EntityDrone.InitLocalActivationCommands`, `AllowActivationCommand` and
`OnEntityActivated` all take an `EntityPlayerLocal` and only ever run on the machine holding the
camera. Either one would mean shipping a client DLL and ending the mod's "install it on the server,
players install nothing" rule.
The wheel's own **Talk** entry is the way in without breaking that rule. It opens the XML dialog
`junkDrone`, and `WorldStaticData` registers both `dialogs.xml` and `buffs.xml` with
`_sendToClients: true` — the server pushes its patched copies to every vanilla client, which parses
them locally. So a server-side modlet can put rows in that menu, one click deeper than the wheel.
Each row is half of a matched pair guarded by opposite `CheckCVar` requirements, so exactly one is
ever visible and the visible one is both the readout and the switch (`XUiC_DialogResponseEntry`
drops a row whose `requirementtype="Hide"` requirement fails). Clicking it adds a hidden permanent
buff that writes one CVar — `AddBuff` is the only write the dialog system exposes that isn't quest
or trader plumbing. That buff net-syncs, so the client runs the effect immediately (the row flips
under the cursor) and `NetPackageAddRemoveBuff.ProcessPackage` re-applies it on the server, where
`DronePatch` reads the result. No polling, no custom network packet, nothing for a vanilla client
to be kicked over.
The switch buffs are **permanent and fire on `onSelfBuff…