Wolf Baginski

I can confirm that over control of this sort is part of such problems, whether with rockets or planes, and whether with manual, SAS, or MechJeb. In 1950s flight testing, a lot of work was in adjusting the control system to get the right amount of control movement.

I was fiddling around, and I am not really sure what I did, but suddenly I managed to have the capsule in the centre and was able to get the rest of the plane to hook up to the node... And pressing Mod to force node attach helps a lot too. Anyway, there's some good suggestions there, and it's maybe also how I got things in the extreme position. Once I got the problem sorted, and made the tweaks to the airframe. I did a test flight on the Valentina "bomber". which is mostly inspired by the Handley Page Victor. I probably gave it far too much fuel, but, with enough air, four J-33 "Wheesley" engines give it plausible speed, maxing out at 285m/s with the first signs of transsonic drag. Bigger engines and intakes can get a bit crazy. I may have given it excessive roll control, but with SAS running it was very flyable on manual. I managed to fly as Mach 0.8 at 26m altitude. I need to trim the weight a bit, take the fuel out of some parts. 80 tonnes is a bit too much, and the service altitude was lower than I wanted as a result. I shall probably take away the outer aileron and give that section a little dihedral. Most of the fuselage and wings come from the B9 set, currently still in development for v1.0.4

I've been working on a large aircraft in the SPH and somehow it has gotten badly off-centre, which has carried through onto the runway. I may just need a new mouseâ€â€the initial problem may be scroll-wheel misbehaviourâ€â€but there seems to be no way to clear this. All the off-centre data seems to be in the craft file, with nothing that looks like a start-here value. I have checked the key-bindings. At the moment some components seem to be outide the space where parts can be clicked on. I do have a spare mouse-thing, but I need to rummage a bit to find it. Any in-game solutions, or some not-too-horrible file edit?

Found it! There's a couple of small antennae in the Blackleg Industries modpack, both designed for surface-mount, the circular one which I described and a long narrow one. I don't know why I'd left that one out of my 1.0.4 install. I think I get a bit nervous about the amount of stuff to install when a new KSP version comes out.

I've hit a brick wall. But there looks to be a new version of the plug-in. It seems to be the interactions with Module Manager. The savefile ends up pointing to ModuleManager.TechTree which is essentially the Stock tree I am wondering how Module Manager does the test NEEDS[CommunityTechTree] This is frustrating.

Sometimes, with a lot of Add-ons, it starts getting hard to find parts. Sometimes things are in an unexpected place when you're doing an Editor selection. Heat-control parts are a bit scattered at the moment, not all in the same class. I may try something with Mod Manager to remedy that. And some parts seem to be in multiple places, which makes some sense but I wonder how it's done. Some people are a bit more careful about names and descriptions, and I can find things bt searching .cfg files. Then you get useful parts you remember from the v0.90 days. Maybe the parts Mod hasn't been updated, maybe you just haven't installed the particular Mod that had it. Which is what I have been looking for. There was a simple model of a radial-mount comms antenna, something for aircraft, mostly. I know it's not in the current Firespitter, KAX, or the test versions of B9_Aerospace. It looks like a flat disk, no animation or anything. Nothing complicated. As a concept it's something useful. I can't even remember the name. Any idea where it might be now?

Meanwhile, I tried building a plane, inspired by some of the bomber jets of the 1950's, such as the Handley-Page Victor and the Soviet M-4 "Bison". The B9 set gave me the parts needed to build a crescent wing, I used the C2-H cockpit from the KAX pack, which looks solidly subsonic, and fits all the 2.5m cylinders It was flying well, so I climbed to 8000m over Kerbin. I'm still trying to turn well, but the design was stable, straight and level. I opened the throttle wide. The airframe's critical Mach number was a little over Mach 0.8, with shockwaves starting to appear at that speed. It was obviously way over-powered, and the speed kept rising. The flames started at about Mach 2.8 and it didn't look like a plane that could go that fast. But it stayed stable until the aft fuel tank, also getting heating from the engine exhausts, exploded at Mach 3.6 I then tried a version using S2 fuselage parts from the B9 set, and made a big mistake. The centre of mass was too close to the centre of lift. It took off OK, seemed to fly well, and then did a series of end-for-end flips. I'm using the Interstellar Fuel Switch mod, which lets me fill tanks with 100% fuel. For ballast, and some 1950s planes had ballast weight added after flight tests, it might be worth leaving an oxidizer tank well-forward of the wing.

