Jump to content

OHara

Members
  • Posts

    1,115
  • Joined

  • Last visited

Everything posted by OHara

  1. I have been flying the first few aircraft I built when I was new to KSP, about a year ago, using the lift curve in the following MM patch. That patch gives roughly the curve here, scaled so that takeoff/landing speeds are 160% that in stock, so it addresses the desire of the OP, and feels more realistic to me. I think I would have been able to handle that, and would have enjoyed it, as a new player. It also require new players to increase their wing-area, takeoff-pitch and/or takeoff-speed. Pulling up to take weight off the nose-wheel are even more important to prevent wheelbarrowing . Landing bounces, and floating past the end of the runway, are less of a problem. There is an interesting interpretation here (maybe just a first-impression) about the strange lift curve in stock, that it compensates for the lack of consideration of the shape of the wing in stock. If that is the reason, the stock lift-curve overdoes it, and we might rather have our glider wings look a little fat, than have space-shuttles float like gliders.
  2. One example is the suggestion from Ferram, whose post there plots a lift curve to substitute for the liftMach curve for wings in Physics.cfg. (For experimental changes, I would scale Ferram's suggested curve down to match the current curve at mach 1, rather than also adjust the base lift as he suggests.) I have been meaning to try this for a while now, expecting it to require some aircraft redesign. I have read complaints about the runway being too short for takeoff, and changing the curve that way might help there as well -- by giving wings designed for trans-sonic aircraft relatively more lift at low speeds. Now, if you want to improve the current flavor of vanilla, and someone says "maybe we can adjust the recipe", you might want to encourage that we try some new recipes, to maybe recommend a better one to the dairy.
  3. So let's put any information, that people might want to avoid knowing, into a spoiler-box
  4. is stable for a perfectly rigid tennis racket. But if the rotation is the tiniest bit off the axis of symmetry, the rotation axis drifts through the body. If the the body is not perfectly rigid, it flexes and loses energy and eventually (after maybe an hour) spins like an axe. The energy E=0.5mv² can go down while conserving momentum because the 'v' is different for different parts of the rotating body. The 19th-century classical mechanics way of working out the details is to use the constant-of-motion angular momentum L = I ω where I is the moment of inertia, and then energy E=0.5 I ω², The moment of inertia depends on which axis the body rotates about, so it can drift to rotating about the axis with the large I, have a slower rotation rate ω, and lower energy E, while keeping the same angular momentum L. There's video of a demonstration in the space shuttle skylab.
  5. Stations that look like wheels are stable in rotation. KerbalX is a nice place to find examples Your picture is helpful. Your station looks a lot like the tennis-racket that @Snark suspected above, with the main engine being the handle. That is not true in general, only for rotation around the axis with the highest 'moment of inertia', that is, the axis that puts the mass as far form the rotation axis as possible, like a wagon wheel rotating on its axis. A tennis racket is stable when rotated as you would if you swing it as if to use it as an axe. Flipping it as a frying pan is quickly unstable, as Snark's link says. Spinning it around its handle is stable for short times only---the tennis racket would have the same momentum but with lower kinetic energy if it could shift its rotation axis to move more like an axe, and as it flexes and loses energy in creaking joints it eventually does rotate like an axe. Assuming you want your station to rotate about the axis of its main engine, try re-arranging so the heavy things are closer to the plane perpendicular to that axis, moving the engine to the center, and moving anything else you can to make it more like a wheel with the center of mass near its center.
  6. These started to appear in 1.2.9, which introduced languages other than English, so I would assume it is a bad interaction between the system for generating the contract text and the system for selecting among the translations of that text in each language. Similar cases have been reported, so there might be a fix coming soon in 1.3.1.
  7. These action groups are missing due to a bug introduced in 1.3 http://bugs.kerbalspaceprogram.com/issues/15410 It can be fixed by removing "displayActions = false" from GameData/Squad/Parts/Resources/MiniDrill/MiniDrill.cfg and similarly for RadialDrill.
  8. The history as I understand it: Suppose you have a rover/probe/lander in a cargo bay. It might flop around in the bay, moving through the walls or even breaking off its attachment point. The obvious solution is to strut it to the bay, letting the struts break when you decouple the rover. However, if you re-dock the rover/probe/lander, the stock game gives no way to recreate the struts. The rover might break off its docking port on the next leg of the journey. Re-dockable craft tend to have wheels or landing legs, so KSP 1.1.1 automatically strutted wheels and legs to the heaviest part. Upon re-docking, the wheels are rigidly attached to the heaviest part of the newly-joined craft. Working around difficulties with the physics of wheels might have been another motivation to implement autostruts. Players at least imagined abusing these autostruts by placing wheels just to get the autostruts. Also, autostruts don't solve re-docking situation where the probe doesn't have wheels/legs. Version 1.2 made auto-struts an option for all parts. If you are even asking whether autostruts are a cheat, I suppose that designing craft that are sufficiently stable is part of the game for you. In that case you'll probably want them only when a massless dragless attachment would be realistic, such as tension lines securing a probe in a cargo bay.
  9. After giving this some thought, I still like the presentation of dashed transfer orbits. It is a graphical representation of what the Astrogator mod shows in its table. Given precise orbits of the starting and destination planets, if we pick a mathematical rule to join those orbits, the math gives a precise transfer orbit. To specify a window of departure times that cost below a certain dV, we need to know the orbits around the starting and target bodies, and where you put a mid-course correction, if any. I can't visualize a simpler interface than alexmoon.github.io/ksp/, and we have nearly that in the TransferWindowPlanner mod. The acceptable-transfer window (for the acceptance criteria I can imagine) is generally not centered on the two-tangent transfer, but it can be visualized using that transfer as a starting point. To reduce journey-time, you start later and arrive earlier. To reduce fuel needs to get to Moho, you wait for the window that puts the plane-change near Kerbin, and depart at the plane change rather than follow the two-tangent transfer so you can do that expensive plane change in the ejection.
  10. Maybe we can show half-ellipse the Hohmann transfer orbit, as an extension of the target-planet's orbit, but in the dashed-line style of an orbital segment after a maneuver. The correct magnitude and direction of V∞ puts us on that trajectory. In the Tracking Station, we could show Hohmann transfers from Kerbin to each other body orbiting the Sun. If a body other than Kerbin has focus, or the craft in focus orbits a different body, we show the Hohmann transfers from that body to the other planets (or if the body is a moon, to the other moons around the same parent). If there is no transfer window within the next orbital period, as is the case for Kerbin to Duna in the image below, we should probably omit that transfer. In the Map View, we would need to zoom out to interplanetary scale to adjust the ejection burn to match the transfer orbit. Having a target transfer orbit, that leaves at the correct time to meet the target, would alleviate my frustration with close-approach markers, which fail to show the close approach until the orbits and inclinations are very closely matched. Probably the transfer orbits should be ellipses, tangent to both starting and destination bodies, with a plane-change bend at the nodal line where the planets' orbital planes meet. These transfers would not be the most fuel-efficient, but give a good starting point from which players can learn to include some plane-correction in the ejection burn.
  11. I don't think they are absolutely required, if you first slow to low Eve orbit, and then cool off before entering. I have been toying with something similar (for no particular reason except to try). Through ample use of the KSP flight-simulator feature (i.e., alt F12, set orbit, revert) I convinced myself that that a light wing-loading space-plane can slow itself from low Eve orbit by pitching up 90° until the speed comes down to 2200m/s. I don't have anything near a complete return vehicle yet, though. I also searched for other's previous attempts and found that Brad Whistance posted a video of a mission very similar to your plans. You might (or might not) want to see what he did for inspiration, and then do it in your own style.
  12. There should be a sub-directory in the directory where KSP is installed, ../saves/your_name/backup/ that has a few recent previous versions of your saves, and one of them might be from before your problems started. Older versions are removed as newer saves are made, but if you move the up to the ../saves/your_name/ directory they will be preserved and you can load them with alt-F9 or mod-F9.
  13. The missing actions are a bug that looks like it is fixed once the next patch comes. You can apply the solution yourself, from the bug report: "It can be fixed by removing "displayActions = false" from config files" which files would be GameData/Squad/Parts/Resources/MiniDrill/MiniDrill.cfg and similarly for RadialDrill. Usually Module Manager is the better way to override configurations, so you keep your customization between game updates, but in this case it makes sense to correct a one-time mistake in the *.cfg files directly.
  14. KSP has an option to make ports dock at discrete rotation-angles, but it is disabled in the stock game. The Module Manager mod is necessary to use it: If you use this patch, you have to align the ports in all three components of rotation (within tolerance) before the ports dock.
  15. Winglets, deployed at 150% in alternating directions, can slow a minimal lander to 400m/s, and full-size parachutes partially deploy at that speed on Duna. We can land on those winglets at 12m/s, whereas early-career landing legs are not stiff enough to protect the engine. Using the reaction wheel (with a pilot or probe-core that has SAS) is important to avoid tipping on the touchdown bounce. One could use the engines just before touchdown, but it is hard to judge distance to the ground when you are new at the game. This lander has enough delta-v to return to Kerbin, using six aero-braking passes to reach the surface. The engineer (or pilot, depending on the rules) needs to repack the chutes after use at Duna. Atmospheric pressure is only 0.07 atmospheres on the surface of Duna, so we do need the 'pressure' slider down to 0.04 atm if we want the parachutes to partially-deploy before their full-deploy altitude. A partial deployment reduces the g-forces on the pilot.
  16. Having a thread for this is a good idea. I am still (since April 2016) playing my first career game, in which I've had Kerbals land and return from every planet and moon except Duna. My Duna probe landed hard, and I seem to have never looked back to Duna.
  17. Stationary? or on the takeoff roll ? (You title did say stationary, but just being sure.) I tried your craft from kerbalx just now. Stationary, in KSP 1.3, with brakes on it remains stationary for me. I notice you set zero friction on the front wheels, which I though maybe would let them slide sideways, but I don't see it slide here. With brakes off it starts to roll (at the expected 1.4km / 600km × 9.8m/s² = 1.4 m/s /minute from the flat runway on small-radius planet) but doesn't seem to slide. On the takeoff roll with no input the wings took the weight off the rear wheels first, leaving just the front wheels pressing down (the 'wheelbarrowing' problem common to nosewheel aircraft if you forget to trim up for takeoff) and that rolling drag near the nose could make the plane unstable in yaw. It was not too bad, though. You might like to add yet another action group binding, to 'deploy' some or all of the canards when gear is down. That will pull weight off the front wheels when you are on the ground.
  18. The code in Kopernicus used a round-to-nearest on the ratio of total-years-to-date-length / day-length, but here you round down. That matters more now that you have an option to show the year change at the nearest whole day. Someone other than OhioBob will likely have more than a one-second error, such as a year 99.999 days long, and the 100th day will be in year-2 because a few seconds wouldn't fit into year 1. Also, both values of 'useLeapYears' use a variable number of days between the first of one year, and the first of the next, so one might think both cases use leap years. I can't think of a better name than 'yearMayChangeDuringDay' For the new option to change year-number on a day-boundary, I would like the mod more if you choose the closest day-boundary:
  19. I thought KSP simulated gravity for each individual part of a craft. That would make it easier to understand the fuel-pumping exploit, http://forum.kerbalspaceprogram.com/index.php?/topic/36949-fuel-transfer-exploits/ and the way orbits are not quite stable when running the full physics simulation http://forum.kerbalspaceprogram.com/index.php?/topic/138506-orbital-decay/ We could try a pendulum satellite and see if it responds to the tidal forces, though probably someone has done that already.
  20. No, MarkusA380 checked for you. He resolved the problem by removing the 1.2-compatible version of Scatterer As far as I know, the sun exploded 7 minutes ago; we'll find out in a minute.
  21. Heat: If you are using version 1.2.2, there is bug #13403 preventing core heat from leaving the drills (which makes them overheat outside of the atmosphere). In case you haven't signed yourself up to read the bugtracker, the fix posted there is to edit GameData/Squad/Parts/Resources/*Drill/*.Drill.cfg to make UseSpecialistBonus = false (being sure to change at least the /final/ of the redundant definitions of UseSpecialistBonus in those files). Given the name UseSpecialistBonus, you might worry that this change would prevent engineers from helping the drilling process, but in fact the change seems to have no side effects. While you are in there, you might want to change AutoShutdown =false, because the drills shutdown upon lack of electricity (not just upon overheating) and require manual restart. (The usual solution to this problem is to switch away from any solar powered drilling operation only during the day.) Throughput: I have also noticed that "Ore rate = 0.13 units/s" is not the current rate of drilling ore; "ore rate" × "load" is the current rate of drilling ore. The "load" is at best 5% in the absence of any engineer, further multiplied by 12% from being away from the optimum temperature in the case you showed us. So you have 0.13 units/s × 0.6% = 0.0008 units/s = 2.8 units/hour from each drill.
  22. On Koperincus' GetDate(), at

     

    // Current Year

    int num1 = (int)(time / Y.value);

      // Current Day
     

    int num5 = (int)(time / D.value) - (int)(Math.Round(Y.value / D.value, 0, MidpointRounding.AwayFromZero) * num1);

    based on the comment just above that code, I would have thought

    int num5 = (int)(time / D.value) - (int) Math.Round(num1 * Y.value / D.value, 0, MidpointRounding.AwayFromZero);

    so that you assume all the years before the current year have had enough leap days to sum to the number of days closest to the last change of astronomical year; then the first day after each astronomical year-change is day 1

    If D = 1000 and Y= 10'400 to have 10.4 solar days in a solar year, then

    time = 105'000   =>   num1 = 10years,  num5 = 105 - 104 = 1days

    ( instead of the current code's  num1 = 10years, num5 = 105 - 10 × 10 = 5days )

    1. Sigma88

      Sigma88

      @OHara you are probably right

      I'll try to bug test this tonight :)

    2. Sigma88

      Sigma88

      actually, it wouldn't be

      num5 = 105 - 10 × 10 = 5days

       

      it would be

      num5 = 105 - 10 × 11 = -5days

       

      so clearly there's something wrong

      I still need to test this more, as of now the results for time 1 would be Year 0 and Day 0

       

      but it should be Year 1 and Day 1 instead

       

      I'm not sure if the +1 gets added later or what (probably yes)

  23. Probably not. If it is 'fixed' by adjusting Kerbin's SMA to make the length of a year exactly 457 days, the position of Kerbin will change when for every save-game that is ported to the KSP version with the fix, messing up encounters on trips to or from Kerbin. The lack of leap-years is not obviously wrong. Some real-world calendars slip from the solar year. If I lived on a planet with no seasons, 0° axial tilt and no eccentricity of the orbit, I would rather let the calendar slip relative to the stars, than have leap days. Better to correct the wiki than change KSP. Kopernicus would make this more obvious, when the home planet has inclination or eccentricity. I see that Sigma88 wrote a GetDate() for Kopernicus that reports the solar year, slipping in a leap day as needed. (Edit: The code comment makes sense, but the code itself seems to increment the number given first day of the year, every leap year, so years start with day 2 for a while, then 3...)
  24. I agree with your math, that neither sidereal nor solar day neatly divides the astronomical year, and your conclusion that they would need leap days to keep the calendar synchronized to the sky. So does : So we expect the Kerbal calendar to drift away from the seasons (if we use a mod to give Kerbin an orbital inclination so we see the seasons) and the rising-time of stars to be different on the same calendar date as the years go by. Neither effect would be obvious in normal use of KSP.
×
×
  • Create New...