OHara

They are calculated on start-up whenever KSP detects a change to the part. They are stored in PartDatabase.cfg which seems an obvious way to avoid recalculating on every start. The part-creator can define the drag values in the .cfg file for the part, and many mod authors do so, and where there is such a definition it is used permanently. Put that way, it sounds like a wisely-designed system. The trouble is the resulting table of numbers is not popular with mod authors (example) and even my faulty sarcasm-detector senses that KSP maintainers are frustrated with drag cubes. The mechanism for automatic generation is hidden from users and mod-authors, and when new artists joined KSP about 1/3 of their models had un-physical numbers in the automatically-generated drag cubes. All the intentional changes that I noticed were for purposes of bug fixing, so on the bug-tracker searching closed items for 'drag'. None of the on-purpose changes that I know of happens to affect any parts in your example. Simply the original scheme for drag is rather sensitive to how the layers of software, modelling to Unity to KSP, describe the exact shape of parts.

I added https://github.com/prestja/Kopernicus/issues/19 but have not set up to compile and test C#, so hope @Sigma88 might still be in position to confirm if this was his original intent, and motivated to make a pull request.

Oops. There it is. The HeatShifter mod calls the Kopernicus routine GetBodyReferencing() that contains the code I paraphrased above, so I still think the problem is in Kopernicus' KopernicusStar.cs

I tested, though, with only Kopernicus and GrannusExpansionPack, and saw the atmospheric temperatures follow Kerbol rather than the local star. (I checked that you did not include HeatShifter's dll your released mod.) @Sigma88's work in Kopernicus to restore the proper effect of multiple stars had a routine (in pseudocode because the name-mangling of C# makes all of this much less obvious) localStar(body) while NOT isStar(body) AND exists(body.parent) body := body.parent return body but his code accidentally tested for isStar(body.parent) so it stopped just short of the localStar, failing to return any star from which to figure atmospheric temperatures. Current Kopernicus Continued has localStar always return Kerbol, which works on lots of planet packs, but makes the code look rather pointless.

There is still a problem with atmospheric temperatures, isn't there ? For example, with Kopernicus-Continued 1.9.1-5, at the equator on tidally-locked Toutatis the alt-F12 aero-Gui shows a seasonal variation of air temperature from 100K to 440K depending on whether the ground faces Kerbol. think the temperature variation was intended to be relative to the local star Grannus. The PanelsFix2 branch of Kopernicus had an off-by-one error in its search for the local star for purposes of heating the atmosphere, failing to find any star, which Kopernicus-Continued-1.9.1-4 avoided by using Kerbol as star the for every atmosphere. I commented on the GitHub but am confused because this aspect of 1.9.1-4 was reported working on that thread --- maybe it was working in the sense of a stopped clock being correct twice a day. I'm not set up to compile and make a pull-request, but if anyone can confirm the problem remains, I can try to set up. It seems a shame to leave it almost fixed.

There is not usually any way to turn off the PB-NUK in the stock game. That option is easily mod-able, though, so you might have a mod that let you turn the PB-NUK off, in which case there should also appear a blue 'Enable Generator' button in the right-click menu. Maybe you have a mod that has some more complicated rules? As a brute-force solution, you could search through the save-file for name = ModuleGenerator generatorIsActive = False and change to generatorIsActive = True

The pistons can 'surface-attach' (as opposed to node-attach) to most parts, so instead of using one cubic-octagonal, I surface-attached both pistons as shown at right. KSP uses a logical tree structure, for things like picking up a part and having a predictable sub-assembly come with, but allows any physical network of connections through the EAS-4 strut. Unfortunately they weigh 50kg each. You can attach the EAS-4 between the moving portion of the piston and its load. Alternatively to the EAS-4, if you enable 'Advanced-Tweakables' through the in-game Esc-key Settings menu, you can turn on same-craft interactions on (1) the piston that would otherwise need an EAS-4 and (2) its load. I'm not a Breaking Ground robotics expert, though -- maybe get this moved to the relevant sub-forum?

The Making History mod did have some engines with misaligned thrust --- the big misalignments have been repaired --- but here the torque shown by KER was only 0.8kN-m from 400kN thrust, so the Bobcat thrust is only mis-centered by 2 mm. The lift from just the passive action of fins should counter that torque with non-noticeable mis-pointing of the rocket. Deflection of the steerable portion of the fins would give on the order of 10kN or so on a 20-m lever (a couple 100 kN-m). Even KSP's reaction wheels give several kN-m (unrealistically strong, but it made a popular game so I won't complain). You might expect that in vacuum you always need to aim the Bobcat 2mm off the center of mass to compensate, just 0.02° on a 20-m rocket. I think you're using the Bobcat as intended, as you need only thrust-to-weight around 1-even after the boosters are done. (some player opinions in this thread) I am stumped why the rocket is pulling north, but I bet someone else will have ideas. (One side effect of editing your own first post is that the thread is not marked as "having new material", but now I've added a new post so it will jump to the top of everyone's list.)

Everything about that rocket looks fine to me. Some accidental asymmetry is usual in KSP (most obviously in aircraft if you let them wheelbarrow on takeoff) and the unwanted yaw that you describe does not seem unusual. It looks like you used radial symmetry (selected by the pie-slice symbol in the editor) to join the boosters and fuel lines. When you pitch east, then the starboard side of the craft has the fuel line facing east, while the port-side fuel line faces west, so there is a little asymmetry there. You might try re-attaching those parts with mirror symmetry (selected by the mirror-image symbol in the editor) to see if you like that better. Other than that, you might just use SAS or trim out (alt-W or alt-S, then later alt-X to cancel) the yaw. You might also like to simplify the craft. Struts, for example, are a little magic in KSP, as one strut fixes parts in all three dimensions, but they weight a lot at 50kg each, so you can use fewer. Fewer fins work if you can slide them further aft. Fuel lines are no longer needed in the situation you have them, now that the decouplers will cross-feed fuel. Maybe some simplification will accidentally give a craft that flies better for you.

This kind of thing happens, for very little obvious reason, between versions. The drag model introduced in version 1.2 is very very sensitive to small changes in the shapes of parts, and for reasons mysterious to me the computed drag changes slightly when the unity engine changes. In your case, the drag-coefficient for the cylindrical sides of the probe core goes from 0.68 in version 1.7, to 0.70 in version 1.10 (by comparing PartDatabase.cfg between versions). You can use a Module Manager patch to copy the old drag cubes into your new installation if you want, and then get the old performance. Parts that changed the visual models had a bigger change in performance (bug report). You have to redesign some of your craft when you change KSP versions. If it makes you feel any better, new players have to redesign their craft between the tutorials and the game. Players who try to build the very first craft from the training mission (which uses an old model) in a sandbox game (using a new model) see drastically different performance:

When you do mine an asteroid to reduce its weight, do it in version 1.9.1 or after they fix a bug in 1.10 (link) where asteroids fail to get any lighter when you mine them.

I still can't find a report on the tracker, so I made one. I can still break off wings in version 1.10.0 the same as with 1.7.3 (haven't tried in between) The pictures in @Boyster's imgur link show the "destroyed by aero forces" message that marks when the force of the relative wind (a.k.a. dynamic pressure) breaks fragile parts (in versions other than 1.10.0) not the static pressure --- so to get the behaviour that @Boyster wanted you do not need to enable 'pressure limits' in versions before 1.10.0, and hopefully versions after. Most people, I think, will not want to enable the options that Just Jim put in his image, unless they have a mod that makes them interesting. The tolerance to static pressure for every single stock part is 4MPa = 40 atmospheres = 400 meters under water. So all this option does is prevent submarines in hard mode. The 'part G-force limits' are 50Gs, the same for every part; they might make it more difficult to protect lithobraking probes with sacrificial shells. By contrast 'Kerbal G-force limits' just below these, is quite fun to have enabled.

