Wolf Baginski

I don't really recall the Valiant, it was half a generation older, but the last Vulcan will cease flying this year. The airframe is just too old, and the expertise needed to extend the life just isn't there any more. In the Red Flag exercises, the Vulcan had a very distinctive shadow that could give away its location . The RAF pilots worked out how to hide it.. They flow low enough to hide the shadow with the wing. I can remember standing on a hillside in Lincolnshire and looking down on a passing Vulcan.

After Max-Q and before MECO and staging. There was a big change in the exhaust plume, still symmetrical, and then things seemed to break up. All right, guys, we are sure where Jebediah was....

The only time I have had a heating problem is with a pure-stock 2.5m stage, a "Skipper" engine and a "Jumbo-64" 2.5m tank. I haven't got around to trying anything bigger, but without some sort of insulator there have been just too many earth-shattering kabooms. There must be default settings for the heat flow, there's nothing different in the part.cfg files. The "Skipper" file does have a commented-out setting. These three look to be standard for all liquid-fuel engines. // heatConductivity = 0.06 // half default skinInternalConductionMult = 4.0 emissiveConstant = 0.8 // engine nozzles are good at radiating. It's common to all three stock sizes, and I am wondering if the Kerbodyne engines have a similar problem. I did some thinking. If the only heat source was the engine, doubling the stack diameter would quadruple the surface area of both the engine-tank joint and the tank as a whole. But there would be eight times the mass of fuel to heat up. On the other hand, the heat generated by the engine depends on the mass of fuel burned, which is related to the thrust. So the Skipper would need to burn four times the fuel to get the same temperature change, which it doesn't. Since it wasn't a problem until KSP v1.0.3 and it doesn't bite until high in the atmosphere I suspect low convection/conduction in the thin air and the radiated heat from the shock-wave heated air. My first fix was doing more coasting, once the apokee was out of the atmosphere. It's also possible that going for three stages instead of two might might reduce the engine heat going into the third stage. But these heat control mods have thermal barrier parts. The Heat Control mod and Heat Management mod have different settings, Heat Control: heatConductivity = 0.001 I have "debris" stages lingering in orbit with very hot engines. It looks a bit excessive that the engine doesn't seem to have cooled down after a couple of days Heat Management: heatConductivity = 0.01 I shall run a test or three, but this may be enough to avoid explosions while allowing the system to cool between burns. I do wonder if having two distinct levels of insulation, with different cost/mass penalties, would be useful

"It's just your rig." I find lines like that a little annoying, guys, but then I started with Flight Simulator on a Z80 processor with 16k of RAM... More seriously, you can manage with low frame rates and keyboard control, but it's a different style of using the keys, and it may not work so well with a joystick. I haven't found FusTek excessive, though my computer is getting old. Age, rather than speed, is what I am watching nervously. It does occur to me that Mod makers could improve how they tell us about these things, or give us some options. Do I want detailed IVA for a space station? It's not something vital, and perhaps it would be a good idea to organise the folders, and document the changes needed, that would let us remove the IVA features. Similarly, some of the bigger Mod packs might be usefully split, or at least organised in a way that helps us choose. I've trimmed a lot of stuff out of B9 Aerospace, cut it back to just the essentially orbital stuff like the M27 Capsule. It wasn't too hard, the folder names for Parts are a big clue. I am not going to complain about somebody getting fancy, but lets not dismiss the problems with "It's just your rig."

Looking at the Wiki entry on Kerbin's atmosphere, it specifies how to convert Kerbin altitude to the US Standard Atmosphere, and that model in turn allows you to calculate what Mach 1 is. Things change at the tropopause, which is a little below 9km on Kerbin. Mach 1 drops from 339 m/s at sea level to 295 m/s at the tropopause, and is then steady to 16km, which is the equivalent to the cruising altitude of Concorde. I didn't bother with figures for higher. Concorde speed was limited, by the thermal heating effects on the aluminium alloy used, to Mach 2.2 I infer from a description of why Concorde was white that the heat flow was dominated by radiation from the shockwave-heated air. One Concorde that was painted in a darker colour was limited to Mach 2. I expect you have already done the calculations, I attacked the problem for rocket boosters and trans-sonic drag. Concorde went supersonic at around 25,000 feet, which is a little over 6km in the Kerbin atmosphere. My plan is to hold at 300m/s until 6km altitude, and then accelerate quickly though Mach 1, and stay below Mach 2.2 (650m/s) until 16km altitude. That should help keep heating problems under control.

