cgwhite4

After experiencing some problems with the KAS winch system in connecting some rovers on Eve, and IgorZ determining that an auto-strut problem was to blame, I got the beta and modified the designs for the first two rovers, using the TJ-2 as suggested. Prototypes of these two modified rovers were sent to Duna, and they have been successfully connected at my Duna base, allowing me to manufacture fuel on the surface of Duna (one of the rovers has drills, the other has an ISRU). In the process, I discovered that a stock part I had previously overlooked was superior to the system I had originally designed for holding the equipment on top of the chassis. At some point in the future, further rovers with Extraplanetary Launchpads resource extraction/conversion systems may be sent to allow for launches from Duna. As for the original set of rovers on Eve, if I can complete the set (I would need 2 more), they would then be able to "self-replace" with upgraded versions (I'll have to fashion an adapter to allow resource transfer between the two sets). This is definitely working better than the old system, aside from having to get everything closer together (which also means I must be careful with solar/radiator array placement, so as not to have a conflict there: not a problem on Eve since they would fail under the high pressure anyway, but I'll have to be careful on Duna and, should I eventually get there, Laythe).

Good to hear. Resource levels at my Minmus base are now too low to support another mission, but my Gilly base should still have one launch left in it (thanks in part to a procedure I used to suppress a Kraken), and the interplanetary alignment situation I currently have favors Gilly (destination will be Duna). I've also got some space junk floating around Kerbin that I can work on de-orbiting (with a vessel that I launch from Kerbin). Once the space around Kerbin is clean and my Gilly base is back to full crew compliment, my next target will be Moho, but those plans would be going nowhere without working augers.

Jarin, Fireheart318: I believe this is the same problem I reported on page 175, and I believe the update to KSP 1.2.2 is to blame (they probably changed something that interacts with Extraplanetary Launchpads). What we need to do is wait for taniwha to diagnose and fix it. Fireheart318: Very low orbiting Gilly station, you say? That sounds dangerous. Some time ago, I did a mission to Low Gilly Orbit. I was in a circular orbit at about 5km altitude. Unfortunately, Gilly has mountains that are taller than that, and I had a Controlled Flight Into Terrain incident resulting in Rapid Unscheduled Disassembly. Best to stay up at least 10km if you are not in a landing approach or liftoff.

escu: I see you are using some mods other than EL's prerequisites. You should probably list those (and their version numbers) so taniwha knows the relevant situation on your computer exactly. If the problem happens to be a mod conflict, he will likely need this information to diagnose it correctly. Thanks to your screenshots, I see you are running Flight Engineer (which I do not have). I do not recognize those gold domes in your base. What mod are those from?

I have another auger issue. This time, it continues to indicate inactive and the button continues to say start instead of stop (even though the animation starts). Most importantly, no metal ore is produced. Pressing the button again has no effect: the button still reads start, the animation continues, and metal ore is not produced. This time, I initially observed the problem at my Minmus base, but tested my Gilly base, and got the same result. As before, I am able to continue with my current mission due to having sufficient resources in my tanks to build the needed craft, but the bug will become problematic for future missions. This is likely related to the release of KSP 1.2.2, as this is the first time I have attempted to use augers since then.

Autostrut test complete: 3 images highlighting the results have been added to previous link. The one now in position 3 shows me turning on the autostrut visualization, position 2 shows the undocked state, and position 1 is the image you requested (and the orange beam pattern therein sure looks different from its undocked counterpart shown in position 2).

https://www.pinterest.com/cgwhite4/ksp-bug-involving-rovers-on-eve/ It looks like the screenshots ended up in reverse chronological order: I'll have to remember to start with the one I want last from now on. For both rovers, the end with the ladder is the front. The Rolling Auger (on the left in most shots, distinguishable by the drill-like parts with yellow cylinders on top (they are Augers from Extraplanetary Launchpads)) is where the winch is mounted (on its rear). The Rolling Forge (with the thinner structure beneath its service bay (the smallest of the Smelters from Extraplanetary Launchpads)) has its connector ports mounted to its sides, so it must "cross the T" on the rear of the Rolling Auger. In the two pictures on the right, the connection is in undocked mode, and both rovers are stationary despite being on a slight slope, thanks to the brakes. In the middle picture, I have just switched it to docked mode. Multiple tires blow, and the rovers begin sliding, which continues in the two pictures on the left, which provide a different angle, and a close-up of a blown tire. You can also see the barriers I had to "spawn in" (by editing the SFS) as a stopgap to prevent the rovers from continuing to slide downhill. Please note that the brakes on both rovers are constantly on, no directional inputs were issued (pitch, roll and yaw meters remain zero), there are no tire-eating "seams" between my rovers and the barriers, and although I forgot to switch to surface mode, the target is a nearby stationary object, thus surface velocity = target velocity.

