OHara

I do not know why adding a docking port would change things, but I do know what is happening in your second image showing the problem. KSP makes a (simulated) mechanical connection between the part you place and the parent part it was placed onto. (The part that is highlighted by your mouse pointer when you place the new part, is the parent part.) That means that placing parts gives you what people call a 'tree' of connections, with all the connections looking like branches with no loops. So the boosters in your image cannot be connected to both decouplers; it appears the booster is connected to the lower decoupler. The way to add more mechanical connections is to place an EAS-4 strut between parts. Then you can have a more complicated net of mechanical connection, not limited to a tree. Players often connect boosters in the style at right.

Yes, many people do. The usual meaning of 'impulse' as force integrated over time, and the usual meaning of 'specific' as per unit mass, would give a 'specific impulse' with units m/s as you wrote at the top of your notes. Conventionally, in rocketry, people state an Isp with units of seconds, as if they had measured the force in kg-force rather than Newtons, so you need that extra factor of g=9.8m/s² to make the units work. In KSP, you might reasonably wonder "g for which planet?" The answer is 'g' for the planet where the Isp was measured or specified using local kg-force, so Kerbin, which has the same 'g' as Earth.

I don't see any similar problem when I tilt the sepratrons on my Saturn V. Maybe something got confused in your install. Maybe deleting partdatabase.cfg to let KSP rebuild it will solve it. If you like, you can put your craft file on the bug tracker, and I'll try to spot the problem, or someone else might spot it first.

If by 'like that' you mean that body lift pushes up/down when the part is angled is above/below prograde then yes of course. But, I don't think the designers succeeded in making body lift work in the game. The high drag of the flat faces makes these lifting bodies never beneficial in my experience. Some people use the Mk2 parts sideways, so the sharp edges go into the airflow, with very low drag, if you need to pitch up or down. More people set just enough angle of incidence to wings on their Mk2 planes so that the Mk2 fuselage ends up perfectly prograde --minimising its drag-- when the plane goes through the sound barrier. A few people use the blue lift vector in the SPH to make 1° rotations. That vector shows you the lift force as if the airflow was coming from 1° below the nose, so you can rotate the whole plane with the smooth-rotation circle until the vector goes away, then snap-rotate wings in absolute mode to level, so they have 1° incidence.

