[1.12] Extraplanetary Launchpads v6.99.3

[taniwha]

Update: I have EL working with Trajectories and cleaned up a bit, just going through some final debugging.

[taniwha]

I have released version 6.8.0 of Extraplanetary Launchpads.

Changes from 6.7.3:

• Ensure the built vessel's orbit is valid at all times (fixes problems with Trajectories etc)
• Prefix remaining EL part names with EL (fixes clash between EL's magnetometer and stock's). WARNING:this can breaks saves, but is easy to fix, see below.
• Add an IVA (very basic) to launcpad2 (much as I want to deprecate the thing). Fixes lost KIS inventories (unless that's been fixed in KIS without me noticing). Also includes an internal module to update the IVA's position and rotation for animated parts.

WARNING: this update will break saves and craft files that use any of the following parts:

Auger, SmallAuger, TinyAuger, Magnetometer, RocketBuilder, Smelter, SmallSmelter, TinySmelter

The solution is simple:

1. back up your save (persistent.sfs) and craft files
2. search for the above names (note that part names in craft files are suffixed with _partid (numbers)) and prefix any instances (watch out for Manetometer as that is the part name for the new (1.10) stock part) with EL. eg, ELAuger, ELTinySmelter etc.
3. save the file
4. rinse and repeat as necessary (for each craft file)
5. profit (ie, have fun)

[taniwha]

It turns out I forgot to update contract stuff and I missed the OMD. I'll get a fix out shortly.

Also, for those who are comfortable with the command line, this works nicely:

for f in *.sfs; do grep -q 'Auger\|Magnetometer\|OMD\|RocketBuilder\|Smelter' "$f" && sed -ie 's/\<\(Auger\|SmallAuger\|TinyAuger\|Magnetometer\|OMD\|RocketBuilder\|Smelter\|SmallSmelter\|TinySmelter\)/EL\1/g' "$f"; done

(change *.sfs to *.craft for craft files (gnu grep and sed))

[taniwha]

And quick on the heals of 6.8.0 comes 6.8.1 (brown paper bag release).

Changes from 6.8.0:

• Fix missed OMD in part renaming
• Rename parts in contract ISRU part requests.

WARNING: this update will break saves and craft files that use any of the following parts:

Auger, SmallAuger, TinyAuger, Magnetometer, OMD, RocketBuilder, Smelter, SmallSmelter, TinySmelter

The solution is simple:

1. back up your save (persistent.sfs) and craft files
2. search for the above names (note that part names in craft files are suffixed with _partid (numbers)) and prefix any instances (watch out for Manetometer as that is the part name for the new (1.10) stock part) with EL. eg, ELAuger, ELTinySmelter etc.
3. save the file
4. rinse and repeat as necessary (for each craft file)
5. profit (ie, have fun)

Also, for those who are comfortable with the command line, this works nicely:

for f in *.sfs; do grep -q 'Auger\|Magnetometer\|OMD\|RocketBuilder\|Smelter' "$f" && sed -ie 's/\<\(Auger\|SmallAuger\|TinyAuger\|Magnetometer\|OMD\|RocketBuilder\|Smelter\|SmallSmelter\|TinySmelter\)/EL\1/g' "$f"; done

(change *.sfs to *.craft for craft files (gnu grep and sed))

[pmoffitt]

This works but leaves a bunch of temp sed files in the default directory where the command line runs from (they all start with sed).  Not sure how to fix that at the moment. Makes backup files of the ones that are changed by putting an e on the end of the filename extension like sfse (it's a sed thing that I have no idea how to turn off and didn't feel like writing more code to remove them).

For Windows 10:
Install grep and sed from http://gnuwin32.sourceforge.net/

Save the following as a .cmd file updating the varible KSP
Open a command prompt and run the command you just saved followed by a space and the save game you wish to modify (example:  ELFix.cmd mysave)

REM EL fix for version 6.8.1 for Windows
REM Written by Pat Moffitt 9/7/2020 based on taniwha's line of code from https://forum.kerbalspaceprogram.com/index.php?/topic/54284-18-110-extraplanetary-launchpads-v681/page/233/&tab=comments#comment-3849847
REM Leaves a bunch of sed temp files in the default folder you will probably want to delete them
REM Also creates backups of changed files by adding an e to the end of the extension (.sfse or .crafte) you may want to delete them too.

@echo off

rem test input if no paramater provide tell the user and end
if "%1 "==" " goto noinput

REM set the following to your Kerbal Space Program install\saves folder currently set for the default for Steam
set KSP=C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\saves
REM Set to the Game Folder
Set SG=%KSP%\%1

REM Test input to see if it exists
if not exist "%SG%" goto nofolder

REM This adds the gnuwin32 bin folder to your path statement so they will run without specifing the path before them
REM I rem'd out this line cause it kept adding it to the path over and over again, only needs to be done once take out the rem if grep or sed can't be found
REM set path=%path%;C:\Program Files (x86)\GnuWin32\bin

REM search the game folder for sfs files that contain the EL text that needs updated using grep and then changes adds EL to the beginning of that text using sed
for /r "%SG%" %%f in (*.sfs) do grep -q "Auger\|Magnetometer\|OMD\|RocketBuilder\|Smelter" "%%f" && sed -ie "s/\<\(Auger\|SmallAuger\|TinyAuger\|Magnetometer\|OMD\|RocketBuilder\|Smelter\|SmallSmelter\|TinySmelter\)/EL\1/g" "%%f"

REM Same then for craft files
for /r "%SG%" %%f in (*.craft) do grep -q "Auger\|Magnetometer\|OMD\|RocketBuilder\|Smelter" "%%f" && sed -ie "s/\<\(Auger\|SmallAuger\|TinyAuger\|Magnetometer\|OMD\|RocketBuilder\|Smelter\|SmallSmelter\|TinySmelter\)/EL\1/g" "%%f"

REM all done go to the end of file and exit
goto :EOF

:noinput
ECHO You mush enter a save file to update for this script to work
goto :EOF

:nofolder
ECHO Your save game folder does not exist:  %SG%
goto :EOF

 

Edited September 7, 2020 by pmoffitt
Put code in a code block per taniwha's suggestion.

[taniwha]

@pmoffitt It might be worth considering putting that in a code block (the <> icon in the message editor)

[TotallyNotAPilot]

How do I launch stuff from the launchpads? I'm trying to find how I select a launchpad from the VAB, or am I supposed to do it a different way? I apologise for such a petty question but I really love this mod concept but I could never figure it out for myself to use.

Edited September 8, 2020 by TotallyNotAPilot

[capi3101]

7 hours ago, TotallyNotAPilot said:

How do I launch stuff from the launchpads? I'm trying to find how I select a launchpad from the VAB, or am I supposed to do it a different way? I apologise for such a petty question but I really love this mod concept but I could never figure it out for myself to use.

In order to use the remote launchpads, you need to have one deployed on a craft already - either one at an orbiting space station or one at a ground base - and use the Part Action Window to access the construction/launch interface. At the same remote outpost, you'll need to have a supply of RocketParts available for the construction of the craft, and you'll need to have sufficient fuel supplies to gas the craft up for once construction is finished. 

Take this with a grain of salt. I use a pair of different mods - MOLE and Pathfinder - that rely on Extraplanetary Launchpads for that same functionality, and that's how they work. For ground bases there's also a process of staking out an area for building a remote pad but I'm not familiar with that since the aforementioned mods largely negate the need for that process. For that, I'd suggest reading the manual. Much of the information in it still applies.

Edited September 8, 2020 by capi3101

[Tonka Crash]

9 hours ago, TotallyNotAPilot said:

How do I launch stuff from the launchpads? I'm trying to find how I select a launchpad from the VAB, or am I supposed to do it a different way? I apologise for such a petty question but I really love this mod concept but I could never figure it out for myself to use.

These are not designed to allow new launch sites directly from the VAB, but as places where you can build new craft away from KSC.  When in doubt RTFM

[Nicky21]

New game freeze when finalizing the build. 1.9.1.

 

I have been playing this save for a few hours, I switched to the starbase then finalize the build. Game froze with the base showing the built part.

https://easyupload.io/eaxyzs

 

Later, i uninstalled kerbal engineer, went to the base and finalize teh build succesfully, no freeze.

https://easyupload.io/ckuvnc

 

 

Even later, i reinstalled kerbal engineer, loaded the savegame from before and finalize the build, again, succesfully.

https://easyupload.io/sn3rc0

 

I don't think KER is the culprit.

[taniwha]

@Nicky21 Thanks for that. I'm actually starting to wonder if it's KAC even though I use KAC, too (and I checked: same version, 1.9.1, too). However, regardless of which mod, if it's caused by NaN orbits, then it may be fixed in 6.8.1. I really hope it's not one of your part (modifying) mods (TS, NF*, IFS...).

[pmoffitt]

I have been having issues of not being able to time warp when at my base on Minimus or any vessel near there.  Not sure if it is due to this mod or another I have installed (or a combination of mods) and not sure I want to take the time to figure that out.  I am able to time warp in other places such as the space center or tracking station (and maybe on flights not near the base).  I don't see any hints in the logs.  (I haven't turned on verbose logging.)  Anyone else seen this behavior? 

