swjr-swis

I remembered that I did a very similar plane a while ago, only missing the variable sweep wings because 1.3.1 didn't have DLC. I imported the plane into 1.12.4 today and decided to give it a try.
I ended up ditching the hinges for this one. Even using the bigger-size hinges, the joint strength was too low and it kept either flapping or altogether breaking off, even in straight flight. So then I tried with the rotors, and those seemed to work a bit better. They are draggier than the hinges and thus impact performance a bit more, and there is still a good bit of flexing on high G turns, but overall I think it still a success. The plane is extremely controllable at all times, and the wings stayed on even through some pretty rough testing.

Feel free to re-use this solution for your builds. The entire wing assembly, including the 'counter-lift' sections that stay clipped inside the fuselage, is attached to the rotor. From the underside, looking from the back towards the landing gear, you can just grab the lower corner of the rotor and offset it for inspection or lift it off and save as a sub-assembly for reuse.
 
Some video footage showing Jeb putting the SWiS 41-F Blackwood Mk2 to the test:
 

The thrust limiter is an artificial limitation imposed by the game editor, forcing fixed 0.5 steps. Nothing stops you from manually editing the craft file (or if you've already launched it, the save file) and lowering that limiter to say, 0.01%. Search for 'thrustPercentage = 0.5', since that's the value you have on it now.
That should at least give you more time to react for the cut off. Not sure if it will help to show the maneuver time though - at some point the values become so small the in-game code simply shows zero regardless.

 
For future reference, if you wish more accurate thrust for small probes, try using monoprop and either one of the small RCS thrusters - 0.1 Thruster power, 20x smaller than the Ant.

With the one you linked last and less changes:

Mostly I notice those prop blades generate much less thrust from the same available torque than the duct fan ones I used. You'd need to double up on them to get even close. Also, their optimal angle of attack seems to be more in the range of 7-9 degrees, although it's hard to pinpoint because the display values are very erratic, even when flying stable and level.
DDE Mustang demodded 2
 

The description text is somewhat misleading: it does nothing with the intake air. That particular part does have a small bonus in drawing off heat and radiating it away, but to be noticeable it needs to be directly attached to the engine (or other part) you want it to affect.
 
In a row, no, because then they're no longer directly attached. But you can attach multiple of them radially to some engines, and then they will all affect that engine. The key is attaching them directly, one way or another.
 
Again, no, because then they would not be directly attached to the engine.
 
If you're serious about achieving the fastest speed possible with only jets:
Go directly for the RAPIER, do not pass Go, do not waste time with any other engines. Do some research into KSP engine atmospheric/mach curves. The way KSP works, the speed optima are in fact lower in the atmosphere. Build with high-temp resisting parts - you will need them. @Snark's advice on wing AoA is good, but if you're trying for the highest speeds I'd recommend using Big-S elevons as wings. You can 'deploy' them and regulate their AoA with the deployment slider, which will let you finetune the angle live as you fly. When first lifting off that angle needs to be higher, but once you're in the speedrun, you'll want to tune it down to the bare minimum to just stay in the air. Good luck in your endeavours, and don't forget to post some progress reports! Screenshots and craft files... or it never happened.

Welcome to the forum!
On the top right of the screen, one of the icons looks like a gas can. Click it. It will open the resource panel of your craft. In that panel, click the white square to the left of the resource you are interested in transferring (in the case of the Baguette, since it carries LF and Ox, click both of those). It will open ALL tanks on your craft that can hold that resource, as if you had right-clicked them all at once. Pin all the Baguette windows by clicking the black pin icon on each tank window. Pin one of the tanks you want to transfer fuel from. Now click the white squares again in the resource panel. All windows that were not pinned will go away. On the one non-Baguette tank window, click the 'Out' buttons for LF and Ox. ALL the Baguettes will start filling at the same time. If they are not full when that tank is empty, unpin it, right click another full tank, and pin it. Repeat steps 6 and 7 until all Baguettes are full.  

That training was created in an older version of KSP. The drag/aero physics have since then changed, but the training was never adapted to it. If you follow that particular training to the letter, your chute will either shred on the way down, or never open at all.
The only way to survive the training as it is now, is to limit how high you will get (rightclick the chute and slide the 'Min Pressure' all the way to the left so it will deploy in thinner air, and stage the chute when you're still going up, as soon as the icon goes white again), *and* try to be as draggy as possible on the way down (hold pitch up or down and keep doing flips until the chute has fully deployed). It also helps to hold pitch up or down on the way up to force an arc instead of going straight up... that will also limit how high you go.

In the SPH/VAB, if there is no existing thumbnail yet for the part (and variant!) you select to place, a thumbnail is generated.
So, to generate any missing part thumbnails, just go to the part and select it as if to place it on your craft.

Yes, it's reasonably safe to assume that was the date you started that career. It should've been created automatically, with the two contained folders SPH/VAB, when you created your first craft in that career. Since normally nothing else is created/deleted in that folder, the date should be left undisturbed from that moment.
 

You probably didn't scroll enough down the pick list; you can go back as far as 1.0.5. They leave only the last minor patch of each version, and they never added anything older than 1.0.5.

Yes, there are ways. That and more, in fact. Just one recent example I can find in a quick search on the KerbalX craft share site: the Titan v2.
Replicas in (stock) KSP are not easy: due to the limited set of parts and different scales of kerbals, vehicles and solar system, you will find yourself struggling to find the right combination of size, looks, and functionality. For replicas, looks are often the most important parameter (size following closely), in which case you'll inevitably have to compromise on functionality. It's generally accepted that replicas require using special techniques, like clipping and craft file editing, to compensate. No one will fault you for that.
For this project specifically: if you wish to hold onto the relative size and power of the entire rocket, there really isn't a stock engine that looks much like the RD-270 on the first stage of the UR-700, or that delivers the relative power required. The Rhino, as others have already mentioned, was re-engineered at some point by Squad to be specifically a vacuum engine, and won't give you the raw ASL lift-off power that you would need.
The properly powered ASL alternatives, like the Vector and the Mammoth, when placed by themselves, change the engine looks a lot. Building a notch smaller (2.5m), you have the Mainsail at your disposition, which is a proper ASL engine, but looks a little less like the RD-270. You'll have to decide what is important to you in this project.
If you want to hold onto the looks and sheer size of the original, you could choose to clip a Vector into each Rhino, in such a way that the bells end at the same level (to avoid them obstructing each others' thrust). You'll end up with very powerful ASL thrust, and unless someone looks directly into the bell, you should get a very convincing effect.
 

https://bugs.kerbalspaceprogram.com/issues/9557
https://bugs.kerbalspaceprogram.com/issues/13413
Very old problem which is being attributed to the Unity/PhysX engine.
On the other hand some mods appear to find ways to work around it to more or less degree (and so far none of them apply to kerbals - yet):
 

Besides the very common issue @bewing explains and the others he mentions, I see other potential causes. But you haven't shared the craft file, so it's guessing.
Are your engine pods and main gear actually attached to the wings, or are they attached to the body and offset to the sides? Wings have very flexible connections by default, and those heavy pods with powerful vectored thrust can cause the wings to independently flex higher and lower, making it veer off course. It's better to attach engines and gear to the body and offset them, so the wing flexibility doesn't affect them. It looks like your CoL is very far aft. As your plane picks up speed and lift increases, it will tend to want to lift its butt before the nose, at which point the main gear have less and less contact with the tarmac - leading to the dreaded wheelbarrowing. Consider designing the plane with a CoM/CoL a bit closer to the body center, or add flaps ahead of the CoM that move the CoL forward during take off. You have placed your main gear in series instead of parallel, and with a good bit of distance between them. Additionally, they are very far aft as well. What this does is create considerable difficulty for the plane to rotate, adding additional stress to the aft gear, which also causes them to 'buckle' slightly in random directions. This too will make the plane veer off. Finally, as you accelerate and get near to take off speeds, aerodynamic forces start to overwhelm gear friction/steering, and it's actually your rudders taking over. But these too look to have very little leverage in your design... if I'm not mistaken, the CoM is quite far aft and very close to them, leaving very little arm to work with. Mk3 parts have quite high drag when even slightly off perfect prograde, so the whole body in front of the CoM probably create strong yaw forces than the rudders, with so little leverage, may not be able to correct sufficiently.

Landing legs have been... let's put it mildly... a bit 'touchy' for a few versions of KSP now. Regardless of what you do, there will be spontaneous explosions at touchdown. Eve is especially prone to cause such explosions, because the gravity is significantly higher, which exacerbates the problem.
Theoretically, and logically, the answer should be that you look at the 'Stress Tolerance' value of the parts, and compare that to the weight of your craft (adjusted for local gravity). This number should indicate how much weight they can handle, or how many legs you need for the calculated weight. But as you can quickly notice, that value has already been raised to an absurd number in the stock game, and legs still explode anyway.
So the most practical answers are:
If you still want to use legs anyway: however many legs you use on Kerbin, times 1.7x, plus a safety margin of about 25-50% to allow for a few legs to explode. Legs are going to explode no matter what you do, so try to think in terms of 'how many legs do I need to have left after the inevitable explosions for my craft to remain stable'... and go with it. Use something other than legs. Ironically, just about any part not meant to be a landing leg is more reliable to land on than landing legs. The whole concept of 'suspension' is practically useless at the moment with how buggy it is, and KSP physics do not penalize sudden stops, so you may as well just pick parts with the highest crash tolerance (other than actual legs) that look like they'd make pretty legs and use those. Just keep your velocity under their crash tolerance and your craft will be fine.  

IPS abandoned markup code for users and chose explicitly for WYSIWYG only. So that's what we get.
There's still some legacy crap in there that parses some codes.. or it may not, since they don't care to keep it updated, and any update may break it or drop it altogether.
https://invisioncommunity.com/forums/topic/417407-ips-40-the-current-state-of-bbcode-and-its-future-is-bbcode-officially-abandoned/?page=4
 

High ejection force, no clamshell, and it tends to help to keep the seams of the fairing shell sides on whatever parts you want to protect - in this case, mainly the wings. You may want to turn the fairing base 90 degrees to make the seams be on the horizontal plane.
 

Install your 1.5.1 in another directory. Copy over just what's in the 'saves' folder. That way, you can have the two games side by side. If 1.5.1 works, you can decide later to delete or archive your 1.2.1 install. If it doesn't work, you can still play 1.2.1 unaffected.
This is assuming a stock game. Mods will complicate things, but mostly comes down to the same thing as long as you install the same set of mods in both games.

Yes there is: like @PrvDancer85 mentions, you need to add a probe core so it can be controlled when detached. Then once detached, make sure SAS is off and set a trim for the axis you want the spin on. Eg. for a propeller with a probe core in the direction of the shaft, hold Alt-E or Alt-Q for a sustained spin.

The decoupling side of the hardpoint would need to attach to the base of the fairing - not the shell, or the interstage nodes... that will indeed not work. Keep in mind the root order required by KSP for part attachment, and the attachment rules for hardpoints (surface attachment on both 'ends'). For the hardpoint to work as the decoupler of the torp-like craft (the payload), it would need to be the root of that payload. If you already have the main craft and payload craft separately built, you would need to follow a few steps to make it attach by the hardpoint: Attach the small hardpoint to the base of the fairing. With the re-root tool, make one of the Mk1 tanks the root of the craft - you need to use a part that can be surface-attached to place it on the hardpoint. Load the main craft. Load the payload craft with 'Merge'. Now you can attach the payload to the hardpoint. The hardpoint adds a tiny bit of drag to the payload craft, even if clipped - but much less than the CO construct you use now. So it's worth doing.
 
Yes it is. As long as the fairing is closed it's shielded. But don't take mine or anyone's word for it: Alt-F12, Physics, Aero - enable the first option to see drag numbers in the rightclick menus and confirm for yourself.
 

Yes it still is a thing, for the exact same reason. However, now it's also significant to minimize the transition between attached parts. In other words: since RAPIERs are 1.25m, the small nosecones are not the best choice anymore, since that attaches a 0.625m to a 1.25m part. The Aerodynamic Nose Cone or Advanced Nose Cone do a better job on a 1.25m node.
Tip: call up the debug console (Alt-F12 on PC/Win), and under Physics/Aero, enable the two first options to get some insight on design vs aerodynamics. The KSP aero model can sometimes still be pretty counter-intuitive, so it helps to see 'live' how things play out.
 
Very touchy subject. There's been a few upgrades to the game engine (Unity), which at one point completely borked the wheels/gear system. They were forced to change over to a new system, which has never quite got back to the level or stability the old wheels/gear had. One of a number of things lost in that transition was the option to lock suspensions - it no longer exists, and there doesn't seem to be any outlook on getting it back again.
In return, the system we have now sometimes decides to ignore friction, or creates phantom self-amplifying forces and bouncing, and generally likes to explode a whole lot more than it used to. Yay for progress.
 
In general, yes. Resource extraction has been made a bit more complicated and overall seems to result in less ore than in 1.0.5: you now need to keep in mind the optimal core temp of drills and converter, which requires radiators appropriate to the gear. Also, the small drill and converter have been nerfed so they basically never operate at optimum anymore - they overheat regardless of the amount of radiators you install.

You have to configure the joystick axes in the settings first - it seems that by default they are not assigned, to prevent an unused joystick from causing unexpected steering input.
From the main menu, go to Settings, Input, then for each of the Pitch/Roll/Yaw Axis on the right side of the screen, click the buttons behind 'Primary' (gray buttons marked with a '<'), then move the joystick axis you wish to assign to it.
Then scroll down and do the same for Throttle.

Looks like an oversight, the devs may not have anticipated that so many mods would add custom config options.
Best thing to do is to report this with that screenshot in the KSP bug tracker (after checking if it hasn't been reported already).

Main rule is: the subassembly needs to be 'attachable' according to the game rules. Iow, the root part of the subassembly needs to be either surface attachable, or has to have an open stack node.
Contrary to what @Magzimum says, this can in fact include the root part too, the entire craft you build, as long as the above applies. Another interesting detail: due to the above rule, one can create a subassembly with a root part that would normally not be accepted as a root part (ie. that cannot be placed as the very first part, like most surface attachable parts). The game only cares about it being attachable somehow. Quick test to prove the above: place an octo probe core, attach any other part(s) to it - but leave either the top or bottom node of the core open. Now grab the probe core and you'll see that the entire craft can be dropped as a subassembly. However, if you use both the top and bottom stack nodes for other parts, and grab the probe core now... no dice, no subassembly allowed.
If you have a set of parts that you wish to save as subassembly, and somehow it won't save, it can usually be solved by using the re-root gizmo, and picking as root any other part of the set that still has either an open stack node or is surface attachable. Of course this may not attach as logical/pretty as one would wish, which is why you should always build a subassembly with the main rule in mind.

The parameter is called 'maxPressure = 4000' (4000 is the current default for all parts), and the cfg files of parts can be found in /GameData/Squad/Parts. You probably want to use a Module Manager patch to do this.

Without a craft file to test, it's hard to say for sure... but I've seen it before, and in that case it was caused by struts without endpoints.