Galane

Do you have corrective steering on or off?

The history of the Krover-Kleveland series thus far. First off some leftover rockets from AARP's "not-a-missile, really" Armed Camp/Guard program were hastily modified to launch Kethane scanners into Kerbin orbit. Our scientists were disappointed that not only were the best deposits under water or at high latitudes, there were none in the immediate vicinity of KSC, except for a large but low grade deposit just offshore to the south. The next best locations to mine Kethane were the moons, Mun and Minmus. After having an unsolvable systems glitch where only a single scanner can be operable in Kerbin orbit at any time, the decision was made to send a large scanner to Minmus with a large fuel tank so it would be capable of making many orbit inclination changes. Getting such a payload there turned out to be AARP's longest, most failure filled R&D program to date, but the resulting launcher proved to be very useful for the next phase. Alan Aerospace Recycling and Packaging next embarked on a project to design vehicles to mine the newly discovered resource called "Kethane". But simple landers won't do, noooo. They should be mobile! Also, designing a vehicle to reach the Mun is easy-peasy so we shot for Minmus instead because any rocket that can reach Minmus can also reach Mun. The initial design, dubbed "Krover", is quickly scribbled out on a drink coaster in the CAD department's cafeteria then hastily assembled - Neglecting such niceties as lights and ensuring all the wheels were on straight. During drive tests it first goes off the back end of the pad, then wants to constantly swerve to the right. "Just keep bumping the joystick to the side, not like it can drive too fast on Minmus without crashing. It needs to be in space ASAP!" After a surprisingly short series of test flights on top of the Minmus scanner launcher, Krover was on his way to Minmus. It was extremely difficult to drive, was slow to fill its Kethane tank, ran out of power in the dark and our remote operators complained they couldn't watch it work at night without any lights. However, they did eventually find a way to remotely correct the rotation of its two crooked wheels. After filling Krover's tank and launching it back into Minmus orbit, our attention turned to the Mun. A second Krover was assembled but with the 3x2 panels changed out for 6x1's and two RTGs and a pair of small Kethane scanners were added after the chief janitor (and engineer) said "Instead of sending a separate satellite and rover, why not use the rover as the satellite to find the green stuff, then land it on a good spot?". The suggestion was met with such enthusiasm that once again lights were forgotten and unfortunately the crooked jig used to mount Krover's wheels was reused. It was also decided that the changes merited a new name, Kleveland. The new vehicle used a lot of fuel landing, even though the Minmus Intercept* stage was used for the initial deorbit, came down on a steep slope and was impossible to move without it violently swerving and tipping over. It also did not have enough fuel to make it back to Mun orbit, let alone complete a rendezvous. Our dream of having the same rover design for both of Kerbin's moons was dashed. After some quick BOTC (Bottom Of The Coaster) calculations, it was decided to allow Kleveland to crash and start over with a fresh coaster for a Mun mining rover. *Called such because it was required to finish the intercept at Minmus but ended up being weight carried to Mun. Will be removed if/when there are more Kleveland 2M flights. Phase II was then begun. Everything on the wheel mounting jig used on Krover and Kleveland tested out perfect, but after attaching the wheels to the girders, two were always crooked. Rather than continuing to fiddle with the design anymore, the stack of coasters was retrieved from the card table in the rec room and the best scribble was chosen to be the design for Kleveland 2. Much of Kleveland's central stack was kept, with the addition of 2 more RTGs for a total of 4, and two 3x2 panels. The girders were laid out in a straight direction, which eliminated the wheel attaching issues of the original design. LIGHTS! Someone finally remembered the lights. Placing the drills fore and aft presented a problem of where to locate the engines and fuel tanks. The new girders were ideal for laying down a pair of tanks and 10 small engines were mounted in various locations. The new arrangement was powerful enough to lift Kleveland 2 in Kerbin gravity right from ignition. "Overpowered? Don't know the meaning of that word." was heard more than once from members of the design team, along with a "YES! This ought to work on both moons!". The general appointment was soon dissed as the new design also showed itself to be a fuel hog, burning too much on the way down to make it back up from the Mun. Having confidence in the basic layout, several attempts were made with changing the tanks out for stretchy ones, pulled out to the limits of the size of the rover and trying to limit fuel burn by turning some of the engines off but it made no difference, it'd always burn over half the fuel on the way down so there was no way this design was ever coming back up with a full Kethane tank. There was nothing for it but to add a Kethane converter to a Mun mining rover. During a strategy meeting it was decided that the original Krover-Kleveland design was too limited and that unless the wheel problem could be solved it was pretty much useless even for Minmus. Kleveland 2 would become the prime design for Minmus and a modified version with a Kethane converter would be dubbed Kleveland 2M (M for Mun). A small converter was wedged in between the top of the battery and a shortened docking port support girder and after debugging the fuel flow from the converter to the side tanks (enlarged stretchy ones from the Kleveland 2 tests) a 2M was duly launched to Mun. By this point in the program, nobody was surprised that it worked, but more calculations (this time on a 2A/2B ruled writing pad) showed it to be an inefficient way to loft Kethane from the Mun. Turning to a fresh sheet of paper, a design was sketched for a 2M with the stretchy tanks stretched a wee bit farther and a large converter installed. It was named Kleveland 2Ma then abandoned on the (writing) pad as an even less economical way to lift 4,000 units of Kethane. The next step was proceding immediately to Kleveland 3M with two 4,000 unit tanks in tandem on top of an oversized bi-coupler with a single large drill a stack of large batteries, a large converter, 7 RTGs and lots of solar panels. Balance problems despite COM and COT being aligned (it flipped and tumbled down the pad ramp the one time it was tested under power), the need for even more wheels and the problem with it falling apart as the struts vaporized when the rover was staged off the bi-coupler doomed it. (Note: The preceding paragraph never happened, just check AARP's files, there's nothing there on this design.) The next step was proceeding immediately to Kleveland 3M with a single 8,000 unit tank, two large drills, the wheels and girders from Kleveland 2, more batteries, 6 RTGs, a large cnverter and a lot of 6x1 solar panels should have the 3M as a useful workhorse of AARP's Kethane mining system. Despite its greater weight it has shown in simulation (that would be using Hyperedit) to be capable of lifting 8,000 units of Kethane to a 15KM Mun orbit from a surface altitude of less than 3,000 meters, with what should be enough fuel left for a refinery rendezvous. If not, just convert some of the onboard supply. It only remains to build a launcher capable of actually transporting a Kleveland 3M to the Mun. Done! Using the vertical external mounting properties of the large drills, small diameter tanks were extended down from beneath them, either side of a Rockomax 64. That pattern was continued down to the booster stage, which is a hybrid asparagus/parallel staging style. The three upper stage engines do not share fuel. The side engines stay on through circularization then a fuel tanker is docked to top up everything. Once the Transmunar Injection burn is finished, remaining fuel in the side tanks is transferred to the big tank and the side tanks and engines jettisoned. Didn't have to clean them up, the transfer trajectory had them hit the Mun dead center. As for the other part of the program, the orbital refineries are simple and completely unremarkable. Just a stack of an 8,000 unit Kethane tank, an RCS tank, Rockomax 64, some batteries, reaction wheel, large converter, remote guidance unit, engine, RCS jets, a 3-in-one UbioZur Omni docking port and four giant solar panels, stacked as appropriate. A refinery expansion has also been built, but with a 4,000 unit tank, six giant panels and two standard docking ports on its sides. We left the design of these to the journeyman parts stackers and they worked first time out, nothing special about the designs. I just had a look 'round the web, figuring I could find *something* on those 2A/2B or 2B/2A grade school writing tablets with the thick and thin blue lines and the hideous, red and blue, drum beating clown on the cover - but nothing. Absolutely nothing to be found! Students in American grade schools used them by the ton 30+ years ago.