Still wish there was a good way to keep everything from moving around when it's on the ground.  It seems to be somewhat under control but somethings still move and break things.

I did just manage to lunch my first ship from the Minimus base I have been trying to build up.  (Woot, Minimus now has communication satellites.)

[taniwha]

@pmoffitt What does KSP say about why you can't timewarp? (should be a message)

As for "bolting things down", Take a look at the "no launch clamps" in Diamond Grid: I created them specifically for this sort of thing (and you can use regular (stock, not ReStock (need to sort that out)) launch clamps as well, just be careful not to stage by accident (cover of the EL manual shows stock launch clamps in use, lower left corner)).

[pmoffitt]

19 hours ago, taniwha said:

@pmoffitt What does KSP say about why you can't timewarp? (should be a message)

As for "bolting things down", Take a look at the "no launch clamps" in Diamond Grid: I created them specifically for this sort of thing (and you can use regular (stock, not ReStock (need to sort that out)) launch clamps as well, just be careful not to stage by accident (cover of the EL manual shows stock launch clamps in use, lower left corner)).

KSP doesn't say anything it just doesn't move past real time most of the time.  If I am controlling the main base or anything near it on Minimus, when I push the period button, the time warp bar in the upper left will become visible but not increase.  Sometimes, if I switch vehicles (using [ or ]) and then push the period, it will actually increase warp and then I can switch back to the main base.  When that happens, the period will increase time warp without issue.  It feels like some rover thinks it is moving and is blocking time warp form starting or maybe it is an issue with KerbalAlarmClock, I really don't know.  Nothing in the KSP log that says what is happening.  I should probably turn on verbose logging and see if I can find something.

 

