Galane

https://en.wikipedia.org/wiki/OpenCL OpenCL, cross platform, works with nVidia and ATi/AMD GPUs that are new enough. The problem there is the earlier GPUs capable of running OpenCL code are not so speedy at it. For example, a GeForce 9800GT can barely squeeze out 22 khash/second with an OpenCL cryptocoin miner program. (It doesn't fare any better with a miner written for CUDA, nVidia's hardware native GPU program environment.) Go a few generations farther, (and change to AMD) and a Radeon HD 6870 will grind out over 300 khash/second. That's 300,000 256 bit encryption keys per second, and compared to the latest GPUs is considered very slow. There have been special systems built with multiple video cards, capable of trying over a trillion passwords a second. One could crack any 12 character password in five minutes or less. Hollywood password cracking is now real, and with the latest GPUs would be even faster. A super accurate drag model could be done, but not many are going to want to buy a $500+ videocard to use it. Sabre Dance at only 2 degree angle of attack? Ouch.

Sooo, it's more realistically simulating how masses and forces twist parts, and it'll break things it didn't break before, which held together under less realistic physics simulation? I like making things which push beyond the edge cases. Designs that reliably fail can be easier to tell why they fail than one on the edge which sometimes fails and sometimes works perfectly. I just posted a craft in the MechJeb thread, built specifically to always do an extreme fail on landing guidance (and to try MIRVing the VAB, gotta have fun while testing...). Why? To be used for finding what causes such failures, to improve it for ships that aren't so far over the edge. I have one launcher with a bunch of orange tanks, which despite KJR and plenty of struts, still sheds one of the first stage tanks once in a while. Revert to launch and it'll launch again fine. It's one of those edge cases where I can't see anything that stands out as wrong, and since it works almost all the time and this ain't real life where sporadic failures are expensive, not a huge problem. (Unless I was one of the players who never ever uses the F9 key.)

MechJeb landing guidance stress test. http://pastebin.com/L4nrMwmJ I put this together to see if I could make a ship that always fails at landing, looks like I did. Pop it into a 71KM orbit, turn on RCS, target the VAB and watch it fail miserably, every time. It will do large and crazy "corrections", landing guidance will say simulation timeout, then restart. I kept using hyperedit to refill the fuel tanks, also aborted landing and retargeted the VAB several times. It finally chose a trajectory and stuck with it. Still missed hitting the VAB, made a nice MIRV impact on the grass just south of KSC. Solution? Don't install so much turning power. But it might help in debugging why some times with some ships that have normal amount of turning control it flips out and climbs instead of deorbiting and sometimes cannot manage to circularize *and* center an orbit around a planet or moon. (A perfectly circular orbit with a periapsis through the atmosphere, or terrain, tends to not be very survivable.) Instead of trying to figure out edge cases that sometimes work and sometimes don't, try one that goes way past the edge and reliably fails. Hopefully what's going un-right will stand out. Edit: I updated to build 181 to re-test this, deleted all of MechJeb's configuration files too so nothing in those from previous builds could be affecting it.

Interesting. Got that config handy? Works with Module Manager? What does KJR 2.0 change that makes it break, but doesn't break with 1.7 and is even better on that part without KJR? Edit: I increased breakForceMultiplier to 1.5 and it still falls apart on the pad.

A Kerbal grappling gun would be useful. Get lost in space? Aim at the ship and shoot a line to grapple and pull yourself back.

I had a bit of a rendezvous autopilot oops here. http://forum.kerbalspaceprogram.com/threads/69162-All-assembled-in-orbit-ready-to-go-but-my-computer-isn-t IIRC it was with build 169. Made some nice debris clouds and even had some pieces exiting Kerbin SOI on nearly straight line courses.

On the pad! Liftoff! For Kerbal Joint Reinforcement 2.0, it has been suggested to edit "breakForceMultiplier" in config.xml and change the value from 1 to 1.5. This has not yet been tested with this craft. Could also replace the tall side tanks with stacked pairs of Rockomax 64's, at the expense of adding more parts.

