colmo

This seems to suggest that wings generate lift, as defined in their .cfg parameters, regardless of their orientation, at least on the forward-backward axis. I'll have to get round to some forward-swept wings to make use of it. I'd like to see a test with the structural wings rotated 90 degrees on one side, and maybe some tests to see if wings with more or less sweep than intended generate less lift, due to not travelling in exactly their optimum direction. There is nothing in the .cfg to indicate "This way is forward", except the orientation of the attachment point. One thing I've been testing is anhedral (downward sweeping - unstable and agile, wants to roll over) and dihedral (upward sweeping - stable, self-leveling) wing placement - this definitely has an effect similar to their real-life counterparts. I built one deliberately unstable fighter (based on the Eurofighter) with anhedral wings which I dubbed the 'Widowmaker' due to it's propensity to fall out of the sky. Avionics didn't help, it just made it reluctant to turn.

I just acquired a 2nd hand 10 inch Dobsonian - Skywatcher 250px. It's a bit of a beast. A Dobsonian mount severely limits astrophotography capability, but it's awesome for the Moon. In astrophotography, one way to avoid the issues of Earth's rotation and view rotation inherent to Alt/Az mounts is to stack short exposures. It's even possible to stack frames from video.

If you want to take the mod approach, check out Vlad. Just Vlad's Airbrakes. The best spaceplanes do indeed glide like a brick - no avoiding it to prevent too much lift causing it to tumble on re-entry. Learn how to use trim (Alt+WASD) to bring your nose up without constantly hitting S.

There are some real sadists playing this game.... Can we have a Kerbal-friendly non-pinch mitt for the claw, please?

1. Define the purpose of the PC, thus the software to be used, including OS, thus the minimum and recommended hardware requirements. PSU wattage is important in gaming rigs with hungry GPUs, for example. Image or video work needs big harddrives. 2. Define the budget. 3. Consider things like screens, chairs, peripherals and backup PSUs in case of power failure. These things will be around a lot longer than the box, so choose wisely! 4. Take anti-static precautions when handling components. 5. Get the install right - try to make a backup or restore of the clean, new OS install, to revert to when things go wrong. 6. Keep the wiring tidy, but don\'t cable tie it into place unless you\'re sure everything goes where it should. TBH, these days it\'s a piece of cake - virtually everything is on the motherboards these days and the days of dip switches are over. The rest...well, it\'s all over the Internet and there are books aplenty.

A carefully specified self-build will last you ages - my own box is well over 5 years old - I\'ve mostly just added more hard-drive space as it got cheaper. As a former PC builder myself, I will say the quality of off-the-shelf PCs was (and probably still is) lower than one you do yourself. My basic build would probably start with - a quality Antec enclosure with PSU, - a Gigabyte motherboard (my experiences of motherboards were that Gigabyte were the best quality, though my present box uses something else - just don\'t scrimp too much on the motherboard) to suit the - CPU of choice (I\'m not sure how much multi-threading would help KSP, which is the only argument for the AMD Bulldozer chips over an Intel at this moment), add plenty of decently fast RAM (currently cheap, so load up), - a small SSD for boot and swap duties plus a - gargantuan regular drive (or two, mirrored RAID, if you\'re really worried about data loss) for storage. Look at your price per Gb for a bare drive. If using a SSD, a slower, green model may suit, unless you work with large files like video, in which case faster is better. I don\'t know what GPUs perform best with KSP, and they\'ve always had diminishing returns with cost - I\'d look at power consumption as much as frame rates as that will test your PSU requirements too. Some GPUs just seem stupidly expensive given their purpose and optimum lifespan. One thing about building a PC - the contents of the box will come and go, but there\'s three or four things you\'ll have a lot longer: - The monitor(s) - I\'d buy the best monitor I could. There are some very good monitors out there now. Learn about IPS, MVA and TN panels and select what\'s right for you - this depends what else you use your PC for. - The mouse and keyboard. Think of your hands, wrists and fingers. Pick comfortable peripherals. - The chair. You may be sat in it some time, so do your body a favour and get a decent one.

I\'ve been holding off getting some astro gear even though it is, after all, what I\'m currently studying. My main fear is that astrophotography can get very expensive very quickly - I\'m eyeing the new Meade LX80 mount to which I can attach my existing photography gear or an OTA I have yet to select. Reports I read suggested the software for tracking was still buggy. The other off-putting feature is the weather of my homeland - it\'s under a cloud much of the time!

Already done with the Damned Aerospace Crewtank. The main advantage of these is the MechJeb exploit allowing multi-part rockets.

I use Linux to run KSP, and quite well too, for a PC with a 5 year old spec (Q6600 with 6Gb and a Nvidia 8800GS). Currently using the Nvidia installed binary, but depending on distribution, other repositories work too. I ran into some issues with other drivers, which don\'t run KSP. Joysticks do NOT work. The KSP Linux thread: http://kerbalspaceprogram.com/forum/index.php?topic=9263.0

