Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by OHara

  1. I am pretty sure they are no longer used ---unless you go into the debug menu and select the old drag model. (If you are curious, and want to check, you could temporarily edit a cfg file to increase each by 100× and see if it changes anything in game.)
  2. A head-wind can often help takeoff and landing, on a short airstrip and on a soft grass field. Landing a spaceplane on KSPs Duna is quite difficult because of the bumpy ground and high landing speed. If Duna had a regular cycle of periodic high winds, that might enable some spaceplane missions (that today depend on extensive use of the quicksave). Physical effects of weather would make the game interesting, although I'm not sure if that would be interesting in a fun way or in a frustrating way. Different kinds of weather have been suggested for KSP2 L L L L L L
  3. Yes. I was thinking that if a player leaves the thrust on a craft and then switches to other craft, the time-acceleration would be limited by the craft-under-thrust in the highest local gravity. Given the relatively easy integration, I didn't think the time-acceleration limit would occur very often, and the slow-down would be signalling something the player should know about. Even at 10-million times acceleration, with a 30fps update for physics, an update is 4 days simulated time. The Voyager probe doesn't see much change in accelerate during that time, but if you had an ion craft spiralling out of low-earth orbit it would need maybe 1-minute steps, so time-acceleration limited to 1000× while the probe raises its orbit Probably better, as you say, to let the integration routine use an adaptive step-size, but choose step size internally, presenting an interface that asks for the initial state, the force function, time to which to integrate, and an error limit. That is how Numerical Recipes wrote their ODE integrators in the 1980s, though it was awkward in Fortran77 without function pointers. Letting each craft or colony update itself to the next time-frame to be presented to the player, keeps the detail of choosing integration time-step local. Those integration time-steps look pretty quick, with under 30 floating point operations to figure the 3D force. KSP2 might choose to disallow thrusting on craft not attended by the player, if it turns out to be frustrating when players forget they left a craft thrusting. That might prevent micro-g thrusters being practical in the game, but is it not obvious we really want those. Finding SOI changes does require iteration, because you are looking for closest approach between two bodies, craft and planet, each taking curved paths under central gravity. Unattended thrust doesn't make that any harder, but even in KSP1 without thrust you sometimes miss an encounter on craft in some tight orbit, while at maximum time-warp. That does seem to force a choice between (1) computing every craft's trajectory carefully enough to catch any SOI encounter, sometimes limiting time-acceleration (like the yellow clock in KSP1 when physics/GPU cannot keep up) or allowing an SOI encounter with Mun to be missed while watching a craft go to nearStar. Either would be fine with me.
  4. I am optimistic that faster time-warp could be practical because... The acceleration of a craft under constant thrust, using the SOI approximation for gravity, is fairly smooth when far from the gravitational body x'' = µ/(xcraft − xbody)² − T/m and we know ahead of time when we need to take smaller integration steps---when the craft is close to the body---and have one reasonable method from KSP1 of limiting time-warp speed when closer to the body. Now, KSP1 does not have thrust during on-rails time warp, but still limits time-warp at low altitude. I think the reason was so it could stop time-warp before we enter the atmosphere or hit a mountain (which doesn't always work). But, the projected trajectory in Kepler form r = SMA (1−e²) / {1 + e cos f } could have made it easy to project when the orbit we will cross any critical altitude 'r' such as the atmosphere or highest mountain. One arc-cosine gives the 'true anomaly' f, and the two more trigonometry functions and a forward application of Kepler's equation gives the time we are projected to cross the critical altitude, so we know ahead of time when to slow the time-acceleration. KSP1 seemed not to use altitudes, but instead 3D geometry to find intersections, and I think that historical accident is why we sometimes time-warp through an entry to Eve's atmosphere. KSP2 would need to convert from position and momentum to the projected Keplerian orbit to show the projected trajectory, and check for encounters with other SOIs, but that need be done once per display-frame, so no increase the computational load at higher time acceleration. Not all easy, but it seems feasible to me, and worth it for a game about orbital mechanics.
  5. I took a guess at the answer to the question of the title, and imagine that KSP2's time-warp mechanism need not be much different to KSP1's. For context, Earth's orbital radius (SMA) is 145 Gm and period is 32 Ms (a.k.a. one year) Jupiter's orbital SMA is 780 Gm and period 105 Ms. The nearest star Proxima Centauri is 40'000'000 Gm from the sun, but its nearest neighbour is 2'000'000 Gm away, and that neighbour is the binary Alpha Centauri, two stars 3500 Gm apart. Kerbin orbits 14 Gm from its sun with period 9 Ms. Jool orbits 67 Gm away, with period 105 Ms (One Jool orbit takes 1050 s player-time at maximum KSP1 time-warp. A Hohmann transfer from the inner planets takes about 1/3 the time of an orbit, so 6 minutes(!) player-time, but going to Jool is a big event. Folks using Outer Planets Mod probably use Better Time Warp and its 'Hyper Warp' option to accelerate time by 107 when needed; this works fine for my on my laptop because KSP1 uses the sphere-of-influence approximation and can compute positions from Kepler-orbit formulas at each screen-update.) So I guess there might be a 'nearStar' at 1'000'000 Gm (1 peta-meter if you know that prefix) from Kerbol. KSP uses engines with reaction mass (no warp drive) and I can imagine the players might accept a speculative nuclear engine with magnetic-confinement nozzle producing 1000 km/s exhaust velocity (Isp = 102'000 s×g). Delta-V = 1000  km/s × ln(10) = 2300 km/s, if 90% of the ship is fuel at departure. Using half the delta-V to accelerate (ignoring the minor ~5 km/s to escape Kerbol) and half for arrival, the velocity is 1150 km/s = 1150 Gm/Ms (=0.4% c) for most of the trip. So I'm guessing it would take about 870 Ms to get to nearStar. Time acceleration at 10 Ms per 1 s player-time (KSP1-BetterTimeWarp's fastest setting) would make the trip take 90 seconds. I think it is feasible to simulate craft under thrust at that rate, because each accelerating ship is a 1-body problem in 3-D space under a constant thrust plus gravity from a single celestial body (compare to Principia handling the n-body problem with n² interactions between the n=16 celestial bodies). I would not expect engines to give anything close to 1-g acceleration. Speculative engines based on known principles would be limited to delta-V that makes the trip take a few years anyway. In my guessed example, we could use 50 Ms on either end of the journey to accelerate/decelerate at 0.02 m/s².
  6. This is the key of what surprised me. Aerodynamic forces really depend only on the velocity of the craft relative to the air. (Now, pilots tend to believe that speed relative to the ground matters, and that wind is a separate force, due I think to intuition gained from experience on the ground. Part of pilot training is to recognize the error of "the myth of the downwind turn" which claims that an airplane taking off upwind will loose airspeed due to wind upon turning downwind; in fact, pilots see the ground and in such a turn the pilots often subconsciously reduce their airspeed.) I realise that the point of the mod is the weather simulation, not adjusting KSP's craft-physics. But I can read C# and having your description of the intent maybe I will be able to suggest a realism-boosting simplification on the github.
  7. The delta-v in the case where you rotate the velocity keeping constant speed, is just the length of that arc. follow : Δv = 2 v sin(Δi/2) follow : Δv = v Δi (×π/180° if Δi has units of degrees)
  8. The formula you used is correct for an instantaneous burn to go directly from the first velocity to the second. Principia computes the burn assuming you rotate the craft as the prograde/normal/binormal coordinates rotate. Principia rotates the instantaneous velocity of the craft through part of a circle, and that requires more delta-V (in this case, π/2× rather than √2× the orbital velocity). @jd284 figured this out recently in the Principia thread (despite some confused and incorrect arguments given there)
  9. In stock KSP1, jet engines work only on Kerbin and Laythe; no oxygen for air-breathing engines at stock KSP's Eve or Duna or Jool
  10. This, or a very similar glitch of KSP1's drag model, came to light here:
  11. 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
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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?
  21. 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.
  22. 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.)
  23. 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 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) − Cargo bays no longer protect separate craft, affecting some rescue missions and some pre-robotics propeller craft 1.10 + Comets + Corrected drag from several Engines and the M.H. Structural Tubes − Fuel transfer often fails due to a UI glitch (fixed in 1.11.1 I think) − Mining asteroids adds mass to the craft without removing any from the asteroid 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
  24. 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)
  • Create New...