Luis

This is a bad experiment, since every coin flip happens under different conditions that are impossible to validate. You can't crowd source anecdotes and call the aggregate "data". I know this was just a lighthearted thing, but sheesh.

That's not an especially good reason, because it's entirely possible that you wanted the first press to lower any landing gear that was still up instead. It's also not the reason for this behaviour, because it predates being able to set the starting state of the gear in the VAB. When this bug first appeared, somewhere around .21 I think, landing gear always started raised but you still had to pointlessly press G twice to get it to lower the first time. This is a bug, plain and simple.

I'm generally happy to use mods to overcome peeves, where possible (PreciseNode, KER etc). This takes care of the most egregious stuff, but I'm still left with: 1. Lag in the VAB when moving large subassemblies around. 2. The irregular placement of windows on the Mk1-2 pod that makes symmetrical placement of radial chutes pretty much impossible. 3. Camera gimbal lock. 4. Not being able to set up manoeuvre nodes for a ship before launch. We really ought to be able to right click a landed ship in map view and generate a launch manoeuvre that includes adjustment handles for apoapsis and start of gravity turn. This would give you a suborbital parabolic trajectory that you could add regular M nodes to, for circularisation etc.

There are lots of reasons why they couldn't fly. At least not as normally depicted in D&D. Also, aren't they supposed to be magical?

I'm pretty sure Dragons break a few laws of physics themselves. ^^

That actually sounds like an excellent compromise. I've been thinking about this and I had come to the conclusion that free, unlimited, magical torque did feel a bit too cheaty to me. I was planning to have a personal 'rule' for my next career save that RCS should be used for all turning manouvers. But I like this better. We get high power torque for short term manouvers and low power torque for very minor station keeping. But not enough torque to magically hold a lander on a hillside forever. If this was added to the stock game, I'd be quite happy. If it was created as a mod, I'd install it on any save that was using the other realism mods, such as FAR and Deadly Reentry.

How does the ISS shed angular momentum now? Are they really burning propellant to unwind their gyros every few days or weeks? Edit: This report says that the ISS chooses its attitude so that the net torque over a whole orbit is zero. So they normally only need to burn propellant for major attitude changes to accommodate docking.

Yes, you are doing it wrong, but don't blame yourself. It's because asteroid science is counterintuitive. You can't use the science instruments - they act as if the asteroid wasn't there, as you say. You can however collect a surface sample. You do this by right-clicking the asteroid itself, not the Kerbal. As if that's not weird enough, I believe that the sample you collect counts differently for each biome. So you can collect one sample from an orbit around the Mun, then push it to Kerbin orbit and collect another. I assume the reason for all this is that asteroids are actually ship parts, rather than planetary bodies. So the code for science collection on a planet or moon doesn't work the same way.

I'm afraid you remember incorrectly. 2^64 nanometres is just over 18 million kilometres, which is well inside the orbit of Mercury (69 million km) in our solar system, and about a quarter of the way to Jool in the KSP system.

Making interplanetary craft more interesting. The extra weight is pretty trivial since even the umbrella antenna is very light but a mechanic that rewarded you for having a relay satellite around Duna, so that your tiny lander probe could bounce signals off it, would be very satisfying to me. Ideally, I'd like line of sight calculations to take into account whether the signal is blocked by a planet, but I'd settle for a simple range check.

The Mk1-2 also has windows in very awkward places that interfere with radial parachute placement. I like the looks but it's very annoying to use.

I figured out my particular problem. I had an old version of the DLL in the folder of another plugin that relies on MechJeb. Updating just the copy of the DLL in MechJeb's own folder caused it to break. Updateding both copies restored functionality. Just in case that helps anyone else!

Yes,same for me. Cleared out the previous version, installed v198 to the GameData folder. The part appears in the VAB but attaching it doesn't bring up the menu.

I love the hype and I'm entirely relaxed about the release schedule. KSP is fantastic fun to play right now and it is just going to get better. In fact the only way it could get worse is if an update is released with serious bugs still in it. As for worrying about spoilers, personally I find this weird. KSP doesn't have a narrative, we make that up for ourselves. The fun of new parts for me isn't discovering them in the VAB for the first time, it's building ships with them and flying them. I actively hoover up as much information as I can about new releases and I enjoy watching YouTube videos of other people playing the game, almost as much as playing it myself.

Technically, the semi-opened form of the chute is known as 'reefed'. The effect is similar but drogue chutes are quite different.

You can, of course, always use the master volume control for the computer itself. Most keyboards have function key shortcuts for this.

I agree, it basically makes no sense that we have an SAS that will hold the current vector, but not orient us automatically to prograde or normal. I'd be happy for it to be high up the tech tree, expensive and use a lot of electricity, but it should be there as an option.