That\'s right - it\'s received mixed reviews. All reviews are linked, so you may determine which is most insightful to you.

My planned craft, the \'Orion\'. Unfortunately I have an annoy tendency to refuse to power jet engines using rocket tanks, power rocket engines using jet tanks, use the aero-spike engine, or build anything much bigger than that. Any advice in regards to keeping within these parameters? Its actually quite hard to stop one set of engines guzzling the fuel of the others. I\'m planning a similar smallish K prize candidate using the radial engines - atm, looks like they\'re going on the wingtips to get thrust symmetry with just two. I find the lack of thrust vectoring on the aerospike unforgiving.

Excellent! Have you a pic of the Mk2-to-1 adapter? - D\'oh, didn\'t spot it.

It was the blank second line that did for it then? Grand, looking forward to it.

I\'m away from the PC with the specific file, but I think this is the same (link - http://kerbalspaceprogram.com/forum/index.php?action=dlattach;topic=13711.0;attach=24491): // SFS Craft File ship = CK VTOL-TwinTurbine MkII version = 0.15.2 type = SPH PART {

These also perform excellently as landing flaps. Well done.

Mod the cfg to have no fuel consumption and no thrust

It threw an unhandled exception error. See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.ArgumentException: String cannot be of zero length. Parameter name: oldValue at System.String.ReplaceInternal(String oldValue, String newValue) at System.String.Replace(String oldValue, String newValue) at KSP_Ship_Converter.Form1.Button3_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.269 (RTMGDR.030319-2600) CodeBase: file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll ---------------------------------------- KSP Ship Updater Assembly Version: 1.0.0.0 Win32 Version: 1.0.0.0 CodeBase: file:///Y:/PlayOnLinux\'s%20virtual%20drives/KSP/drive_c/KSP_win/Ships/SPH/KSP%20Ship%20Updater.exe ---------------------------------------- Microsoft.VisualBasic Assembly Version: 10.0.0.0 Win32 Version: 10.0.30319.1 built by: RTMRel CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.269 built by: RTMGDR CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.278 built by: RTMGDR CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.282 built by: RTMGDR CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Runtime.Remoting Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll ---------------------------------------- Accessibility Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging='true' /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box.

Oh goodie....I have a whole fleet needing conversion...

I\'ve built single-engine jets capable of 550 m/s, and similar double engine ones that can\'t go much faster, so lack of power isn\'t it. They do have more altitude ceiling, though, which suggests atmospheric pressure has a bearing. Ultimately, it\'s drag - all those parts accumulate drag (I presume the KSP drag model is still the very basic 'add all the drag of every part together') which is what limits top speed, but the bonus of extra lift makes it easy to take off. One way to reduce overall drag but maintain lift is use fewer wings with an upward angle of attack. Shift+WASD on a wing, canard or control surface does that, in steps of 5 degrees or so. My D171 Deltawing uses this on the front canard. The B231S Jet uses it on the main wings. You can also do it on the rear of the craft, but then the tilt needs to be downwards to induce lift. This is why control surfaces on wings appear to behave strangely - if the wing is in front of the centre of mass, and you try to pull up, the surfaces point down. Move the wing back fractionally behind the CoM, and they point up instead.

Someone needs to stick a load of ladder rungs and a Damned Crewtank to that moonlet. Maybe even add a hatch and crew capacity so it\'s actually a hollowed out space-station. Also, what\'s the rescaleFactor that will get it up to the 2km limit?

There\'s a few things I want to do that the stock parts can\'t cope with, but a rescale adequately fixes: Note the huge swept wings and landing gear - both are the result of adding this to their part.cfg: rescaleFactor = 2.5 (The default value is 1.25). So sizing things up is easy enough...but what about their other parameters? Mass is easy - newmass = oldmass * (rF/1.25)^3 (so for a straight doubling of linear dimension, you multiply the mass by 8 - this is true of volumes too) However, what about the rest? Lift, drag (inc. angular drag), breaking values, crash tolerance, etc.? I want to create only new parts that are in balance with the old. I\'m not a physicist or engineer, so this may actually be a facile question, but I\'m open to ideas.

The hatch will be more like a cat-flap

Give some of my birds a go (link in sig). A few key things to get right first - put the heavy stuff (fuel tanks) in the middle of the plane, if the plane pitches forward, move the wings forward (and vice versa). Use the standard winglet at the back of the plane, or the standard canard if the plane wants to go nose up, because it generates more lift. Put control surfaces on the back of the main wings. Use a tailfin with small control surface to give yaw control. Deltawings are the easiest to fly, but they require a canard at the front, and I find you need to angle either that canard and/or the control surfaces on the back of the big wing. Angled surfaces mean that the plane pitches up depending on speed and atmospheric pressure, so lift balance is not the same at all velocities. My biplanes take the opposite approach - low-speed planes just use lots of wings to generate lift.

You can copy ships from the VAB to the SPH folder and launch from the runway instead. If you want to be able to edit them in the SPH, open the .craft file and change the line near the top that ends VAB to SPH.