Yeah, but then one has to land the rovers and the Kethane transport landers close to each other and be able to horizontally dock the two to transfer Kethane from the rover to the transport, which on the Mun will likely also need its own converter to be able to refuel to get back to orbit. I've ended up with most of my Kethane on Mun and Minmus in some quite rough territory. So far my rovers have been able to plonk down anywhere and mine Kethane. A few times I've had to move them. If a separate rover and lander can't line up to dock, both are stuck where they are. If the rover is given large enough tanks that when refueled it can get back to orbit to relocate, may as well have everything on one vehicle. A plain lander with both mining and refining would be stuck if it misses the deposit. No Kethane = no way to refuel, would have to make a sub-orbital hop. I may look into such a ship for deposits on flatter ground.

Mods I have installed, in the order installed. SelectRoot http://forum.kerbalspaceprogram.com/showthread.php/43208-0-21-1-Aug12-SelectRoot-Let-another-part-be-root-now-with-less-restrictions MechJeb 2.0.9 http://kerbalspaceprogram.com/21mechjeb209/ (Have to fiddle with some things to get it to be always available in .22) Stretchy Tanks http://kerbalspaceprogram.com/stretchytanks/ Procedural Fairings http://kerbalspaceprogram.com/procedural-fairings/ ReStock http://kerbalspaceprogram.com/0-21-restock-parts/ KSPX x0.2.3 http://forum.kerbalspaceprogram.com/threads/30472-0-21-x-KSPX-Kerbal-Stock-Part-eXpansion-mod-reposted-v0-2-3 (Only the large_shortMonoTank, large_tripleFuelTank, large_sasModule, mini_asas and mini_sas. Mini SAS is really Inline Reaction Wheel Micro.) Kethane mod. Omni docking ports, combining the Clampotron and Clampotron Jr. and one that combines all three sizes. (Find the UbioZur welding thread for the .cfg files to have them.) Quantum struts (still haven't used them on a rocket). With all that loaded, .21 would run for about 5 to 10 minutes before crashing, but while it was running it worked quite well. The Squad texture redux pack made it run very well, often for several hours before it'd crash, quite often I'd be done before it'd crash. With all that loaded, .22 is an absolute slug. Even the spaceport external/menu view is slow. So I wait for the updated shrunken Squad texture pack and one for the latest Kethane mod .8 version. My .21 setup with all these mods and an 11.3 meg save folder (with 71 rockets and one aircraft) is only 1.2 gig (1,289,839,706 bytes) with these reduced size stock textures. Plain vanilla .22, fresh out of the ZIP, not even run yet, is starting out at 1.45 gig (1,564,505,219 bytes). Plain vanilla .21 weighs in at 1.37 gig (1,479,244,660 bytes). Shrinking these huge textures makes a very large difference. I could add more stuff and still be smaller than stock.

