Galane

These are all very interesting designs. Good to see all stock parts Eve landers that work. For my Eve lander I've exploited the power of lighter than air flight (four large Hooligan Labs lift bags) to get up to 25KM before lighting the engines. Works from any starting ground altitude. Making it extra difficult I set out to make a lander that could bring a 2 man lander can back to orbit. I also have rovers to mine, refine and refuel the lander because it starts its landing with less than 50% fuel load. Not for weight savings, it can land starting with a full load, but to save fuel in the transfer stage because it'll have to go out to Gilly to top off for the trip back to Kerbin. Just need to get my quad core AMD Phenom II system put together to be able to handle the parts monster ship for the "real" trip out to Eve. 2.5 Ghz dual core AMD 7550 is surprisingly laggy with KSP once the parts count gets up there.

Some SRB gliders I've been experimenting with. glider-landed-0 by g_alan_e, on Flickr The classic SRB with wings and wheels. Stable under thrust in atmo until going fast enough to heat up. Needs constant pitch up correction while gliding. glider-landed-1 by g_alan_e, on Flickr The new SRB. Had to use a pair of dropping wings at the back to be stable under thrust, dropped to be stable gliding. Had problems getting it off the runway, this one scraped its booster off but had enough altitude and up pitch for MechJeb to keep it under control on the way up. Landing was a bit of a miss. glider-landed-2 by g_alan_e, on Flickr Success. I put a huge pair of wings on the front to pry it off the runway. Also put wheels under the booster to protect it. Front wing drop was manually staged, had to time it right. Too late and it would pitch over backwards and slam into the runway. Too early and it'd pitch over forwards and slam into the runway - despite the COL shifting behind the COM after dropping the front wings, which should have made convert to stable rocket flight. Once high enough it would rocket on up OK but had a period where it would pitch up too much before coming back - resulting in losing some downrange distance. Getting off the runway was much easier with the old SRB, sets at enough up angle it has next to no takeoff roll and Ascent Guidance takes it up... sometimes. Can you make a glider with all solid fueled rockets that can get to orbit, (these probably could with manual flying) any sort of orbit with a periapsis at least 70KM, then return to KSC runway for a deadstick landing? These can't do the return, they have no deorbit capability yet, still working on the whole taking off and landing without blowing up thing... You may have noticed the radial mount parachutes. They're attempts at recovering from spins, stalls and dropping straight down backwards. Dunno how they get into that situation and why they won't come out of it automatically even with the chute - when they will glide straight as long as they don't stall. What I've noticed is that control surfaces behind the COL lift up when you want to climb. This in front of the COL drop down. I presume it's to rotate the plane about the COL in flight. Problem is when attempting to take off from the runway all control surfaces except the ones at the very back should go down to pick the plane up. What I get with these ships is all the controls behind the COL moving up and keeping the thing pinned to the runway. This could be corrected by a check to see if the plane has lifted off yet, if not, control surface movement behind COL should be inverted to increase all lift to get the plane up. Another way to correct it, without having to change the game program, is a flap control surface that can only move in one direction and has a top and bottom - and is setup so that when oriented top up and behind COL it will move down when the plane is commanded to pitch up. It should also be action groupable to disable and return to neutral position. I see why canard designs work so well in KSP since all wing surfaces have vertical lift all the time. Real canard design aircraft are more efficient because the main wings don't have to fight against the rear stabilizer's downforce. The traditional forward wing lifting and rear stabilizer pushing down to counteract the slightly forward COM isn't modeled properly. There needs to be some liftless fins to take the part of flat or symmetrical aerofoil horizontal stabilizers, or a way to individually tweak the force strength and direction of wings and fins.

Would that make it a KASteroid?

Mountain boarding mecha!

The video of the airplanes flying together was very nice. Would have worked better had the pilot not tried to buzz the buildings. ;-) Reminded me of that old Sega color vector game TAC-SCAN which had a formation of multiple ships.

