while impressed, i did experience a few bugs, reported. here are some ideas to improve use:
-use a strafing mining method rather than tunneling. get in range, hit the ore, strafe left 3 meters, down 3, right 3, up 6, left 6, down 9, right 9 etc. I mine with this method as it allows you to dump unwanted ore while mining. And if your cargo becomes full, it can be interrupted and the mine exited safely. with the tunneling method you have no choice but to continue. that wastes a lot of ore.
-use a sorter to allow the user to elect unwanted ores. its safer than letting them play with the code or block naming (have not looked at which sort method you are currently using other than its not a sort block) this suggestion also relates to the bug i reported that when cargo is filled while inside asteroid, ejectors fill with wanted ores and there is no reserved space for sorting to dump. a sorter followed by a small cargo for 'surge' then an ejector(s) solves this problem as only unwanted ores get to the ejectors. this system can then be activated through script, though im not sure if sort lists are accessible to be read (can tell you when dumping is finished by comparing list to inventory to reduce waits)
-turn off ejectors when docked
-include a status 'dumping unwanted ores' in the LCD panel
-remove references to solar in bottom left LCD panel
-Display currently stored GPS on left panel (opposite damage panel)
-include a programming block called 'User Manual' and load it with, well, a users manual. capabilities, known limitations, description of controls, normal operating sequence, a description of the different reported statuses and what they mean, a description of possible fault conditions. and of course a reference back to here. i haven't confirmed, but i'm sure the PB would support developer comments in code.
-make any block not required to be accessed via the system menu hidden. keeps it clean when docked. i have some where all user functions are on the G menu and the only visible items are the remote blocks.

on a side note, something i discovered with a project if you ever implement this on a large ship: if you dock with a connector then a merge block (so you can move it around sans explosions) all of the block groups in the small vessel get erased. i solved this in my timer based computer (i use them because its basically procedural programming and i seem incapable of adapting to object orientated concepts) by not using groups in the program. so every block is addressed as an individual entity rather than a group. groups i then identified by affixing codes to the block names. it also helps to attach a name prefix identifying the block as belonging to a specific vessel. eg, WicoAM Sensor 2 FCD L (Wicorel auto miner forward collision detection group left sensor) in my code method). its a huge job to convert to groupless, but saves headaches if you ever add a merge function for transport.

I agree with the alternative method. I had a similiar meted (but still tunneling) that I had planned to implement (I have a searchshift mode). However, I didn't have an easy way (yet) to automate the movements precisely.

I do want to do a miner that's meant for clearing out a 'large' asteroid from the inside out layer by layer.. (and make space for a nice base in the process..

The ore not dumping while inside (while pretty full) is a bug; I will fix.

Small ship sorters are big things; but I will experiemnt with them. You are correct that the dumping is handled by the code currently.

I do have on my 'wish' list to add ore types to dump to the config file.

I do have many blocks hidden; but more could probably be hidden.

Groups; I understand the problem. The code is already limiting itself to 'local only' blocks so there is no confusion when multiple ships are docked to the same ship. Merge, however would cause problems until un-merged.. I will look at the groups. On issue is that the autopilot program I'm using depends on groups itself.

Thanks for the feedback.

hey, a 'hollow it out miner' sounds cool!
Small ship sorters are on the small conveyor size... unless i misinterpreted that...
i wasn't concerned with the code running while merged (would be cool for automated un-merge/launch though), i was concerned with the groups being deleted when un-merging.
the group thing though, only matters for large ship size for now (afaik the merge is block not available for small ships?) unless folks use the mod for small ships. i haven't experimented with a small grid ship (with groups) docked via locked connector to a small large grid ship that is merged to large large grid ship. i would be interested to see if the small ship lost its groups when the small large grid ship un-merged. anyway, it was just a heads up if you had plans on applying this to a large grid.
feed back makes the world go round :D
-sorry, control theory nerd humor-

Already have most of the changes/fixes done and am testing.. a bit distracted by DX11. oh and work. :(

And I found the small sorter. So the PB just turns on and off the ejectors as appropriate to safely spew stuff out..

hehe, who wasnt distracted by DX11? fair enough you are a Modder and would have had a legitimate reason. i was just floating in space drooling onto my faceplate... it is pretty out there.

so, more requests. while i was doing my two miner test, they approached each other and both threw a "ship in the way" message or something to that effect, im afraid i didnt write it down. now, that state halts mining progress. thats cool if you can move the other ship. but if that other ship is another miner...
-can we have a reverse light please? its dark in those tunnels.
other than that, this one seems to work really well. although
-more descriptive attention needed messages? like 'attention needed, no asteroids found' or 'attention needed, cant find clear route to target' it would help with quickly assessing the situation if you were busy doing something else.
-also for the collision, collision fwd, collision bottom etc. that would also be handy when it halts on collision, as they could stack, collision fwd bottom.

thats all i got. thanks for the fast turn around on the other stuff too. the manual was very handy. it seems that for my last test i was using it a little wrong. and the config file is great. im hesitant to play with code, so i wasnt touching too many things in case i broke something. but now i know that panel is supposed to be altered, it really added a new level of neat to this machine.

The current system handles angled collisions where one hits the side/back of another and then the other miner moves out of the way (unaware that there was even a potential collision in the first place).

The head-on collision is a tough one in the mine tunnel. Who is supposed to move and how? The only way to resolve is to back one of them out.. But that's not easy to do when controlling the ship manually, much less automated. I'm not really sure what can be done except to call for help.

Before DX11 I was thinking of removing the lights because of potential FPS savings.. Now I'm thinking of adding more because, as you say, it's very dark in there. You can add your own light if you want. Add it to the "Lights" group and it will automatically get turned on/off.

I'll look at adding more detailed error messages.

Glad the manual helped. Let me know if you have any other questions.

Thanks for the feedback.

Feature request - quite simple - I stuck a passenger seat on to the vessel so I can sit on the craft while I remote control it. :)

