tehAon’s Drone Automation Kit – Junk Drones Do Your Chores (Server-Side)

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…

- **Fixed: Auto-Salvage wrenched the switches that make a POI work.** A `powerSwitch01` on the wall
next to a garage door, a push button, a valve handle, a key rack, a wire or timer relay, a pressure
plate, a quest generator — every one of them is tagged as salvage in the game's own block data, so
the module took them exactly the way it takes a sink. The damage is invisible at the time and
permanent afterwards: none of those blocks is craftable or in a loot list, so the door they opened
never opens again, for the life of the save, for every player who comes to that POI after you.
Auto-Salvage now leaves switches, buttons, relays, pressure plates, quest triggers and powered
doors, lights and traps alone. It is matched on the block's class rather than a list of names, so a
modded switch that derives from one of them is covered too. `SalvageSwitches="1"` in
`droneautomation.xml` puts the old behaviour back for anyone who wants it.
- **Fixed: the land-claim rule had three ways to quietly not apply.** Auto-Salvage has always been
meant to work unclaimed ground only, and it asked the game the obvious question — but
`World.GetLandClaimOwner` answers "unclaimed" for claimed ground in three cases: the claim block's
chunk is not loaded, the claim block is not the owner's *primary* one, or the owner has been away
long enough for land protection to lapse (`IsLandProtectionValidForPlayer`). On a server, the third
is the one that bites: go on holiday for longer than the server's land claim expiry and a drone can
strip your base while the claim block is still standing in it.
The module now also reads the persistent claim map directly, which has none of those holes: a claim
block that exists protects its ground, whoever owns it and whenever they last logged in. There is
no setting for this one, and there should not be.

- **You can tell Auto-Salvage what to leave alone, in game, without looking anything up.** The
obvious design — point at the thing and exclude it — does not work, because by the time anyone
notices the drone ate the working vending machine, there is nothing left to point at. So the
interface starts from what it just did:
- `/das last` — the last 20 things it salvaged, newest first.
- `/das skip 3` — never take that kind of thing again. A log line means the whole family by
default (one wrecked sedan means every sedan), `/das skip 3 exact` for the one block.
- `/das allow <name>` — undo a skip, or permit something held back.
- `/das list *vending*` — every salvageable block on **this** server matching a pattern, read
from the running game, so it covers whatever overhaul or POI mod is installed.
- `/das what` — name the block you are looking at, before it is taken.
- `/das rules` — what is in force. Allow beats skip, so "none of this family except that one" is
sayable: skip `cnt*`, allow `cntToilet*`.
Every rule reports what it actually covers when you add it (`7 block(s): cntVendingMachine, ...`),
because a wildcard is easy to type and easy to get wrong.
- **The drone says the first time it takes a new kind of thing**, once per kind per world, with the
command to stop it. That is the moment a player finds out this is configurable at all.
`AnnounceNewTargets="0"` silences it.
- **`NewTargetPolicy="ask"`** for servers that want nothing touched without consent: an unfamiliar
block family is left standing and reported instead of salvaged, until someone allows it. Default
stays `"allow"` — today's behaviour — so no existing server changes on update.
- Exclusions now take `*` as a wildcard, in `droneautomation.xml` and in `/das` alike.
- Rules set in game are stored in the **save** (`droneautomation-salvage.xml`), not the mod folder,
so they survive a mod update and belong to the world they were made for. The config file's own
`<exclude>` entries are merged in …

- **Claims game 3.2.0.** No code changed. Every external member the DLL binds to was checked against
a 3.2.0 build with `refcheck.py` and all of them resolve, so the range widens from `V3.0.0-V3.1` to
`V3.0.0-V3.2.0` on evidence rather than on hope. The old label meant "the newest version anyone had
got round to checking", not that 3.2 was known bad — players on 3.2 were being told to stay away
from a build that already worked.
- **The mod page no longer states the game range in prose.** It now uses the `{{GAME_RANGE}}` and
`{{GAME_LIST}}` placeholders that `nexus_sync.py` fills in from `GAME_VERSIONS`, so the next
widening reaches the page by itself. The page had said "V3.0 and V3.1" in two places, and both
would have gone stale the moment this release landed.

- Works on game 3.3. Game 3.3 rebuilt how bags, containers and item stacks are stored, and made a drone's mod slots private. On 3.3 that left 0.10.1 unable to read any of them: every module failed on each pass, logged an error and did nothing. All eight modules now work on every game version from 3.0.0 to 3.3.0, from one download.
- If a later game update moves them again, the mod says so once in the log at startup and stops there, instead of logging an error on every drone pass.
- Nothing else changed: modules, schematics, /das rules and settings carry over.

- Auto-Harvest now works with self-seeding crops. Mods that make a crop grow back on its own after you harvest it — Self Seed Farming is the common one, and Ghoulette's Wasteland Pantry offers a patch built on it — take away the seed a vanilla crop drops and have the game put a seedling back instead. Auto-Harvest looked for that seed to know what to replant, found none, and left every vanilla crop standing, while modded crops that still dropped a seed were reaped. It now reaps those crops too, and puts back the same seedling the game would.
- Vanilla's radiated mushrooms grow back the same way, so the drone now picks those as well when they are inside your land claim.
- Nothing else changed: a crop that drops a seed is replanted from that seed exactly as before, and wild crops are still left alone.

- Simplified Chinese. Every module, schematic and stat label now has a Simplified Chinese name and description, contributed by catgodcx. A few terms were adjusted to match the game's own Chinese, so the Lucky Looter perk and the schematics read the same as they do everywhere else.
- The drone's "Automation modules" menu can now be translated, and comes in Simplified Chinese too. Its rows used to be fixed English text. English players see exactly the wording they saw before.
- Players on a dedicated server still install nothing: the server sends the text to each player in that player's own language.
- To add another language, add a column to Config/Localization.csv named the way the game names it (tchinese, german, japanese and so on). A language with no column keeps showing English.
- The /das chat replies are still English only.
- Nothing about how the modules work changed.