The panels remain functional and F3 remains clear, after putting them through aero forces that surely broke panels before. This looks different to the already-reported graphical error on truly-mechanically-broken panels, so I made a bug-tracker entry https://bugs.kerbalspaceprogram.com/issues/25795

I think @Boyster means the problem with solar panels and antennae failing to be ripped off on re-entry reported here (link) and not the crushing controlled by the pressure-limits option. The strange survival of solar panels through re-entry is not publicly visible on the bug-tracker yet, but mentioned as a 'known bug' up-thread. Do you see it in your view or does it need a report?

I think you are misunderstanding the part pressure-limits option in the difficulty settings. All parts have the same limit of 4000kPa, about 40 atmospheres, and if you select the pressure-limits option they are 'crushed' at about 400-meters depth in the oceans and explode. Not many people enjoy this option. This pressure-limit setting, and the G-force-limit for parts (interesting for some modded parts) are still working correctly -- as is the more-generally fun G-force limit on Kerbals. Antennae and solar panels are now surviving atmospheric re-entry in version 1.10. This problem was discussed here (link) but is not on the publicly-visible bug tracker yet.

There are posts in the Tech Support and Gameplay Questions sub-forums. But, mostly I think not so many people are playing version 1.10 yet, so it will take longer for bugs to be confirmed. The drag of core-game engines, and other parts that have holes through them, was finally fixed in version 1.10 (link link link) --- after being present for a couple years. Unfortunately, they also added a new feature to the drag system for parts with variants, which made the drag of the engine plates wrong (link). The engine plates problem has a posted workaround (for players on PC) and at least it is limited to parts from the Making HIstory mod.

In the first post of this thread, under the title "Add Angled Docking Ability to Docking Ports"

KSP2 is likely to appeal to people who don't play video games, and thus do not have a gaming console, because the interesting part of the game is different to other games. I had to turn graphics up from the minimum to see shadows on the ground when landing, but otherwise have found the game playable and enjoyable for 5 years with near-minimum graphics. Generally I buy a computer every five years, use the newest one for work, and retire the old work computers for home. KSP needed a graphics card so I play it on what is otherwise my 'work' computer. A 4-core Intel i7-6500 at 2.5GHz and a Radeon R6 M360 is enough for ray-tracing as used in lens-design, CAD modeling, and the image processing that I do, ... but in KSP I have to swing the camera toward the sky to get full frame-rate (25fps for a green clock). Gaming machines cost a lot more than KSP2's planned price.

