OHara

Oops. They are restored now.

there is a note in the changelog for 1.11.0: * The LFB KR-1x2 Twin-Boar Liquid Fuel Engine now has the correct diameter. which probably broke the flag. So to restore the flag find the original twin-boar under Manufacturers : Kerbodyne

Initially hiding the extrasolar planets could be fun, if there is a good mechanism in the game to discover them. I don't find Research Bodies' mechanism to be fun, myself, with the manual pointing and repeated clicking. KSP1's Sentinel Telescope has a nicer mechanism, and it could fit KSP very well if the telescope found those asteroids and planets that were sufficiently lit by the sun or local star (youtube link). Then we might send telescopes to orbit the other stars to find their planets, and it might be challenging to pick an efficient orbit and guess the right inclination. For scanning surfaces, the mod ScanSat fits very well into KSP, as it maps the surface depending on the orbit we choose for the scanner. The information it provides is potentially found on the internet, but ScanSat makes those maps useful in-game so there is plenty of motivation to plan the satellite scanning missions. There is not much randomization in KSP1, and that fact allows more shared experience, challenges, mission reports, taking inspiration from others' youtube videos, etc. I suspect we don't need the parts that are random. Distribution of ore varies from game to game, for example. ScanSat mapping Eve to pick a good location for a base, was more fun than trying to line up maps found online with my view in the game would have been. But then, sharing a solution that works for my game led to the obvious question "what if there's no ore there?" so the solution is less shareable in KSP1.

Yes; it is a long-term background amusement. I got interested in trying to adjust the Jool and Duna systems to make them stable, which is actually very difficult and complicated. (One of the well-known youtube explainers surveys the problem here, in his nicely intuitive style.) As the days get shorter in the northern hemisphere, I'll make more progress. By all means, tell us here if you explore any interesting aspects of Snarkiverse with Principia.

Yes, with the curved side down they will. I've made airplanes using flags as wings, and remember someone posted one on the forum, but I cannot find it now.

Yes. Kerbals have always tended to slowly slide along ladders. Recently, around version 1.10-ish, the game changed to stop them when the reach the end of a ladder, which probably causes the difficulty you mention. Very recently, there appeared an option in the pause menu (Escape-key, settings, 'Kerbals stop at end of ladder') to let you change that. I like your idea of using the flag as a stepladder.

The lower speed of sound in colder air explains some of the lower aircraft speed. The drag of the fan blades goes up significantly, and their lift falls, as the speed of the blades through the air increases through the speed of sound. That means propeller-driven craft have a top speed somewhat under the speed of sound, as the blades are moving through air faster than the craft. I don't think it gets cold enough to make a 10% difference, though. Maybe KSP also has the density fall more quickly with altitude, over the colder regions of Kerbin. If you still have quick-saves at different latitudes, you can use the alt-F12 debug menu =>Physics=>Aero=> display Aero GUI to see the temperature and density of air around the craft, to see which properties vary. The fan blade gives the most thrust when it meets the air at 5° angle of attack, so the optimum blade pitch will be flatter at lower speeds.

With mission cost a multiplicative factor, and ISRU allowed, it is tempting to design a electric-prop-assisted spaceplane, decouple from an ISRU and drills at the runway, leave the IRSU making fuel while taking the swimming trip to Eve, and then recouple and refill upon return, much as one would refuel a rental car. But, probably that fuel would be deemed a significant factor and not counted. I think KSP 1.12.x has corrected the recovery-cost calculator with respect to robotic parts and their optional motors. So the in-game recovery calculator might work for this challenge.

The top post makes it clear that the wind simulation creates abnormal physics, with the parachute of a free falling body tilted off from vertical, but I though I'd try a sailboat anyway. I set up a 20-knot wind from the east, so Jeb is on starboard tack with wind coming from his right. As soon as the boat starts to drift downwind, the weather vane swings as if to indicate that the wind is coming from the west. The boat settles in to moving backwards. Similar strangeness is seen flying and airplane in a crosswind, again coming out of the east. We would expect to point our nose a few degrees east of North, in order to have a north-bound ground-track, with level wings. But the only steady configuration I could find has me banking toward the east, which strangely does not result in the aircraft turning. It looks like some kind of vector addition is done to figure the airspeed, but then the direction of the relative airflow is determined by looking at our velocity over the ground --- for lifting surfaces at least; parachutes seem to follow a different rule. So sailboats, would work very differently in this world's physics.