Then no .22 for me until this is updated. Unless I want to run it vanilla style. I need to get more RAM in my computer, 8 gigs or so, then upgrade it to 64bit Vista Ultimate from 32bit XP Pro. Already have a dual core Phenom II CPU in it. (Would be unlocked to quad core if the chipset was just one revision newer, but hey, the motherboard was free!)

Because that's yet another mod to add and take up memory space. Even with the Squad textures redux it's real tight on space on this XP box with only 2gig RAM. I assume a 64bit OS with lots of RAM so the KSP process can have the full amount addressable by a 32bit program would work quite a bit better. Love the terrain conformal map, makes it much easier to target hexes around the edges of deposits where with the floating map it was possible for a parallax error to get the landing target outside the hex with kethane.

If you use "Reset [body] Data" does the scanning have to be redone to show the new locations or will it refresh all the hexes that have been scanned, the ones not a capital A in the map blocks in the persistence file?

I installed Hyperedit and have been using it to fill the Kethane tanks to do Kerbin based function testing. Last night I wasted a bunch of time trying to build a rover with a pair of 4,000 unit Kethane tanks in tandem. Figured I could stack it on top of an enbiggened 2 to 1 adapter flipped upside down. Got it balanced with one big drill on one end, center of mass over center of thrust, and it'd flip over. The other gotcha was having to attach the one tank to everything else with struts. Aside from the balance issues, that *could* work - if KSP didn't treat the strut attached parts as part of a lower stage and delete all the struts when the rover's cut loose. Could do it with a pair of clampotron Sr's but that'd just be more weight on the rover. So that whole project went in the bin and I started over with the stretchy tanks, girders and wheels from Kleveland 2M (not pictured yet) and built up from there around an 8,000 unit tank and two big drills to keep it balanced. It's a heavy beast with the large converter, 6 RTGs, tons (literally) of batteries and 12 6x1 solar panels. Amazingly, it can lift from Mun full up with the same two radial mount engines as Kleveland 2M. Doesn't leave much fuel left in the stretchy tanks (which have been pulled out longer) but it does work. I was getting real tired, don't recall if I made rendezvous with the refinery in Mun orbit or not. Now I need to build a launcher under Kleveland 3M (M for Mun) to get it to Mun without Hyperedit, at least once! So much for my ideal of being able to use the same Kethane rovers on both of Kerbin's moons. I supposed I could send a Kleveland 3M to Minmus... but Krover and Kleveland don't have enough fuel to land on Mun and get back to orbit while Kleveland 2M is terribly slow at refueling with its small converter. Could put a large one on and stretch its fuel tanks and call it Kleveland 2Ma but for only 4,000 a trip it's not worth it.

If you could decipher the map blocks in the save file you could drop some Kethane anywhere you want on any planet or moon. I noticed the Sun has zero but there's a map block for Jool. What good is Kethane on a planet that has no solid surface to land on? What you should be able to do is copy the Kethane map data to a text file then paste it into a new save file to preserve your deposit locations. A graphic Kethane editor that works outside the game would be very nice. I'd move the existing deposits on Kerbin that are under water to the nearest land. Got a big one offshore south of KSC I'd like to scoot northwards a bit. 'Course having Kethane mining ROUV's would add a lot to the game.

