Watch the quickstart video guide (first one).
https://www.youtube.com/watch?v=n0Cbl-Pv-Qc

Take a look at this world upload with all three drones and dispatcher ready.

Prepare the carrier. This can be either mobile rover/carrier or station.

1. Build PB, antenna, power source
   
2. Build connectors that face upwards (drones would descend and dock using their bottom connector). Connectors should contain "docka-min3r" in their names (this tag can be changed on the top of the code).
   
3. Get Dispatcher boot command batch from the main page and place it into PBs' Custom Data.
   
4. Get the code into the PB editor, recompile.
   
5. Optional: build two Wide LCDs and put their names into the add-panel and add-logger CustomData lines. Alternatively, name those screens so they have "scam-log-panel" and "scam-gui-panel" in their names
   
6. Optional: build control seat in front of your "scam-gui-panel" and name it to match the "command:add-gui-controller:scam-controller" line.

1. Get the min3r of choice or build your own (guide on how actually to would be added later).
   
2. UPDATE the code in the drones' PB, make sure Dispatcher and all Agents run the same version. I re-upload blueprints far less often that the SCAM script itself (this workshop item).
   
3. Check the Agent boot command batch from this page. It may be more up-to-date than the one inside.

After you have Dispatcher and Agents up, make sure they are linked together. Agent PB should show DispatcherID in it, and Dispatcher PB should list all active Agents (subordinates).

I recommend starting with a command:create-task from an Agent. Fly it manually to the point of mining, place it above with some spare altitude (not lower than terrain slopes around you). If you are on planet, running command:create-task would start a mining task centered on that point, and shafts would be aligned with gravity (exactly downwards). If you are in space, then the Agent orientation would determine that mining direction, so align it accordingly. Do not use the system for a asteroid mining inside planetary gravity area - it would consider this planetary mining and would mess everything up.

The Dispatcher would accept the task and broadcast mining command to all active drones, respecting the group-constraint (see script arg reference discussion).

If you take a look at the logging panel (or Dispatcher PB screen if you don't have one) you'd see GPS points that describe your mining task. They can be used later using command:create-task-gps (see script arg reference discussion).

Having a camera on an Agent or Dispatcher would allow you to designate a mining task using command:create-task-raycast. Point a camera to the ground, and run that command while still looking through that camera. If you are on planet, avoid using that on terrain slopes - in that case it's better to drive a drone there and do old-fashioned command:create-task.



Before making the drone of your own, take a look at stock models.

Flight control code is based on AutoPillock core and supports all types of thrust, including gravity drive.

• PB for SCAM code.
  
• Connector facing down.
  
• Gyroscope named "forward-gyro" (can be changed in the code - ForwardGyroTag). The gyro should look forward the drills and connector, i.e. down to the mining area.
  
• Remote control
  
• Antenna with enough broadcasting range
  
• At least one thruster in every direction.
  
• Drills facing downward. They can have connector between them in a chessboard pattern.

The drone considers it's forward direction based on how you placed forward-gyro. It would align itself with gravity or mining plane based on gyro orientation, and it would mine forward.

When mining or travelling around, the drone considers the forward-gyro position the pivot point of the drone. It is recommended to place the forward-gyro as close as possible to the middle rotation axis of the drone (ideally, when you roll-override the gyro, the gyro should stay in the same world space spot).


The code would attempt to estimate the "circular-pattern-shaft-radius" value automatically based on drill positions. If you want to override it, just place command:set-value:circular-pattern-shaft-radius:{value} below the set-role command in Custom Data boot batch.


The drone needs enough thrusters to support itself on max load in the highest G environment you want it to operate in. That is absolutely required for bottom-facing thrusters that would do the most weight-lifting.

You need some side-facing thrust too. If the drone tilts in G-environment, side thrusters would contribute more to the total lift, while downward thrusters would reduce their contribution. At high angles the drone can find itself being unable to support itself, in this case the code stops, releases control and turns vanilla dampeners on (the drone would probably float to the ground and crash unless you save it with manual rotation adjustments).

You need at least one thruster facing upwards, even if you don't expect the drone to fly tilted so much.


You can add timer following naming convention
{MinerState}.OnExit
{MinerState}.OnEnter

Where MinerState is
[Disabled, Idle, GoingToEntry, Drilling, GettingOutTheShaft, GoingToUnload, WaitingForDocking, Docking, ReturningToShaft, WaitingForLockInShaft, ChangingShaft, Maintenance, ForceFinish]

The code would try to run appropriate timer when it changes state. For example, you can have Maintenance.OnEnter timer turning a sound block on, then Maintenance.OnExit timer do the opposite.