Perfectly acceptable to do. You can save a local copy with the seat added and make that one.

I've also seen many mods with really cool seats.

I remote control them from my base and don't go out with the miner. I usually have 3 or more running. Every once in a while they get hit by meteroites and I have to go out and inspect visually and repair.

There's lot of other things you can add like more cargo containers, more batteries, etc. I've also demonstrated making a minimal version with very few cargo containers for a starting one and then upgrading it from there.

I wanted to make the published version using no mods. I can't maintain a bunch of different versions of the miner, so I tried to make it so it was easily modifiable to meet whatever needs the user had. In the recent changes, I've made the scripts support solar panels and multiple batteries so that the user can add those and they will work.

Awesome setup a few thoughts.

It does not seem this has been tested in survival much, upon loading it in my survival world it cannot even move (even manually) as at idle it is nearly in overload. Seems to need more reactors, unless it is meant to run off the batteries and the reactor is a backup.

There is alos a distinct lack of information on how to get it to not think it is in creative mode, as is the default in the blueprint.

Lastly, this may be me missing something as I haven''t used programming blocks much and I am just getting into them but the Miner Status prograaming reports that it is too complex and needs to be re-built.

Also the LCD programming block reports assembly not found (the missing MyPowerProducer, etc) but maybe that will be fixed (or being re-done) in the update tomorrow.

There is only one reactor. the batteries must be charged to power all of the thrusters.

It should detect the mode by the cargo volume. Creative has very large reported capacity and survival has 'normal' range of capacity.

Status reporting that is a problem.. Is is connected to anything or just the miner.

LCD can be updated from the workshop, I'm pretty sure MMMaster has already changed it (back) to use the detailed info for power.

It now shows as being in survival. I will watch on the next one to see when it detects it is in survival.

As to the one reactor... that didn't help much as I had it sitting away from my station when I built it, so it was stuck there as it could not move. I guess I could have manually set the batteries to charge and just waited. I threw a few more reactors on it (thankfully there are plenty of spots to mount them) to move it to a connector.

Okay, updated version is running now. Came up with a few suggestions.

The miner does not see to calculate modded reactor output correctly, I replaced the vanilla with a Azimuth tiny and it shows me using 652% of the power and the LCD reports the max output is 1mw.

The ability to set whether the miner will use the reactor as primary vs the Batteries would be nice. Due to a 20% loss when charging batteries it is wasteful to run them if you don't need them. Combined with the use of automation to auto refill the reactor on docking, I prefer to keep the batteries as a backup source.

The ability to set the docking entry or multiple waypoints besides just the one. Seems the system does not allow us to enter extra way points currently. My station is quite large, and the closest asteriod I am mining is on the other side, the miner gets a bit confused trying to work its way around the station and usually ends up saying it is blocked. The ability to set addtioanl waypoint in the docking/exit would prevent this.

Also it would be nice to be able to see the battery recharge time remaining as opposed to % level if possible (or a toggleable option for those that like %).

I tested mods before, but not since the change back to parsing detailed info again. I'll take a look at that.


If you turn off the batteries, it will not use power from them.

They just need to be above the 'minimum return %" that you can set in the config text panel.. This needs to be at least 10%.

Another faeture I just thought of. An repair sequence. Basically if it detect damage it will stop doing what it is doing, move to a repair entry, then repair spot waypoint until it detects there is no damage, once repaired the miner moves to a repair exit point, then resumes normal operation.

This would allow for either manual repair or having it pull into a repair bay/tunnel to be auto repaired, the seperate exit point would be useful if more than one miner or automated ship is running at a time.

I will disable the batteries for now, will it auto turn on the batteris if the reactor runs low? If not that would be a good feature.

Ability to only detect as under construction when a attached projector is on. Right now any repairs involve adding a projector, lining it up, making the repair, then removing the projector. The whole process has to be repeated everytime a repair is needed, since the script only detects one is attached not whether it is active.