Would be bunches simpler if one person mods all the .22 pods to integrate MechJeb then posts them somewhere. I copied all the mods I'm using to the .22 install and deeeerrrrppp- it's super laggy and then crashes. Going to have to wait for PolecatEZ to get the texture redux updated for it, and for Kethane. Going to have to go back through my rocket catalog and add nosecones to the ones without them.

Avast Antivirus does not do a false positive.

I've run them both ways on several rockets and been able to create complex boosters that keep all the engines lit AND drain the tanks without imbalance. The trick is to go in and out from the center, not around in a circle. Despite the outward pipes, the fuel will drain from the outer tanks first, same as asparagus staging, but without the staging. That's how I built a huge SSTO. Just kept adding engines and fuel until it would make a 70KM orbit with just a whiff of fuel left in the first stage. Several hours worth of R&D and many launches into this one. Now I need to design a bigger Kethane rover, with 8,000 unit capacity and the big drill, and of course a bigger launcher. Going to have to find some good aftermarket wheels too because the stock ones just won't cut it.

Tried that once with a booster that had quad tanks in parallel, with an action group to shut two engines off. It only drained two on one side then went spinning around. If it'd drain opposite corners it would have worked.

For going downhill, don't use the brakes at all! Set action groups to toggle the motors on the front and rear wheels. When going downhill, disable the front wheels and periodically hit the reverse key to apply counter torque on the rear wheels. They'll slow the rover down without flipping it over like braking with all the wheels or reversing all the motors can. Counter torquing the motors is also far less "grabby" than using the brakes and can't lock the wheels so you're less likely to slide the wheels. As for MechJeb's speed control, it doesn't do squat to limit the speed of a rover rolling freely downhill. Lost your way? Use MechJeb's landing autopilot as beacon. Pick a location on the map then watch the distance. If it's getting less, you're driving the right way. If you have rockets on the lander it'll also save you in the event of a "terrain assisted launch". Quickly poke the land somewhere button and it will level out and land. Set the parking brake before you touch down. If you're using it for direction guidance, click quicker on abort then land somewhere. Now that I know that fuel pipes have to go on backwards to get Kethane converters to fill fuel tanks that're out of direct line fuel flow, I can continue my R&D program for a Kethane mining Mun rover. Minmus is easy, the gravity is so light my first rover design works there, can land and has enough fuel to get back to orbit. As for useless, I still have the stock rover stuck in a crater on the Mun. I may take some of my missiles there and try a bit of orbital bombardment to get rid of it.

Fuel pipes backwards from tank to converter. Got it.

Does it work for .21? I have a rover with a couple of crooked wheels in orbit around Minmus that I want to swap out for the one I fixed. Edit: Decided to try it and it claims I don't have Java and it doesn't find the save file either.

Here's an issue with the mod. The Kethane converters can refill monopropellant tanks wherever they're attached but fuel tanks only if they're directly in line with the converter in the rocket stack. (Verified by taking all the mono tanks off that are directly on the kethane tank and stuck one on one of the stretchies.) I tried connecting the side tanks on this rover with pipes to the converter and pipes to the Kethane tank. Doesn't work. The configuration pictured has a small fuel tank under the converter, which it will fill, but then it stops. The fuel won't go though the pipes to the side tanks. Could repeatedly fill the small tank then manually do alt+right click transfers but that would get old real fast. Can the same crossfeed rules the Kethane converters use for monopropellant be applied to fuel and oxidizer? I've never used an ion engine so I haven't tested if this is also an issue with xenon. Something else that doesn't work (at least not in a usable fashion) with this rover is running the engines and the converter at the same time. It generates enough fuel to keep the far side tank steady at the level it is, while the near side one drains and unbalances the fuel load. I want to be able to take this thing to the Mun and be able to refill its fuel tanks so it can get back up off the Mun. Note: This is a static test mockup, thus the lack of any struts supporting the stuff piled on the top. However, it can be driven around. Shortly after confirmation of the failure to transfer converted fuel to the side tanks and discovering the fuel imbalance issue with running the engines while converting Kethane, someone on the staff took it out for a remote joyride, got it up to nearly 30M/sec several times (with nearly full kethane and fuel tanks!) until the inner rear left wheel failed. The datalogger showed the driver (who will soon be out of a job!) swerved hard, the rover rolled and was severely damaged*. He also extended the solar panels at speeds over 10M/sec, resulting in their instant destruction. (Makes a note not use that brand of PV panels for my house...) *Meaning everything exploded except for the girder units and the 7 wheels still attached to them.