All the cool kids are using Jupyter notebooks these days, or so I'm told : The radius of orbit, where we switch from one approach to the other being most efficient, exactly where the single-burn delta-V is the same as the final orbital velocity. This allows a reasonably efficient way to find which approach is more efficient in KSP by setting just one maneuver. I have some intuition for this crossover, in the case where the parent body is very dense and heavy : the Oberth effect removes your interplanetary energy for negligible delta-V in that case, and then you need pay only the orbital velocity of your target. In the general case, I can prove it from @ManEatingApe's math with some (very ugly) algebra. But I have no intuition for why the crossover point is so simply related to the final orbital velocity, in the general case, and that drives me crazy.

I didn't expect it to be fixed, but its still on the list of bugs Just to be explicit, from the point of view of users using releases, the atmospheric temperature bug first appears in release 1.9.1-2. Release 1.9.1-1 gives us cold air at the poles, warm at the equator. Release 1.9.1-2 gives solar panels the flux they deserve from suns other than Kerbol, but with that fix came the bug with planetary-uniform air-temperature.

It depends, on how fast your are coming into the SOI, and how high the target orbit is. You can plan a maneuver to go directly into the target orbit, and compare the delta-V to the resulting orbital velocity. If the required delta-V is greater than the orbital velocity (coming in very fast and aiming for a high orbit) then you might save some fuel by doing the capture burn very low, where your fuel is much more effective at removing your excess energy, and then paying to get most of the orbital velocity back when you are back at the target-orbit height. There is a concept of a "gate orbit" that comes up when people talk about the reverse problem: what orbital heights are good from which to launch an interplanetary voyage. The gate-orbit height for any given destination is the dividing line between which of your two options is more efficient when returning from that destination.

That is strange. If those keys show up in the relevant 'Settings' screen that you get from the main menu at game-start (shown at right) then they should operate the wheels just as well as WASD do. Probably something went wrong, so it might work if you recheck that the settings were stored correctly, and try again. If you prefer numeric keypad keys, you can select them on the same screen; maybe they will work for you. Whether SAS is on or off, if the reaction wheels are active and have default settings, the WASD keys will rotate the ship. You can turn the reaction wheels off if you like by right-clicking on the reaction wheel (or command pod that contains a reaction wheel) and turn it off or have the reaction wheel respond to [Edit: 'SAS Only' and not your keyboard input.] Oh, that might be the problem, if the round window on the Cupola is still pointing up when you use it for the rover. Rocket-style command pod have their 'forward' direction pointing up by default, so the "drive forward" command would by default activate any wheels that would move the craft toward where the top of the rocket would be, and you might not have any wheels that move the craft in that direction. There is another option if you right-click on the Cupola to set a different control direction.

Right mouse-click with the pointer over a part. I see it called the Part Action Window (PAW) in this forum, but the KSPedia just says right button click

No. Realism by itself doesn't seem very important in a game. But coherence seems important for the rather complicated game KSP. For me, the use of real physics in most areas, with simple exceptions for good reasons like the 1/10-size 10× dense Kerbin, lets me remember the rules of the game easily enough for it to be fun. It does seem that KSP2 will need to bend reality in some way to give the Met.Hydrogen engine an in-game niche alongside nuclear engines. I am guessing that the first is a stepping stone to the latter. Can you imagine ways to have both (unreal but imaginable) technologies each have their own advantages for different uses?

We don't want interplanetary travel to be too easy, of course, because doing things that are tricky enough to be interesting is the fun of KSP. Another interplanetary enabler in KSP was the Alcubierre Warp-Drive mod, that keeps things interesting because it does not accelerate/decelerate the craft, only warp space around them so they are translated relative to the rest of the universe. That opens up possibilities, but makes you think ahead about how to match velocities with the destination body. I'm trained as a solid-state physicist, so I do cringe at the name of 'metallic hydrogen' for the fuel. Eugene Wigner did predict possible metastability when he first extended the theory of molecular orbits to the simplest possible solids, at the dawn of solid-state theory in the 1930s, but there is no reason to expect unusual metastability all the way down to the few GPa range of reasonable pressure vessels. We would expect to need very high pressure to contain such a fuel, nearly as much as needed to form the metal initially. The more energy released between a metastable state and the ground state, the more likely it is to quickly slip out of that metastable state. Nuclei stay metastable for reasonable lifetimes, at even higher energy differences to the ground state, but chemistry and solid state physics just don't have those high energy barriers that nuclear interactions provide. I'll just re-imagine 'metallic hydrogen' as some heretofore unknown isotope of H, which is still suspension of disbelief, but feels a more honest in its suspension of disbelief. I can get over that name if it makes a good game. I can see how Kerbals having some monopropellant with a release energy so high, that the product is at 7000 K, would inspire development of magnetic rocket nozzles, because 7000 K would melt the solid parts of the nozzle if we let it touch. Then magnetic rocket nozzles then open the door for for atomic rockets with even hotter product. That seems to open up a coherent sequence of different engines for different purposes.