Well, do you see any good set of rules to disallow clipping? I think KSP version <0.90 had parts on the same craft collide with each other, but allowing clipping seems to have been a net benefit, especially for people who try to make replicas. KSP1 tries to prevents some parts from functioning (the "cannot deploy while stowed") if they are enclosed in cargo bays, and players were often frustrated and surprised by how exactly KSP1 decided when parts were 'enclosed'. FAR since its 2015 'Euler' release, on the other hand, lets me clip an engine inside a fuel tank for drag-free thrust, and I see nobody complaining. After reading the "Rethinking clipping" thread, I think it is better to let the players enforce their own clipping policy. This reminds me of another complication from computing drag body-lift for the whole craft : the game then needs to divide the aerodynamic force among the parts, and apply the correct force to each part, assuming KSP continues to treat parts as independent physical bodies. (I cannot figure out FAR's rules for dividing the force, just from reading its code.) The boosted lift, however, does allow the fun flying by Cupcake that Laie pointed out a few posts up, and also lets new players get off the ground more easily. KSP1 also boosts drag at low speeds, resulting in a L/D (a.k.a. glide ratio) a bit smaller than similar-looking real aircraft. Players using FAR also complain that their planes float the length of the runway. I did not mean to imply that it was bad that planes can float down the runway, because players add airbrakes and chutes to stop in the available distance.

After playing KSP two more years, with and without the mod FAR, I have change my mind slightly on what would be good to keep from KSP1 aerodynamics. Calculating drag and body lift per part and combining parts with simple rules, creates strange behaviour when players make craft in natural ways. Today there appeared a video doing a recreation, that (1) places a narrow decoupler between two wide parts, and (2) uses Mk2 parts at the front of the rocket. Experienced KSP players, including the video-maker, know that this creates very large drag on the top of the rocket, especially if it turns even slightly off prograde. There have been a few forum threads about what people want from aerodynamics ( link link link ) and there was also a thread about when part-clipping makes KSP a better or worse game: Given that, I now hope that KSP 2 uses the shape of the assembled craft to figure aerodynamic drag and body lift, rather than shapes of the individual parts (aspects 0,1, and 2 in my list in the top post). That would make "clipping for performance" more important in KSP 2 challenges, but I think players understand that intuitively and would allow/disallow that as they like for their own play or challenges (as opposed the less-obvious node-attaching for performance in KSP1). Probably too late to have any influence on KSP 2 development but you never know. Has anyone else changed their mind on this topic?

That is a good question, and also I think a good answer. Finding which options will be the more-fun ones for enough players to make a successful game, is I suppose the art of game design. I would say that KSP 1 did a decent job choosing which crazy fictions were justified to make a good game. Immortal Kerbals, that do not eat, made the game accessible to enough players to keep the game alive . . . and then some of those players made life-support mods. That might not have worked the other way around (if the base game required life support). Instantaneous communication does make the game mechanics a lot easier. RemoteTech has a switch for signal delay, and the game-play reviews I have seen all turn that off. Even with signal delay on, the human player controls Kerbals with no delay, so to make a consistent mental model of the game mechanic, any change of plan from Mission Control must be instantaneously communicated telepathically to the Kerbal pilots. I understand the desire in the OP for a mechanism to make Kerbal pilots more necessary. Maybe the line-of-sight requirement for communications (as in RemoteTech as I see it used, and in stock CommNet) would be enough.

The mods Environmental Visual Enhancements, (or maybe the new version here) and RSSVE or RSSVE_Lite. Environmental Visual Enhancements tells the GPU how to draw clouds and atmospheric effects; RSSVE has the configuration files that specify where to put the clouds on real solar system planets. That means you should remove E.V.E.'s default configuration files (delete GameData/BoulderCo/) when you install RSSVE. CKAN might do this for you. (In order to build craft that can get to orbit from Earth, you will also want either SMURFF or Realism Overhaul to get more realistically efficient engines.)

I've been happily playing version 1.7.3 with the latest version as a side install to see what new things were there. Now I'm thinking of shifting to a new permanent version so was hoping someone would have the definitive answer to the question. Several bugs that appeared in a .0 release were repaired in the .1 release, so we can ignore those for this question. I tried making a list of pros (+) and cons (−) for each version --- the pros/cons that I care about --- and think I'm concluding that 1.8.1 is best for me. 1.8 + Updated to a long-term support version of Unity. That makes mods generally compatible with 1.8+ + Can edit action groups in flight + Aerodynamic control surfaces now have separate amplitudes for 'deploy' angle versus 'actuation' angle − Since 1.8.1, cargo bays no longer protect separate craft, affecting some rescue missions and pre-robotics propeller craft 1.9 + Free-flying camera with F2 + the Set Position in the cheat menu ± Propeller & Fan blades respond as collective/cyclic to pitch/yaw/roll (Breaking Ground mod) − Phantom forces from EVA Kerbals made pods tumble (resolved in . . . 1.10.1 I think) 1.10 + Comets + Corrected drag from several Engines and the M.H. Structural Tubes − Fuel transfer often fails due to a UI glitch (workaround by mouse-over the resource icon, per linked thread, fixed in 1.11) − Mining asteroids adds mass to the craft without removing any from the asteroid ± New part: surface-attachable Flag 1.11 − Plumes on several rockets are shorter that they used to be + Inter-stage fairings now let go when decoupled (previously would stick to the decoupled craft in some cases) + EVA Construction 1.12 + Subfolders for craft files visible in the VAB/SPH

For anyone who hasn't seen in, there was a preview of clouds (link) for KSP 2 (a serious preview, not just the April fool's joke). I also like the idea of wind to enable windmills, sailboats, and to make airplane and parachute landings more interesting. KSP does not have any random events (for the most part) and that seems to fit KSP being a game that rewards planning. So maybe should be predictable, such as winds that come up in the afternoon, but are calm every night and every morning. Then if weather does affect a launch to rendezvous with an orbiting station, it could make an interesting choice between flying through the weather, or waiting and then doing the required orbital maneuvers to meet the station. Earlier discussions of weather in KSP 2 (link link link link)