For the Kethane symbol, the mod's author has KH4 on his forum avatar.

Any plans to have the scanned grid show up in Tracking instead of the all empty one?

I'd like to see MechJeb able to do launch control more like how real rockets launch. They light the engines a few seconds before releasing the clamps. That way full thrust is on and the force is already pushing up. The release is fairly gentle, like holding onto the skids on an RC helicopter at full throttle VS having the rotor stopped then dropping it and pegging the throttle at the same instant. The way MechJeb launches, the rocket is under gravitational acceleration *downwards* at the same instant the engines light. That puts huge stresses on the vehicle. Hold the clamps until the engines are on and the rocket just goes up like a balloon. If all the clamps would have to be in the second stage up from the bottom, not a problem. Have a section of Ascent where you can check Launch Control: Delay release by {number box} seconds. If there's anything besides launch clamps in that stage then pop a warning that Launch Control requires only launch clamps in that stage. When I first started using MechJeb I had to reinforce some rockets that were fine with manual control run that way. Can still do it by doing a manual throttle up, ignition then release then engaging the autopilot but I'd prefer it to be automated. Even with such a control those dratted brutal Mainsails could still be a problem. I've taken to setting action groups to lock their gimbals. Seems to help keep them from ripping things apart*. So does locking the gimbals on the central engines on any rocket. I have some that just have a single Skipper in the middle with various others wrapped around asparagus style and locking the gimbal on just that one engine stabilizes the whole thing. Apparently it helps MechJeb a lot to have a central thrust vector that's not wobbling about. *I lost track of how many fails I had with a 4x orange tank and mainsail booster, under a jumbo-ized 1 to 4 Rockomax adapter. The only way I found to keep it together was to surround it with 8 more orange tanks with Skippers and lots of struts and lock the Mainsails gimbals, then asparagus stage. When the first skippers drop, there's still enough struts keeping things together. By the time the second pair drops the altitude is high enough and MJ has backed off the throttle enough that the big engines won't start popping struts. Once I solved its self-shredding problem so it could get a big Kethane scanner to Minmus, it also got used as my reliable booster to lift my Kethane mining rovers to Mun and Minmus. (Getting the rover full of Kethane back up off Mun, a less successful venture...) Here's all the files in my VAB folder right now. http://partsbyemc.com/pub/AARP-Kerbal-Space-rockets.zip Includes a notes file on the mods I have installed. Doesn't mention the Squad stock textures redux but that has no effect on the game other than slashing the memory use by about 300 megabytes so it doesn't crash any more often than vanilla KSP. MechJeb is integrated into the stock command pods so if you don't have any MJ or are also using it integrated the craft files will still work.

Do you think I could edit all those to .707 or .7071 and it'd still work? If it does then a .craft processor to remove unnecessary over-precision on part rotations could be a useful utility to help KSP perform better. If it could also process the persistence and quicksave files to do that, it would be an extremely useful utility. What would be a very useful plugin is an alignment shop. Use it to select two or more parts (possibly upper limit of 8) then click a button to vertically align them all to an average of their various positions. Since vertical position in the VAB appears to be calculated from the floor at zero, that would have to stay with the large numbers. I wonder what KSP does with the vertical position numbers in flight? The reference point would have to change. Another trick for the alignment shop would be perfect angle snaps, especially to 90, 45, 60, 30 and 21.5 degrees, with the decimal positions capped at 4, or 3 if the precision is good enough. The building system has some issues with that. Try rotating an ox-stat around a round fuel tank while looking on from above. Note how the angle of the panel doesn't always stay tangent to the surface of the tank. It tilts back and forth. Is it aligning to the faces of the part rather than tracking perpendicular to the radius? If an alignment shop plugin could have a button to do that, it might be a good feature but not if it blows rotation numbers into scientific notation territory. Programming such a plug in is beyond my skills. I know the *what* but not the *how*. At least I figured out how to manually align the wheels. Now I need to look up how to swap the wheel aligned and leveled Krover for the one orbiting Minmus, without losing its load of Kethane or increasing or reducing its fuel level. Perhaps I'll wait till I get a refinery there and top off its tanks.