Problem with that, is it will tend to spin around the horizontal axis, which will make measuring the deflection very difficult. Take the corners on the left up to one wire and the corners on the right up to another, then it can't spin so easily.

The serial communications is indeed heavily based on Zitronen's plugin. Receiving works almost exactly the same, but I started doing the transmit function before it had been added to KSPSerialIO so my version is a bit different there (and probably less elegant). DSKY functions aren't actually implemented yet but it will use the prog switch to change the numeric buttons from controlling action groups, to being used for data entry. With the prog switch on, you punch in a two-digit program code. If it requires further parameters, you'll then be prompted to enter them, using the OK or Cancel buttons after each one. The actual programs will be fairly simple, because I don't want completely automated missions. It's just intended to remove some of the jobs I find tedious. I'm planning to have a gravity turn program, and programs for changing the apoapsis and periapsis but I haven't decided yet what else to include. It's really there to provide room for expansion. It may open KOS, but it's possible that MechJeb will have the everything I need, and I'm already linking to that. The MechJeb interface isn't done via keybinds (since there aren't any, as you say). The attitude control functions on the KEEB simply send a command request in the serial packet to the game mod and then this calls the MechJeb API directly. This turned out to be a good deal less difficult than I feared.

I'll put the code on GitHub when I get a second. There's nothing especially fancy about the sketch, but there are a lot of separate things to control so I'm bumping right up against the Arduino Leonardo's memory limit. Some of the functions, like the messages that appear on the LCD screen are handled by the mod in KSP and then passed back to the KEEB, as a way of saving space.

Just gone public with my own little project. Here's the link to the thread.

Having worked on this for almost a year, I think I'm finally ready to go public. This is my attempt at a hardware mod, inspired by the many others in this forum. Features: Throttle can be smoothly controlled using a rotary dial, but it also has buttons that will jump immediately to full throttle, 80%, 20% and off. The LED readout shows the current throttle setting. Abort action group triggered by a flashing illuminated button. This must be armed using the switch, which is itself protected by a switch guard. Switches for the RCS, SAS, landing gear, lights and brakes. Each one has an LED to indicate its current state. The brake function can be activated using the momentary push button, or by flicking the switch to activate the parking brake. Numeric buttons for action groups and data entry. Program mode. This allows activation of DSKY-style stored programs and manoeuvres. IVA switch to flip between internal and external views. Twin digital joysticks can be remapped to different keys, to change between flight and docking modes etc. LCD display shows basic orbital/ surface/ docking/ EVA information. Flight mode selector. A rotary switch to change between flight, docking, landing and EVA modes. This remaps the joystick keys and changes the information that appears on the LCD. Battery indicator. 3 LEDs show current battery status and whether it is charging/discharging Staging activated by a flashing illuminated button that is protected by an arming switch. Alarm conditions indicated by a flashing button, buzzer and LCD display message. Press the button to acknowledge the current alarm and silence the buzzer or use the override switch to disable all alarms. Map switch Attitude control system. If MechJeb is fitted on a ship, the attitude-mode rotary switch, and control buttons can be used to automatically orient the ship prograde/retrograde, normal/anti-normal etc. The KEEB (which stands for Kerbal Etc Etc Board) communicates with the game via a plug-in, based on the KSPSerialIO mod by Zitronen. This gives it live updates of the ship's apoapsis, periapsis, speed and so on, as well as the current state of all the controls so the hardware doesn't get out of sync with the game. The electronics is built around an Arduino Leonardo and four SX1509 I/O expander boards. Power is supplied by an external 5v supply module. The case is made from an MDF shell with 3mm aluminium sheet for the exterior. There are still a few loose ends to tidy up, like better panel decals and some extra software features, but I will be demonstrating the KEEB in action at the Sci-Fi Weekender in North Wales, on Saturday 22nd March. A 6-page article with some of the details of the build will also appear in Build Your Own PC magazine on 27th March and then in PC Format magazine on 10th May.

If I measure the gravity high above the Mun, is that a physics experiment or an astronomy one? Is the atmospheric composition of Duna, chemistry or physics? Assigning experiments to one field or another would be fairly arbitrary. And what would it achieve, besides making the science archives screen more complicated?

Failures don't need to be random. I also like the idea of test flight missions but it would be perfectly possible to have missions such as "This engine seems to overheat in a vacuum." or "These parachutes don't deploy above 500m/s." or "This fuel tank leaks slightly." The mission would be to confirm the fault in the part by flying in such a way as to trigger the failure condition, and then manage to recover (through skilled piloting or by having redundant parts) so you can live to tell the tale.

I think the problem with using having the map mode initially just show a smooth sphere, is that map mode isn't actually a separate map at all. It's just a zoomed out view of the real world with some extra labels on it. The planet meshes are all predefined and it would be no simple task to replace it on the fly.