For me, the sum of all the drags under 'debug' in the parts' right-click menus, plus 'induced drag' at the bottom of the aero-GUI window, has always added up to the total drag that KSP applies to the craft. I don't see anything that you've missed above. Maybe put the craft file on KerbalX or somewhere and one of us can check the sums in our installation of KSP ?

This has come up as a request a few times (link link link) but no-one seems to have any better answer than to watch the nav-ball label and set it back after an undesired change.

What you say about basic RSS and RO is true. Realism Overhaul does not yet convert the Making History engines nor add real-fuel capacity to the tanks. (I made my own quick patch for the tanks here.) The video you linked lists the relevant mods in the video description --- including Katniss's Cape Canaveral and several parts mods.

That's interesting. Very short mod. Now I see the new function ApplyCoordUpdate was added to ModuleDockingNode and there is a function of the same name in ServoBase from Breaking Ground. So the mod restores the original positions of all parts on a branch of the craft involving an unlocked docking port, before any quicksave or upon reload. So if we did rotate any docking ports to straighten out a space station, that straightening will be un-done upon reload, which seems fine given the request.. I am confused what might happen on something like a Canadarm with docking ports and robotic parts working together. We can AdvTweakable::Rotation:unlocked on those docking ports where we do not want the effects of this mod. Ideally, given how the original KSP saved craft, we would restore the unstressed position rather than the original position. That is, save the positions of the craft including effect of motorised joints but not the effects of stress on the craft. In hindsight, maybe KSP should have saved the current flex on each joint, in addition to part-positions, so it could later distinguish flex from motorised motion. The Klaw was the first part that would pivot and flex, so it has has for a long time showed this drift upon save/reload. That is why I though the root of the problem might be in JointLockState, which is common to all the affected parts, but JointLockState doesn't seem to keeping track of the rotation of the joint, at least not publicly.

The apoapses, the highest points on each elliptical orbit, don't move at all in stock KSP, so the tetrahedron formed by those apoapses doesn't move at all. If you are thinking of having the satellites be in a rotating tetrahedron with vertices not moving relative to each other, the thread a while back (link) was about why that is not possible.