And when you go from the SPH to the runway, your vehicle *isn't* rotated 90 degrees. For the actual game physics they probably really aren't from VAB to pad, unless what's seen through the VAB door is actually the exact same 3D space you see from outside on the pad... It's just... aaaaaaahhhhghhh... the default rotation in the VAB is correct per the visuals. Pop in the rover body, attach wheels and it looks ready to roll out the door and up the ramp... but it appears on the pad sideways. To have the position on the pad be 'right' the vehicle has to be built 90 degrees rotated in the VAB, and even then it's 180 off because pressing W has your vehicle driving off the back end of the pad. I should rotate that test rover 180 degrees, sideways the other way, and see if it puts the front end towards the ramp. I never caught that 90 degree rotation building rockets where rotation of the entire vehicle made no difference. Rockets go up. Rockets going sideways not good. And why is it always daylight in the VAB, even in the middle of the night? KSP couldn't change the coordinate system without breaking all previous .craft files, but the number of digits after the decimal on things that don't need so many digits shouldn't be a problem. Just ignore the superfluous digits on old files when loaded and flown and truncate (without rounding!) them when re-saving. Any of them in scientific notation, truncate and convert to normal numbers. If not so easy to ignore the extra, pop up a dialog saying the file needs to be re-saved before it can be loaded/edited/flown.