Too bad KSP's limitation of not allowing loops of nodes prevents using this to make a Sarrus Linkage. Late part suggestion. Plain old wedges in a few angles which could be stuck on then attach a hinge or rotator or structural part to stick out non-orthogonally. Look up a Kaman 'eggbeater' twin rotor helicopter to see where this idea is going... Synchronizing the two blades would be a problem unless there's some way to craft high speed gearing in KSP? The wedges could also be used to 'bend' a robot or crane arm to be able to reach over an object without needing to add a hinge in the middle. An alternate method would be a hinge which can have its angle tweaked and locked in VAB/SPH. Yet another on the wish list, one shot robot parts that can be moved once and only to their pre-set limit then they lock and the servo control for them vanishes. That'd be useful for something like an Eve rover that will be dropped, unfolded for use then left there. No need to fold up what won't be recovered.

I tried doing that on Duna but the landers I built couldn't bring up enough Kethane to much more than refill their own tanks, and I'd send them down with not much more than enough fuel to land. They could get to minimum orbit then have to make some fuel to rendezvous. Fortunately they were capable of getting to Ike and I'd also taken along two Kethane scanning satellites and one of them had enough fuel left to get out to Ike. My Eve mission (still stalled in Kerbin orbit due to a lack of CPU grunt power) will use two rovers, one for drilling and one for converting Kethane (both will land without parachutes - tried chutes and they'd get unstable and crash) and a manned lander. Connect all with KAS to fuel up then loft high as possible with gas bags before firing up the engines. By manned lander I mean one with a 2 man can, not one that barely gets a command chair and one kerbal back.

If you have any engines in a stage that does not have an inline or radial decoupler in the same stage, MechJeb may light those engines at the same time as engines in a lower stage - even though if you stage manually the engines fire in the sequence you want. The easiest way to see this is to make a simple rocket with a couple of small SRBs with a decoupler between them. Put a Stayputnik on top for remote guidance and four Sepratrons around the upper SRB. Put the lower SRB in the lowest stage (2), the decoupler and upper SRB in the middle stage (1) and the Sepratrons in the top stage (0). Launch with auto staging and a fraction of a second after the first staging and lighting the upper SRB MechJeb will light the Sepratrons instead of waiting for the upper SRB to burn out. If you're doing manual staging, those Sepratrons won't light until you hit the space bar. Currently the options with such cases are 1. Stage manually while Ascent Guidance controls steering and throttle. 2. Set the auto staging limit to one number below the stage where MechJeb won't follow how manual staging works. You will then have to trigger the staging after that point manually, which will happen in the order you've built it. 3. Redesign your rocket to include an inline or radial decoupler *icon* in every stage with an engine. Try placing a couple of the small radial decouplers on the lower SRB (which is in stage 2) and their icons in stage 0 with the Sepratrons, then launch with auto staging set to 0. Also try stacking two inline decouplers between the SRBs but put the icon for the lower decoupler in stage 0. If you put the upper decoupler in stage 0 it will block the thrust of the upper SRB because it won't trigger and drop off until the upper SRB burns out. Edit: Tried it and that doesn't stop it. The decoupler with the engines you don't want to light prematurely has to stay with the rocket. MechJeb does not seem to have any issues flying a rocket with decouplers that will be discarded before they can be triggered because they're not physically attached to any component in the stage their icons are placed into.

On Windows, Run as AN administrator is not the same as running AS Administrator (logged into the Administrator account). There are three main types of Windows user accounts, the Administrator (note uppercase A), which is much like Linux Root but there are still some things one cannot do. Regular user with administrator rights, you can run any program, access almost any folder - but with some things you have to click the "Yes I really want to do that" button and the ability to "Run as an administrator" on a one shot basis using the right click menu or always by setting it in the file's properties. That does not confer *all* of the power of the Administrator account, and you must know the Administrator password to set that in properties. Then there's the pretty much useless (in its default settings) Guest account. If you have a program that's being balky about working properly, the easiest first thing to do is Run as administrator. If that works and you trust it, no problem. Or you can dig deeper and figure out exactly which bits of it Windows is blocking and see if just those parts can be unblocked. For me, I just set KSP to Run as administrator and *#%@ trying to decipher exactly what Windows' problem is with it or what recent update is messing with it. It works and that's what matters to me for KSP.

A list of such DLLs to manually unblock would be very useful, especially since some of the blocked ones seem to be part of vanilla KSP.

