Subscribe to download
[SCAM] Simple Concurrent Adaptive Min3r

I designed this autominig solution to suit my approach to mining automation in vanilla game. The main goal was to make a system that would allow extremely early mining automation in survival with great scalability later on. At this moment it's tuned to mine spherical/saucer vanilla ore deposits in space and on planets.
Check out the sample to see if it's your thing before diving further.

• Send to new mining spot with exactly one command (by positioning drone or doing camera raycast)
  
• Scale number of drones easily with no added set up actions
  
• All drones mine the single spot (called mining task) together with exclusive blocking shared path segments to avoid collisions (HOPEFULLY), hence the Concurrent word
  
• Drones are recalled with a single command and dock to moving carrier automatically
  
• Drones try to ignore stone layer, adjust max mining depth based on ore gain analysis, so it's kinda Adaptive

• Current mining pattern and concurrency approach requires all acting drones to have the same size
  
• Drones have to be vertical miners (drills facing down, going downwards)
  
• Base docking area has to be top open, docking drones descend vertically
  
• Probably have quite an amount of bugs and hikkups - while I used them A LOT during my survival playthrough, I might've missed lots of test cases because of my playstyle, also recently the code undergone a huge rework

1. Watch the quickstart video guide or read this guide
   
2. Get the min3r of choice or build your own
   
3. Copy the code to drones' blueprint, make sure Dispatcher and all Agents run the same version

Adaptive mining is a feature that allows dynamic change of mining plan based on ore income. If enabled on agent, it would constantly check what content gets into drills and do several adjustments:
- change skip-depth (distance from the mining area surface where drills block incoming ore, to eliminate stone input)
- change depth-limit
- send direction-banning messages to Dispatcher.

direction-banning would cancel out planned shafts in a small cone (going from the mining plans' center). This represents areas that are considered not worth expanding to.

Adaptive mining should be toggled on Agents (toggle:adaptive-mining in CustomData or run arg). If it is enabled on Dispatcher, it would enforce this setting on all drones in active group during task creation.

It is disabled by default to avoid confusion

Any ore input except Stone is considered valuable.

Small space: https://steamcommunity.com/sharedfiles/filedetails/?id=2572154521. Not recommended for G environments. Risk of peer damage: almost zero.

Small atmo: https://steamcommunity.com/sharedfiles/filedetails/?id=2572218085. Tested up to 1.2G. Risk of peer damage: small.

Large gravdrive: https://steamcommunity.com/sharedfiles/filedetails/?id=2576438985. Not recommended for G environments. Risk of peer damage: none.

Small H2 (test prototype): https://steamcommunity.com/sharedfiles/filedetails/?id=2583145703. Tested up to 1.2G. Risk of peer damage: medium.

Those commands are executed immediately on start/recompile. During runtime they can be fed to PB via run argument.


Too big to be included here, see script arguments reference discussion.

• Do not copy-paste drones in creative during their activity. If you have to, use clear-storage-state command and then copy
  
• The orientation of connectors matters, both on base and on drone. While autopillock should handle any cases, drone pathing currently optimized for stock drones - vertical mining, vertical landing.
  
• If you add/remove any blocks during operation, you need to recompile everything
  
• When drone docks, it switches all batteries in recharge mode. After recent update, this might block a drone forever until you switch batteries manually. If you experience this, toggle base connectors' Power Transfer Override ON.
  
• Use command:clear-storage-state on every PB to reset all internal state, if you see some weird behavior. You can use command:global:command:clear-storage-state on Dispatcher to broadcast it to every linked drone
  
• Getting exception "Not enough thrust to compensate for gravity" - you drone struggled to overcome gravity. Can happen to weak ion min3r when in G environment and fully loaded.
  
• If you have issues with drones not docking, make sure nothing is messing up with connector Custom Data. The script uses it to claim connectors for drones.
  
• In case of deadlocks when drones seem to wait for each other and do nothing, try Purge Locks command as a last resort.
  
• Don't use on asteroids in planetary gravity field. This would be considered planetary mining and won't go as you expected.

Please tell about them in the bug reports discussion .
Before that, make sure dispatcher and drones run the same script version (shown in the PB run printout).
Check script logs from dispatcher and drone - if you did not add specific LCD for logging, log can be found inside PB screen. Often you can get what went wrong right from the log.

Please prepare to answer these questions before asking or posting bug report:

1. Does the dispatcher PB show those drones as "ID awaits docking" in PB info printout (where runtime info, version, etc shows up)?

2. Do those free connectors you expect drones to dock to have something in their Custom Data (should be empty or having THAT drone ID)?

3. What lock ownership does the GUI show for those stuck drones ("general", "force-finish", etc)

4. Does the "Purge Locks" GUI button solve the issue?