Here's my test rover. I tried to compare Kleveland 2's numbers to Krovers but couldn't figure out which wheel was on which corner, and it also looked like they were in a different order in the .craft file. That's when the idea hit me (ow!) to make a very simple rover to look at. What still bugs me is WTF the rotation and position mumbers have so many decimal positions? Some here go so far as to require scientific notation! I bet there could be a significant performance increase if the position and rotation numbers of all the parts were limited to only 3 or 4 digits after the decimal point. And why is a 90 degree rotation from the default orientation 0.7071068 or -0.7071068 (or close to it, the final digit was 7, 8 or 9 in Kleveland 2 but all 8 in the test .craft)? Is KSP using radians instead of degrees? Scientific notation to specify the rotation of a component in a simulation *game*? Sheesh. Why rot = -2.000552E-17,-0.7071068,2.000552E-17,-0.7071068 when rot = 0,-0.7071068,0,-0.7071068 does exactly the same thing? I bet rot = 0,-0.7071,0,-0.7071 would be just as good, would reduce the size of .craft files AND reduce the calculation load on the CPU. ship = rover-cfg-test version = 0.21.1 description = type = VAB PART { part = roverBody_4294125302 partName = Part pos = 1.676209E-07,5,2.770103E-07 rot = 0,-0.7071068,0,0.7071068 attRot = 0,-0.7071068,0,0.7071068 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 0 link = trussPiece1x_4294123334 link = trussPiece1x_4294123268 EVENTS { } ACTIONS { } MODULE { name = ModuleTripLogger isEnabled = False EVENTS { } ACTIONS { } Surfaced { } Flew { } FlewBy { } Orbited { } SubOrbited { } } } PART { part = trussPiece1x_4294123334 partName = Part pos = 1.295976,5,3.209211E-07 rot = 0.5000001,0.5000001,-0.5000001,0.5000001 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 1 link = wheelMed_4294118110 link = wheelMed_4294117472 sym = trussPiece1x_4294123268 srfN = srfAttach,roverBody_4294125302 EVENTS { } ACTIONS { } } PART { part = trussPiece1x_4294123268 partName = Part pos = -1.295975,5,3.463971E-07 rot = -0.5000001,0.5000001,-0.5000001,-0.5000001 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 1 link = wheelMed_4294117970 link = wheelMed_4294117288 sym = trussPiece1x_4294123334 srfN = srfAttach,roverBody_4294125302 EVENTS { } ACTIONS { } } PART { part = wheelMed_4294118110 partName = Part pos = 1.295976,5,-0.3245719 rot = 0,0.7071068,0,-0.7071068 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 1 sym = wheelMed_4294117970 srfN = srfAttach,trussPiece1x_4294123334 EVENTS { } ACTIONS { } MODULE { name = ModuleWheel isEnabled = True brakesEngaged = False steeringLocked = False isDamaged = False invertSteering = False motorEnabled = True EVENTS { UnLockSteering { active = True guiActive = False guiIcon = Unlock Steering guiName = Unlock Steering category = Unlock Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } LockSteering { active = True guiActive = False guiIcon = Lock Steering guiName = Lock Steering category = Lock Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } EnableMotor { active = True guiActive = False guiIcon = Enable Motor guiName = Enable Motor category = Enable Motor guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } DisableMotor { active = True guiActive = False guiIcon = Disable Motor guiName = Disable Motor category = Disable Motor guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } InvertSteering { active = True guiActive = False guiIcon = Invert Steering guiName = Invert Steering category = Invert Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } RepairWheel { active = True guiActive = False guiIcon = Repair Wheel guiName = Repair Wheel category = Repair Wheel guiActiveUnfocused = True unfocusedRange = 4 externalToEVAOnly = True } } ACTIONS { InvertSteeringAction { actionGroup = None } LockSteeringAction { actionGroup = None } UnlockSteeringAction { actionGroup = None } ToggleSteeringAction { actionGroup = None } ToggleMotorAction { actionGroup = None } BrakesAction { actionGroup = Brakes } } } MODULE { name = FXModuleConstrainPosition isEnabled = True EVENTS { } ACTIONS { } } } PART { part = wheelMed_4294117970 partName = Part pos = -1.295976,5,0.3245727 rot = -2.000552E-17,-0.7071068,2.000552E-17,-0.7071068 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 1 sym = wheelMed_4294118110 srfN = srfAttach,trussPiece1x_4294123268 EVENTS { } ACTIONS { } MODULE { name = ModuleWheel isEnabled = True brakesEngaged = False steeringLocked = False isDamaged = False invertSteering = False motorEnabled = True EVENTS { UnLockSteering { active = True guiActive = False guiIcon = Unlock Steering guiName = Unlock Steering category = Unlock Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } LockSteering { active = True guiActive = False guiIcon = Lock Steering guiName = Lock Steering category = Lock Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } EnableMotor { active = True guiActive = False guiIcon = Enable Motor guiName = Enable Motor category = Enable Motor guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } DisableMotor { active = True guiActive = False guiIcon = Disable Motor guiName = Disable Motor category = Disable Motor guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } InvertSteering { active = True guiActive = False guiIcon = Invert Steering guiName = Invert Steering category = Invert Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } RepairWheel { active = True guiActive = False guiIcon = Repair Wheel guiName = Repair Wheel category = Repair Wheel guiActiveUnfocused = True unfocusedRange = 4 externalToEVAOnly = True } } ACTIONS { InvertSteeringAction { actionGroup = None } LockSteeringAction { actionGroup = None } UnlockSteeringAction { actionGroup = None } ToggleSteeringAction { actionGroup = None } ToggleMotorAction { actionGroup = None } BrakesAction { actionGroup = Brakes } } } MODULE { name = FXModuleConstrainPosition isEnabled = True EVENTS { } ACTIONS { } } } PART { part = wheelMed_4294117472 partName = Part pos = 1.295976,5,0.3253658 rot = 0,-0.7071068,0,-0.7071068 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 1 sym = wheelMed_4294117288 srfN = srfAttach,trussPiece1x_4294123334 EVENTS { } ACTIONS { } MODULE { name = ModuleWheel isEnabled = True brakesEngaged = False steeringLocked = False isDamaged = False invertSteering = False motorEnabled = True EVENTS { UnLockSteering { active = True guiActive = False guiIcon = Unlock Steering guiName = Unlock Steering category = Unlock Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } LockSteering { active = True guiActive = False guiIcon = Lock Steering guiName = Lock Steering category = Lock Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } EnableMotor { active = True guiActive = False guiIcon = Enable Motor guiName = Enable Motor category = Enable Motor guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } DisableMotor { active = True guiActive = False guiIcon = Disable Motor guiName = Disable Motor category = Disable Motor guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } InvertSteering { active = True guiActive = False guiIcon = Invert Steering guiName = Invert Steering category = Invert Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } RepairWheel { active = True guiActive = False guiIcon = Repair Wheel guiName = Repair Wheel category = Repair Wheel guiActiveUnfocused = True unfocusedRange = 4 externalToEVAOnly = True } } ACTIONS { InvertSteeringAction { actionGroup = None } LockSteeringAction { actionGroup = None } UnlockSteeringAction { actionGroup = None } ToggleSteeringAction { actionGroup = None } ToggleMotorAction { actionGroup = None } BrakesAction { actionGroup = Brakes } } } MODULE { name = FXModuleConstrainPosition isEnabled = True EVENTS { } ACTIONS { } } } PART { part = wheelMed_4294117288 partName = Part pos = -1.295976,5,-0.3253652 rot = 0,-0.7071068,0,0.7071068 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = -1 sqor = -1 attm = 1 sym = wheelMed_4294117472 srfN = srfAttach,trussPiece1x_4294123268 EVENTS { } ACTIONS { } MODULE { name = ModuleWheel isEnabled = True brakesEngaged = False steeringLocked = False isDamaged = False invertSteering = False motorEnabled = True EVENTS { UnLockSteering { active = True guiActive = False guiIcon = Unlock Steering guiName = Unlock Steering category = Unlock Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } LockSteering { active = True guiActive = False guiIcon = Lock Steering guiName = Lock Steering category = Lock Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } EnableMotor { active = True guiActive = False guiIcon = Enable Motor guiName = Enable Motor category = Enable Motor guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } DisableMotor { active = True guiActive = False guiIcon = Disable Motor guiName = Disable Motor category = Disable Motor guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } InvertSteering { active = True guiActive = False guiIcon = Invert Steering guiName = Invert Steering category = Invert Steering guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } RepairWheel { active = True guiActive = False guiIcon = Repair Wheel guiName = Repair Wheel category = Repair Wheel guiActiveUnfocused = True unfocusedRange = 4 externalToEVAOnly = True } } ACTIONS { InvertSteeringAction { actionGroup = None } LockSteeringAction { actionGroup = None } UnlockSteeringAction { actionGroup = None } ToggleSteeringAction { actionGroup = None } ToggleMotorAction { actionGroup = None } BrakesAction { actionGroup = Brakes } } } MODULE { name = FXModuleConstrainPosition isEnabled = True EVENTS { } ACTIONS { } } }