As for "bolting things down" I played with Launch Clamps, they did help some but there were some issues with it like that they adjusted the height of the part from what I has it set to when buildt and I didn't like that.  And even then, things were moving.

The root part of the base should be the lightest piece of the base and all parts are connected using the KAS Resource Transfer Station with link set to dock. All the pieces are on KAS Pylons in an attempt to make things more stable.  There isn't much motion going on but there is some.

Edited September 11, 2020 by pmoffitt
correct typing errors

[taniwha]

@pmoffitt Well, I have no clue about what's going on with timewarp, sorry. I don't think I've ever seen such.

And yes, launch clamps adjust their length, because they must (to accommodate uneven ground). That your vessel winds up at a height different to what you set in the VAB (or SPH) is due to how vessels are spawned. When launching normally (pad or runway), KSP finds the lowest point on the craft and puts that to the "ground". Launch clamps auto-extend to the floor in the VAB and SPH thus setting that to be the lowest point (unless the bottom of the vessel has been put below the floor, in which case that is the lowest point). EL actually does the same thing with two differences: first it pre-rotates the clamps so they are pointing in the right direction (because EL lets you rotate a vessel arbitrarily), and second, the clamp lengths are reset to their default. This is to avoid clamped vessels being spawned too high.

There are three things you can do about this:

1. Add a part to the base of your vessel that comes down to the VAB/SPH floor when the vessel is at the desired height. You can always remove it and recycle it
2. Use a -Y bounds stake on higher ground to set the height of the base of your vessel. This can be a problem on flat ground, though (I actually prefer building on hillsides).
3. A combination of the two

Unfortunately, as things are currently, there is no way to raise a survey stake. This is due to EL's rules for what qualifies as a survey stake:

• The part must have the stake module
• The part must be the only part in the vessel

The first is not surprising, but the second is there to avoid survey stakes attached to the sides of ships for storage (not that this is possible with EL's stakes, but a mod replacing the stakes could allow it) being added to the survey site incorrectly. Sure, I could have made them have an "on/off switch", but I wanted stakes to be as easy to use as possible.

Well, actually, there is a way to raise a stake: just drop it on a part of the vessel that's the right height: EL does not care whether the stake has been driven into the ground or is just floating around (this is why stakes that have fallen over aren't too big a deal).

Anyway, built vessels with launch clamps not being at the height set in the editor is because EL gives you much more control over the vessel's position and orientation than most people would ever want. For reference:

Also, some might recognize this:

[pmoffitt]

On 9/10/2020 at 7:19 PM, taniwha said:

@pmoffitt Well, I have no clue about what's going on with timewarp, sorry. I don't think I've ever seen such.

And yes, launch clamps adjust their length, because they must (to accommodate uneven ground). That your vessel winds up at a height different to what you set in the VAB (or SPH) is due to how vessels are spawned. When launching normally (pad or runway), KSP finds the lowest point on the craft and puts that to the "ground". Launch clamps auto-extend to the floor in the VAB and SPH thus setting that to be the lowest point (unless the bottom of the vessel has been put below the floor, in which case that is the lowest point). EL actually does the same thing with two differences: first it pre-rotates the clamps so they are pointing in the right direction (because EL lets you rotate a vessel arbitrarily), and second, the clamp lengths are reset to their default. This is to avoid clamped vessels being spawned too high.

There are three things you can do about this:

1. Add a part to the base of your vessel that comes down to the VAB/SPH floor when the vessel is at the desired height. You can always remove it and recycle it
2. Use a -Y bounds stake on higher ground to set the height of the base of your vessel. This can be a problem on flat ground, though (I actually prefer building on hillsides).
3. A combination of the two

Unfortunately, as things are currently, there is no way to raise a survey stake. This is due to EL's rules for what qualifies as a survey stake:

• The part must have the stake module
• The part must be the only part in the vessel

The first is not surprising, but the second is there to avoid survey stakes attached to the sides of ships for storage (not that this is possible with EL's stakes, but a mod replacing the stakes could allow it) being added to the survey site incorrectly. Sure, I could have made them have an "on/off switch", but I wanted stakes to be as easy to use as possible.

Well, actually, there is a way to raise a stake: just drop it on a part of the vessel that's the right height: EL does not care whether the stake has been driven into the ground or is just floating around (this is why stakes that have fallen over aren't too big a deal).

Anyway, built vessels with launch clamps not being at the height set in the editor is because EL gives you much more control over the vessel's position and orientation than most people would ever want. For reference:

 

 

I Installed Diamond Grid, those parts are handy. I may have to use your models to create some of my own.  Different sized and see if I can create an offset.  Ok, maybe I will do that someday (dreaming). 

The trick of a disposable part coming down to the ground is handy.  That helps me with several issues including getting rovers to be right side up with they are created. That would also work nicely for creating brand new vessels on the ground.  However, at this point I am mostly adding on to existing vessels on the ground.  The Micro-Pads are giving me fits with orientation.  Either they don't really orient correctly or I just don't understand them.  But it seems to not mater how I set the orientation in the VAB or SPH they always come out the same and the pointer directions on the pads don't seem to matter.  Setting the point direction by having an Engineer reorient them is a pain as you can't completely see the direction they are pointing until you attach them (and they aren't near the ground to work on). The parts being attached always seem to orient themselves based on the default direction of the root part of the vessel in the VAB/SPH (select root part and hit space to return the vessel to it's default orientation).

Using +x direction posts have helped me with some of my orientation issues with brand new vessels (at least now I can keep them from being built into existing things and blowing up and rovers don't have to drive through things to get anywhere).

I attempted to build a 6 way connector with the launch clamp connected to the bottom of the 6-way connector with a micro-pad.  No matter what I tried it ended up with the launch clamp being created coming out horizontally (not going down to the ground). That may be because the clamp wants to connect on the side not on the bottom of the 6-way (or not using the top of the clamp but the side at a right angle).  I had to connect the clamp to the side of the 6-way,  it appears to spawn with the launch clamp going down to the ground that way.

It would be nice to have better control of spawn orientation.  I have no idea how one would do that without adding more complication to building things onto a vessel.

I have built on a greater flat on Minimus.  1.5 km away is a place that has metal ore.  Funny how I can drive a rover out that, stop it, engage parking break and target the main base the navball tells me that the rover is moving 0.2 m/s relative to the target.  In theory, they are the same distance from the center of Minimus and should be "orbiting" at the same velocity about the center of mass. Things that don't solidly snap to a mount point in the VAB/SPH (like servos) end up moving off of where they were attached. (Makes adding a useful crane to the top of a vessel difficult to say the least.)

I have only been playing KSP for about 6 months (starting with KSP version 1.9 from Steam with both Breaking Ground and Making History).  I almost finished a complete Career Mode game before I started installing mods (finished as in having most of the Tech Tree completed). I really like the idea of creating and launching ships without having to get them out of the gravity well of Kerbin.  So, I have started playing sandbox mode to learn how to use MechJeb and now how to build a functional base.  First on Minimus to mine the resources needed and then maybe an orbital base that I can feed materials to.  I still haven't figured out how you guys create such nice looking bases.  Maybe that is a failure of imagination on my part.  At this point, I do have a functioning base that can sustain itself and create ships.  It takes it some time to build the rocket parts and then the ships.  But, I can build small single stage ships on Minimus that have easily 4000+ deltaV using LFO and they don't need to burn it all just to get to obit.  (Need to figure out how to mine / make Xenon for the Ion engine.)

Thanks for listening to me go on.  Also thanks for the Mods and ideas.  (I may be spending too much time trying to make things in KSP and not enough time taking care of real life. But that is always an issue with playing with computers and games.)

Edited September 13, 2020 by pmoffitt

[taniwha]

13 hours ago, pmoffitt said:

Setting the point direction by having an Engineer reorient them is a pain as you can't completely see the direction they are pointing until you attach them (and they aren't near the ground to work on)