In KSP 1.2.1, I had been noticing an issue with maneuver calculations. I am running Extraplanetary Launchpads, Kerbal Attachment System, and Module Manager, and I frequently launch missions from my EL-supported bases on Minmus and Gilly. Gilly is used more frequently due to launch window frequency. During some recent missions to Duna, my Trans-Duna Injection would be long enough that I would still be burning when I exited Gilly's Hill Sphere. At the moment I transitioned to Eve's influence, the maneuver calculation would be thrown off, projecting me beyond Dres and requiring that the rest of the burn be completed without accurate delta V information (or worse, requiring me to switch the SAS to hold position mode to avoid a directional change that would ruin the TDI burn). Upon yesterday's release of KSP 1.2.2, things got worse. I launched a vessel from Kerbin on a mission to Gilly to recrew the base there. I was able to get into a parking orbit, but during my Cis-Eve Injection, as soon as my projected course exited Kerbin's Hill Sphere, the maneuver calculation was again thrown off (this time, much more severely). The transport vessel does not contain any EL parts, and has only one KAS part: a connector port (previous missions to Duna and Ike that experienced this issue in KSP 1.2.1 lacked even this connector port). At around the same time as my update to KSP 1.2.2, I updated KAS to 0.6.1, which was active when I attempted the Cis-Eve Injection. As for the other two mods I am using, I have currently EL on 5.5.4, and MM on 2.7.5. I currently suspect that this is a KSP issue, not a mod issue (particularly since it has affected craft that had no mod-based parts whatsoever). Has anyone else experienced a maneuver calculation glitch (perhaps serious enough to ruin your maneuver) when either your vessel or your projected path crosses a Hill Sphere Boundary (e.g., entering that of Mun or Minmus, or exiting that of Kerbin into interplanetary space)? Edit: On closer inspection, I noticed that my trajectory was briefly passing through the Hill Sphere of one of Kerbin's moons without the glitch occurring at that point. It is only occurring when I my trajectory goes interplanetary. I have also now been able to extricate myself from this situation using similar techniques to how I kept my previous Trans-Duna Injections on target. I am now in Gilly orbit preparing for my landing, and did not experience this issue during the Eve capture, Gilly intercept, or Gilly capture burns. I suspect it may occur again in the future unless the underlying problem is found and patched, but for now, I have worked around it. Edit #2: The issue has recurred for another mission of similar profile (another Gilly recrew). Between this mission and the previous one, I sent another mission from Gilly to Duna, and like in 1.2.1, the issue occurred as it exited Gilly's Hill Sphere mid-burn. Edit #3: In yet another Cis-Eve Injection (same mission profile), I have discovered that the glitch will not occur if I am in object view (instead of map view which I have been for previous instances). If I am in object view when my trajectory exits Kerbin's Hill Sphere, I observe the "camera snap" where it pivots about my craft to view it from another angle, which I can use as a signal for when it is safe to switch back to map mode. The issue is still occurring, however, if and at the point at which my trajectory re-intercepts Kerbin (i.e., my orbit goes out first due to needing Eve to gain on me, and ends up exactly 1 Kerbal year long), as well as for Trans-Duna Injections from Gilly when my vessel itself (not its trajectory) exits Gilly's Hill Sphere (One of the countermeasures I am using as a workaround requires me to be in object view so I can see my altimeter and know when to switch SAS modes).

I recently experienced an issue while attempting to attach two rovers together. They are designed so that in order to connect them, one must "cross the T" on the other. I had parked them on a shallow slope on Eve, and had locked the brakes on each. Neither was sliding. I then sent a Kerbal on EVA to attach them via winch. Both rovers are part of a resource extraction/conversion system related to Extraplanetary Launchpads, so a docked connection is required. Unfortunately, any time I attempted to attach them, I would end up with multiple blown tires, and they would start sliding down the hill, away from the command center of my base and its flag. I believe this is related to some brief violent shaking that occurs when I load a quicksave that has a similar pair of docked rovers (also at my Eve base). This shaking occurs at the same time as the clicking sound made by the docking mechanism while focusing on or moving within range of a base using the winch system, and has a tendency to compromise the structural integrity of the rovers, which unfortunately seem to have a structural weak spot where the equipment/command section is mounted to the chassis. I suspect these problems may have something to do with the "physics easing" that has been added in KSP 1.2. Connecting undocked and then switching modes failed to resolve the blown tire / sliding problem. I have had to resort to repairing/resetting damaged rovers via edits to the SFS, and spawning in barriers (made of ore containers and launch clamps) to hold my sliding rovers in place. Attempting to despawn the barriers after making the connection resulted in the sliding resuming, and the barriers are only a temporary solution anyway: to get my base fully online, I must still send 2 more rovers and make 3 more connections (these 3 will be end-to-end instead of "cross the T"), which will likely be problematic. Does anyone know of a more graceful / less drastic workaround for this issue, and is this likely to still be a problem with the new attachment systems in KAS 1.0? I should note that this occurred before KSP 1.2.2 came out today, and I have yet to try anything with it installed (in part due to the patch causing a compatibility warning for Extraplanetary Launchpads). Edit: I realized I had not updated to KAS 0.6.1. However, doing so does not appear to have had an effect on this issue.