You would launch each satellite 1.5 hours, ¼ of a Kerbin day, after the previous launch, and turn north after launch enough that each orbit has about 35° inclination. Strictly speaking, you would launch when Kerbin has made a ¼ rotation relative to the stars, which is several seconds shorter than ¼ day. If you want a regular tetrahedron, the eventual inclination would be 35.26° = arcsine (1/√3) Then with satellites in those inclined circular orbits, you can visualise the tetrahedron and boost the apoapsis of each satellite to the desired corner. To make the orbit take on Kerbin day, watch the orbit period on the maneuver tab as you boost the apoapsis. Strictly speaking again, Kerbin rotates relative to the stars once every 5h 59m 9s. It might be more enjoyable to put four markers into the desired orbits with the cheat menu => Set Orbit. Then you can pilot rockets with your real satellites and have targets to aim for. There was a related thread a while back (link) that might be interesting.

You might have to explain what the bug is, exactly, because not every modder will have run into this problem. I do notice that in version 1.12, if I put stress on the craft (I used 'hack gravity') so that all the joints give a little, then quicksave and quickload, most of the joints are initially back at their unstressed position upon quickload (which has been true in earlier versions of KSP) but the joint between the docking ports loads back at its stressed position, and then the load on the craft moves them further (which is new, though similar behaviour was reported with the motorised joints in the new robotic parts). Repeated quicksaves and quickloads make the docking ports move further and further from their original positions. A module-manager patch to remove all the new options @PART[*]:HAS[@MODULE[ModuleDockingNode]] { @MODULE[ModuleDockingNode] { @canRotate = false -rotationTransformName = delete -maxMotorOutput = delete -rotationTransformName = delete -maxMotorOutput = delete -RESOURCE {} -rotationAxis = delete }} does not solve the problem with the docking-ports moving after repeated quickload/quicksave. So something changed the rules about how these particular joints are saved in the savefile. I suspect the trigger for the new rule might be 'IJointLockState' because ModuleDockingNode now inherits from IJointLockState. I do not know any way to change that inheritance. Of course, we could all just use KSP 1.7.3 or maybe 1.9.1. Older versions of KSP had the ability to align docking ports, having the docking ports joint only when aligned, if we enabled the option with a module-manager patch @PART[*]:HAS[@MODULE[ModuleDockingNode*]:HAS[~snapOffset[]]]:FINAL { @MODULE[ModuleDockingNode*] { snapRotation = true snapOffset = 90 captureMinRollDot = 0.9998 // cosine 2°, adjust for different tolerance acquireForce = 0.5 // per user preference, default is 2.0 }}

Occasionally, FAR misunderstands the size and shape of modded parts from their configuration files. Sometimes the mod does tricky things with scaling that fools FAR and the mod cleans things up to be compatible with FAR; other times FAR corrects the miscommunication: https://forum.kerbalspaceprogram.com/index.php?/topic/182679-112x-restock-revamping-ksps-art-july-20/&do=findComment&comment=3554204 There is an option in the FARc menu, 'Transonic Design' => 'Display Debug Voxels', that shows the shape FAR is using. (The option works in most versions of FAR, but for a couple versions of KSP, it shows me nothing.) Maybe there are error messages in the alt-F12 console that might identify the problem and help you solve it. Look in the subforum for the mod that contains these parts, and in the FAR sub-forum, for anyone that might have had this problem.

. . . when you are in the flight condition where drag is most critical --- which is often at the sound barrier. For landing and takeoff, you can place your gear to get a higher AOA as was said above, because drag is not so critical there. And that is only in stock KSP, with the flat-bottomed fuselage. You can turn the Mk2 parts on their sides and make a very . . . interesting looking aircraft. Or you can try the mod FAR where body lift is a bit more realistic.

I still had a version-1.11 installation so I copied the Squad/Parts/Utility/mk2DockingPort/model.mu into the corresponding place in the 1.12 directory structure, deleted the mk2DockingPort.mu from 1.12, and that brought back the correct control-point orientation. Probably during the artistic revision, there was some mistake in keeping the needed reference points for the docking. Copying the model only gives a grey part, so copying also the mk2DockingPort.dds restores the old textures, and copying mk2DockingPort.cfg to overwrite the 1.12 version might be a good idea.