Wolf Baginski

If you're flying a plane with wings on the default alignment you'll see that the plane is pointing slightly above the prograde indicator in level flight, and a bigger wing will reduce the difference. That's basic aerodynamics. At any particular angle-of-attack, the bigger wing has more drag. But it needs a lower angle-of-attack to get the same lift. And if you're flying nose-high the fuselage will generate more drag. So a slight rotation of the wings will pay off. How much? You would have to test, but least drag at cruising speed will have the nose and prograde markers aligned and on the horizon. The classic short-wing high-speed design is the F-104 Starfighter. It was designed for altitude and speed, as was the English Electric Lightning used by the RAF, which solved the problems by a Kerbalish answer, "Moar thrust!". It still has fairly small wings. I usually use Procedural Wings for my spaceplanes, and with the body lift from Mk2 parts it can sometimes be a bit tricky getting weight far enough forward. I have successfully flown a Mk2 design with no wings, but directional stability was low, and take-off speed was in the silly-high range. A while back, I built a plane reminiscent of the bomber designs of the early Fifties, and flew non-stop around Kerbin at sub-sonic speeds. With more powerful engines and better intakes it would go supersonic. But the wing was big, probably too big.

I've been testing Spaceplanes, which can be a bit different. But, with the right intakes, one per Rapier, I can get over 1400 m/s before the switch to rocket-mode, and not get too much heating. I watch the apoapsis (Kerbal Engineer is good for this) cutting power when it slightly exceeds the target height. Since I'm still deep in atmosphere the apoapsis will drop during the coast upwards, and a short burn after leaving atmosphere will correct any undershoot, and incidentally raise the periapsis a little. The circularisation burn is locked to Prograde with the SAS and it can be done in two burns. Burn 1 raises the periapsis above the atmosphere, while Burn 2 on the next orbit's apoapsis completes the job. Spaceplanes essentially switch modes with the equivalent of a low gravity turn, dropping their nose at around 20km to get the most out of air-breathing mode. With the new drag models, and the re-balanced thrust from engines, things in atmosphere will be a bit different, Good old-fashioned rockets do better with a steeper climb since the thicker air just wastes delta-V. The thrust and iSP changes will all have an effect on existing designs.

I find myself baffled by the use of pre-coolers. Maybe their characteristics, as an extra intake, are a slightly crude way of modelling what they do, though that would depend on the pressure and speed curves. A wingtip mounted stack of intake, pre-cooler, and R.A.P.I.E.R seems worth trying, rather than some other 1.25m part.

The R.A.P.I.E.R. can be set to auto-toggle between modes though the timing may not be ideal. I set up an Action Group to toggle the engines and the intakes together. I have found single-R.A.P.I.E.R. designs to be a bit difficult to get up to the high-thrust speed region, but they're possible with small wings (lower drag) and small spaceplanes. This is where a parts-mod can pay off. There is at least one ultra-short cargo bay for Mk2 spaceplanes. This is one of my successful single-R.A.P.I.E.R designs using stock parts. The wing is a bit bigger than it needs to be. You could use a 1.25m Service Bay forward of the cockpit to carry Science, and the cargo bay maybe ought to be moved forwards. It works, but it's only a start. It's a bit marginal, you could replace the cargo bay with a crew compartment, but where do you put the docking port?

I would seriously consider the B9 Procedural Wings, since they can much reduce the number of components, and a wing can include fuel tanks.

Here's an idea: A "bulged" cargo bay. Not super-guppy style, but with the belly and doors having a little more clearance for radially-attached parts on a 1.25m core. You could have a very short adaptor which has attachment space for batteries and other useful stuff. Would the adaptor need bay-doors? I'm not sure, depends how you attach the satellite being delivered to orbit, and you need the length clearance.

Scramjets at higher altitudes than conventional engines, that's the whole point, and when orbital velocity is about Mach 7.8, with slight but noticable drag changes with attitude, before you get low enough to see the shock-heating, it's tricky getting a plausible balance. The scaling effects on Kerbin don't leave that much of a gap for a scramjet to fill.

I am watching this with interest. Wing thickness would be expected to have an effect, but the standard root thickness, combined with a short-span, long-chord, wing on a spaceplane does look implausibly floppy