This answer brought to you by the numbers 0.7071068 -0.7071068 and 0,0,0,1 I made a very simple test rover using editor extensions vertical snap to ensure the wheels would be attached straight. These are the numbers to align the wheels of a four wheel rover, turned sideways in the VAB so that when KSP spins the entire ship 90 degrees onto the pad (WTH does it do that?) the wheels will be aligned straight in case you want to drive off the pad without having to drive back and forth to turn. pos = 3.55579,33.96711,2.078393 <-Position coordinates. The middle number is the vertical position in the VAB, NOT relative to any other part of the rocket. To have all your wheels in the same plane, change all the middle numbers to be identical. Choose it from one wheel and copy it to all the other wheels. rot = 0,0.7071068,0,0.7071068 <-This wheel happens to be perfectly aligned! attRot = 0,-0.5000001,0,0.8660255 <-Change this for ALL the wheels to 0,0,0,1 I'd think there should be a - in there for one side or the other but the test rover came off the build floor with all four wheels set to 0,0,0,1 and in proper left-right orientation. pos = -3.617311,33.96711,-2.062999 rot = 0,0.7071068,0,-0.7071068 <-Another perfectly aligned wheel! attRot = 0,-0.5000001,0,0.8660255 pos = 3.557416,33.96853,-2.063938 rot = 0,0.7372773,0,-0.6755905 <-Ah, now I see the problem. Symmetry and angle snap didn't *quite* snap it right. attRot = 0,0.4617487,0,0.8870109 pos = -3.618935,33.96853,2.079332 rot = 0,-0.6755905,0,-0.7372772 <-Oh, symmetry, you mischievous minx, you've turned this wheel ever so slightly off too. Shame on you. attRot = 0,0.4617487,0,0.8870109 I yanked the launcher out from under Krover, twiddled these numbers and now it drives straight, and I put all the wheels at the same height. Now to make these alterations in the full-up .craft with launcher - or possibly I'll just delete it since I won't be using it again. I may make the changes to the original Kleveland since with a bit more electrical generation added and lowering the wheels to match Kleveland 2's ground clearance it'd be good for Minmus and other small moons. Kleveland 2 appears to drive straight but I'll check its .craft to see if the rotations need tweaked.

Yeahhhh. It doesn't work so well when you try to have two or more ships at once under MJ control. I tried a few times to aim a few boosters and a manned ship at KSP so I could watch a landing amidst a rain of crashing stuff. Didn't work. Would spin the manned ship around but wouldn't fire the engine. Pretty much dead in the water until the first one I sent down had impacted. You can have multiple *unguided* things going down to crash at the same time. Either aim retrograde and burn until the orbit intersects the ground or use landing guidance to start, then abort. Switch to a different ship before the first one drops to far below 70KM. With practice and starting from different altitudes it's likely possible to drop several things onto close to the same place, but only if just none are being actively guided. Last night I was sending my 2nd Kethane mining rover to the Mun. I tapped a tanker almost dry to refuel and dumped it. Just used smart ass to aim retrograde and did the burn manually, then turned off smart ass. I figured it'd do burn and forget. Nuh-uhh! Until that tanker had hit the surface KSP wasn't letting me go anywhere else with anything else, not any way but manually. Could not target anything. Click on Mun, click set as target, it'd flash the orbit green then back to grey. What I haven't tried is a 'no look' MJ guided landing. In other words, using a ship that MJ has no issues with on staging, start from a high enough orbit so you can switch to another ship before entering the atmosphere, then start the automatic landing and switch to another ship and *don't try to do anything else*. Will MJ set it down OK or will it go on a rail to impact?