I already said I have it in its own folder directly under the drive root, so that is not at all the issue! Some fairly recent Windows update is apparently blocking KSP from loading some mods like MechJeb, Blizzy78's toolbar and even part of its own files that it needs to function. The crew icons wouldn't show up, couldn't get any crew info right clicking the hatch, and with the Kerbal X there was no stack of staging icons so the ship couldn't be launched. Setting it to run as an administrator not logged in as Administrator fixed ALL of those problems. What may be a part of it is if you have *copied* instead of *moved* some mods, craft files etc from an old KSP setup used on Windows XP to a freshly created KSP folder structure under Windows Vista or 7. These newer versions of Windows have a stupid thing going on about allowed permissions on some files and folders created with XP. You're not allowed to save files into the folders. You are allowed to open old files in those folders but cannot save changes to them - but a *copy* of the file with a different name can be saved to the same folder or use the same name in a different location. Then the new file can be copied over the old file, and with a click of the button to override with Administrator-fu, you now have full access rights to *that* file. How to tell if you have one of these problem folders. Right click then go to New. If the only option is New Folder, you have the problem. Create a New Folder then open it and right click - and you have the full list of New things you can create. I have tried Microsoft's official method of taking ownership, I've tried Registry mods that add Take Ownership to the right click menu but none of them have corrected this problem with Windows 7 x64 and old files and folders that where never ever in a protected location with XP. It's like a bank where the teller refuses to allow you to deposit money in your accounts, and the vault door has a sign saying "Absolutely No Admittance" - with a button under it and another sign that says "Press Button to Open Vault". It is a broken thing in Windows for which the only full fix is apparently to *move* all files and folders affected to a different location, then if you need them where they were, move them back. But back to KSP. I made a new folder to put all the KSP stuff into, and extracted a fresh copy of the latest KSP 0.23.5. I then copied mods from my 0.23 setup which were already at their latest version. For all mods that had been updated since I last played, I did new downloads and installed them. 100% of that all worked until a few days ago! Then KSP suddenly had the problems listed above and the only thing that fixed them was running KSP as an administrator, which is similar to running a program as SU in Linux. I haven't tried *moving* my 0.23.5 setup somewhere else then moving it back to see if it'll run with the default permissions a user account with Administrator rights has. I suspect it may not since some of the non-working parts were part of the stock KSP game.

Also @BARCLONE If you're on Windows, right click KSP.exe then click Properties, then the Compatibility tab. Check the Run this program as an administrator tab. (You'll need to know your Administrator password if one is set.) Even if your user account has administrator rights, you're not running *everything* will full access unless you're logged in with the Administrator account. Doing that fixed MechJeb not working, the toolbar not working, the invisible crew (they are in there, I managed to kill the orange suited trio while attempting to figure out WTH was going on) and not having a staging icon stack with the stock ships. If you're on Linux or OSX, try running KSP as superuser (SU command).

I don't have KSP in a protected folder. I made a new folder on D: just for it, and suddenly today MechJeb went missing and if I tried launching stock ships there was no crew and no staging icons and the blizzy toolbar was also not working. Setting ksp.exe to run as Administrator fixed it all. There were some updates pushed out for Win 7 last night so I'm betting the fault lies with one of them.

If you're using 64 bit Windows, right click ksp.exe then click properties. Click the Compatibility tab then check the Run as Administrator box. You'll need to know the Administrator account password for your PC. That is like setting a permanent superuser command. I had to do that to get MechJeb and Blizzy78's toolbar working after the latest updates to Windows 7 x64. I don't know if this is a problem on 32bit Windows. The only x32 version of Windows I've run KSP on was XP. Won't hurt to try checking that box.

If you're using 64 bit Windows, right click ksp.exe then click properties. Click the Compatibility tab then check the Run as Administrator box. You'll need to know the Administrator account password for your PC. That is like setting a permanent superuser command. I had to do that to get MechJeb and Blizzy78's toolbar working after the latest updates to Windows 7 x64.

Cure found. Right click ksp.exe then the compatibility tab and check the administrator box at the bottom. Probably a good thing to put in the OP of this thread. Since the latest round of updates to Windows 7 I've been having to do that with many 32 bit programs to allow them access to their own files. Dunno if it's only a problem on 64 bit Windows or if it's affecting 32 bit versions.