It's a fairly standard change. In the .cfg file for the engine will be a line for this, defining the location and direction for the attachment points. node_stack_bottom = 0.0, -0.125, 0.0, 0.0, 1.0, 0.0 You'd fasten a decoupler to this node for staging. When v1.0 came out the spec had changed. The direction definition had changed The revised line would be node_stack_bottom = 0.0, -0.125, 0.0, 0.0, -1.0, 0.0 The original version would now have something attached to the bottom node pointing up. Changing the sign fixes that so the object attached will point down. You'll see how the first three numbers, the node location. are set in relation to the object centre, The polarity of the direction numbers now matches that for the location. It can be done with a standard text editor, though Windows and Apple/Linux have slightly different End-of-Line markers. These files use Windows format so Notepad is fine. KSP itself doesn't care about such slight differences, but an Apple/Linux format can be hard to read under Windowsâ€â€the whole file looks like one line. Usual rules, have the original zipfile in a safe place and work on the copy of the .cfg file. This is about as simple a change as you get. It'll work so that you can assemble something but some numbers were generally changed by Squad, such as the temperature limits.

There's detail in the radiation modelling, but I am not sure whether there is detail in the modelling of the shaded areas of a planet. If there's an atmosphere, conduction and convection are going to dominate. There are certainly ways of making radiators, components which block heat conduction, and something like a heat-pump

It can be hard getting an exact number for inclination, but it takes little delta-V to miss the target at about the right angle. You can eveball it while you adjust the burn, the exit trajectory shows the orbital plane. Then, when you get in the SOI, you can do a burn to get the correct periapsis, burn at periapsis to get the initial elliptical orbit, and burn at apoapsis to fine-tune the inclination and timing. Because you're going so slowly at the apoapsis of a highly elliptical orbit you don't need a lot of delta-V. It depends a little on the aerodynamics model, but you can change the amount of braking by adjusting attitude. Pure prograde with a spaceplane produces less braking than going into the radial SAS setting, and you can do that in very thin air. Eventually the attitude can't be maintained by the reaction wheels you have. This sort of manouver can certainly shift the location of the periapsis a little. It's a fine-tuning though, not such a big change. This is the general sort of thing that was done by the Apollo capsule and the Space Shuttle on re-entry, Apollo for the landing point and the Shuttle for losing velocity as high as possible.

I admit I am not keen on complicated IVAs, they seem associated with horribly slow frame rates, though some things may improve with v1.1 But here's some inspiration, a full 360° view of the cockpit interior of a Vulcan B2. The tech is essentially 1950s, but things didn't change until the late 70s, and then it took time. I remember seeing the first HUDs, and it was still a long way to the "glass cockpit" of today. http://www.i360uk.com/hosting/xm655/vulcan_v2.html

Orbital velocity reads at around Mach 7.8 in Kerbal Engineer as you start touching the atmosphere so things could get a mite warm. The altitude maybe is more significant, since it will need air but too much makes the ship explode, though this curve would give you a quick velocity boost with all that thrust at Mach 4 and above. It does look as though you got the Mach numbers wrong when you labelled the graph.

So that's why my Spaceplane blew up on the runway (Not one of your parts). The 0.625 Turbo Jet (The high-speed model in that size) has wonky particle effects, a continuous flame even at zero throttle and no fuel left. I am not using HotRockets. That's annoying but it doesn't break anything.

Having a Kerbal present, and maybe limiting the relative speed of the two craft (but can you click on things fast enough?) would both fit with the idea of a simple system with a low footprint. Some of the early attempts at in-flight refuelling were at the level of passing cans of fuel from one plane to another. It might be simpler just to have the transfer take a little longer, and confirm within range at start and finish. Rendezvous but not docking. And maybe the range could be increased with better tech. If you want outright cheats, you can get them anyway.

