Stoney3K

To begin with, you need more wing mounted at an angle of incidence so you can keep your nose prograde when accelerating to hypersonic speeds. Climb above 10K then accelerate with your jets until you get up to about Mach 3.5-Mach 4. When you want to engage the rockets is entirely up to you but for one thing: DO NOT pitch high up since this will induce a ton of drag and slow your plane back down. If your apoapsis is low, pitch up slightly (to about 15 degrees over the horizon, the rest of the climb is already caused by the curvature of Kerbin). Those two LV-909's should be enough to get that bird into orbit. Looks like you burned way too much LF on the initial jet ascent, try climbing slower in the lower atmosphere so you're not wasting fuel on drag.

You can always climb over the target altitude and nose-dive to reach Mach >2 if you don't have the Whiplashes yet.

When you can change the name of animations on the fly (which is possible if you have control over the contained PartModules and Models), you can control each attached part individually and their animations would function correctly. If it is possible in code, it would be nice to not have to change the transform and animation name, and just go by them in the order they are declared, but that will only work if Part.Modules[<ClassName>] returns an array of all the modules with the same name, instead of the first, and the same goes for Part.Models. There is a method called Part.FindModelAnimators[] (and correspondingly FindModelTransforms[])which returns all animations with a specific name. It is quite possible that, through a lazy implementation of specific PartModules, only the first is used because part programmers assume that there are no identical models used in a specific Part.cfg file. To fix it, you would need a separate PartModule which, as you said, catches a call to a specific transform and forwards it to all named transforms in the list. An alternative approach is to get all the parts and find out which animations (and transforms) have identical names, and re-name them at load time. One action for multiple meshes works for a few part groups such as resources (solar panels, fuel cells) or landing legs, but it's not always a good default behavior. It would be useful to replace the "default" action which was bound to the singular part, but in some situations, like docking ports, you will want separate actions for specific parts.