One technique which emerges with MechJeb2 ascent guidance is to set a reasonable acceleration limit in MechJeb2, a little bit more than the SRBs can provide, and then the central liquid-fuel booster runs at a low throttle in the thicker atmosphere, where it has a low Isp. When the SRBs run empty and are staged, the central booster can have most of its fuel left and runs with better Isp. Also the drag is less in the thinner air. It can be done manually. Start at full throttle until at over 200 m/s and then throttle back to keep the indicator at the top of the green section. The SRB burn-out is somewhere around 8km altitude, and you will need to increase throttle to near the maximum. The green segment tops out at 20m/s/s which can be marginal for heating if sustained. I have had second-stage boosters overheat and explode if they get too fast too soon. Trans-sonic drag at lower altitudes is still a problem. On the other hand,a higher ascent speed reduces the time fuel has to be burnt against gravity and reduces the time with high-density air. Speed of sound with Kerbin altitude (approximate). Altitude Speed (km) (m/s) 1 334 2 329 3 324 4 319 5 314 6 309 7 304 8 298 9 295 Not everything goes supersonic at the same time, airflow over some parts of a plane are faster than over others, so you'd need a margin to avoid the trans-sonic drag. If you accelerated to 300 m/s and allowed the speed to even drop slightly you would minimise the time in the denser atmosphere, and a 30-second SRB burn does most of it. Concorde went supersonic at about 25000 feet, slightly over 6km in Kerbin terms, so 300 m/s isn't far off. Increase the throttle to get through the trans-sonic region. The speed of sound is computed as constant from 9km to 16km. After that, Kerbin's atmosphere is rather tenuous, but that is where you get lot of pretty red flames on re-entry. Mach 3 and below are fairly safe. Concorde's thermal limit was Mach 2.2 at 60000 feet, which is just below 16km on Kerbin. Call it 650m/s. The flight profile used a slow climb as fuel was burned. Anything faster and they would have had to have used exotic alloys for the structure. If you check the Wiki, you can find how to convert Kerbin altitude to the equivalent in the US Standard Atmosphere, which let me calculate the speed of sound. As for Shuttle SRBs, the separation was at about 45km, which would be somewhere around 35km for Kerbin. Burn time was about 110 seconds. Anyway, I hope that gives you some ideas for using SRBs.

I wouldn't call it a critical bugfix for most purposes, though it does affect loading old saves, but I would be inclined to skip 1.0.3 entirely and release a version for 1.0.4, even if all that involves is a version-check difference. At the moment I am not using the aircraft side. There's a bunch of orbital stuff I am entirely too fond off, such as the M27 command pod. I manually deleted the rest of the Parts folders, and I suppose there's other stuff I don't need to load, but the RAM footprint elsewhere in the B9Aerospace folder doesn't look that significant. A longer-term suggestion: something in a similar style to the M27, either 2.5m or 2.5m-to-3.75m, that could give extra living space and/or service module functions. Not a pure cylinder or cone, maybe a larger flat window panel, maybe two nodes for docking ports, rather than a full 4-port hub. The M27 has a movie influence, and movie spaceships I see, even ones trying to feel real, tend to have more design coherence than an M27 with basic cylindrical parts added. It goes off in the same directions as the Apollo Lunar Module. I have a few ideas I maybe ought to try. I can do 3D modelling, but the specifics of KSP are still obscure to me...

Tentatively, the bugfix in 1.0.4 may have benefits that ripple through other areas. I'm not sure I ever saw the bug itself, the [rob;ems I had may be an install problem that I'd missed and fixed without conscious intent when I upgraded. I did edit a couple of .version files. MechJeb is working, but the default settings probably need tweaking for atmospheric flights. I found they did for best results with all the 1.0.x versions of KSP. Many of the early real launchers had high TWR, and the astronauts pulled a lot of G. With current aerodynamics and heating, things can get out of hand. 1: The Terminal Velocity limit may not be safe at some altitudes. 2: An Acceleration limit helps. 3: On a rocket booster, increasing the Angle-of-attack limit can keep you close to the planned trajectory 3: Look to tweaking the trajectory. The default seems to have the gravity turn a little too fast The YongeTech Tech Tree plug-in is working with the latest version. Anything that works on v1.0.3 should work with v1.0.4 and it looks as though most of the changes will have no great effect once you get into orbit. One of my first test-flights did survive re-entry without a heat-shield, but then I discovered I had forgotten the parachute. Ooops!

