ScrapIron

I had the same problem. I had multiple asteroids attached with tiny crafts (basically short tubes with klaws at opposite ends). After checking everything: electric, thermal, storage, drill depth, etc. the drill wouldn't start. As soon as I detached an asteroid the drill "kicked-in" immediately.

I think this is a great idea. Or an asteroid chain. I tried this with a simple linking mechanism with claws at both ends, too. The thought was to link several asteroids and then mine them all at once. However, after the third asteroid linked, the "wobbles" appeared, and the arrangement violently resonantes until it rips itself apart. And since we can't attach more than one claw from the same craft, there was no way to make it stable. The physics engine (Unity) and/or how KSP interacts with Unity limits some of the design possibilities. With that said, it works great for simpler designs, or forces us to develop creative solutions.

I just experienced this, freaked out, did a search, and this thread popped up. To anyone who experiences this problem, follow any of the three fixes mentioned by Tweedler . Just make sure to back-up, just in case, and boot the game AFTER performing the "persistent.sfs" file swap. Also, if you don't have Steam just find the KSP directory in Program Files, etc., as suggested by The_Cat_In_Space.

Ok, thanks for confirming my suspicions. I've developed an algorithm for non circular transfers. The basic mechanics is relatively simple, alg-trig formulas, but there's no way to solve the system of 5-6 equations I get. The transcendental trig functions make it so. Time gets a little complicated, too. The orbiting craft has to travel partly around its orbit, and then around the rendezvous ellipse. This time has to match the time of the target in orbit. The series expansions relating time and true anamoly, or numerical integration (which is just a simple series with lots of terms) work. My process has been this: given the positions of orbiter and target, determine where the orbiter burns and with what delta-v. I choose a position ahead of the orbiter in increments, then choose increments in delta-v for each position to determine an ellipse that just touches/intersects the target ellipse. Then, check the time of flight of both objects. If times match (are close), then done. I've tried working tangents (derivatives of polar positions) into the problem, but that fails because equal tangents don't insure intersection. Anyway, I've got an iterative procedure that working. I was just wondering if anyone else here has attempted this, and it seems so. There's supposedly a third degree differential equation that's really efficient at getting the solution. I've read a little about the Lambert problem, but I was trying to solve the problem myself, from scratch; just basic principles. Another note, too. Excel sucks for this type of heavy-duty number crunching. I had to put in error catches because dumb excel truncates floating point numbers due to its rudimentary bit scheme. Have to do this in a real math language. I've enjoyed solving this problem by myself, with only basic principles (mechanics, etc.). Now that I've done it, I'm curious to see what other folks have done. I'm relieved too, to know the solution is not closed form (trivial). The drawback of working alone is the almost insane, or obsessed state it can put a person in. I imagine this is how some of the pioneers felt at times, Kepler for sure. Thank you for responding, and thank you for the links. Very appreciated!

I've experienced the same difficulty with the robotic parts. I've tried making movable docking ports so rovers could more easily attach to mining craft on the mun, etc. I also run tests on Kerbin, and when I do, the rover, once docked, using a hinge or hydraulic actuator, violently bounces out of control. I've also tried to make extensions for rover wheels. The thought being, a compact design for transport, and then extend the actuators with the attached wheels for a stable, wide wheel base once a location is reached, i.e. the mun. But the wheels attached to the actuators bounce violently out of control. I've tried using the larger actuators, and I've used steel plates to stiffen the connections. It doesn't seem to matter. It's so bad sometimes, it rips the Rover apart. This should definitely be a high priority bug, as these usages for robotics would seem to be extremely common. I've already wasted days trying to get different designs to work, and now I'm so discouraged, not only am I abandoning using these parts, I'm even discouraged from playing altogether.

I'm very new to the community, but very thankful already to all of the great posts, mods, and calculators. I particularly like the calculators that folks have developed, and I'm wondering if anyone has more detailed knowledge about the actual mathematics. It seems the calculators are using approximations, which is understandable since the math gets tough quickly without them. Specifically, I've been looking at planetary phase angles. Olex's (https://ksp.olex.biz/) calculator and KSP wiki (https://wiki.kerbalspaceprogram.com/wiki/Time) both report that the optimal phase angle for transfer is 44.36 degrees. I can derive this value, but I don't think it's technically correct, and that it could vary, say, between 38-53 degrees. Can anyone discuss this? -Also, I apologize if I'm posting in the wrong place.

Although I've been flight simulating for about 20 years, I'm a little new to KSP. First, thanks to all of the modders out there, and to the entire communtity. A special thanks to linuxgurugamer for creating AFBW. It baffles me why KSP doesn't have an effective way to use a joystick, and no commands for prograde/retrograde/normal, etc. I'm hoping linuxgurugamer (LGG) updates the awesome AFBW for the new version, 1.8 that just came out for KSP. I was so disappointed when I went to play today and realized that Steam updated and the joystick no longer worked. CKAN also showed that AFBW was no longer compatible. Awesome mod LLG.