#Mining drones drive back and forth

18 messages · Page 1 of 1 (latest)

lyric swift
#

If you draw a line of excavation from left to right, the mining drones will start excavating in the middle of that line. They will then work left and right from that center point.

The problem is the mining drones will drive from the leftmost excavation to the rightmost excavation, mine a block or two, then drive back to the leftmost excavation. They waste a lot of time and energy driving uselessly back and forth.

digital thistle
#

Same issue. It is annoying when trying to clear a large area out. Part of it seems to just be the drone's decision making as they do some dumb things, including driving to the other level to help with building something that completes before they get there.

#

Overall, the drones fail to do jobs locally (to where they are) vs what they think is more important (same job, but with a large travel time).

left forge
#

The drones attempt to mine the last thing you "highlighted." If you go left to right the last thing you highlight will be the first thing they try to mine. If you wipe back and forth it gets more complicated. Also there is color coding. Red gets worked on immediately and bright green is dead last

digital thistle
#

It seems off for the mining to be "last selected, first drilled' given most other things I have noticed is in order of placing (ie: build order / delivery of matierals to buildings) follows the order of first placed, first served.

#

I will try marking for the drill in a "last is first" approach and see if the drillers are any "smarter" (behave as expected).

#
  • nope, Just retested it with the current patch, it is first marked, first drilled.
left forge
#

Try this experiment. Mark a small group of boxes with red. Then mark another group a short distance away. It will stop mining the first group and immediately move to the second group. It is the same when you do a large "swatch," except it can't get to the last item immediately, but will remember where it is, at least that has been my experience. Your milage may vary. 🙂

digital thistle
#

the experiment only works if you use "high prioity" for both boxes. That is not ideal way of working as you can never have the option to "jump the que" for work needing to be done. It is also not the "normal" usage pattern.

#
  • Just playing around with the normal pattern again and while it does allow batches, and will work in order of the batch (ie: mouse press to start, mouse release to end), the closest logic I can see is that it is not the "start" or "end" that gets worked on first, it is which side / area is closet to the lift. (I also see this with regolith collection, closest to the lift gets picked up first, even if the drone is next to some already). You can test this yourself by doing a section of drilling with a "U" shape. Regardless of which leg you start on (with the bend being deep in the rock), the leg which is closest to the lift will get the drones first, followed by general access to a mineable item (if using a lot of drones). This will explain some of the "excess walking" that is occuring when drilling, as well as why some mining sections seem to have the drones "starting in the middle" (as that is the closest point to the lift). Which then leads to lots of walking/travel as the drone heads to the next accessible "closest to lift" square.
latent river
#

what if they just make it where the drones mine the next minable highlighted area and not use some algo from left to right.

latent river
digital thistle
# latent river what if they just make it where the drones mine the next minable highlighted are...

wishfully, a "what is close that I can do" in the same job teir (that currently exists) would be good. Ideally, what is with in 10 (randomly selected number) squares would be enough of a pre-check before resorting to the current "find work anywhere" mode. (no point doing multiple (increasing) distances as it adds to processing time/power needed per decision, so just do it once). Or, in a lower processing needed coding terms, break the grid into 10x10 (or some other random number) and have each set as a "local" job list. Advantage is short travel time to next, staying "in the area" and only needs to be processed once (ie which grid task belongs too). Less overall processing than a "distance to next task" and most people will not notice the difference too much. Currently, the distance to lift would be adding some processing time (2 dimension calculations), but I am guessing it is done once when the task is created then stored in a sorted list, then the next drone that needs job takes the first from the list (saves processing time / list is sorted closest first).

#

Though to save on initial coding changes, the "grid" could be more "cake slices" to instead of square grids, it would be more triangular. Down side is small areas near the lift, and large segments far away from the lift.

#

-For a quick "low level" change in how tasks are assigned, it will depend more on how the low level logic is currently being worked out. Definitly not expected a major rewite in Early access anyway. If wanting to be really quick on roll out, do the "distance to next task" approach (high CPU), but have it as a option in settings under "testing ideas" for those that want it and have a beefy system (and just auto select the first task that is with in 10 squares, so similar distance). No need to get the PERFECT next task, just as long as it is "about here".

#
  • for example, if 5 tasks are with in 10 squres, take the first one found (most likely closest to the lift given the main task list). This might have drones "migrating" towards the middle, but will skip their traveling across the map to the over side of the lift that is most noticable in their silly traveling.
digital thistle
#

Thinking on this, the bulk cargo hauler drone does do a bit of "looking around" for rigolith when looking to fill up, that logic seems mostly what would be needed for keeping a mining drone working in a given area for a bit longer. But then looking at how a bulk cargo Drone works for picking up small piles of raw resources, it too needs a bit of work to reduce the number of trips it makes when picking up only 1 item from the ground. So might not be the best example of a "quick fix".

spice lichen
#

As long as the blocks are the same color, there should not be and "order of operation" other that closeness / least travel/time. The current behavior is unintuitive and unexpected.