I had a glitch with MechJeb that was fixed by a KSP restart, possibly linked to needing to change the graphics setting to use all my screen and not the default window. Several Mods have already had version tweaks put onto Kerbalstuff. There are a few new parts, remember, and I'd expect some aerodynamics and re-rentry tweaks to be needed, at least. The new Yongetech Tech Tree loader/manager doesn't seem to work on v1.0.3 but since that's still under development that doesn't astonish me. I've seen one or two mentions of things needing a recompile to work with earlier v1 version changes, and I've wondered just what that might mean. I am guessing that this is something that needs the compiler to refer to a current Squad DLL to get the calls right, almost routine modern programming. The last programming I did was in BASIC... For MS-DOS...

I did some tests late last night and Chatterer was working with 1.0.3 I see a stack of revised mods appearing on KerbalStuff Since I bought direct from the Squad/KSP site and use the Windows zip file I can have both 1.0.2 and 1.0.3 available I sort of doubt it will make much difference, but nVidia had a new driver version out yesterday. I installed it before I saw the KSP announcement. My hardware is old enough, and KSP is obscure enough, that they never seem to get mentioned in the changelogs from nVidia.

One small UI tweak would be good. There's nothing on that start-screen to indicate there's a drop-down menu to list the available tech trees, nothing to show that there is an alternative available. I don't think I see this every time, but the same symbol as used on a Windows scroll-bar is common. That's in Unicode, at U+25BC and called the Black Down-Pointing Triangle. â–¼ The first time I tried the plug-in I did wonder if the other tech tree had been installed properly.

I use 64-bit Windows 7. With only 4GB of RAM that might seem superfluous, but it make a big difference. The 32-bit version grabs a chunk of the 4GB address space for things such as the video RAM. With only 4GB of RAM I maybe wouldn't see any advantage from a 64-bit version of KSP. I'm using most of my 4GB with 32-bit. With 8GB of RAM, I'd expect things to speed up because there would be far less need for virtual RAM, and a 64-bit KSP would maybe be better able to handle textures and stuff. Though I sometimes wonder why programmers in general insist on keeping everything loaded into RAM, which a disk-cache for the not-in-use stuff might help with.

There was, late in the v0.90 cycle, a Mod with perspex-bubble capsules. That might be good... [Checks] "Panopticon Hi-Viz Command Pod", back in April, I expect it needs the tweak for the node definitions, as well as any rebalancing, and you would have to launch the capsule in a fairing. There's an encapsulated version of the EAS which could be good on a rover. That might be better for immersive VR. I've never been much into IVA, and the tech is expensive. On the other hand, could something be done with a capsule of that sort, with a well-designed IVA, and the Google Cardboard interface which lets a suitable mobile phone provide the display? I tried it last Christmas, and I don't have a phone which meets the full standard (depends on the magnetic field sensors), but my eyes aren't really good enough for stereo. The Google Cardboard rig is a decent way of trying out the way things look, otherwise VR is currently more akin to an expensive toy, in a way that our computers are not.

This sounds like one of those complicated things, but multi-core computing has been around for long enough that, just as with 64-bit, the general lack starts to feel disappointing. 64-bit processors were launched in 2003, 64-bit Windows XP in 2005. Multi-core was a bit earlier. Multi-threading isn't quite the same but overlaps. A thread is a logical structure for splitting up the work, for such purposes as multi-tasking and tack-switching. I know it can get complicated, but, as we know, they got a man to the moon more quickly. (I don't expect Squad to be fixing the problem, any more than I expect them to be fixing Windows or designing processor chips.)

