OHara

Members
  • Content Count

    539
  • Joined

  • Last visited

Community Reputation

456 Excellent

2 Followers

About OHara

  • Rank
    Junior Rocket Scientist

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I have often found the challenge of making craft structurally stable to be fun. And, I understand why Squad wanted to let KSP simulate failures of rockets and other craft, and why joints of limited strength between ideal rigid bodies is the practical way to simulate that on computers. Players do not like it when their rockets wobble, but a couple well-placed EAS-4 struts fixes that quickly. The new auto-struts can sometimes fix the problem, but they are invisible and sometimes surprise cause players trouble. Since version 1.2, the EAS-4 strut adds zero drag. It is heavy, though, at 50kg. That is not so much compared to the benefit it can give, but it seems more mass than it should have. I think there is a psychological effect discouraging players from using the EAS-4 strut because it adds more mass than it seems it should, especially when there is a mass-less (but less fun) alternative in auto-strutting. If the mass were reduced to 10kg, it would be a bit lighter than it looks like the strut should be, and I think that will reverse the psychological effect, and encourage players to go back to the EAS-4. @PART[strutConnector] { %mass = 0.01 }
  2. We often use the Hitch-hiker and the Mobile Processing Lab turned sideways as parts for bases, and, will continue to do so for at least the several months until KSP-2. In the way we have lander- and rover-variants of the Mk2 lander can, it would be nice to have a variant of each of these parts, in which the internal-view model is rotated to make sense with the cylinder axis laying flat. Some different details on the outer model would be nice as well. Then there are more parts that make sense for base-building, with the Hitchhiker being sleeping quarters and the MPL being working space, to go along with the Mk1 Crew Cabin that I use as a sitting room.
  3. The bug-tracker item with the highest number of up-votes is "1.25-meter inconsistent part widths" and there is also an earlier report "mk1-3 bad compatibility". I could find only a little discussion I could find on this forum, here The Mk1-3 command pod (like the Mk1-2 before it) the 1.25-meter parachutes, the launch-escape system, and the 1.25-meter docking port, have a smaller diameter at their 1.25-meter attachment node than all the other 1.25-meter parts. We can scale the Mk1-3 model to match its attachment nodes, and then it fits the other 1.25-meter parts. This scaling also increases the size of its lower face, meant to fit 2.5-meter parts, but I find the fit there to look fine, because of the rounded bottom of the pod. The pod now extends beyond the matching heat shield, but according to the thermal-debug numbers the heat-shield still catches 98% of the compression heating upon re-entry. (Of course we would want Squad to adjust the taper of the pod so both top and bottom match standard diameters.) I scaled the launch-escape system and parachutes as well; but left the docking port alone because its ring needs to match the other 1.25-meter docking port, and its small flange doesn't look too bad to me. @PART[mk1-3pod] { @MODEL { position = 0, 0.018, 0 scale = 1.07, 1.01, 1.07 } } @PART[LaunchEscapeSystem] { !mesh = delete MODEL { model = Squad/Parts/Utility/launchEscapeSystem/LaunchEscapeSystem position = 0, 0.02, 0 scale = 1.08,1.00,1.08 } } @PART[parachuteLarge] { !mesh = delete MODEL { model = Squad/Parts/Utility/parachuteMk16-XL/model scale = 1.06,1.00,1.06 } } @PART[parachuteDrogue] { !mesh = delete MODEL { model = Squad/Parts/Utility/parachuteMk25/model scale = 1.06,1.00,1.06 } }
  4. The new-with-1.7 maneuver panel does show the phase angle of the craft relative to a target, using the third tab selector. Unfortunately, it shows the phase angle around the body your craft is orbiting (say, Kerbin) not the body that both you and your target are ultimately orbiting (say, the Sun). We could report it bug tracker, if we have an idea of what behavior we want. (Non, on ne peut pas le changer. On peut signaler un bug, si l'on peut expliquer une comportement préferée. )
  5. Maybe you have some trim left over from the flight in atmosphere. Alt-W/A/S/D, or on linux right-shift-WASD, sets trim and alt-X resets it to zero. I'm not sure that it makes sense for the trim to also affects reaction-wheels, but it does, and KSP reaction wheels are quite strong an present by default in all the cockpits. That is just a guess, though. It often helps if you can upload an image of the craft to some hosting site like imgur.com and copy a link to this forum. And, welcome to the forum.
  6. Yes. They are useful relative to rovers for the same reason aircraft are useful where there are no roads. They are slow relative to jets, but in KSP can be solar powered which gives them flexibility that you will probably enjoy. They can be tricky to hold together in flight, so when I made a sufficiently robust plane I put it at <kerbalx>
  7. There is a problem, that the new propeller blades give no lift underwater. Tw1 has reported it as bug 23271. The only solution I know is to use the older aerodynamics surfaces, like elevons, instead of the new propeller blades.
  8. KSP aircraft are heavier in terms of tonnes than the real aircraft they resemble, so need to fly the pattern faster, so need a larger pattern. I suggest putting the downwind leg at least one runway-length away, and using a 500m ASL pattern altitude. The base leg should be just beyond the transition from grassland to low hills west of the runway. The Gull with gear up will fly level at 70m/s on 1/3 throttle. There is a strong interaction between pitch and airspeed, and the Juno engine is slow to respond, so you do need to use pitch to control airspeed. Set the throttle higher or lower than 1/3 depending on where you want to be in altitude in the next 30s. Turning will lose either altitude or airspeed, unless you compensate with throttle. Probably turning downwind you'll still be hunting for pattern altitude, so it will be messy anyway. If you turn to base, and then final, at constant airspeed, the turns will start you on your descent.
  9. KSP uses a reference frame that rotates with the planet, for craft in low orbit (where the EVA report would be "in low orbit") or lower, including on the ground. That means we cannot demonstrate Foucault pendulums in KSP. It is a known issue on the bug tracker at #5234. The software quality department marked it 'not a bug', based on a user's excellent explanation. If we as players have good reason to want KSP to use an inertial reference frame, I think we could reset it to 'yes a bug'. I'm not sure we want to ask for a fix, though, for fear of side effects.
  10. There is good reason to believe that a FAR-like aerodynamics model could be adjusted for game-play balance. Ferram pointed out (here) how KSP chose an unrealistic curve for lift-coefficient-versus-mach#, multiplied by a high pre-factor. This choice allows a KSP aircraft to perform reasonably well through a very wide speed range, whereas in FAR you want different designs for different intended speeds. The higher low-speed lift in stock lets us easily fly small aircraft, despite their heavier weight due largely to the unrealistically heavy engines, that seem to be intended to compensate for the smaller planet. (You can try a more realistic lift-versus-mach, with otherwise stock aerodynamics, with a patch here.) A 3-D-flow approach to aerodynamics would likely simulate lift-coefficient-versus-mach with an empirical curve, and in maybe KSP 2, that curve could be adjusted for game balance like it was for KSP 1.0.5. I would hope that KSP continues to put these curves in configuration files, so we can substitute a realistic curve.
  11. Occluding airflow from anything in the shadow of another part, from the direction of the oncoming air, same as they did for shock heating, does seem an obvious thing to try. Maybe Squad did try this, alongside the connected-face occlusion method that we have now, while working on version 1.0.5 That would avoid the complexities of shielding in closed cargo bays, because anything that fits inside the walls of the 'drag cube' (in fact almost always a rectangular prism) of the enclosing part would be occluded. Many parts now protrude beyond the heat-occluding walls of their 'drag cube' in the part database, so those configurations would need a review, or else players will place parts that look enclosed but are really exposed. Probably lift would need to be occluded as well, or else the mechanism encourages tucking wings behind a bulging forward airframe. Then, as you say, the main wing on a conventional aircraft would sometimes shadow the tail, giving an interesting effect in handling. Occluding everything in a shadow would strongly encourage players to tuck all surface-mounted parts inside the cylinder of the rocket, or especially of the space-plane. One nice thing (for game-play) about the connection-based drag model is that there is no incentive to tweak placement of non-aerodynamic parts for drag; so we're not tempted to tuck parachutes in just a little further; but then again we'd like to get some benefit from tucking batteries fully under a nose-cone. You know that I think (link) that a lot of the weird aspects of the drag model are repairable. If there is a change, maybe you'd like to go all the way to 3D flow around the craft, like the Ferram Aerospace mod. The goal of that mod was realism (somewhat nice for a game) but it ends up presenting the player with reasonably simple rules to get good performance (very nice for a game). Well, area-ruling isn't a simple rule, but it is a physical rule for which we can develop an intuition (as opposed to the rule to stack 1.25-meter parts to avoid big transitions in their diameters as in PartDatabase.cfg.).
  12. Yes, it looks like the lift of the new props goes to zero under water. I suspect Squad will be reviewing the lift physics these props, because it is too easy to make a perpetual motion machine with them. But I also suspect they won't include underwater lift unless one of us puts a bug report on their tracker with at least a craft file, better with a savefile. Quite soon after the BG motors were available, people made props including submarines (link) using the old control surfaces, which do work as propellers under water.
  13. It looks like the helicopter blades are responding to the roll control. By default they do move in response to pitch/yaw/roll, in the same way as the ailerons from the main game, except that their roll response is reversed (bug #23244). When the blades are put on a rotor, the pitch/yaw/roll deflections that would work on a craft moving forward are not often effective in hover. For your craft, it looks like the roll response is effective, but in the wrong direction. You might want to turn off the roll response on the helicopter blades. Or,if your coal is to control the craft in hover using aero-forces only, with no reaction wheels, try it without SAS and use reverse roll-control by hand.
  14. Brikoleur made a few, before stock prop-blades, on kerbalx Snark made a hybrid, on the general-purpose thread
  15. Another thread on this topic referenced a magazine article "Bernoulli or Newton, who's really responsible for lift?". The author could not have meant his title to be taken literally, given that birds and gliders predated Newton. From the use of those names in the article, it seems that author used 'Newton' to represent the cause of higher pressure on the lower wing surface, and 'Bernoulli' to mean the cause of low pressure above. It seems he was imagining the reaction force of individual packets of air to be the 'Newton' mechanism, and the higher speed of air above the wing to be 'Bernoulli'. Bernoulli's principle is usually derived from Newton's laws, applied to air as a fluid. The tricky part of the Bernoulli result is handling the net effect of all the packets of air pushing on each other and accelerating each other based on Newton's laws. So you might say Newton + Air-Air-collisions = Bernoulli. The article quotes examples from the Air and Space Museum expert, on how the pressure decrease above the wing is the larger numerical force. From this I would conclude "the air pressing on other air is a big deal". The magazine-article author, and pilot, chose a catchier conclusion "So much for the 'kite' effect, or Newtonian lift. Bernoulli wins". That is a maybe little unfair to Newton, and not very helpful for understanding. The reason the air sped up over the wing was the ambient pressure pushing it into the space the wing has cleared for it, that ambient pressure accelerating the air per Newton's law. And, the low pressure is allowing the ambient pressure to accelerate more air from above into the low-pressure zone, where it will join the down-wash behind the wing, part of the grand conspiracy of Nature to act according to the pattern expressed in Newton's third law. That would be 100 kPa = 10 tonnes-force per square meter. That does make the point that air is pushing on us surprisingly hard. Aircraft only get 500 kg-force/m² from their wings, with the upper surface pressure only reduced 5% or so. High-altitude aircraft work at lower pressure. The SR-71 seems to get 400 kg-force/m² = 4 kPa up where the air pressure is about 4kPa. That would seem to be a concrete example, but you might argue if that is flying like a wing, or more like kite; they call that airplane 'the sled' Hydrofoils get more lift per square meter because the density of water is higher. If the pressure above the foil goes to zero (or actually to the vapor pressure, small compared to 1atm) you get cavitation and the water separates from the foil. Usually this is uneven and causes turbulence and drag, but if the craft can thrust through that drag, the flow can separate from the entire upper surface of the foil, and have nearly a vacuum over its upper surface.