Yeah, this can be quite tricky. I haven't decided on what sort of hidden mesh to put inside the pad to help (that's all those arrows visible when placing uses KIS are: just extra mesh). Part of the problem is it depends on which node is being used.

13 hours ago, pmoffitt said:

The parts being attached always seem to orient themselves based on the default direction of the root part of the vessel in the VAB/SPH (select root part and hit space to return the vessel to it's default orientation)

Looking at the code, it does seem to use the default orientation. However, this is, again, for consistency, just not necessarily the consistency you want.

However, the difficulty I've encountered with the micro pad and the other actual pads (not so much with survey builds) is what led me to create craft hulls (they default off because people complained about them: easy to turn on in the EL options in the space center scene). They don't help much when the build is rotationally symmetric, but they sure do help other times (and even help verify it's the correct craft being built).

13 hours ago, pmoffitt said:

Using +x direction posts have helped me with some of my orientation issues with brand new vessels (at least now I can keep them from being built into existing things and blowing up and rovers don't have to drive through things to get anywhere).

Bounds stakes can help here no end, too, especially in combination with direction stakes (so you know exactly which side of the stake the build will be placed). The hulls can help a lot, too, since you can actually see how the build will be placed.

13 hours ago, pmoffitt said:

I have built on a greater flat on Minimus.  1.5 km away is a place that has metal ore.  Funny how I can drive a rover out that, stop it, engage parking break and target the main base the navball tells me that the rover is moving 0.2 m/s relative to the target.  In theory, they are the same distance from the center of Minimus and should be "orbiting" at the same velocity about the center of mass. Things that don't solidly snap to a mount point in the VAB/SPH (like servos) end up moving off of where they were attached. (Makes adding a useful crane to the top of a vessel difficult to say the least.)

These are unrelated. However...

The velocity difference is because on the surface of a rotating sphere, no two points have the same linear velocity vector (they all have the same rotational velocity vector, though): remember, velocity = omega x radius (all three are vectors). Thus, moving directly north-south will change the magnitude of the velocity (as the point moves closer to/further from the axis (depending on start latitude)), and moving east-west will change the direction (as the surface curls around the axis).

Robotics parts are another matter entirely. The drift is due to the joints being springs. That doesn't cause drift for non-robotics parts because all the parts have their static vessel-relative positions and orientations saved. However, robotics parts have an extra joint that allows the parts to sag under various forces, and then the robotics system updates the saved positions and orientations of all the parts. Thus, the next time the vessel is loaded, it is loaded with sagged parts, gravity (or whatever) causes more sag, rinse and repeat. This has always been a problem, even 7 years ago with the robotics mods (Da...Robotics (name will probably get auto-censored) and Infernal Robotics (continuation of DR)). This is actually related to the Base Kraken as documented in the EL manual (4.2.1, pages 20-22).

14 hours ago, pmoffitt said:

Need to figure out how to mine / make Xenon for the Ion engine

Kethane (should work in 1.10.1, despite any warnings, and I'm working on an update that fixes particles) lets you create xenon (as a by-product of LFO production in the large (2.5m) converter). I think @Angel-125's mod suite has something in it, too.

14 hours ago, pmoffitt said:

I still haven't figured out how you guys create such nice looking bases.  Maybe that is a failure of imagination on my part

I'd say more a lack of experience and thus knowledge of how parts fit together (and, I suspect, a desire to design your own rather than just copy someone else's). Parts mods help, no denying that, but functional designs generally look nice. Even my shanty-town stations (rockets "strapped" (docked) together in random orientations with docking ports bolted on (vai KIS) in random positions...) have a certain appeal to them. Maybe I've watched Titan AE and read Stephen Baxter's Raft a few too many times (T.AE isn't too bad a movie, and Raft is (imo) a very good book (and why I argue that Kerbals miscalculated G by an order of magnitude)).

Also, something that I've noticed in all the best base pics I've seen: lights, lots of lights. Especially habitation parts should all have their lights turned on. Lights make the base look lived in and thus cozy. External lights help, too, especially because they make your base visible in the dark and thus set up some nice contrast. Basically, never underestimate the power of good lighting.

[Nicky21]

The latest release is much more stable. 8 builds, no crashes so far!

Thanks !

[taniwha]

@Nicky21 Awesome!!! Thanks for the feedback. Let me know when you get to 16 builds

[taniwha]

I have released version 6.8.2 of Extraplanetary Launchpads.

Changes from 6.8.1:

• Hopefully fix interaction with InterstellarFuelSiwtch tanks
• Fix BoM not updating correctly when changing selected craft
• Fix support for ReStock launch clamps: they should now extend properly when built at a survey site. PR sent for rotated clamps.
• Vessels touching an EL pad (launchpad, orbital doc, landing pad) are forced to take on the landed status of the pad's vessel. This works around a problem in KSP where vessels landed on another vessel (particularly after scene load) are suborbital instead of landed.
• Keep track of the selected pad between vessel switches. This fixes a (to me) major annoyance with multiple pads on a base or station (ie, EL forgetting which pad was selected when a build is finalized).

No new save-breakers in this release, but do check the release notes for 6.8.0 or 6.8.1 if upgrading from an older version.

[pmoffitt]

Oh nice, the selected pad (or survey stake) between vessel switches was annoying but not a show stopper.  I have seen an issue with ReStock / ReStock+ where some parts are no longer stackable (oh wait, that's is probably a conflict with KIS).  I stopped using ReStock for now.

I begin to think the no longer stackable issue wih KAS.CH1 and KAS.JS1 are actually caused by one of the USI mods (konstruction maybe).  And just removing the mods doesn't fix it. 

Edited October 12, 2020 by pmoffitt
Updated cause for parts not being stackable

[taniwha]

@pmoffitt Yes, the non-stackability of ReStock parts is due to their nodes being insided the colliders (and thus a KIS issue). However, I am working on a PR for KIS to deal with the embedded nodes (by adding an auto-offset when dropping parts). I ran into some issues with it while testing and have a pile of things on my plate, but things are close.

[Tonka Crash]

@taniwha Any idea What determines contact with the ground for a drill?  I just completed a drilling rig/resource processor on Mun.  I used 3 drills from @SuicidalInsanity's Stockalike Mining Extension mod.  When I try to start extracting ore the two right most drills get an error "No Ground Contact" The left most has no problem.  They all checked ok when launched directly to the runway.  I did multiple launches to the runway to make sure I had the core heat handled with everything running.

Rotated to show the extension through the ground.  I quit and restarted KSP to check and the two drills still fail to sense the ground.

As built in the SPH

 

 

 

 

 

[taniwha]

@Tonka Crash first, to answer what's wrong: the two rightmost drills are too deep. Now to get to why...

The test for ground contact is done by doing a ray-cast from the tail transform to the head transform (as named in the config file). If this hits the ground (ie, the surface is somewhere between the two transform points and the part is not upside down), then ground contact will be made.

For EL's auger, the head is even with the very edge of the digging end, and the tail is at the mid-point of the yellow housing. I can't say exactly where the transforms are for those (rather cool looking) drills, but my guess is the tail is a little below the axle of the digging scoops. I recommend asking @SuicidalInsanity to raise the tail transform somewhat (maybe well into the motor housing).

BTW, love your base. looks awesome (as mentioned to @pmoffitt, the lighting helps no end). Also, I like the mix of support styles, and that tubing... (just overall a very nice base)

[Hohmannson]

10 hours ago, Tonka Crash said:

What determines contact with the ground for a drill

There is another possibility for a bug - there are cursed places on some celestials, where drill-detected ground does not align with actual ground. On Pol, mostly. In such case, KSP harvester module allows drill-less harvester parts, that only need landed state to operate.