OK, been checking. The 2.5m to 3.75m conical compartment that you may have noticed in the picture I posted a few pages back, showing a v0.90 attempt at a wide-base lander, is in the Stockalike Station Parts Expension from Nertea. It can carry 4 Kerbals, and I've done a successful re-entry using it with a Mk1-2 capsule, but it is a bit minimal. Out-of-the-box the "crew tube" has no electric charge or RCS propellant, which tends to overload the Mk1-2. I may make myself a tweaked version with some battery capacity, at least. The 3+4 combination with a battery, would make a good vehicle for supporting a space station. The test flights used a 3.75m "pancake" tank of Monopropellant with four of your "Dibamus" OMS/RCS modules, giving plenty of delta-V for a rendezvous. I decoupled this before the re-entry. Some sort of fuel tank/adaptor with a full-size node at the top and four smaller engine mounts part-way down the tank side, radially-recessed into the tank, would reduce the vertical protrusion of the engine and give rim-space for landing legs. Might it have a central attachment node on the base? Could that be a way of carrying a Rover? Think of something akin to a folded version of that engine unit in your pics of the big landing-legs demo. 5m top, 4 x 1.25m bottom, could be a useful lander descent stage. An LV-T45 "Swivel" is about 12 times the vacuum thrust of a 24-77 "Twitch" radial mount engine That could imply some sort of heat shield that would be notched to allow the rockets to fire. A small retro-rocket pack that was visually a .625m pack (Mercury-style) which triggered a 1.25m fairing from the decoupler would look good.

This made a big difference for me in the KSP v0.90 days, and of course I am going to try it. I sort of expect to be disappointed by the bugs that may turn up, but it looks as though you will be occupied by more important stuff.

We have Valentina Kerman now. We need a Rosie the Riveter poster. Thee were two, the genuine article by Norman Rockwell, and the "We Can Do It" poster briefly used by Westinghouse. Either could be Kerbalized.

I hadn't thought of it like that, you I think you may be right. I know too much about real farming to be interested, but farm-by-wire is a feature of modern tractors. Flight Simulator, you could use real-world aviation resources. Train Simulator and the like don't need steering, but managing a steam locomotive is a lot like managing the delta-V. They're all a bit simplified. I'd want to see somebody else telling us what the controller is really like before I spend money. I had mechanical linkages between control lever and hydraulic valves and that's a totally different feel. When I last bought a joystick it was still all analogue. But it does look plausible as a general purpose controller. My ancient Thrustmaster hardware was programmable, and it's a plausible project to convert it to USB with something such as an Arduino board. It was expensive, and very well-constructed. Even then there were cheaper alternatives which maybe didn't have the reliability. You know the sort of hardware they use with game consoles. It's USB and can be plugged into ordinary computers. There can be drivers. The older Playstation/XBox styles of controller are almost a standard Jebediah, no!!!!

Choose something nice and simple. Something like the FL-R25 RCS Fuel Tank. It's a simple shape and UV map. All the files are in the folder ../GameData/Squad/Parts/FuelTank/RCSFuelTankR25/ Tricky bit: you need a texture editor that can load .dds files. There is a plugin for the GIMP, and that's all free. There are other options. Make a copy of the folder and work on the copy. It's worth having your own personal ../GameData subfolder and even better to have a folder for working on files. The file with the visible texture for that model is named model000.dds You can change the rectangle to change the texture for the outside of the tank. It's like a sheet of paper that's wrapped around. When you save the file as .dds, remember compression, and tell the editor prog to create the mipmaps Best change the name and desription in the .cfg file. Put the revised set of files in a folder in your personal /GameData subfolder, start KSP, and it should be sitting there ready. Check how it looks. Pay attention to the existing texture. I found that I had to do a vertical flip so that text came out right. That model has some text on the top and bottom of the tank, and you can see how that works out. (I was making a combined RCS Tank and battery. The part.cfg changes are fairly simple, and I spent an hour or two making a distinctive texture. There's a trade-off between texture-size and detail. I tried to put in too much detail. It ended up looking like a blurred blob.)

