Jump to content

OHara

Members
  • Posts

    1,108
  • Joined

  • Last visited

Everything posted by OHara

  1. Real helicopters are unstable. If any gust tips one off of vertical, it starts to drift sideways and then swings back and forth in oscillations that grow. 'Dynamically unstable' is the term. Quad copter drones use differential pitch to get differential thrust on the four rotors. This can be done in KSP but is not very convenient. KSP version 1.9 and later let you enable pitch, yaw, and roll, control on the propeller blades, which makes them change their angle of attack as they rotate, giving more lift on one side of the disk than the other (like the cyclic control on a helicopter). This is easier to use in KSP because pitch yaw and roll are controlled by SAS. With four small rotors, the differential lift won't have as much lever arm as differential thrust, but it might still be plenty to stabilize your lifter.
  2. I learned arithmetic in the US in the 1970s, never saw the acronym 'PEMDAS', but was taught effectively P, E, MD, AS where ×÷ share the same priority, computed left-to-right. Nevertheless, when I see the implied multiplication 1/AB, I understand it to mean 1/(AB). In compound units with a product dot in the denominator, like Wb/A·m or W/m·K, I understand Weber per (Amp-metre) and Watt per (metre-Kelvin), as if multiplication was higher priority than division in that situation. I suppose humanity could decide on a convention to take P,E,M,D,A,S literally, but I don't recommend it because: Calculators and programming languages tend to group ×÷ in the same priority, done left to right, and likewise +− . P,E,M,D,A,S taken literally would give 1 − 2 + 3 = −4
  3. The efficiency in terms of thrust per fuel-burn (the ISP) is constant for KSP engines (wiki link). I suppose the idea is that when the ramjet catches more air, proportionally more fuel is burned. So that means you are looking for the conditions to give you the best speed per thrust, which in cruise is the same as speed per drag. The attitude (pitch) for lowest drag in level flight is called the best-L/D angle (best lift / drag). This angle of attack also gives you the best glide ratio, so you can find it experimentally by finding the pitch that lets you glide the furthest with engines off. For typical KSP aircraft this attitude has the nose pointing near the top of the prograde marker. At low altitudes, the best-L/D speed is pretty slow. At higher altitudes, the best L/D angle relative to prograde stays fairly constant until you near the speed of sound, at which point you need to point a bit closer to prograde to reduce the extra parasitic drag (as modelled by KSP). Then to make drag as low as possible to climb as high as you can to the thinner air, until you find you need to pitch up further than best L/D angle just to stay aloft. If That generally means to fly near the ceiling altitude of the aircraft, full throttle. A good fuel-per-distance design would have enough wing area that you are below the speed of sound in this configuration, to avoid the extra drag at and above the speed of sound. There have been some fuel-efficiency challenges (link link link) but none I can see specific to the Whiplash engine.
  4. One well-regarded series is this one. It uses older versions of KSP so the user interface will be slightly different to what you have, but the ideas are all the same. One change with newer versions, experiment storage containers, gives you another option for carrying 'science results' back home, so you might look at that on the wiki and decide if you want to use it as you follow the tutorials made before it was in the game.
  5. This suggestion was made to the KSP2 developers early along, so they probably at least considered making a more flexible attachment system. Given what KSP1 does with struts and docking ports, I think the User Interface is the trickiest part of making a non-tree structure KSP. Any system that has the user place a parts one at a time on an existing craft gives a singly-connected (tree) structure: the new part is connected to the single part on which it was placed. 1) The ReCoupler mod automatically connects nodes that are within 10cm (adjustable) of each other, and uses colour-coded highlighting to show the user what is going on. 2) Stock KSP1 lets us connect struts between parts. These count as extra parts, even though they don't move independently of their parent. They automatically disconnect if decoupling leaves them as the final joint between parts (which is usually convenient, but not always). If we could also make a "weld" between two parts, that would not disconnect, that would have allowed more natural construction of ring structures. Slightly off-topic, the mod QuantumStruts gave a nice variant of the KSP1 struts, which automatically (re)connected upon docking. The same behaviour could be re-imagined as a mechanical (not quantum) mechanism to help us build more rigid space stations.
  6. I believe your expectation is correct. I don't think anything outside the sola system other than stars are bright enough to for human eyes to see in colour. A telescope can collect a lot of light with its big collecting lens or mirror, and send it all through the pupil of an eye, but there is a rule in optics that demagnifying the aperture always comes with magnifying the image by the same factor. So the extra collected light from a nebula is spread over more the human retina, resulting in the same too-weak intensity on each of our colour-sensitive cones. No way to perceive the colour of nebulae with our eyes in real-time; we need long exposures on film or image sensors. The Trapezium part of M42 is near some young bright stars, which I assume are hiding the background starfield in zoomed-in images of those bright stars and nebula. And that silhouette image seems to represent a craft painted a very flat black (or rendered with an inappropriate ambient light setting). The sum of far-away stars does of course produce ambient light in interstellar space (lighting the nebulae, for example). While not having been in interstellar space personally, I would expect a white craft to be look nearly as bright in that ambient light, as a blurred average of the stars in its background. If there was a mirror on the craft, I would see the starfield behind me in that mirror, which on average is as bright as the starfield in the background of the craft. If the mirror is frosted, the starfield is blurred, so I see uniform illumination in the mirror with the same average brightness. If we have white paint instead of a frosted mirror, that paint scatters probably only 80% of the ambient light, so I expect the craft would be a bit dimmer than the average of the starfield in the background.
  7. For each of the mods mentioned in the original post, I know I've seen some version of the mod that will work with any given version of KSP since 1.73. There is also an old thread with discussion on this topic -- after 1.12 was released so recent enough to be relevant.
  8. Felipe Falanghe, who started the game, wrote the main theme. The credits are in the readme.txt: KSP Main Theme: Written by Felipe Falanghe Arranged by Víctor Machado Stratejazz: Written & arranged by Felipe Falanghe Other Tracks: Arcadia, Bathed in the Light, Brittle Rille, Dreamy Flashback, Frost Waltz, Frost Waltz (Alternate), Frozen Star, Groovy Grove, Impact Lento, Wizardtorium Written by Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 Additional Music: Víctor Machado
  9. Yes, the off-by-one bug in the days and years has been there since the manoeuvre editor was introduced.
  10. Well, conceptually the radius of the SOI is related to the central mass, but in the implementation there are separate parameters sphereOfInfluence and gravParameter to express the central mass. (I don't think anyone has set those parameters independently using Kopernicus, so maybe KSP1 computes sphereOfInfluence based on gravParameter behind the scenes.) Someone could program a game to check if a craft is inside an arbitrarily large SoI, and then when it is time to calculate Kepler orbits, apply gravParameter=0, so the potential energy is a flat plateau inside the SoI, and the Kepler orbits degenerate into straight lines in a frame of reference moving with the SoI. Someone else mentioned a harmonic potential, like a linear spring pulling toward the centre of the SoI, so the force gets weaker as you get closer, which also has orbital shapes that you can write out with sines and cosines. I would not guess that either of these SoI solutions would add to the fun of a game. With KSP1 and Principia, I enjoyed trying to get a craft to pseudo-orbit the L4 point, mostly because that pseudo-orbit is so strange. I never considered placing something in an orbit identical to Mun's but 60° advanced and calling that 'L4'. So I agree that Lagrange points require N-body gravitation. Only our craft need to feel gravity from N bodies at once (so the "restricted N-body problem" you referenced). And to play with Lagrange points, and experience other complicated motions around Rask & Rusk, our craft need only feel gravity from N=2 planets at once.
  11. If you want to make them work like aircraft airbrakes, use the orientation your second picture. Actuators don't fail in KSP, but the way that part looks it is easy to imagine the actuator failing, so you might be more comfortable if the airbrakes look like they would retract if they fail. Or, in your case you might prefer them to stay deployed if they fail so might want them in the orientation in your first picture. The orientation makes very little difference in their drag, as implemented in KSP, for this particular part.
  12. The wiki (link) says that the [Option] key serves this role on a Mac keyboard. I can imagine it might be right-Shift (which KSP can distinguishe from left-Shift) if using non-mac keyboard on MacOS
  13. Sorry to see that no-one has recognized the problem yet. Telling us the version of KSP and operating system (Linux, MacOS, etc) might help someone here recognize it. There is a text file "KSP.log" written in the directory where KSP.exe is, and that file might show an error message at the end that. The bug-reporting guide has instructions on where to find another copy of that log file, that sometimes has a few more lines in it : https://forum.kerbalspaceprogram.com/index.php?/topic/83213-stock-support-bug-reporting-guide/
  14. The settings screen does show an apostrophe, with the default settings for an English-language keyboard, but that is a lie. The default key to reset the focus in map mode, is actually ` back quote at the upper left of the keyboard.
  15. There is a suspicious, and very difficult-to-parse, entry in the changelog: * Fix Ap and Pe markers appearing in future patches in space not aligned to current patch rendering when in career games that have yet to have patched conics available. I remember that I depended on switching to map view to see the apoapsis, in order to learn how to get into orbit in KSP. Just to let the OP know, many players here recommend that new players start in "Sandbox" "Science" mode. "Career" mode makes the early game difficult -- and difficult in a not-fun way, when you are still learning the game.
  16. That makes sense to me. The flats could easily be salt flats, left behind from an evaporated ocean. Maybe instead of sodium chloride, the 'salt' could be menthol to fit with some of the EVA reports referencing mint ice cream (or some in-game text; I cannot remember exactly where mint ice-cream was mentioned). There are a few reasonable possibilities, though. The people developing the follow-on game, KSP2, talked about Minmus having been hotter, and the flats being molten and then solidified rock. We talked about the possibilities here (thread link) The one thing that doesn't seem to make sense is simple water ice in the flats, because water-ice evaporates, and Minmus' gravity is to weak to trap the evaporated vapour, so ice flats would not last very long.
  17. Between version 1.8.0 and 1.8.1, KSP stopped protecting separate craft in fairings and cargo bays. Kerbals seated in a command seat inside a cargo bay are protected (as seated Kerbals are not independent craft) and that can be a lightweight solution, if your challenge allows command seats.
  18. KSP1 has the capability for option 3 in the top post, thrust profiles. No stock SRBs use them, but players have written configuration files to do so (link link). The interact in the simplest possible way with the fuel-fraction and thrust-limiter sliders in KSP1. The thrust-limiter reduces thrust by the requested fraction across the whole burn. The fuel-fraction acts as if the booster was loaded with fuel in the same pattern as it has when fuel has burned to that level. The interface is a bit awkward because it works in terms of fuel remaining, so you type the curve in reverse order. I like this profile, similar to picture '3' in the top post, for limiting the g-forces late in the booster phase: @PART[*]:HAS[@MODULE[ModuleEngine*]:HAS[@PROPELLANT[SolidFuel]]] { @MODULE[ModuleEngine*] { %useThrustCurve = true %flameoutBar = 0 %thrustCurve { key = 0.00 0.4 0.0 1.2 key = 0.60 1.0 0.0 0.0 key = 0.98 1.0 0.0 0.0 key = 1.00 0.5 -40 0.0 } } }
  19. RemoteTech (with the delay option enabled) implements signal delay between probes and KSC or the nearest manned "Command Station". RemoteTech does allow the player to control Kerbals in the Command Station or elsewhere, as if by instant telepathic communication. If KSP2 has probes automatically execute maneuver nodes, maybe that could enable signal delay to work with a reasonably simple user interface. We could set/cancel maneuver nodes only a signal-delay or further in the probe's future. But then probes could only land by parachute/aero/lithobraking unless there is a system for programming them. Has anyone used KSP1 RemoteTech's signal-delay option, or seen posts from players who have explained how they get things done using it?
  20. There is a natural place in that gap that KSP2 might have chosen: let the planets and moons feel gravity of the single parent body only, in Kepler orbits 'on rails', but let our craft feel gravity of all nearby(*) celestial bodies. That would seem to let players do the interesting things, like park craft near Lagrange points and play with tidal forces on orbits, without any worries about the orbits of planets being unstable. (*)I suspect the criteria for 'nearby' might be rather strict, maybe only Rask and Rusk, so that satellites in low-Kerbin orbit are not perturbed by the gravity of Mun. Or maybe not. It is not obvious to me whether very weak effects of far away celestial bodies would be interesting or just frustrating.
  21. by default, the Δv indicators in the VAB show the results you would get in atmosphere. The nuclear engine does not work very well in atmosphere. You can press the Δv button and select 'vacuum'.
  22. I was also unable to get that aircraft to take off. Before taking off, an aircraft needs to rotate the nose up a few degrees (unless it already is raised by the landing gear) but the I couldn't do that with the elevators trimmed (alt-X) fully pitch-up. There just isn't enough lever arm to the main landing gear for the elevators lever up the mass of the craft. At 100 m/s (223.604 miles per hour) the wheels start to shimmy. If I move the landing gear forward, closer to the centre of mass, then I have enough lever arm (barely). So probably try more of these adjustments, going further than I did. Sometimes it is nice to rotating the wings up a little (giving them angle of incidence) or rotate the rear stabilisers down, until the centre of lift is right above the centre of mass. CoL behind CoM is good advice for beginners, to make the aircraft stable, but once you know it is stable you can adjust to make it easier to fly. and also real aircraft (wheel-barrowing) .
  23. and you do not need to do that rescue right away. The game KSP made Kerbals perfectly happy to sit in space for long periods of time, so you can + rendezvous to get the 'Science' and leave the Kerbal there, or + repeat the mission with another Kerbal, repairing any mistakes so it succeeds, using quick-saves to re-try as many times as you like, + do different missions to build up Science, until you can build a bigger craft to bring that Kerbal home.
  24. True. Turning the rocket about 45° from vertical on the way up is the only way to survive this tutorial. When you build a rocket in the VAB you have the option to reduce the thrust on a booster, so it burns slower (but usually you want them at full thrust or just use a smaller one). In the tutorial where they built it for you, you do not have that choice. A few other tutorials have bad instructions. I made a list here that I think has all the problems; at leas no-one has corrected me yet
  25. KSP1 provided some helpful options, for people using regular computers, as opposed to gaming PCs. I hope KSP2 does similarly. I use a laptop that I bought in 2016, which is the only time I ever bought any more than the integrated graphics : CPU i7-6500U at 2.5 GHz GPU AMD R7 M360, 2 GB memory and with this I turn most graphics settings down, but keep shadows to help in landings, and use Environmental Visual Enhancements with a simple configuration file to give me clouds to help with situational awareness. This laptop performs better with KSP 1.10 than it did with 1.0, maybe due to streamlining in KSP or maybe in Unity. (For example, KSP 1.0 would often miss key-up events, so if I pressed the key to rotate the view it would oven continue rotating after I released the key. I learned to make extra keypresses as a workaround.) One setting useful to people with slower GPUs and faster CPUs is: Maximum physics delta-time per frame: 0.1 second of Kerbal-time (default is 0.04) It is explained at length here, but I think of it the other way around, 10 fps rather than 0.1 s: "let the GPU go as slow aa 10fps without making the CPU and physics simulation wait on the GPU." My frame-rate drops when the ocean is in view (which doesn't bother me much) but with the default setting, the physics simulation slows (indicated by the yellow clock) which bothers me more. Allowing more time to pass between display-frames keeps the physics smooth even when my GPU struggles. It is also nice to have the option to reduce the resolution in KSP. I use 1900×1080 for work, when I'm slowly poring over details, but don't need that to play a game, so I use 1600×900 for KSP. (Unfortunately, either KSP or Unity or Windows10 intermittently resets the resolution to whatever Windows10 uses, so I try to remember to change the resolution in Windows before starting KSP.)
×
×
  • Create New...