There seem to have been a couple of Firespitter updates last week. I found out about the second the hard way I take care to only have one firespitter.dll in my ../Gamedata and sometimes have to take extra steps to check which version is which. What the timestamp means can be OS-dependent.

The chutes can be in a stage of their own. Or two, drogues first and main chutes second, Or you can set them up with Action Groups. Staging is simple, just hit the space-bar. Either way, you open multiple chutes at the same time, if you set it up that way. Smart Parts http://kerbaldevteam.tumblr.com/post/79232581790/modding-mondays-smart-parts is worth a look for automating things.

At the moment I'm just using a few of the B9 parts. You've done a clear enough job of organising the folders and names that it isn't hard to just delete the HX parts, or any other subset. I've not tried to do anything with the IVAs, there doesn't look to be much there anyway. Do the naming clearly, and maybe write up a list so that we can see how things are split, and we can pick and choose. The D25 and M27 capsules work well in orbit, and are the core items from the Mod for what I have fun with in KSP. They're not real, but they're not wild sci-fi. In style, they've in the same territory as 2001 was, and I could also point at amd the moment when the Starfury did a 180° flip to hit the bandit trapped at its six. 70 years ago, some illustrators showed spaceships inspired by the high-tech of their time, such as the B29 bomber's nose. So just the names maybe aren't quite enough to pick and choose. And that sort of glass nose was commonplace. On the B-29 and the He-111 it was the cockpit, on other planes there was an inline cockpit and a glass nose. The He-111 shape would be rather good for a pulp-SF rocketship. Of course, it would struggle with re-entry, but as long as they go up, who cares where they come down...

As a general point, it's worth making sure that you have the current version of such plug-ins as FireSpitter. I had a bit of trouble this week with another mod that used Firespitter, and discovered that Firespitter had been updated twice last week. The latest version fixed the problem I was having, which did involve loading. The "correct" version is not always the latest. It's possible that you might need to use the Firespitter version included with the Mod. Since I am using 1.0.4 and there have been some significant changes to re-entry I wouldn't expect this current Skylon version to work well. I reckon there might be an earth-shattering kaboom. I got that with a few stock rockets that were suffering from heat-flow from chemical engines. It's a trade-off between the kaboom and using a heat barrier that leaves a red-hot engine in orbit as debris.

The idea of a plain divider or end-cap seems worthwhile for a lot of things. A decoupler-mesh is way too complicated than it needs to be for this, but wasn't there something similar in the old MkIV, a rather thin part? Something like the original MkIV drone core with a bit of different texturing and a different part.cfg could have been workable, but it wouldn't have looked as good as something purpose built. I know the Fustek station parts set has one or two end-caps and covers. That system is mostly 2.5m diameter, and has a 2.5m docking port as well as a hangar unit with a big hatch on the side. I'd class a cap/partition as useful but not vital for v1.0 Some sort of super-pancake model could be used for several purposes. I doubt a space-plane would need a thermal barrier component for the engine, but it could use the same model with a different part.cfg It's not just the LV-N nuclear rocker that pumps heat into a stack. Similarly, it might have some batteries built-in. Maybe a locker for Snacks Storage? How much of the work for those variations is in the the mesh model, how much in the textures, and how much in the part.cfg? And here's one thought for why a partition might be useful. Some sort of clean-room. The partition might have two or three small airlocks. One for personnel, another for samples, and a third for normal "clean" supplies. The lab would have glove boxes, of course. Might be a three-unit set-up. They've landed on Eve, and block A is the part exposed to Eve. Block B is the clean room, a science lab for working on samples, and decontaminating Kerbals. Block C is the flight deck and the living space. Maybe we need a Habitat Access Limiter to control the pod-bay doors. Real life applies. The Apollo LMs picked up a lot of dust from the Lunar surface. Luckily it wasn't a bio-hazard.

It's a bit off to one side of what you have done, but a very small SRB, visually in 0.625 Tiny class, but in 1.25 Small class as far as any decoupler thinks, would go well with the Mk1 Capsule. A model of Friendship 7 that shows the retro pack (A rather big pic). I'm a little doubtful about the colour scheme on the pack, it's from a CGI model http://www.jrbassett.com/images/Mercury02.JPG And this is a picture of the real thing showing the un-striped colouring I expected. http://www.space.com/18129-project-mercury-retro-and-posigrade-package.html Using a smaller-size motor produces an ugly wasp-waisted effect in KSP. This is something that could be produced for both sizes, usable as an apoapsis kick motor for Tiny-class probes as well as being a retro-pack.

