Muito bom, bem funcional.

No problem. Thought I'd let you know so you could potentially fix it in some way. But yea a different blueprint is probably just the easiest

Ah, you're right. I had tried to fix the poly-only case, as I knew many new players would blindly hit subscribe without reading, and I thought it was working for poly-only mining, but it doesn't.

Players in early campaign with only polys should use the last schematic above, "Poly-only mining for early game/campaign".

Hey Killall. I think I discovered why it was only making 1 poly mine. Since I've used it since the start I've had the issue up until the point I unlocked/started building the mega drones (don't know which one it could be because I did both before building the schematic). After that it started working fine. Hopefully you can find a solution for it somehow? Or you might need one that just controlls poly's since I think it just gets stuck on the "bind to mega" command?

yea same, only 1 poly mining and it's not touching any titanium, i haven't opted in for any betas

That's a negative for me, I never opted in for v7.

These are the actual lines which command units to go to the ore's location and mine it:

ucontrol approach orex orey 5 0 0
ucontrol mine orex orey 0 0 0

BTW, I'm reasonably certain that everyone having problems is trying to use this schematic on the v7 alpha.

what line of code is responsible for digging drones?

Works like a charm, binding a whole drone swarm. Not sure if it's version-wise or clientside issues that breaks it for all these other folks.

this only binds 1 poly and the poly will not mine whatever the core has least of, it is mining copper only even though i have max copper and max lead in the core and only 30% titanium in the core.

I don't see any need for an update. Just tested, this schematic still works with multiple units as of 6.0 build 126.3.

@Monk There's a new mining drone schematic that I found and now use:
https://steamcommunity.com/sharedfiles/filedetails/?id=2660414596

Would be nice for an updated version which works with multiple units simultaneously

I as well, can confirm that this only binds one unit. I used this schematic several months ago and it worked perfectly fine then. My guess is that the last update to Mindustry broke this schematic unfortunately.

I have the same issue as Commissar Jones, it seems to only bind 1 unit.

I don't know how that's possible either. Perhaps you are using other logic which is fighting for control of your polys and megas.

so. for me. this thing (without modifying the code) only seems to grab ONE poly and force it to mine. i dono why however

Cool. Now my Polys aren't useless after i capture a sector.

I am one of those punks that just hits "subscribe" then is frustrated inside mindustry because it is buggy (building healing didnt work, and I was confused about the switch). I then went ahead and made a whole "command center for mono/poly/mega" and posted it, and eventually got building healing to work.

I wish i saw all the other code snippets before I started digging in. You did some great work!

FWIW, here are the changes to your code that I did.
https://steamcommunity.com/sharedfiles/filedetails/?id=2385890148

I gave you the 'take my points' award since this really helped me, ive always been confused with logic stuff, like how to use it and such.

You may be playing a game with the "units require ammo" setting unchecked.

Is this ammo thing in a new version of mindustry? When I print out the ammo count, it stays the same.

Units that use electricity for ammo can recharge from any battery. Pulsars do not mine titanium, Quasars do. You can look this up in the core database.

I used memory cells in my script and certain part of the flag number in order to manage only a subset of the units per processor as shown here. (8 processors with 6 units each)
https://steamcommunity.com/sharedfiles/filedetails/?id=2343750512

I think it might be good to create a mining script that allow you to control the number of polys/megas used in mining, by using 1 switch to add more units and 1 switch to remove units from the workers. In this way the spare Polys/Megas can still do what they want.

What are ammo from batteries and Pulsars cannot mine titanium right?

The polys will only rebuild while damaged structures exist. In the rare case that structures are destroyed without any others taking partial damage, or the megas get there quickly enough and repair everything before the polys are able to finish rebuilding, use the included switch to manually deactivate poly mining until everything has been rebuilt.

Hello, it doesn't appear that the logic is allowing the Polys to rebuild destroyed structures. At least, its not happening in my games.

The logic now skips over player-controlled or commanded units, allowing remaining units to continue mining.

Also, when used to control mechs, their pathfinding ability can be described as nonexistent, making this useless for ground units. Oh well.

OK, revising my last comment. *If you are currently controlling ANY of the unit that you want the chip to make mine*, you must reapwn at the core, or it will not work on ANY of that unit.

I know this isn't useful, but... It just plain doesn't work. I set it up, make sure the switch is on, and none of my units go to mine. Period. I looked at it's program, and I agree, it SHOULD work, there's no reason for it not to. But it doesn't.

I've frequently had the same problem in my own projects of the logic commands not doing what they are supposed to for no reason. Anuken kind of needs to fix this crap.

Polys' default AI do not repair, they only rebuild. So because this logic prevents mining as long as damaged blocks exist, if you only have polys, they will idle forever after rebuilding until you clear out or replace all damaged blocks.

I have added a new early game/campaign mining logic for when you only have polys. It will use half of your polys to repair, and the other half to rebuild. Note that Megas are much more effective at repairing, so you should build some as soon as you can, then replace the poly-only mining logic with the normal one.

It does it with polys, any ideas?

Megas will stare at damaged structures, unable to repair, if they are out of ammo. They can restock from any nearby batteries. To get them unstuck, take control of one, then command the others nearby, and take them to any powered battery.

Since this logic frequently takes them to the core, you can put a few batteries near there to keep them topped off.

They wont repair damaged structures, they will fix ghost blocks then get stuck. Any ideas?

Check out my mining script here (require binding to sorters).
https://steamcommunity.com/sharedfiles/filedetails/?id=2335389972

My production transport script here (bind to unloaders/sorters).
https://steamcommunity.com/sharedfiles/filedetails/?id=2334731246

Well, polys are actually quite good at healing a bunch of blocks during a wave, and in my experiments i`ve decided i`d rather see them heal during an attack and follow their AI later to reconstruct, without any mining of the basic stuff that you should get enough of anyway (as you probably can`t setup all 3 actions effectively).

If you have a lot of destroyed buildings, you will have to use the included switch to disable poly mining so that they can rebuild everything. I currently do not know of a way to detect the ghosts of destroyed structures.

Automatic rebuilding should work well enough for now because buildings are usually partially damaged before they are destroyed.

Perhaps idle-cycling with single bound unit while damaged buildings are present is the best solution. This way every other unit will act on their default AI for the duration. I`ll have to try that out.

I didn`t try exactly this, but i`m experimenting with mining for last couple of weeks. All commands are the same. So it is also not a simple guessing.

ulocate will work on its second pass, once something is bound, so thats 1 cycle for mega + 1 cycle for poly.

The delay comes from @IPT value and processor going through all the units sequentially. So micro- processor should have longer delay than logic- one. As i understand it.

Now that i think about it, that is actually a nice idea to break mining for polys when buildings are damaged. Although it might not be enough for them to rebuild everything - my tests show that destroyed buildings are not counted as "damaged".

I don't initiate actions from the max distance, because units bump each other around when all trying to act on 1 tile, and some may get bumped out of that max range and be delayed in performing their tasks.

Have you tested the script in practice and found anything to not work as described, instead of just reading the code and guessing?

In putting ulocate before ubind, I think it is working by taking 2 cycles to perform its function. As it is now, when a block is damaged or destroyed, units take a noticeable pause before starting to repair/rebuild. This is the time it takes for a unit regain autonomy after failing to be rebound by the processsor, and I like the delay because it gives time for your defenses to destroy the threat, reducing the risk to your polys/megas. Afterwards, they resume mining instead of lingering at the front line, which is another benefit over their default behavior.

I have tried controlling the megas' repair behavior (to put ulocate in a "sensible" order), but they fire excessively en masse at each damaged block. They are able to repair much more economically and accurately when allowed to do so using their original AI.

ulocate can`t work before ubind.
It doesn`t make sense to get the state of switch first, then run the script, and only then to check what the state was.
Mining can be done from distance of 9.
Every unit that starts to mine anything in range of 9 from the core will continue to do so, at least on micro- and logic- processors.
This will not automatically pause for "rebuild damaged".

Also, units will fly to bottom left corner if no ore is found.