Using Module Manager 2.0.3.0 which was working with MechJeb build 236 yesterday. The only changes I made today was replacing the MechJeb DLL with build 240 and deleting its automatically created config files - to avoid any issue that might crop up from old data. I'll try the latest module manager DLL and see what happens. Edit: With MM 2.1.0 I get a message during startup that it applied 20 patches with 0 errors and Mechjeb tab (build 236) is back but upon attempting to launch a Kerbal X there's still no crew or staging stack so no launch, not even with ascent guidance on. Recover Vessel works. Something I forgot to mention earlier is Blizzy's Toolbar is also not appearing anywhere. It's not in the persistent file, before updating the MM dll I tried a new game and the problem was still there. (Should try that now but I don't expect it to suddenly be a corrupted persistent file when it wasn't before.) Something, somewhere got twiddled when I ran KSP with MJ build 240. Since I run with logging off (it impacts performance quite a bit on this PC, even though it's an Athlon 7550 Dual core 2.5 Ghz with 6 gig RAM and a nVidia 9800 GT with a gig, running Win 7 x64) I can't go back in time and see what KSP did to foul its own nest - if it even would have logged what happened. Know of a good file difference finding program for Windows? If I could compare a fresh unpack of KSP against my current 'working' KSP directory tree I could possibly pin down which file(s) may be affected.

Here's something odd. I was using build 236. Today I see that 240 is released so I download the DLL and replace 236 with it, and I erase the contents of the MechJeb2 folder under plugin data. When I run KSP and go to VAB there's no MechJeb tab, doesn't show up when I go to launch either. The auto saved ship in VAB is unavailable due to an invalid part. So I recover that ship and try to launch a Kerbal X stock ship. Now I get no staging stack and hitting spacebar won't release the clamps. There's no crew either. I can right click the engines and activate them, and same for releasing the clamps one at a time. The recover vessel doesn't appear when I move the mouse up there and the only revert flight option is to launch, VAB option isn't there at all - but is for ships I've built. OK, not good at all. So I change to the build 238 DLL, same problems. Finally I go back to the 236 DLL which was working and uh-oh! Same symptoms. Something else has broken which is preventing MechJeb from being loaded and is also @#%@%#ing with stock ships. Didn't try any stock one other than the Kerbal X so don't know if it affects others. I'm using this module manager .cfg to add MechJeb, which *was* working just fine. I don't have the MechJeb parts installed, just the DLL. @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = flightControl } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advFlightControl } MechJebModuleNodeEditor { unlockTechs = advFlightControl } MechJebModuleTranslatron { unlockTechs = advFlightControl } MechJebModuleWarpHelper { unlockTechs = advFlightControl } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = advFlightControl } MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = unmannedTech } MechJebModuleLandingGuidance { unlockTechs = unmannedTech } MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech } MechJebModuleDockingGuidance { unlockTechs = advUnmanned } MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned } MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned } } } } Looks like I'll have to unpack a fresh copy of the latest KSP and move all the mods to it, for the second time. Previous time was when I made a part .cfg edit that should have worked (simply adding one missing line in an IR hinge .cfg) but caused KSP to be unable to load any parts except a few Hooligan Labs ones, and it even deleted all the asteroids due to no potatoroid part. Replacing the part .cfg with a freshly extracted original didn't fix it, nor did extracting all stock KSP files and overwriting. I had to start with a completely clean setup and re-add mods. KSP .23 also did that "Parts? What parts?" thing when I tried adding the Suspensatron mod, and with some version of TT Multiwheels. In those cases the fix was simply removing the additions KSP had the problem with and it suddenly had parts again. It had also "helpfully" deleted all flights from the saves except for flags, but no biggie because backup copies.

Would it be possible to have parts that are single use? Move them then have them lock in place and the servo control vanish. That would be useful for things intended to be unfolded then left that way, such as an aircraft or rover that will not be retrieved from the planet it's been landed on.

Yes, in some of the dev builds it's been very good. But the latest thing is to try to make it able to find its way to the docking port from just about anywhere, like the opposite side of a big station. I'd just as soon have a toggle to shut that off and use an earlier version of the docking AP that required the player to get the ports aimed at each other then lock down one ship with kill rotation. It *worked* almost all the time. I've built landers with q-struts mounted on disposable parts so that once the engines and fuel tanks are jettisoned, the q-struts aren't hanging around being useless and adding to the part count in the scene. One other gotcha with q-struts and strut guns is if you use them to bridge a docking port pair assembled in VAB or SPH, they won't let go on a decouple node event on that port. You have to manually shut them off then decouple the ports. Then you can turn them back on and they'll automatically engage and disengage from whatever docks with the port.

Just don't mount them on or aim them at non-physics or massless parts like the small girder "struts" - unless you want a device that rigidly locks your ship's rotation in all axes. Hmmm, I may have to try that with an action group to turn it on and off to see if it makes docking with the current dev version of MechJeb work better. ;-)

