Space Engineers

Space Engineers

211 ratings
[SCAM] Simple Concurrent Adaptive Min3r
5
6
3
2
   
Award
Favorite
Favorited
Unfavorite
File Size
Posted
Updated
205.698 KB
11 Aug, 2021 @ 7:37am
28 Apr @ 8:51am
11 Change Notes ( view )

Subscribe to download
[SCAM] Simple Concurrent Adaptive Min3r

Description
The idea
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.
Distinctive features:
  • 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 limitations:
  • 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
Usage
  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

Advanced features
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.

Tested workhorses

Moved here.

Custom Data boot commands for base and drones
Those commands are executed immediately on start/recompile. During runtime they can be fed to PB via run argument.
Base or Carrier (Dispatcher role)
command:set-role:Dispatcher command:add-logger:scam-log-panel command:add-panel:scam-gui-panel // for GUI mode on the 'scam-gui-panel' tagged screen command:add-gui-controller:scam-controller toggle:log-message command:set-value:max-generations:8 command:set-value:getAbove-altitude:5 command:set-value:skip-depth:0 command:set-value:depth-limit:50
Small drone - all Min3r 69R line (Agent role)
command:set-role:Agent command:set-value:circular-pattern-shaft-radius:3.6 command:set-value:preferred-container:Large Cargo Container x command:add-panel:feed-panel // uncomment below to enable adaptive mode //toggle:adaptive-mining
Large drone - gravity driven variants (Agent role)
command:set-role:Agent command:set-value:circular-pattern-shaft-radius:7.9 command:set-value:preferred-container:Large Cargo Container x command:add-panel:feed-panel // uncomment below to enable adaptive mode //toggle:adaptive-mining

Script argument reference

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

Troubleshooting and advice on how to avoid shooting yourself in a leg
  • 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.

If you have issues
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.

If you have issues with drone docking process
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?
Popular Discussions View All (5)
349
25 Apr @ 12:30pm
PINNED: Bug reports, feature suggestions
cheerkin
35
2
24 Jul @ 6:44pm
PINNED: Set-up guide
cheerkin
21
26 Aug, 2024 @ 3:13am
PINNED: Script argument reference
cheerkin
518 Comments
Mac and Cheese 29 Jul @ 3:37am 
(the antennas)
Mac and Cheese 29 Jul @ 3:37am 
it wont work if theyre on the same grid
Tochas 29 Jul @ 12:18am 
I see, I suspected antenas would play a role here.

I was thinking to have 2 set of antenas on each dispatcher
One with a very short range for compile and assign really really nearby drones

and a long range antena for the rest of functionalities, remote access, etc.

and just make sure to turn off long range antena while setting up drones.

I'll give it a try
cheerkin  [author] 28 Jul @ 3:19am 
There is no way atm, they will interfere if their antenna ranges overlap (or dispatchers are on the same grid). You will need to move away or turn the base dispatcher off, then recompile all drones so they link up only to the ship dispatcher.
Tochas 27 Jul @ 10:37pm 
How can I assign drones to different dispatchers?
I have a base at a moon's surface and my main ship both with its own dispatcher.
cheerkin  [author] 25 Jul @ 1:25pm 
Hm, no, that is not implemented, and tbh still looks a bit counter-logical. If you are able to fly certain drone to a mining position in that environment, that means it is capable to operate? Why call in the different group then? Sounds like you want the drone to act as a designator ship, but there is already a feature of raycast from dispatcher for task creation.
"command:create-task:group-constraint:B" should not be hard to implement though.
Pablo Diablo 25 Jul @ 10:00am 
Thanks for the reply! Sorry, I think I was unclear (or I misunderstood).

I understand the purpose of group-constraints to limit the task to a single type of agent. Not trying to run multiple tasks on a single dispatcher, just use one group to trigger a different group.

What I was hoping is that it was possible to trigger a group-constraint for a different group than the triggering agent. For example:

Drone group A: SG miner w/ H2 thrusters.
Drone group B: LG miner w/ Ion thrusters.

Drone A moves into position above the deposit via RC. Uses a 'create task' command, but instead of triggering the task in group-constraint for type A, it routes it to type B (<<This is the part I'm not sure if it's possible). Drone A moves away via RC, while drone type B moves in to start drilling.

Something like "command:create-task:group-constraint:B"? Though I don't think that exists, is there something with a similar functionality?
cheerkin  [author] 25 Jul @ 2:23am 
For now only one running task per dispatcher is supported. The idea behind group constraints was to use a subset of drones based on environment (e.g. not letting gravdrive miners join the task on planet, atmo-thruster drones in space, etc.)
Pablo Diablo 24 Jul @ 11:40am 
Hey - thanks for the script! (Thought I had posted this already, but perhaps not?)

Is there a way to 'create-task' but aimed at a different group-constraint? I (think I) understand how those interact, but not sure how to pipe the 'create-task' command to a different group.

(So that, for example, a SG drone might be able to send LG miners to its location ... or a non-miner drone running as an Agent can scout out deposits, and then send mining drones to dig it out.)
MMars 28 Jun @ 9:18am 
Hi everyone,

Just noticed "adaptive docking". I didn't see the drones doing that before, but now they are and it causes a lot of crashes around the docking location.
Is there any way to disable it?

I can't find it in the arguments section, custom data, or code. Perhaps I overlooked it?