Don't see why not, whenever asteroids get added to the game. Hopefully KSP won't gain a movie style asteroid belt. A collection of space rocks that thick would clump together into one or more large bodies (AKA a planet or dwarf planet) except in certain circumstances where external gravitational forces would keep them apart, such as in "Trojan asteroids" orbiting Lagrange points. Since KSP physics doesn't do Lagrange points... Would it be possible to simulate them on rails like the planets and moons?

A fix for this should also fix issues with parts made with UbioZur Welding. (I don't use that.)

I posted a ship that shows the problem. Without KJR it has no problem at all. With 1.7 it sags some on the pad and with 2.0 it falls apart. Here's the link, again. http://pastebin.com/v4tykNax

Right now I'm wondering why version 1.7 weakens the TT-70 and 2.0 makes it extremely weak.

Latest build is having a serious problem landing on Kerbin. Shortly after the initial deorbit burn it says reentry simulation timed out. It'll go ahead and land but quite inaccurately and doing a lot of overcorrecting before it gets down to the point where warp can be used to speed up the process. If I abort then immediately retarget it'll work normally, but still miss by 100+ meters. Can't hit the VAB or KSC pad spot on like it used to.

AARP is appalled proud surprised(?) to introduce a FIY (Finish It Yourself) heavy lift launch vehicle, the TT-70 Test Article. As-is, you may go to space today, but you won't be coming back - alive. http://pastebin.com/v4tykNax Note that the Skipper and decoupler on the upper stage should be moved in the staging before sending Kerbals on a suicide mission, or modifying the ship for actual use. This is *not* a flying rocket, it is intended as a test of the TT-70 radial decouplers (due to total failure to hold together with KJR 2.0). Do not kill some Kerbals with it then complain to Alan Aerospace Recycling and Packaging. The only non-stock parts are the big Thundermax 64 tank in the middle, the large adapter on top of it, and the 8 big tanks around the sides. The design originated as a way to get a lot of fuel to orbit, while drastically reducing the number of parts, especially fuel tanks. In flying form it had two rings of 8 ReStock 5-way RCS blocks around the big tank, and one each on the outside ends of the side boosters. It also had a ring of 8 OX-STAT panels on the big tank. There was also a large inline reaction wheel on top of the cone shaped adapter/fuel tank. That plus all the RCS made it very quick turning, even when full of fuel - it makes a pretty good tanker, easily capable of ferrying quite a bit to Mun or Minmus. As it is in the link above, the asparagus staging is set up to work but the solar panels and RCS and other pieces have been removed and the engine and decoupler in the stage stuck on top are in the wrong stage due to it being stripped down for debugging why the TT-70's fail with KJR 2.0 but not 1.7. Fit it out as you like, but don't try using it with KJR 2.0. Moar Struts didn't help. This craft actually does not need KJR to hold together, I tested it without any KJR and it had *less* flex and bounce on the pad as physics kicked in. So I launched it and nothing failed! I've used this to lift much heavier payloads than an orange tank with a command pod and a Skipper. For even heavier payloads, replace the center Mainsail ReStock Bigger Badder Quad Coupler plus four Mainsails and brace it to the big tank with quantum struts. (IIRC, this version may have come before the posted version with 'only' nine Mainsails.) Here's a piccy of the big tank after lofting a heavy rover. Will get a launch shot later.

AARP is appalled proud surprised(?) to introduce a FIY (Finish It Yourself) heavy lift launch vehicle, the TT-70 Test Article. As-is, you may go to space today, but you won't be coming back - alive. http://pastebin.com/v4tykNax Note that the Skipper and decoupler on the upper stage should be moved in the staging before sending Kerbals on a suicide mission, or modifying the ship for actual use. This is *not* a flying rocket, it is intended as a test of the TT-70 radial decouplers. Do not kill some Kerbals with it then complain to Alan Aerospace Recycling and Packaging. The only non-stock parts are the big Thundermax 64 tank in the middle, the large adapter on top of it, and the 8 big tanks around the sides. With KJR 1.7 it stays together. With KJR 2.0 I tested it a few times. The first time all but one TT-70 let go. All subsequent times they all came loose. Then I tried it without any KJR and it was better than with 1.7! Hardly any perceptible downward lurch or bounce at all. So I launched it and nothing broke loose or fell apart, except what was intended to with staging. (I corrected the staging while in flight.) I'm tempted to remove the anti-wobbling struts bracing the orange tank and giving it another go without KJR. Without those struts but with KJR 1.7 I had to lock the center engine's gimbal to keep it stable. I'm a bit surprised that a craft I expected to be dependent on KJR doesn't actually need it, at least not with the payload in this craft. I've used this launcher design to lift much heavier payloads to 71KM orbit. Edit: It's capable of even heavier lifting by sticking a Bigger, Badder, Quad Coupler on the bottom with four Mainsails (12 total) and bracing it to the big tank with quantum struts. Add two rings of 8 5-way RCS blocks to the big tank and it's also surprisingly nimble, able to pivot quickly to align for burns.

Must be the mod parts. Would be nice if someone (who knows their way around a cfg file) could update the KSPX and ReStock files to .23 standard. I can assemble a test article with no mod parts aside from the ReStock tanks - and make it so it'll hang together with 1.7 and come apart in 2.0. (Basically just strip down my big tanker/booster and pile enough weight on in stock parts.)

Some times you need to set the boosters out farther in order to have space between them.

I went back to 1.7 too. With 2.0 the TT-70 radial decouplers won't hold my boosters together, not even with added Quantum struts. The core of the failed one is a ReStock ThunderMax 64 (with one Mainsail on its bottom) with 8 of the extra long Rockomax sized ReStock grey tanks around it, mounted to TT-70's with plenty of standard struts holding the tanks together. With KJR 2.0 the TT-70s all fail soon as KJR is done with its stabilizing load. With 1.7 they hold on just fine, I used that launcher to lift two different heavy rovers form my Eve ship. Tonight I updated to KJR 2.0 and spent a bunch of time failing to get the launcher to stay together before going back to 1.7. I should try KJR 2.0 with some of my large boosters that are mainly built of Rockomax 64 tanks, see if they will break on the pad.

I just used the PAR function for the first time. To keep one rover from drifting off while replacing the rover stacked in the middle, I docked it to a port on the side of the ship's core before undocking and landing the kethane conversion rover to land and recover. After bringing up the replacement conversion rover (with moar quantum struts on its Rockomax decouplers) and getting it docked butt end first after first nose to nose docking to transfer fuel and mono from the booster - I undocked the other rover then gave it a little boost away with RCS. Once it was far enough off, I slowed up with a counter-burst then used PAR+ to rotate so I could use RCS to thrust towards the nose of the ship. Then I set control to the bottom docking port and used TGT- so it'd point away from the target port. I then started thrusting forward a bit so the rover would cut across the nose for easy docking. Once out in front, I shut off SASS and enabled the docking AP with force roll. Had it docked real quick. Now I just have to bring up the two replacement sidesaddle boosters with their larger mono supplies. Might replace the other two as well to further reduce part count and increase mono supply. What I did have a problem with on MJ is landing that rover. After it did the initial deobit burn it kept flipping this way and that, constantly doing corrections and overshooting about 100%. It settled down when I clicked abort autoland then immediately clicked VAB and land at target. It did one more correction burn then settled down to a proper landing, but missed the VAB, landing on the track between it and the pad. Oh well, down safe! I've noticed this same overcorrect this way, then that way, then another way on craft with the ability to rotate quickly. Aborting the landing then enabling it again settles it down, but with even the briefest interruption the target tends to be missed a bit. Put together a 48-7S, Oscar B with a couple OX-STATs and an OKTO2 and try telling it to land. When the overcorrection kicks in it'll burn all its fuel quickly doing 100+ m/sec "corrections" and end up in a skewed orbit instead of just burning retrograde then doing a minor correction or two. (I was using these as deorbitable controls to dock the sidesaddle boosters, then attempting to hit the VAB with them.) If the correction function could be reset without interrupting the targeting... or if it had a self-check on whether or not it was commanding way out of needed range correction burns...

Why are you using that function for docking? Easiest way is to use Kill Rot on the ship you're docking to, set control on the ship doing the docking to its port then target the other ship's port. Engage the autopilot and watch. I don't even know what the PAR- button is for, except it's not something one needs to activate during docking.

Force roll in SASS and in docking autopilot align to different things. For docking it aligns the axes of the control and target ports.

Print in ABS and it's easy to glue together using ordinary ABS cement or some acetone. Can thin ABS cement with acetone to a brushable consistency.

Was running 1.7 with this http://forum.kerbalspaceprogram.com/threads/69162-All-assembled-in-orbit-ready-to-go-but-my-computer-isn-t and it held almost everything together. I'll try it again with 2.0. If it makes it through the apoapsis raising burn then I'll try going to Eve with it. If not, already have plans as detailed there. Unless for some reason KJR has a problem with these cfg modded stock docking ports? http://pastebin.com/7nTXzUB2 (3 way) http://pastebin.com/3jExA8U6 (2 way). I picked up these on the forum a while back, they've been very useful. It was a 3 way which came off the top of the 2 man lander can. I've also knocked those off the top of the can with a Kerbal's head, while trying to use a KAS winch mounted above the can's hatch.

Well, it almost worked. I raised the apoapsis to 105KM, there was a bit of wobble, KJR seemed to be holding everything together. Didn't see anything wrong at the end of the burn. But when I set the next command to circularize... WTH? Something's come adrift. The docking port came off the top of the lander can so there's no in-flight fixing. F9! Will add more quantum struts to the decouplers on top and bottom of the conversion rover to firmly attach to the manned lander and drilling rover. That I can swap out in flight without relaunching everything. Since I can't bring the ship to the tanker, I'll just bring the tanker to the ship, which is in dire need of mono. That... didn't go so well either. Aftermath of rendezvous autopilot slamming the tanker backwards into the assembly, four Skippers at full throttle (a bit too late) after requesting a 150 meter rendezvous. Everything above the can smashed to flinders. Bob and Jeb, either they're ecstatic over the awesome debris cloud, or they're happy to be alive. Some of the many pieces of debris that are on direct Kerbin escape trajectories, or this is how Kerbals simulate a particle accelerator. No problem, we'll just start all over, decouple the lander from the booster and go home... Awesome debris cloud number 2. The deorbit burn failed to achieve sufficient altitude loss and ran headlong into the rear of the booster stage, knocking the lander completely apart and everything off the can, including its parachutes. RIP Bob and Jeb. They don't look happy at all this time. Sooo, I'll be swapping out the conversion rover, with additional bracing. I'll probably also replace all four sidesaddle boosters, replacing the eight each cylindrified mono tanks with one larger tank atop each one. This thing eats mono for pre-breakfast, breakfast, lunch, second lunch, dinner, supper and midnight snack. 18 fewer parts (subtract 28 mono tanks then add 10 quantum struts) should also help a tiny bit. At least it performed as expected under full thrust! (Except for the docking port falling off the lander can...) Edit: Ohhhh. KJR 2.0 is out. I'll try that first. Thank you magic F9 button. (And keeping a backup copy of the save file.)

This has been mentioned quite a few times up the thread. Also the issue where when two ships get close enough for docking (where you can select each other's docking ports) you're unable to right click on command (pod) or control (docking ports etc) parts to get the control menu until going to space center then back to the space view. I didn;t run into that one until I tried to rendezvous two ships in Eve orbit, loaded from the same craft file. Now it happens quite often. The problem with auto selecting when more than one control capable part is present on a craft is selecting the right one. Should it just auto select the one closest to the front *and* aligned with the thrust vector? What about ships where not all the engines or control parts are aligned on the same vector? I think the best fix (aside from Squad fixing it) is for MechJeb to be able to detect that no control/command part is set as the active one then popping up a warning like it does when docking autopilot is enabled and control is NOT set to a docking port. I first encountered this with my kethane satellites around duna and Ike after upgrading from .22 to .23. the satellites wouldn't change orientation, nor wout their thtottles work, until I set the OKTO2 to control from here. Every ship now I have to explicitly set a control part when the ship it's on is separated from the main ship, even when there is only one part with command and/or control capability. There's an oddity with MechJeb and control where it can still control the orientation of ships via reaction wheels even after all the electric charge is gone. RCS and throttle don't work but the ship can still be flipped this way and that. I haven't tested every part individually with reaction wheels, might just be some in the ReStock pack, but no charge should be no control, no how.

But sadly, no wenches.