DiEvAl

@TheFod: Do you realize that the shuttle is not going to return to Kerbin (or any place with atmosphere), so there is no point in it being SSTO or even a plane?

I found that it doesn't load some parts of kethane mod. This happens for parts that have a comment before "PART" line: //comment PART { ... } KSPMM doesn't recognize that this is 0.20 part, so it adds another PART{} around it: PART { //comment PART { ... } } To fix this replace line 625 of Main.vb with this line: If Not Regex.IsMatch(orginalcfg, "(//.*\n|\s)*part(//.*\n|\s)*{.*}(//.*\s|\n)*", RegexOptions.IgnoreCase + RegexOptions.Singleline) Then and add Imports System.Text.RegularExpressions

When I launched I thought it didn't do anything. But in fact KSPMM window was just outside of the screen. I clicked on the tray icon and them "Reset Size" and it fixed everything. ;-) Totally unrelated problem that I got (and fixed) today. When I clicked "Disable All Mods", it disabled all mods that were enabled except for the 0th one (KerbalAlarmClock_1.3.3), and thrown this exception: System.ArgumentOutOfRangeException: ØýôõúѠ÷ð ÿрõôõûðüø ôøðÿð÷þýð. ØýôõúѠôþûöõý ñыть ÿþûþöøтõûьýыü чøÑÂûþü, ð õóþ рð÷üõр ýõ ôþûöõý ÿрõòышðть рð÷üõр úþûûõúцøø. ØüѠÿðрðüõтрð: index ò System.Collections.ArrayList.get_Item(Int32 index) ò System.Windows.Forms.DataGridViewRowCollection.SharedRow(Int32 rowIndex) ò System.Windows.Forms.DataGridViewRowCollection.get_Item(Int32 index) ò System.Windows.Forms.DataGridView.get_Item(Int32 columnIndex, Int32 rowIndex) ò Kerbal_Space_Program_Mod_Manager.Main.DisableAllMods() ò Kerbal_Space_Program_Mod_Manager.Main._Lambda$__35(Object a0, EventArgs a1) ò System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e) ò System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e) ò System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e) ò System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e) ò System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met) ò System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met) ò System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea) ò System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea) ò System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) ò System.Windows.Forms.Control.WndProc(Message& m) ò System.Windows.Forms.ScrollableControl.WndProc(Message& m) ò System.Windows.Forms.ToolStrip.WndProc(Message& m) ò System.Windows.Forms.ToolStripDropDown.WndProc(Message& m) ò System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) ò System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) ò System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) I thought I messed something up when I installed Kerbal Alarm Clock manually before using this program. I deleted all files related to it (except for the one in --MODS--). Turns out I had both KerbalAlarmClock and KerbalAlarmClock_1.3.3 in the list, and now one of them (the one that didn't work) is gone. Everything works fine now

-deleted- Never mind, works now.

Construction brief has been updated:

The point of the engine was to allow you to disable it with something other than action groups: by cutting fuel flow. I don't think you can do that with just docking ports.

I was trying to find a way to make a logic gate that has inputs in the same format as outputs (and not just inputs as action groups, outputs as fuel lines). I have an idea that might work, but I don't have time to try it myself. You can try to build it yourself it if you want. Here is a quick sketch: http://i.imgur.com/t0be6KN.png Black lines don't crossfeed fuel, green ones do. Red is an upwards pointing engine. Blue are docking ports. The circle is a roughly spherical object that can be propelled with engine exhaust (e.g. a kerbal). The piston in the middle can move freely up and down and dovk to the docking ports. It operates in low gravity such as on Minmus. It has 5 places to connect fuel lines: A1, A2, B1, B2 and C. When piston is docked to the top docking ports, A1 and A2 are connected, and when it's docked to bottom ports, B1 and B2 are connected. When not in use, piston is docked to either of docking port pairs. You press an action group that undocks all docking ports and activates the engine. Now there are 4 cases. a) Piston is on the top, C is off. Engine doesn't fire. Piston just falls down and docks to the bottom docking ports. Piston is on the bottom, C is off. Engine doesn't fire. Pistons jumps up a bit, out of docking port reach, and docks back. c) Piston is on the top, C is on. Kerbal flies up, hits the falling piston and makes it go back up. d) Piston is on the bottom, C is on. Kerbal flies up, pushes the piston up, and makes it dock with top docking ports. After this piston is on the top if and only if C was on when we pressed the action group. So basically we have a D-flip-flop in which input, output and inverted output are a fuel lines, and clock is an action group. Note: If you have two of these set to the same action group, you can't directly connect on of the outputs of one of them to input of the other. Now imagine you have an unlimited source of fuel and 2 infinite (in both directions) sequences of these D-flip-flops. You have action groups set up like this: 1 = undock all docking ports in first sequence and fire all engines in first sequence. 2 = turn off all engines in first sequence 3 = undock all docking ports in first sequence and fire all engines in second sequence. 4 = turn off all engines in second sequence Conjecture: For every turing machine you can connect them and set their initial states in such a way that: 1) You can remove a finite number of fuel lines and add a finite number of fuel lines to make fuel lines periodic. 2) You can switch initial states of finite number of D-flip-flops to make states periodic. 3) If you activate action groups in order 123412341234... it'll emulate that turing machine. I believe it's true, but haven't proved it yet. EDIT: it might be possible to use whack-a-kerbal balls instead of kerbals.

@Mookie Images link is broken. I think it was supposed to be this: http://noahhascup.imgur.com/all/ But it says "noahhascup's images are not publicly available".

I think he means this:

COMIC SANS!!! (sorry for caps and off-topic)

I made a rover that was supposed to fix the docking port height problem. But when it docks to something, both crafts start spinning rapidly. Obviously, this can happen to any 2 crafts, but with my rover it happens every time. This makes it perfect for exploring this bug. One thing you can do with this bug is locking rotation of a craft: (it's sitting on the docking port, and everything is in equilibrium, even though center of mass is not above the docking port) There might be other uses for it too. I'll look into them later. -- Digital Evil Alien (DiEvAl)

@supersonic29 Where is the center of mass of your Class E Meet N Greet mk3?

Didn't have more time to work on the bearing station yesterday. I'll come back to it after I experiment a bit with using docking ports for propulsion. EDIT: But I remembered one very important thing: if 2 objects aren't physically connected, they'll eventually drift apart. And even having them interlocked like in a bearing doesn't prevent it. If you turn on time warp, they'll slowly drift apart through each other. Obviously this is not an acceptable behavior for a space station or a warp drive, or pretty much anything else. So I discontinue these two projects.

-deleted doublepost-

I had an idea for a very fancy space station core, that can be used for artificial gravity system and/or propellantless propulsion system (fuel-transfer-based). Here is my prototype: (unfortunately, these screenshots don't show that middle part is spinning at about 1 RPM, but I'm too lazy to record a video) So far I have a 8-wheeled glitchy spinny thingy, which uses tons of RCS to start, stops really quickly, and doesn't conserve angular momentum. The reason for all of these problems is that docking ports are too close and they magnetize to each other. Is there a way to disable it, or at least reduce the range? Do small docking ports have the same range as regular ones? Also, I wonder, what other conservation laws it can break... Maybe I can use it for a propulsion system that doesn't use any fuel, and is faster than fuel-transfer-based ones... But I'll leave this for tomorrow. Today I need to rethink the design, and rebuild it, so I can move the docking ports further apart.