The animation is stored in the mesh file so renaming the animation (and all occurrences of it) in the mesh should change the animation reference. In your example, the ModuleDeployableSolarPanel still only offers one action for opening the panels (it's impossible to open or close either panel animation individually, only simultaneously) because they both use the same PartModule which responds to the same actions. What you'd ideally want is to have a single part (which has a single, lumped physics simulation), which carries the functionality of a lot of individual parts that are attached to it. However, right now it's not possible to address an individual instance of a PartModule because they are not identified in-game by name. I've already thought of making a PartModuleContainer class that stores all identical instances of a PartModule in a list, so a user can address them by tag, and adding actions from the parts contained in the list, taking the solar panels as an example, this would be "Extend Panels 1", "Extend Panels 2" and "Extend Panels All" as actions which are exposed by the PartModuleContainer class at run time, and forwarded to the respective module instance. Such a class can also take care of multiple instances of a MODEL{} confignode, and rename the associated animations accordingly.

I explicitly edited one of the mesh files (the model.mu) to make the animation name unique and edited the part.cfg for that part accordingly, so it worked as a unique "Gigantor XL Solar Array 2" with different transform and animation names (bigsolarpane1 instead of bigsolarpanel and suncatche1 instead of suncatcher). This worked fine when the part was used individually like any other part and when welding, two ModuleDeployableSolarPanels showed up, each producing an equal amount of EC. When I try to weld two Gigantors (which have the same part and animation name), they are lumped together into one ModuleDeployableSolarPanel instance. Next, I edited the craft file to allow different action names for each of the solar panels. Again, this worked fine when the panels were attached individually, with "Extend Panels 1" and "Extend Panels 2" as actions, but on the welded version, only "Extend Panels 1" showed up even though the other action and its associated module were defined in the craft file. This leads me to believe that when multiple, identically-named PartModules are defined in the same ConfigNode, only the first is executed, because it is the first hit on Part.Modules[<your class name here>].

I'm on the trail to find out why that doesn't work. Apparently the way KSP lays out its part files, it only allows one instance of a specific named PartModule per part. If the PartModule is declared multiple times, only the first declaration is used and all other declarations are ignored. I first suspected this would not work because of identical transform and animation names, but even after editing the mesh file from the Gigantor XL to have a unique transform name for each sub-mesh in the part, I still could not get my welded part to work. This means the limitation is in KSP's way of loading PartModules in the database. Here's the snippet generated by UbioWelding after I built two unique, but identical, Gigantors: MODEL { model = Squad/Parts/Structural/trussGirderXL/model position = 0, 0.001, 0 scale = 1, 1, 1 } MODEL { model = Squad/Parts/Electrical/gigantorXlSolarArray/model position = -0.325, -0.009, 0 scale = 1, 1, 1 } MODEL { model = Squad/Parts/Electrical/gigantorXlSolarArray - Copy/model position = 0.325, 0.008, 0 scale = 1, 1, 1 rotation = 0, 180, 0 } MODULE { name = ModuleDeployableSolarPanel animationName = bigsolarpane1 raycastTransformName = suncatche1 resourceName = ElectricCharge chargeRate = 24.4 } MODULE { name = ModuleDeployableSolarPanel animationName = bigsolarpanel raycastTransformName = suncatcher resourceName = ElectricCharge chargeRate = 24.4 } Now there are two ModuleDeployableSolarPanel instances declared in the part file, but only the first one is executed by KSP, presumably because the names are identical. This is also the reason that welding docking ports won't work, the ModuleDockingNode gets messed up when it is combined into a part which has more than one mesh. If there is a way to make multiple "instances" (identical, but differently-named copies) of an existing PartModule, you could make multi-part welds function. In that case, the step-by-step method to weld parts would simply be: * Scan the part files for any declarations of a PartModule that occur more than once (or, multiple instances of an identical part). * If this is the case, make temporary copies of the part's mesh files, replacing the original names with unique names which are tagged (e.g. 'solarpanel_weld1') so the modules can target their respective part animation. * Repeat the same with the names of the PartModules. This may require some fiddling around with .NET typing to make it work. * Set the properties of each PartModule to reference their respective sub-part.

TrackIR works great if you fly IVA, but it's not very useful for the third person view that KSP uses a lot. This control panel from Saitek looks interesting as well (the top buttons would be great for toggling SAS/RCS or switching from translate to rotate mode), but it's only 3 axes. http://store.madcatz.com/brands/saitek/Saitek-Side-Panel-Control-Deck-PC.html

I consider the Mk4 to be the first expansion that may be integrated into stock in a future update (along with Nertea's wonderful Near Future packs). If I get a comprehensive space plane pack, I'd expect there to be some wing parts to go with that. Right now, we only have the Big-S and FAT wing parts for Mk3 and Mk4 designs, which quickly become either *way* too small on large ships or too large and sluggish. I always loved the early type A/B/C/D wing panels which you could snap together like Legos to build your own type of wing. Aside from the fact that I really don't like procedural wings, but that is a matter of personal taste.

If you use a cell to keep your mining rig and ISRU up, at least you have the advantage that it can keep going forever since the ISRU can supply the fuel cell with a continuous flow of fresh fuel.

IMO, even a simple "Transport Kerbal or $cargo to location X" can be a rewarding set of contracts. We'd need Kerbal Constructs to build the target airports which are off-site from the KSC, but I'd definitely support that. The aviation parts don't serve a lot of purpose right now (especially the Wheesley) unless you have enough tech to build SSTOs. Airlines don't need to be limited to Kerbin, I can imagine a "Rotate 3 Kerbals on station X" (which means rendezvous, dock, and exchange crew) or a "Transport 40 Mystery Goo containers to surface base on Minmus" could be really interesting missions as well.

Come to think about it, if you want to splurge, the SpacePilot Pro (is that name a coincidence?) may be a perfect dedicated controller to fit all of your KSP control needs. http://www.muizenshop.nl/0/498/p/3dconnexion-spacepilot-pro/29591/ At $550 it's a bit steep though.

I still think it doesn't make real sense. You can't move a ton of fuel tank single-handedly when on orbit, but you can get out and push to maneuver your entire spacecraft using your jet pack. That doesn't really add up. When on orbit, the only thing that matters is inertia. Even if a Kerbal tries to grab Minmus, it will give it a nudge, no matter how small. It just takes a loooooooong time to move heavy objects.

Can you tweak the Horsefly/Yellowjacket engines so they have faster spool times than the standard jets? Right now, when you use Throttle Controlled Avionics, they're way too sluggish to use as VTOL lifting jets. +1 for some new types of wings, BTW. The FAT main wing is sufficient to get most MK4's in the air, but I'm not a fan of it and I'd like to have some more... cosmetic options.

Surface Lights? Use Aviation Lights, they even have the fancy red beacons and flashers, so you can put a red/green/yellow/flash marker around your docking ports and tell everyone which way is actually up! Near Future Electrical also has a few very nice omni lights which I use a lot for stations.

Isn't that a bit in reverse? I mean, in the real space flight history, fuel cells were developed after RTGs which were damn simple (but really dangerous) to construct.

That depends on altitude. Decoupling at Mach 3 above 25km, no problem.

RCS thrusters don't respond to the throttle control (unless you have MechJeb). Use IJKL and H/N to translate, which is what you want.

I'm usually lazy and set the "Max Persistent Debris" to zero. Because I see absolutely no purpose for having it up there, and the more CPU cycles for physics simulation on useful parts, the better.

If I'm correct, the Mars (Duna) Semi-Direct mission would be two or three separate launches, right? So the mission profile would be something like this: * DAV + refinery launches unmanned and transits ahead of manned mission. DAV + refinery lands on Duna and starts mining fuel to refuel DAV. * Habitat module launches into LKO empty, possibly picking up fuel from an orbital depot. * KRV launches with our three adventurers, and docks with Habitat module. Alternatively, HAB+KRV can launch as a pair. * The HAB module provides housing for our three Kerbals during the long transit period (right?). On Duna capture, KRV remains in orbit, and HAB deorbits to land next to the DAV. * Science is done. Kerbals stay in the HAB module on Duna. * On a return window, the DAV launches into Duna orbit and docks with the KRV, and the DAV/KRV combo return to Kerbin. The manned transit could also be done in the KRV like on the return trip, but that would mean the KRV is quite a hefty ship with enough facilities to sustain three Kerbals for up to a year.

A module that can fab smaller parts from Ore mined on-site would be a good addition. Might be better to integrate that into KIS/KAS than into the stock game, though.

This also happens in stock x32. The data is stored and the science is processed, the only annoying thing is this message which makes no sense.

Seconded. If it is a part that I *want* to control, I would have added a probe core to it in the first place. When you switch to debris, there is nothing you can do with it but watch it float/fly/crash anyway.

Which gives you "infinite everyhing" not "just one engine that can keep going until you run out of power". Aside from the TO's purpose for an electric-only engine, I can see its potential even if you have something that is ridiculously expensive and extremely weak. Think along the lines of a working EmDrive.

Not necessarily. Pure electric engines won't work right now because the density of EC is zero (and therefore, thrust is zero if you use them as propellant). There is nothing that prevents you from building a physics-defying ISRU that creates fuel out of nothing but ElectricCharge. KSP does not check the law of conservation of mass, so you could make an engine that generates a propellant resource out of EC and then uses it. The easiest example would be to modify the PB-NUK to generate MonoPropellant and then hook up a Puff engine which could keep going forever.

I agree here. The first part of career is challenging in its limits but excruciatingly boring in its contracts offered ("Orbit Kerbin", "Take tourist on a suborbital flight"), while the later stage has more interesting contracts which can be accomplished no matter what because there are hardly any limits. And when the endgame is concerned, career is pretty much a glorified sandbox if you complete enough contracts and therefore get an endless pit full of money.