Experiment is certainly the easiest way with KSP. KSP wings have a very soft stall, with their max lift at 30° AoA and falling slowly after that. You might not even notice the stall in KSP. If you are still building airplanes for Duna, I guess you might want to know that KSP does have the force of lift vary according to ½ CL S ρ v², where CL is the coefficient of lift, S is the conventional symbol for total area of the wings, and for density of air (1.1 kg/m³ at Kerbin's sea level) So to fly nearly level for landing, Mass × g = Lift = ½ CL S ρ v², On Duna g is only 0.3 as strong as on Kerbin. And ρ is 0.1 times as dense, even thinner over the higher mountains. So you would need 3× the wing area for Duna as you need for Kerbin, or you land √3 times faster, but Duna is rough so you want the wing area. ( KSP makes two exceptions to the usual Lift = ½ CL S ρ v². The game reports "relative wing area," where 'relative wing area' = 1 looks like 4 m². The coefficient CL would normally be nearly constant for speeds below the speed of sound, but KSP makes the maximum CL quite large, about 8 based experiment, at low speeds, reducing it to 4 at 100 m/s and to the more realistic 1 at the speed of sound -- one more reason to use lots of wing to get landing speed well below 100 m/s. )

About the worry about increased minimum computer specifications, KSP1 has an option that I appreciate, as someone using a general-purpose computer as opposed to gaming computer. "Max Physics Delta-Time per Frame" lets us set the minimum rate of rendered frames. It has a strange name. It sets the inverse of the frame rate, so 0.1 s means 10 fps, and it sets that frame rate in terms of game-physics simulation time rather than real time. For me, the CPU can always run the physics simulation at real-time (at KSP1's fixed 20 ms per physics frame, but my AMD R7M360 GPU can only render planets with oceans at 20 fps. My in-game clock would turn yellow whenever the surface of Kerbin filled more than 25% of the screen, indicating that physics simulation was slowed to keep the default 0.04 simulated seconds per frame. Then I installed EVE because I appreciate clouds for situational awareness, making the problem worse. So I turn "Max Physics Delta-Time per Frame" to 0.1  s so the frame rate can go down to 10 fps without slowing down the physics simulation. Sure, people can perceive frame rates faster than 60 Hz, largely by noticing strobe effects as they scan their eyes across the screen, but the electrical response of the nerves takes 50 ms so the 10--20 fps that I use only delays my response time by another 50 ms and that does not bother me one bit.

For the Realism Overhaul rocket that I posted above, propellant would be 347.6 − 41.4 = 306.2 tonnes, dry mass of the lifter 41.4 − 5.2 = 36.2 tonnes, and payload 5.2 tonnes. That sounds like a good idea. This challenge was a nice idea, because an SSTO rocket is moderately difficult in RSS with the mods that give realistic performance to parts. Previous similar challenges (link link link link) had not much response. I think SMURFF is the best choice of part-mod for a challenge that invites players who are new to RSS, because it does the minimum change: gives realistic mass to the familiar KSP parts. I put the rocket that I posted above on KerbalX. It leaves plenty of room for improvement. It has a decoupler to separate the payload from lifter, because I thought the challenge might use payload fraction as the score. If you make a rocket that gets to orbit, de-orbits, and is recovered it all as one piece, then I will try that style myself.

You already have valid answer to your question. I suspect that other players got interested in other directions, and forget that not everyone has the same goals with KSP as they.

Oh. I suppose you mean In the United States. I went to school in the US and they taught me 'slug' for the unit of mass. Do you not use that anymore? So the term 'pound' or 'lb' for the unit of mass (454 g) and the term 'lbf' for the unit of force (4.45 N) is it? Edit: But that can't be right, because then Newtons' law F = m a would have to be F = m a / g Reading again above I see: So I gather that in engineering people use most often 'pound' for 'lbf', and need only be wary that sometimes people use 'pound' according to the legal definition to constrain a mass. And I suppose the distinction rarely makes a physical difference on Earth; maximum takeoff mass is always applied in locations with 9.8m/s² gravity.

The Dunasoar family (link to kerbalx) are examples of planes and their lifter, that will likely inspire you. The rotors for the propellers are more complicated than you will need if you use the Breaking Ground mod. (Dunasoar was made before Breaking Ground appeared.)

A single model would work for atmosphere and ocean, taking into account the different density of air, water, etc. There is tricky physics at the air-water surface: wave drag and hull speed and planing. KSP1 ignores all of that, except for buoyancy.. Water is about 800× as dense as air, so at a given speed, the water forces on wings and control surfaces would be 800× as strong as aerodynamic forces. More likely, the speeds through water lower by a factor of 30. (KSP1 reduces the hydrodynamic forces, by the factor buoyancyWaterLiftScalarEnd = 0.025 in physics.cfg, so water forces are only 20× as strong as air forces, at the same given speed.) KSP1 also has several other adjustable parameters in physics.cfg. Some are apparently for making splashdowns look believable. There is an artificial extra drag that, as I remember, was added to more quickly bring the velocity of a capsule below 0.1 m/s so it could be recovered. Better, I think, would be to let us recover 'splashed' craft while they are realistically drifting through the water. FAR is also rather messy and arbitrary in its treatment of water. I was frustrated trying to deal with these more complicated rules when building submarines with KSP1. Edit: If buoyancy from hydrodynamics also applied to aerodynamics, that could be a natural way to simulate bases floating in Eve's dense atmosphere. A FAR-like evaluation of the shape of the entire craft, might also evaluate the buoyant volume. (Finding the centre of buoyancy at each depth, is similar to the evaluation of sections that FAR does to evaluate area ruling.) Players could then clip parts to express the tight packing of a dense submarine, or sparsely fill a fairing to make an Eve airship.

But can you hear the pure joy in that kid's voice as he describes the exploit (video link) ? You wouldn't want to take that away from the next generation of KSP2 players, would you? I played around a bit with this exploit, checking that it works as far back as version 1.3. Looking at physics.cfg the cause is obvious; the heat shield ('capsule bottom') is defined as a type of wing with zero drag. Apparently the intention was to let the separate system of body-drag give drag to heat shields. So it looks like a side-effect of the evolution and expansion of the design of KSP through the early versions. I have not seen anyone notice this loophole between 2015 when it probably appeared with the aerodynamics overhaul of KSP 1.0, and that video from October 2020. Honestly, if that were the only type of exploit, I would say things are 'fine' . The frustration comes when exploits, that are less obviously exploits, appear naturally in trying to optimise craft. (And, fine or not, KSP1's aerodyamics is good enough to have a lot of fun.)

A. The mod Persistent Rotation does close. It does a more general thing. If you leave the station rotating in synch with its orbit, so one face points toward the planet, Persistent Rotation makes that rotation persist while you are with other craft. B. No mod that I know of for wobble. Slow wobble dies down in KSP, so far as I have seen, unless you have the SAS system on, in which case a reaction wheel might be on a branch that wobbles opposite to the controller. The physics for slow things is pretty good in KSP, so you can probably find the cause and remove it. C. If you have Module Manager (likely, if you have any mods) there is a patch called "Add Angled Docking Ability to Docking Ports" at the Community Patches

I heard similar, but only something along the lines of "want KSP1 players to have a familiar experience" Desire for a "familiar experience" does hint that the higher lift and drag at low speeds could be kept, but when I asked about that (thread link) people seemed to like that particular choice of KSP1 -- it allows building SSTOs that can land a an easier speed. That is also a change in parameters so is easy to mod away. I've been playing a lot with FAR lately, and myself I like the treatment of the craft as a whole for figuring drag (no individual-part drag cubes). I do not like the very sharp stall with the tendency of wings to tuck down upon stall (I have not yet succeeded in a snap roll) and in FAR that aspect is not changeable by configuration files. Wing interactions in FAR have some discrete jumps when you move wings just a little, so you have to test a lot to confirm that FAR implemented what you intended. I don't know if the KSP2 developers confirmed anything that puts them down the path to the drag cube model of KSP1, but I'll accept it if you have.

Looks like no-one recognised the problem, so good idea to put the craft file where we can see it. There is a line in the craft file saying that one of the MK2 fuselages should be attached to a decoupler link = radialDecoupler1-2_4294554710 but there is no decoupler with that ID number. Somehow the craft file has become internally inconsistent. If I delete that one line, using a text editor, then the craft loads and seems to be working as intended.

It is important, as you noticed, to initially place the SRB on the decoupler, and moving it later does not change the part it is connected to according to the game's logic. The only way I know to do that correctly, is to rotate the view (with right-mouse button or arrow keys) so you are looking straight at the decoupler, remember where it is, and when placing the SRB click to place it when your mouse is directly over the decoupler. The fact that the SRB obscures you view makes this difficult, but it gets much easier very quickly with practice. For a while, I was always swinging my view around immediately after placing SRBs, to check that they really sit on the decoupler. Then later, as Kerbart, says, you can use the move tool to slide them up and down.

I think we all rolled our eyes when we saw some of the more extreme 'wobbling moon will causes massive flooding' headlines. If they really are referring to the 19-year Metonic cycle, I don't see why the word 'wobble' applies. In any case, we're planning to extend the port in Galway, and move housing and shops where the old port was, and nearby parts of town already have coastal flooding every few years, so we have to plan for this. I think the 19-year Metonic cycle causes tides to vary ±2% from their long-term amplitude, so here where the tide swings ±2 meter, high tide will be 20 mm higher than mean local sea level in ten years. Plus local sea level is rising about 2 mm/year at the minute[*], so high tide will creep up about 2mm ×19 /2 + 20mm = 39 mm over the 9½ years of the rising half Metonic cycle. So the 19-year cycle really is of similar magnitude to the current linear trend. ([*]We are on a piece of crust still rebounding at 1 mm/year from the previous ice age, so we have a bit less than the global average rise in sea level relative to the land.) Parts of the city flood when wind from winter storms pushes the water up the bay, giving a storm surge of 1 or 2 metres. 39mm does not sound significant compared to that, until you start thinking in terms of how often you have to sandbag before a storm; 1.95-meter storm surges are more common than 2.0-meter storm surges as those are outliers in the tail of the distribution. Then there is the worry about the rise accelerating. The obvious reference here is that archaeology and zoology both suggest that neolithic people and animals walked to Ireland from mainland Europe over a land bridge that is now deeply submerged. That fits having 10 mm/year rise over the 10 000 years to get out of the last ice age for a 100-meter rise overall. So depending on how fast ocean warming is in future, people worry about needing to move, not so much here with sloped coastlines, but there are countries built in river estuaries.

It probably makes more sense to do this using Realism Overhaul. I cannot use the same parts as above, because Realism Overhaul replaces the 'Mammoth' with 4 SSMEs on a larger 8.4-m tank, and replaces the S3-1440 with an 8.4-m fuel tank, but I see no parts to taper to the 4-m Mk3 pod. I could make a similar rocket using Making History fuel tanks. Realism Overhaul has not yet made configurations for MH parts, so I made the patch below to set fuel capacity following the pattern of Real Fuels. 4× SSME engines with Isp = 4440 m/s = 453 s·g With Realism Overhaul, engines throttle down only slightly, so I shut down 2 of the 4 to avoid excessive g-forces. The Mk3 3-kerbal pod and heat shield weighs 5.24t Payload fraction 5.24 / 347.27 = 1.5% dV = 4440 m/s log (346t / 41t) = 9460m/s (in vacuum) Engines do not re-ignite, so it takes some skill to steer so as to make a circular orbit, which skill I have not yet practised. It might be interesting to see who can get the highest payload fraction from a SSTO in RSS/RO. People use many different part mods with Realism Overhaul, though, so their engines will be configured by designers with varying degrees of optimism.

I can easily imagine that the UI was designed around the parameters of the wing+aileron that go into the simulation. The mod FAR, for example, has these parameters: @PART[winglet3]:FOR[FerramAerospaceResearch] { MODULE { name = FARControllableSurface nonSideAttach = 0 // 0: attaches at root, 1: attaches at leading edge MAC = 1.695 // Mean aerodynamic chord b_2 = 1.587 // Half the wingspan of a pair, b/2 MidChordSweep = 22.1 // Angle of sweep TaperRatio = 0.449 // chord at tip / chord at root maxdeflect = 15 ctrlSurfFrac = 0.2 // How much of the area deflects }} and your marked-up images seem to show ctrlSurfFrac being adjusted. That video (link) shows the other parameters being adjusted, but also the spanwise position of the aileron is being adjusted, which I do not see as a detail you can adjust with FAR. I like the idea of having the aileron as part of the wing, because then you can model the interaction in a simple way and have the same part act as a flap giving more low-speed lift. (FAR, being hard-core, does estimate interaction between KSP1's separate wings and elevons, but I have enough understanding to know that is more difficult.) I would accept that symmetric camber is an appropriate simplification for a game like KSP. Asymmetric camber would give lift when the airflow is parallel to the chord of the wing, but then we would need to make the foils symmetric, which is a subtle thing to see, for vertical stabilisers and rocket fins. It is easier to see in-game when we rotate the symmetric aerofoil slightly, to give the same effect. The next detail we might notice from an asymmetric aerofoil would be that it stalls a little earlier when used upside down, and that is maybe subtle enough that no-one would miss it. I would also accept that ignoring the cross-section of the aerofoil is appropriate. The thickness of the wing and location of the maximum thickness are difficult to see in a game. The aspect ratio ( b_2 / MAC ) and angle of sweep seem to be enough detail with which we can describe the kind of wing we want and at what speeds we can expect it to work well.

Often, the challenge maker will submit his own attempt at the challenge, and that often helps the rest of us understand the intention. I use only the simpler SMURFF with RSS (not the full Realism Overhaul). SMURFF adjusts the mass of KSP's engines and tanks to more realistic values, but does not change their Isp, nor the types of fuel, so I am using KSP's generic 'liquid fuel' and 'oxidizer'. The US Space Shuttle's Main Engine (SSME) is the RS-25, which inspired the KS-25 in KSP, so I used the 'Mammoth' engine which groups 4× KS-25 'Vector' engines and sized my rocket around that to see how much I could get into orbit. To my surprise, I could get the 2-tonne 3-kerbal MK3 pod into a 1180-km circular orbit. Isp = 3090 m/s = 315 s·g (same as in stock KSP) SMURFFed tanks which when full are 97% fuel by mass dV = 3090 m/s log( 395 t / 20 t ) = 9218m/s (in vacuum) Payload fraction (Mk3 pod and heat-shield) 2.9 t / 395 t = 0.7% In hindsight, given that this is a SSTO so the engines come all the way to orbit, I should have balanced payload mass closer to that of the engines and empty tanks. I had to throttle rather deeply to avoid excessive g-forces, which drives home the fact that the single-stage design has me carrying heavy powerful engines beyond where they are needed. (I did not expect to reach such a high orbit, so had not enough monopropellant to de-orbit the pod, so now I'm making a rescue mission.)

That is a common symptom for new users of Kopernicus. Assuming you have your beautiful DDS files (or maybe PNG files) of the correct size and shape, then the problem is correctly showing Kopernicus where to find them and how to use them, which involves the configuration files with their barely-adequate documentation. On this forum, you can use the three dots '...' beside your post and then the 'report' option to type a message the volunteer moderators to ask them to close your thread (or move it or merge with another or anything else we need their help to do).

What do you mean by 'code' here ? 1. In KSP1, the mod Kopernicus provides the code that makes KSP1 load the player's desired planets instead of the default planets. In this case, 'code' is instructions to the computer, and writing it (that is, 'coding') requires understanding in how KSP1 and the operating system work. ( I think it would be nice if KSP2 could incorporate this capability, so planet-designers do not need to first re-write Kopernicus. ) 2. Then there are the configuration files that define the planets (system.cfg, etc., for Kopernicus for KSP1). These are structured text so can look like code, but most people would call them configuration. They were not documented well for KSP1 and Kopernicus, but it has gotten a little better. 3. Then there are the image-like data-files defining heightmaps and textures and planetary rings and auroras and clouds, etc. There are already editing tools to create these files. Also, I think the people above might be referring to this recent thread :

This has been a problem with KSP since version 1.11. The bug goes away if you buy and install Making History but other than that, no-one has reported any solution (other than stubbornly refusing to use the SAS options that should not be there)

Well, FAR also describes wings with a set of variables (listed under FARWingAerodynamicModel in the configuration files) but it still works pretty well. The exploit with the heat shields is mostly due to the way KSP1 removes drag on surfaces where fitting parts are node-attached (since version 1.0,5). The unusual lift of heat shields makes some contribution to the exploit, but zero drag is the big loophole.