There's a couple of BBC documentary short films, James May at the Edge of Space and James May on the Moon where he goes for a ride in a U2. The first one is shorter, only covers the U2 ride but it has some bits cut from the longer one. He talks to some of the Astronauts (three of the 12 who have set foot on the Moon have died, the rest aren't getting any younger) who went to the Moon and it also covers all the preparation for his U2 ride. Something crazy about the U2, after all these years, they still use a chase car to talk the pilots down for landing, instead of doing what I'd think should be plenty obvious. Mount a video camera in the bottom of the fuselage so the pilot can see when the wheels are down. 'Course then they wouldn't have a reason to chase the U2's with a Pontiac (imported Holden) GTO.

But Jool has no surface, at least not that can be reached. If the HE3 collection will work when the ship isn't the focus, you could put the airship into an elliptical orbit with an apoapsis above the atmosphere and KSP won't kill it when it's not the active ship and you can switch away when its above atmo. You will have to deal with aerobraking if you're on that ship when it dips into the atmo.

I added that, put it in the same location in the cfg for the industrial hinge as it was in another hinges cfg file, and KSP decided it had no parts at all, except for a small number of Hooligan Labs airship pieces - so it deleted all the asteroids due to the potatoroid part missing. If the testing save had had anything in flight, it all would have been deleted too - everything except flags. KSP .23 or .22 did the same thing when I tried the suspensatron cfg mod on one of the rotatrons, and also when I tried installing TT Multiwheels. Get just one cfg KSP doesn't like and it nukes itself instead of simply ignoring the one file and popping up an error message. I had to do a clean setup of KSP and put all the mods in from scratch to get it working again. Good thing I still haven't tried my .23 saves in .23.5 yet.

RCS delta V? Great heaping gobs of it. ;-) One of the ships' booster stage was a ReStock ThunderMax tank with two rings of 8 5-way blocks, plus two rings of four stock 4-way on the lander. The other one had a booster with four Rockomax 64 tanks (under a ReStock Bigger, Badder, Quad Coupler - a part also used to put four mainsails under the ThunderMax) that also had sixteen 5-way blocks. Both very agile ships with RCS, plus they had plenty of reaction wheel torque. I've used both of those booster core stages with various asparagus arrangements around and different payloads for many flights. The four orange tank one is the main core of the ship still circling Duna and the same for the assembly waiting to go to Eve. The ThunderMax one with a single mainsail in the middle makes a very nice fuel tanker. I had to shut off RCS and finish the docking with just torque for turning while goosing the ship forward with engine thrust. (Four mainsails on each ship so very little throttle was needed.) The wobbling as they approached was all due to SASS and TGT+. The magnetic port attraction would dampen the oscillation. Using TGT+ on both ships has always been a problem because as one ship pitches or yaws, the other tries to track it. That correction causes the first ship to try to track the one docking to it. They just keep giving feedback to each other's targeting and it increases until they're swinging way off target. The solution has always been to get them aimed at each other about 100 meters apart, set kill rot on one (usually the larger one with a slower turn rate) then turn on docking autopilot, sit back and watch it do its thing. What it appeared to be doing with the docking ship was yawing and pitching to keep the port tracking on the other ship instead of translating straight sideways. I much preferred it when the docking autopilot relied on the human to get the right ports aimed at each other then just flew it in to dock with little correction needed.