I did mess around a bit, using the Kerbal Aircraft Extension for the prop engine. 1: Without the need for the jet at the back I could use the Stock Tail Connectors. They're a bit long for the crew pod, though some parts Mods have alternative 1.25m nosecones that are more pointy 2: The setup needs adjusting for a prop engine. It has to be moved forward so as to clear the crew pod's nose. 3: I also tried the 0.625m jet engine from Modular Rocket Systems. Plenty of power. It all flew, and I could land it. I then did some messing around in the SPH and built a twin-turboprop transport plane using some KAX parts. It flew pretty well, first time, though I get a bit finger-tangled when flying planes in KSP. TweakScale and some sort of Fuel Switch mod helps a lot. You can easily replace oxidiser with fuel. I would be surprised if KSP couldn't cope with asymmetry: that's a feature of the Space Shuttle.

One thing which KSP, even with FAR, might not include is the effect of the rotating prop-wash. It was this, rather than "torque", which tended to make the WW2 single-engined fighters pull to one side during takeoff. Anyway, a clockwise prop would have an effect which a jet engine doesn't. Photos of the real thing also show more streamlining of the crew pod. Maybe a Tail Connector rather than a reversed Nose Cone? There is a slight weight saving, but it would look a bit long. I'm trying to stay Stock, but a Glass Nose nosecone would be a nice add-on part, whether for German WW2 aircraft or a B29/B36/B50. It doesn't have to do anything, just look different to solid metal-stuff. (The B36 feels rather Kerbalish: a mix of prop and jet engines, and they tested a "parasite" fighter which could be deteched to defend the bomber.)

I'm working on YongeTech versions of the Stock tree (more as a reference source) and the Community Tech Tree. Thread here: http://forum.kerbalspaceprogram.com/threads/127408-Using-the-YongeTech-tech-tree-plug-in Since most Tech Trees seem to contain the Stock Tree and add to it, having a full YongeTech version of the stock tree seems useful as a resource, even with YongeTech able to use the stock tree. I have some testing yet to do, before I release test versions.

One of the recent add-ons is the YongeTech tech-tree plug-in. This does two things. It allows a KSP install to run multiple different tech trees, selected when the new Squad is created. To do this, it specifies the link between a Part and a Tech Tree node in the TechTree.cfg rather than in the Part.cfg. And you can still run a game with the Stock Tech Tree. The release thread is here http://forum.kerbalspaceprogram.com/threads/125338-1-0-3-YongeTech-Tech-Trees-Plugin-%28v1-2-1%29?highlight=Yongetech While there is a demo tech tree, just having one is a bit pointless, and a day or two ago I started looking at things to see if a YT version was possible. That needed a bit of work to actually get a list of what stock parts were linked to which stock node. I decided to make a YT version of the stock Tech Tree, which is maybe a little pointless, but provides a base for other Tech Trees. It actually lists the relationship between stock parts and tech nodes. I then turned this into a YT version of the CTT. These seem to work, and I figure they would be useful for Mod creators. At this stage, it needs other eyes than mine to check things. Are any parts missing? Are all the nodes in the right place? That sort of question. Also, importantly, how is a new part, node not specified in the Tech Tree, located? Incidentally, there are a few extra bits in the Stock Tech Tree entries which don't seem to be used. RDNode { id = start title = Start description = The technology we started out with. cost = 0 hideEmpty = False nodeName = node0_start //What does this do? anyToUnlock = False icon = RDicon_start pos = -2568,1199,-1 // A few nodes have numbers after the decimal point which seems over-precise scale = 0.6 Unlocks // This is the YongeTech method of linking parts & nodes { part = basicFin part = mk1pod part = solidBooster_sm part = GooExperiment part = trussPiece1x part = parachuteSingle } } I still want to make one or two tests before I make the trees available. Does anyone have a suggestion for how to label them in a way that Module Manager can recognise and act on? I don't want to mess up how a parts mod might set tech node links.

It was getting plenty late enough when I posted that last bit. The CTT does use Module Manager: it adds nodes and changes node positions and links, but it only modifies the TechTree.cfg file. It doesn't change the part/node links in the part.cfg files I think a YT version would be able to put some parts in different places. If a part isn't specified in a YT-style TechTree.cfg what happens? It makes sense for the part/node link in the part.cfg to be applied. This probably is getting into Add-On development territory now. I'll concentrate on getting a YT-Stock and YT-CTT set up before I start a thread in the development forum.

