Coyote Foxtrot

Please refer to this thread on how to appropriately use the Gameplay Questions Forum.

I don't know what they are talking about, but rotating that hard points will not change how they will separate. How the separate is determined by the order they are placed with the first placement of the hardpoint being the thing it detaches from. Essentially, you will be placing your craft on your payload rather than your payload on your craft. Re-rooting will also not work as it will swap which side the hardpoint will detach from.

I do not use the stock hardpoints when it comes to hardpoints in the sense of carrying weapons. Typically the "hardpoint" is just parts meant to visually represent it, but when it comes to attachment it is attached by some other method like the TT-38K Radial Decoupler clipped to hide as much of it in the missile, or having attach points to use a stack decoupler and then use the move tool to position them.

If you want to find it through file explorer (assuming Windows and default Epic Games download), start looing in your local disk > program files > epic games > Kerbal Space Program.

The center of thrust of a rocket is far from the center of mass which allows it to have a strong torque do to having a large moment arm. When it comes to aircraft it is likely a lot closer so when it comes to control, the method used needs to be quick to adjust and drastic. As an example a VTOL aircraft I made was design with three jet engines with two in the back and one up front and there is a net torque with a tendency to pitch up. It has this tendency to reduce complexity so only one mechanism is needed to entirely block any thrust from the front engine causing a strong pitch down movement. The engines always remains at full thrust and a part physically blocks the thrust. There is a big trade off I make with hovering designs as in reducing the needed control systems I reduce how much I am able to correct any movement.

There is no way in the stock game to feed data into KAL controllers and have them output as a result. If you want to have it do it automatically, you can have a KAL control that adjusts the thrust limiter of an engine over time to compensate for fuel use and I believe you can then use a KAL controller attached to throttle to control the speed of the first KAL controller so it changes the thrust limiter at the correct rate of fuel drain in proportion to thrust. This is really overcomplicated and probably unreliable way to do it. Depending on what you're doing, it might be easier to use a KAL controller attached to pitch/yaw controls that adjust the thrust limiter of engines to induce a thrust vector effect.

You'll want to be on either high or lower orbital altitude to have a different orbital period so it can catch up to you or your catch up to it. After a couple of orbits it will be close enough that you can make a maneuver node to intercept its orbit with a close separation distance.

Science are represented as “physical” packets. They are also stored in their specific part (e.g. command module, MPL, Kerbal, experiment part). So even within the same ship a Kerbal will need to EVA to move collected science around.

I believe in the input section of the main menu settings that shows the control axis, there will be a bubble to click on to invert the axis. Like in this image.