I'm trying out my own Lite-version suggestion, since I'm currently running games that are maxed out on Science, as far as the Tech Tree is concerned. It does reduce memory usage enough to be making a difference, and I haven't seen any warnings. Sentinel hasn't flashed me any red-level memory warnings today, even when I was testing a very complicated situation that has been giving somebody else problems. (It's still maybe too-complicated but not hitting RAM limits.) It's improved, and I'd certainly use it were I starting a career or science game from scratch.

Following-up. Your quicksave loaded OK, and I don't see any sign of the troublesome mods I have experienced. You do have a lot of stuff in Kerbin orbit, and it would be worth spending a bit of time in the tracking station deleting debris. But the big jump is when you get close to something. On final rendezvous approach now. And it all starts looking familiar misbehaviour as the Mining thing comes close. I don't seem to be maxing out any of my processor cores, but both the debug window and my system utilities show very high memory usage. And you're going to land that on Minmus? Wow! No, I don't have the tools to be specific, but you look to have a situation involving huge spacecraft, and while memory isn't tight on my system, you look to be running into KSP limits. Eventually things just locked up. That is a very big mining rig you have there, and it might be that if you want something like that you're going to have to resort to "cheat" tools to get it into the target location. Eventually there will be a 64-bit Windows version, and while that might be a problem for some plug-in code, it might be the answer. As it is, I think you have a situation that is a bit too complicated. It was an interesting test of my system, and I know I am getting better from it since I replaced the motherboard. But the end result from your situation is similar to what I was getting, or not-getting, from an overloaded system. And it certainly looks like the limits of what KSP can do.

Mods are likely part of it. The first thing I would check is for excess memory usage, many of the specific problems have that feel. I have had problems with recent WIP versions of a certain space-station parts Mod, it looks to have excessively complicated IVAs. When I was using it, I had some of the same problems with crazy rendezvous/docking. I'll see whether I can get anything from that quicksave, but I may not have the same parts available...

While SCANsat is one of the Mods that gives a good science return without being crazy, I can certainly see the point of not using it. I may be setting up a separate install for sandbox-style ops, without the extra Science stuff, though it does seem to rather miss the point. Maybe somebody should set up a decoration-only science mod which just has a few colorful boxes to stick on your craft? A quick check of the .cfg files shows that everything is done by the .dll, so just removing that folder would kill both the data collection and the part animations. I suppose the Module section would need deleting from the .cfg to stop any error messages. But that would give you a SCANsat lite as a placeholder, so that existing savefiles wouldn't be broken. The actual models and textures would still be there, referenced by the same internal name. And now I am wondering where SCANsat stores its data. It must store the locations scanned somewhere, even if the actual map data is generated from existing in-game sources. Yep, that data is in persistent.sfs

I have seen reports of there being two large Win10 patches last week, in very quick succession, with no real explanation from Microsoft. There were "cumulative updates" on August 11th and August 14th: report here http://www.theregister.co.uk/2015/08/17/microsoft_replaces_windows_10_patch_update_wont_say_why/ The boot process apparently stalling could well be a patch download/install, I had one last week for Windows 7. Microsoft are very reluctant to tell you what is going on when they fiddle with the expensive hardware on your desk. Check, but don't expect a useful reply.

The word is "ordnance" An "ordinance" is a type of law, and the two should not be confused. Unless you are Judge Dredd and the results are funny.

Dihedral helps with the stability, though there are other ways of doing it. Put the wings at the top of the fuselage, such as with the Hawker Harrier and, to get the lower stability of a fighter aircraft, you need anhedral, the opposite. But it doesn't do a lot for the early stages of reentry. You will see more drag from the SAS set to radial rather than prograde, and the more speed you can lose over 50km altitude the better, but you won't see much from the stability boost of dihedral. There's just not enough air. The SAS system can cover up a lot of weaknesses in a design, and this roll stability is one of them. And it needs a lot of dihedral to get a significant loss of total lift. But it needs a lot less lift to roll the plane than to stop it falling out of the air. It's a bit of a simplification but a 5° dihedral will lose less than 1% of total lift, and for small changes, drag is proportional to lift. But the control surfaces roll the plane by generating lift. So a small dihedral is going to make a very small difference. What can matter more is the pitch control. In a conventional layout the centre of mass is in front of the centre of lift, and the pitch control, the tailplane is at the back. So, to keep the plane in balance, the tail has to be pushed down. Which means more total weight needing more lift and creating more drag. Canard foreplanes get the same effect by lifting the nose, which means less lift needed for the same weight, and so less drag. Does it matter? You can make more of a mess by flying the wrong ascent profile.

There's two sorts of cheat. I'm wary of mods that do things like provide way more thrust that fits with stock, it takes away the challenge, but just building and testing a craft in sandbox mode, before going to career mode with it, is a pretty good substitute for simulator training and testing. There's a lot in between those. But it's not fun if it gets too easy.

With the Behemoth mod elsewhere, maybe there isn't the urgency. In the v0.90 days we had three mods giving us 5m tanks. Two seem to have largely faded away. There are design choices, it's not the same look, but it is an answer. I did a trial with one of the Space-Y multi-engine adaptors, inverted and tweakscaled, do deliver several 2.5m station components Drag was a problem, and maybe a big fairing should be the priority.

A good source on the net for information about naval weapons is http://www.navweaps.com It's astonishing what they did with pre-electronic technology. A video here: The reference to HMS Excellent, which is the Royal Navy's gunnery school, suggests this was a serious demo of the old methods. And the is a USN training film showing the computer technology that was used. This was the sort of computer that the old science fiction stories envisaged. By the end of WW2 the RN and USN were getting their range data with radar. By then the USN was transmitting the aiming data direct to the turret control, essentially using synchronised electrical motors called selsyns. And the USN battleships, using those electromechanical systems, were engaging targets in the 1991 Gulf War. There were other sorts of non-electronic computer, mechanical and electrical, digital and analogue, and Babbage's Difference Engine would have worked if it had been built in Victorian times. Oh boy, Lovelace and Babbage... http://sydneypadua.com/2dgoggles/the-marvellous-analytical-engine-how-it-works/