swjr-swis's post in fuel transfer to many Baguette was marked as the answer
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.
swjr-swis's post in Basic Flight Training - Chute not deploying was marked as the answer
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.
swjr-swis's post in Squad/Parts/@thumbs folder was marked as the answer
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.
swjr-swis's post in When did I start my career? was marked as the answer
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.
swjr-swis's post in Why do people put nosecones on the rappiers on SSTOs? was marked as the answer
swjr-swis's post in Is it possible to access versions Pre-1.0 (Alpha or Beta) of KSP though STEAM? was marked as the answer
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.
swjr-swis's post in Building very heavy rockets was marked as the answer
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.
swjr-swis's post in Kerbals constantly sliding, in even terrain too was marked as the answer
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):
swjr-swis's post in Why does my spaceplane not go straight on the runway? was marked as the answer
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.
swjr-swis's post in How many landing legs was marked as the answer
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.
swjr-swis's post in KerbalSpaceProgram Forum markup language? was marked as the answer
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.
swjr-swis's post in Fairings and radiators do not mix?! was marked as the answer
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.
swjr-swis's post in Can i transfer my saves from 1.2.1 to 1.5.1? was marked as the answer
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.
swjr-swis's post in Reaction wheel perpetual spin was marked as the answer
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.
swjr-swis's post in Klaw and Juno in a fairing! was marked as the answer
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.
swjr-swis's post in Oldtimer coming back, in need of some help from veterans was marked as the answer
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.
swjr-swis's post in Thrustmaster T160000M not working as input for KSP 1.3.1 was marked as the answer
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.
swjr-swis's post in Can't accept while customizing new game start was marked as the answer
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).
swjr-swis's post in Fun with subassemblies was marked as the answer
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.
swjr-swis's post in Screenshot Question was marked as the answer
Those messages and the shortcut are from the Windows 10 'Game Bar':
And the screenshots are saved by default under C:\Users\<yourusername>\Pictures\Screenshots
swjr-swis's post in How doe Fuel Flow work in 1.2? was marked as the answer
The priority numbers let you program which tanks will be emptied first. The higher the number/priority, the earlier they will be emptied. Note that when the numbers are negative, a higher priority is shown by a 'smaller' negative (closer to zero).
The green wavy line at the moment does not change direction with how the fuel flow is programmed, so just take it as informational to show which tanks a particular engine can draw fuel from.
swjr-swis's post in Singing Capacitors/Tranistors during load was marked as the answer
I've been using an open source utility called 'NVidia Inspector' (more recently split into two apps, the 'NVidia Profile Inspector' is the one to use now, the other is for overclocking and monitoring the card). The Profile Inspector gives direct editing access to the driver profiles, including framerate caps and much much more.
Download link to latest stable: http://www.guru3d.com/files-details/nvidia-profile-inspector-download.html
Latest but maybe not so stable build: https://ci.appveyor.com/project/Orbmu2k/nvidiaprofileinspector/build/artifacts
When you start it, at the top left you can select one of the existing driver profiles to edit. Or you can create a fresh new profile (the little yellow sun icon, top center). Before doing anything, I'd advise to export a full backup of the profiles (green arrow up icon slightly more right) so you can always return to default.
The frame rate limiter / vsync parameters can be found right at the top in section 2 - Sync and Refresh. Changing is as simple as clicking and selecting one of the optional values, or typing if it requires a hex value. Remember to Apply Changes when you're done (top right).