I can't imagine that the nuclear engines will be efficient enough still being that deep in the atmosphere. Whiplashes and RAPIERs will still operate at high altitudes and the Panther still can in afterburner mode. If you're going for a U-2 approach, thin but long wings are essential (albeit, the actual shape of the wing won't matter so it could have a long chord). The amount of air pressure decreases so the U-2 uses more wing surface to produce needed lift over flying faster like the SR-71 or A-12 which simply travel faster for more air pressure and lift. When it comes to maneuverability, it will generally be bad. If relying on control surfaces, have more control surface area farther away from the center of mass to allow for more torque to be produced by them. Thrust vectoring will generally give the same amount of torque for control, though, there is reduction as thrust reduces with less air (unless using a closed cycle engine). This only deals with maneuvering in terms of the direction the craft is pointing. If you want good maneuvering in terms of changing your direction of travel, you will have to settle with post stall maneuverability with vectoring engines as there is simply not enough air to allow for your wings to produce enough lift to effectively change the direction of travel quickly. You say that the engine is too long. Is it because you are getting tail strikes on take off? If so, you can either wait till you get enough speed to pitch up to a lesser amount, or you can angle your wings up to introduce an angle of incidence so that even if your plane is level, the wings will already be generating lift with some speed. There is an added benefit that it will decrease body drag as less body lift is generated where a component of it acts against the forward movement of the plane.

To recover a ship with this mod, you need to select it in the map menu and then there should be a button on the bottom or side that says "SSS". Clicking it will automatically add it to your folder of saved crafts. Ensure that the mod folder is placed in the gamedata folder.

The ship will exist somewhere in the very long persistent.sts file I believe and it should be possible to copy that over to a new .craft file. I remember there being a mod that will allow you to do so without doing it manually (though, I do not know if it works), but I have not been able to find it yet. Edit: try this mod https://spacedock.info/mod/644/Ship Save Splicer

There are Mun craters, and then Mun large craters.

Are you using a tail-dragger or tricycle gear configuration? There is a certain condition with a tricycle gear configuration that causes the aircraft to be unstable in yaw while on the ground. It happens most with landing due to braking action, but I have seen it on some of my crafts where the aerodynamic configuration of the plane pushes the nose into the runway. If force is applied in pitching down whether from engine thrust, aerodynamics, or braking, more force is applied to the nose wheel increasing the nose wheel's normal force and therefore friction. With that increased friction any deviation will cause the plane to turn and with it being in front of your center of mass, it will cause the craft to turn more. The default settings for the steerable gear have their angle limiter decrease with greater speeds (where taxi speeds are essentially below 10 m/s). You can change it so it doesn't do that, but your nose gear will still have too powerful of a correcting force and can cause you to spin out (and if you don't use a steerable wheel for your nose gear you can't even steer). The better solution is at a medium speed to start pulling up to get pressure off the nose wheel disempowering its turning power. You will lose the ability to correct yaw from the nose wheel and will have to rely on your vertical stabilizer and rudder, but there should be at this point sufficient speed to use them assuming it is large enough and far enough away from the center of mass.

Not a way to pump, but you can modify the craft file to give SRBs more fuel by modifying the SRBs' module "amount = #" and "maxamount = #" values.

You could try having a kerbal place a ground anchor and a grabber unit underneath the base and then precariously drop it on it.

Look to the control input indicators at the bottom left of the screen. If they still properly correspond, that means there is an issue with the orientation of the control point of your vessel. If not, you can go to the settings in the main menu, control inputs, and change the buttons for roll and yaw.

Landed vessels are a bit iffy. A sure-fire way of keeping a base still is using a ground anchor with a docking port to dock the base to.

Design challenges like fighter jets can be a bit different to designing for a space mission as the design targets aren't given to you as you don't need to be concerned about getting it "there". When it comes to making these, it it better to set out design constraints/targets to aim for. Do you want an long-range air superiority fighter? You'll probably want to design it to be able to carry many fuel tanks but be able to drop them for improved maneuverability when dogfighting. Want an interceptor? You're probably more concerned with speed and range rather than maneuverability, so powerful engines and a lot of fuel is in need.

I honestly do it the lazy way, but I found this thread with illustrations for the different methods of rendezvous.

For your first question, BDArmory adds modules along side the weapons that allow you to set up AI controlled tanks/ground vehicles and planes/aircraft. I also believe there is a module for a craft to behave as a missile, but I've never tried that one out. Using BDArmory's modules also does allow you to have crafts follow you as a wingman. There is a certain derivative of BDArmory created for the Runway Project and, in my opinion, it works a lot better for AI controlled competitions.

Using RCS thrusters will typically cause a change in orbit and relative velocity to your target as the thrust is not perfectly only effecting orientation causing some thrust to change your orbit. This issue is exacerbated with your craft here as RCS thruster are not placed symmetrically around the CoM of the orbital maneuvering portion. This will cause the RCS thrusters fire in an uneven matter and although it can rotate your craft, it has unwanted thrust changing the orbit. One method is to have your new station module isolated and maneuver itself with its own RCS thruster system. Of course, this will add complexity with needing command modules and whatnot added to your module. Another method is to toggle off the RCS and rely only on reaction wheels to rotate your craft. It is a a slower unless you have large or many of them, but they allow you to orient yourself without having thrust which can change your orbit (and relative velocity to your target). You currently seem only the small integrated reaction wheels that come with the command module you are using. You could stick with that and slowly rotate with RCS off or add additional reaction wheels near the CoM to allow for greater rotational control. A note about your module is that it seems to primarily be batteries with no way to generate electricity. It's easier to think of KSP's electrical system as power production and capacitors. The batteries can be thought as the capacitors and store electric charge for those moments when you need a lot of electric charge quickly (e.g. running/transmitting science experiments). Unless you have things that need electric charge production to match their usage, you can simply used a limited amount of them whether it be radioisotope thermoelectric generators (RTGs), solar panels, or fuel cells.

Instead of using KAL controllers to turn light on and off, what I do instead for the navigation lights is having the controllers control the RGB values of the lights over time. I'm not sure if it's been fixed, but they all have to have a minimum value of 1 or else the color bugs out. I have a subassembly that I use to quickly place a full set of navigation lights that I could share if you want it. Here's an example of one of my airliners using this method of strobe lights. You can see that the tail strobe lights have a hard switch from white to off. The KAL controllers are actually making the light jump from max for all RGB, then 1 for all RGB.

When is comes to CoM and CoL, there is a bit of nuance to it. When it comes to standard forward flight, the purpose of having CoL behind CoM is to have passive stability to the craft. With the CoL infront, the AoA will naturally want to increase; this is considered to be unstable. Having the CoL behind means that the AoA naturally wants to decrease; this considered to be stable. The further back the CoL is, the more stable (the more the craft will want to return to its flight path vector/prograde) it is, but also the more resistant it is to change. Having CoL close behind the CoM is to balance between stability and maneuverability. Placement of the CoL however is also dependent on the torque produced by thrust based around the CoT's vector and position relative to the CoM. This sort of balance between stability and instability is on two planes for pitch and yaw. If the issue is purely on vertical takeoff with little to no horizontal speed, aerodynamics play almost no effect and it now comes to a balance of the CoT relative to CoM. You want the average vector mainly to go through the CoM; it does not necessarily have to be directly underneath the CoM, but it would require a greater angle the further away resulting in horizontal movement. Without RCS thrusters or different engines/gimbling engines for thrust vector effect, you will essentially have no control over the craft in VTOL mode. You can either have engines rotate/gimbal around the CoM so it results in torque in different directions or you can place multiple engines that you can quickly vary the thrust in to allow for uneven thrust and control over the craft.' You will need to maintain some of this vertical thrust and balance until you achieve enough airspeed for you control surfaces to be effective. With the issue of veering off the runway, assuming you are mostly using a tricycle gear design with a singular nose wheel, the same idea with the stability and instability with lift applies with the gears. It is best to get pressure off of the nose wheel as soon as you can to reduce its friction with the surface and power to change the crafts direction and then instead rely on your vertical stabilizer and rudder for yaw control. Make sure the main gear is just behind the CoM to allow the needed force to pull your aircraft up is reduced as it's like a seesaw. The further back your main gear is, the smaller your moment arm for your elevators are and the less force you have to rotate your aircraft (assuming you are not using canards).