HoloYolo: I agree. I have been sending specialized rovers to Eve recently to create a base (I am using Extraplanetary Launchpads). I launch them from my base on Gilly (made of landers), and thus I am able to get into a Low Eve Orbit with plenty of fuel for a retropropulsive entry. Even then, however, my north-south precision is dependent on orbital inclination, and I therefore typically have to drive each rover 20-30 km to get it to my base. Consequently, I have to drive over many seams to get to my destination. I frequently find that when I try to go over a seam on Eve, I end up blowing one or more tires. I believe this is most likely to occur if I hit the seam at an angle (instead of head on) or if I am going too fast. Thankfully, the rovers are manned, so I can have a Kerbal get out and repair the tire. Still, it is quite a nuisance (particularly when I am trying to drive uphill). I am planning a similar operation for Duna, so hopefully this gets fixed soon. Galileo: I can see why. Based on my experience, that looks like a very high probability of a blowout. I recommend quicksaving just before you try to move.

5.5.1 installed, augers back online.

I tried retracting the landing gear on the module of my base containing the two augers, resulting in that module's engine bell acting as landing gear and putting the drills slightly further into the ground. Unfortunately, this had no discernable effect, and to get them any lower, I would have to somehow cause the "rapid unscheduled disassembly" of that module's engine, directly above which is a fuel tank, and that base's fuel tanks are all full. I should also note that whether that module is on its landing legs or on its bell, a non-zero metal ore rate is indicated above the word "stalled", but the main Metal Ore resource bar indicates a rate of zero and does not move.

Xavier Laxworm: After finalizing the build but before releasing the vessel, try adding fuel to the system so that you are full even with the tanks on the vessel you are building. If you are operating on the surface of a celestial object (like I am) and attached to a mining rig with drills and an ISRU, use these to top yourself off before releasing. The system will have no choice but to give the constructed vessel a full tank of fuel when you release (because there will be nowhere else for the fuel to go). If you are operating in orbit, you will probably need to dock with a fuel tanker (or multiple tankers depending on fuel capacity of tanker and constructed vessel), transfer fuel from the tanker(s) to the tanks on your constructed vessel, and then undock from the tanker (so its tanks can't work against you). Make sure all fuel tanks on the constructed vessel and anything attached to your orbital dock are full before releasing, or the fuel will likely end up transferred to any non-full tanks not on your vessel. I have used this procedure (specifically, the surface variant of it) for all launches not from Kerbin, and have even had 1 successful mission from a launchpad since KSP 1.2 came out.

I forgot to mention that the augers with which I am having the issue are of the largest size. They are making contact with the ground: I have had this base since before KSP 1.2 came out, and they were working fine then.

I am experiencing an issue with augers in 5.5.0. I turn them on, but they indicate "stalled" and fail to produce Metal Ore. The Metal Ore tanks in my base on Gilly (which is where the augers I am attempting to use are located) are not full, and I am able to perform resource transfers between them. I have more than enough electricity for the augers to function, and I have verified that there is Metal Ore present at the location of my base. Module Manager and KAS were already updated prior to installation of 5.5.0. No other mods are present (I am not using the features that require KIS). All other resource extraction/conversion at my Gilly base is working normally: Metal Ore can be converted to Metal and through the sequence of steps to build rockets, I was able to build one rocket without running out of resources, and I was able to fuel that rocket. (I did experience a Kraken upon releasing it for launch, but after some trial and error, I was able to work around the Kraken by returning to Kerbal Space Center and coming back before any of my buildings were damaged.) Unfortunately, my next planned launch really needs to be from Gilly (it absolutely cannot be from Kerbal Space Center due to my use of inverted Big-S Delta Wings at the top of my craft to help stabilize it during retrograde Eve atmospheric entry), and I likely do not have enough resources left on-site to build the intended craft without getting my augers working again.

This is the thread I was attempting to post to. Edit: Now, this post is currently pink and listed as hidden. Is that what should have happened? (It did not.) Edit #2: Tried again, and this time, it appeared pink like this one did.

Hello everyone. I just got on the forums today. Right now, I'm trying to notify the individual responsible for maintaining a mod of an apparent bug with said mod. However, I am having difficulty determining if my reply on the mod's topic went through. I know that since it was my first post, it should go onto a moderator approval queue, but I'm not sure how to tell if even that happened. It looked like nothing happened, and in my confusion, I hit the button a second time, and so may have committed an accidental double reply. The second time I pressed the button, it changed briefly to say saving, and then changed back. It's been a couple hours since then, and I'm getting a bit concerned that my reply may have failed. Any advice?