The part.cfg seems pretty simple, though there might be balance issues with cost and tech-tree position FL-R25 tank: Dry Mass = 0.15 Mg Fuel capacity 250 units = 1.00 Mg Cost = 600 Z-1k rechargeable battery Mass = 0.1 Mg Battery Capacity = 1000 units Cost = 880 Since the Z-1k is half the height of the tank the combination could be: Mass = 0.25 Mg Fuel Capacity = 125 units = 0.5 Mg Battery Capacity = 1000 units Cost = 1380 I think that's a good starting point for game balance. Cover something that size with solar panels and you have something that allows a long-duration mission. The battery capacity might be too big, but it has the physical plausibility. Texturing I shall have to think about. Just half-battery, half-RCS, seems a little unimaginative. Maybe more on the theme of the service bay and the universal storage mod. That is, black-and-white panels, a hint of vertical corrugation, and maybe some warning symbol. Anyway, I just ran a test, merely a changed part.cfg, and it works and looks OK with the default texture for the fuel tank. It goes well with the K2 capsule Mod, which is a vaguely Gemini-like two-kerbal capsule in 1.25m size. And now lunch. Should I add some capacity for Snacks...

I suspect the open-door problem on the service-bay section may come down to the default mesh. I like the idea. I could put stuff such as batteries and small fuel tanks inside the section and cover the exterior with solar panels. If there's a better fix for the general problem of mounting stuff on these doors it would be better. The Space Shuttle had heat radiator panels on the inside of the payload-bay doors. Since it's possible to put multi-resource storageâ€â€batteries. fuel. monopropellantâ€â€into a fuel-tank section ("Fuel Switch" comes to mind) that might be a better answer to that particular case. Start from the smallest-size stackable tank. It wouldn't be hard. And, looking at the stock parts, once you have a stackable battery it seems almost superfluous. But a battery/monopropellant unit at 1.25m diameter might be a handy option, something like an FL-R25 RCS Fuel Tank with half the fuel and the battery capacity of a Z-1k Rechargeable Battery. I can imagine Valentina, in the VAB, with a screwdriver, making something like this. manufacturer = Valentina's Too Obvious For Boys Parts Emporium description = One night Valentina slipped into the VAB with a screwdriver and a large hammer, and put some batteries into a fuel tank for Monopropellant. She twisted some wires together and wrapped them in gaffer tape. Nothing has exploded, yet.

The VAT change was at the start of 2015. I'm not going to try to explain it, but it hardly matters now whether KSP is being bought from Mexico or the Netherlands The change closed a huge tax avoidance loophole. As I said, the EU Data Protection system is a good thing for the customers.

There are several alternative tech trees out there. I have been assuming that an alternative tech tree loads with all the other Mods, applying to all the different games that can be selected. such as Science and Career and their saved games. It strikes me as possible that the tech tree could be loaded when a saved game is restored. Since the save stores the unlocked nodes there seems to be some potential for awkwardness if it doesn't happen this way. I am thinking of trying a different tech tree, one which better handles some of the large-size tanks and engines, and i wonder if I need to set up a second copy of KSP just to use a different tech tree without breaking anything. That looks to be the only safe option.

There's another angle here. which may affect the interpretation of those terms. The EU has different laws surrounding computer data and software to those in the USA. While I'm not claiming to be an expert on the details, going through a company in the Netherlands, subject to that general legal framework on the protection of personal data, is actually rather reassuring to me. So what it says about how the program may send certain data isn't so bad. It looks to cover such things as the Patcher program and a possible crash reporter. And, under the EU laws, they can't just sell the data to Kerbodyne so you get spammed with adverts for rocket launches. They're telling you what they're doing, and like any contract it doesn't detail the surrounding laws. A side-note here: most EU countries don't work on Common Law principles such as found in the USA and UK. The Netherlands (and possibly Mexico) uses "Roman Law". Is that significant here? I have no idea.

One partial answer to the problems with height and lander stability would be a landing leg that unfolds more outwards than current ones do. I'm going a bit by guesswork here, but something that gives a lander the same effect as being the next size up without needing a greatly enlarged fairing. this was one of my v0.90 designs. It uses a 2.5m capsule, and the conical piece takes up up to 3.75m It's also an attempt to land a rover, with a fuel tank as a balance weight that can also be left behind. But you can imagine how big a fairing it would have to use. I could seeing it needing a 5m booster to get it into orbit The extra spread makes a huge difference to the slope-stability. The vehicle is rather over-powered, enough thrust to soft-land on Kerbin and, without the legs and platforms, might make a good orbital work-vehicle. But it feels at the upper-end of plausibility for the Kerbal attitude to problem-solving. I think that might be a usefully-different sort of landing leg