There are signs of something different in the stock Tech Tree coming when v1.x.x appeared. My first step will be to duplicate the Stock tree using YongeTech . All the tech trees I have looked at use the Stock node names as a base, I suppose so that a third party Mod will work if it doesn't take advantage of the new nodes. Since YongeTech gives the Stock Tree as an option this might seem a bit pointless. I see it as a first step to a YT version of the Community Tech Tree. If I can get that working, it could be useful. I did try the CTT, but it needed a whole distinct install. And the base CTT doesn't depend on Module Manager

At least I got the Node IDs, which are the internal names for the default Tech Tree nodes. That was easy. They're not quite the same as the Names displayed, and under the stock system you still have to examine every part.cfg file to get the part's internal name, and the tech node it is assigned to. Yes, the information is in the Wiki, but those pages use the visible names displayed for humans and I have a suspicion it isn't up to date. And some stuff uses a different filename to part.cfg Anyway, here's the list of internal names. I kept the "id = " partly for clarity. I am not sure how far I am going to go with this, but a YongeTech-format version of the stock Tech Tree might be useful. It does have the virtue of having all the node-placement info in one place.

More details: The standard Tech Tree is in ../GameData/Squad/Resources/TechTree.cfg The YongeTech system adds "title =" and "description =" fields to the root TechTree section and, in each RDNode section adds the linkage between node and part, in this form: Unlocks { part = YT_probeCoreCone part = solidBooster_sm part = standardNoseCone part = sensorThermometer part = basicFin } It should be possible, in Mod Manager, to check for the presence of that section and add a new part, instead of changing the part's part.cfg but you don't seem able to read the setting from one file and put it in another. Let me check a small parts-mod... Something from Blackleg Industries, it's pretty small, and the Circular Antenna is useful. The part.cfg puts it in the "electronics" RDNode, which happens to be in the Standard Tech Tree, so I don't think it needs an edit. Here's the thread with the Module Manager data. http://forum.kerbalspaceprogram.com/threads/55219-1-0-x-Module-Manager-2-6-6-%28June-25%29-With-more-nyan?highlight=Module+Manager The Community Tech Tree includes instructions for the commands needed to put a new part in the tree using Module Manager, changing the part.cfg entry. The example checks for the Community Tech Tree and changes the tech node specified in the part.cfg I don't see why a YongeTech-type TechTree.cfg can't be modified instead. but the details are where I start feeling very lost. I could throw AWK at a TechTree.cfg and get a list of the nodes but then what? I shall depart and fan my fevered brow...

As near as I can tell, Tech Tree mods, and the part mods that support them, depend on Module Manager to set the correct node in part.cfg files. The Tech Tree seems to be set at KSP-level The fairly new YongeTech plugin allows the player to select a Tech Tree when creating a Squad, so the same KSP install could have different Tech Trees. Part of how it does this is by listing part/node relationships in the .cfg for the Tech Tree. In many ways the YongeTech method looks better, but it seems a lot of work to convert a tree from one to the other. A YongeTech version of the Community Tech Tree would be tempting, but I am not sure how the part-mod would need changing to support the YongeTech system. It seems possible that a Module Manager file could be converted from one format to another by one of the standard tools, such as a Perl script. I am now scared. Perl scripts are the over-heating booster of my meagre programming skills. I am not sure if I have even correctly understood the problem. Am I even thinking about it right?

Would anything have been changed if the two computers had been communicating? They probably do need to reliably signal a few things to each other, but some of them would be events that could also be detected by instruments such as accelerometers. Full communication could be a lot more complicated than a wire carrying a logical 1 signal from the stage 1 PSU, which breaks on separation. It's more complicated than a second wire carrying an OK from the stage 1 controller. But the more complicated, the more bugs there might be.

I gave it a try in v1.0.4 and I couldn't get to VR on the KSC runway. It only reached about 122 m/s and it was still solidly on the runway, and there wasn't a runway any more. It looks good, but either I am doing something wrong or the new aerodynamics can mess up complex wing structures. I shall try a few things when I have the time, maybe approximating JATO bottles with an SRB. A mod I can see a use for would be a small-diameter SRB with built-in decoupler and a fairly short burn time to get something up to flying speed. Size-0 (0.625m) with a nose-cone and a high ejection force decoupler.

Yep, Second Law. There's a song about it.