Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    This isn't a FAR-caused issue; this is an issue that happens anytime in KSP when you have insufficiently secured boosters. What's happening is that your parallel stages are flexing at the radial decoupler under thrust, and are not simply flexing inwards; they are also flexing such that each booster's thrust produces a slight rolling moment. Likely what happened was you redesigned your asparagus-staged rocket for use with FAR and weren't as liberal with the struts as you were in previous designs or you struted the boosters in such a way that they were more prone to flex in one way than another. Another possibility is that you used fins for roll control in the atmosphere, and now that you're out of the atmosphere you don't have any roll control. Short answer is, no, it's not FAR; your design flexing at the joints is what's causing that. If you put it in space in stock KSP it would do the same thing.
  2. ferram4
    @nothke: That looks about right for a bow shock in Mach ~1.4 flow; try to make the shock tend towards the Mach angle as it heads away from the craft, and make it a little tighter around the object. As an idea of what you should be going for: Bullet shadowgraph, Mach ~1.5 Apollo capsule CFD simulation, 14 degree AoA, Mach 4.9 Mercury capsule shadowgraph, Mach ~3 What you have is a good starting point, but it needs a little bit of tweaking; perhaps an animation that is set to vary with Mach number could be used for this?
  3. ferram4
    Atmosphere scale height is how quickly density falls off with altitude, using the formula: density = SL_density * e-alt / scaleHeight Where: SL_density is 1.225 kg / m3 and scaleHeight is 7.5km for Earth. Unfortunately, the game cuts everything off when the ship is above maxAtmosphereAltitude or when e-alt / scaleHeight is less than 10-6. If you try increasing scale height, you'll just increase the altitudes that you hit the same atmospheric densities at.
  4. ferram4
    @sparker: And let me guess, the attach nodes are much smaller than on the stock parts, right? FAR uses attach nodes to help determine drag, and when they are set wrong the calculations are often off. If that's not it, then the origin of the part might be placed in the wrong place, causing things to screw up. Basically, when mod authors make parts that aren't set up completely, bad things happen. @Dragon01: I'll look into that. It's probably just mod parts designed to different guidelines.
  5. ferram4
    Reference area is approximately the total surface area; it makes handling skin friction drag easier. Also Cd = 1 only happens in incompressible flow; as Mach number increases, the Cd for that heads towards 1.86, most of the change happening near Mach 1.
  6. ferram4
    Attach node size doesn't change anything in terms of connection strength or stiffness, only the proximity needed to attach two parts to each other in the editor. That said, the way to change the size is to look at the attach node definitions; there should be either 6 or 7 numbers there. The 7th number (which defaults to 1 if it is not listed) controls the size of the attach node.
  7. ferram4
    I figured it was something like that. I can look into making it ignore the parachute shape itself, which should fix the issue.
  8. ferram4
    Procedural fairings are your friend.
  9. ferram4
    Yes. It supports most mods by default, unless they use wing parts. However, if a mod advertises that it has FAR compatibility and it has wing parts, the wings will work properly.
  10. ferram4
    Let me guess, since you're using the Realism Overhaul, you're connecting it to a stretchy tank, correct? That's actually an issue with stretchy tanks, where the attach node (which KJR uses to place the attach joint) isn't set unless the part shape changes. Since it never changes in flight, that means that the attach node is placed at the default position, which generally ends up deep inside the tank; that extra distance allows for more flexing. Whenever NathanKell gets the new stretchy tanks version out that should be fixed.
  11. ferram4
    A drag coefficient of ~0.002 is for very, very low skin friction drag only, with no significant pressure effects. A drag coefficient much higher than that would include pressure effects, like shockwaves, air being compressed, pressure much lower than the ambient, etc. Odds are that if your DRE shield isn't making enough drag that the fairing is somehow picking it up by mistake... try putting some extra space between the fairing and the shield and see if that changes things.
  12. ferram4
    Ah. I didn't include the large SAS in my list of attach node fixes; basically, FAR thinks it's a narrower part than it is for attach node purposes. Add this to the end of your ferramaerospaceresearch.cfg file in the FerramAerospaceResearch folder and everything should be fixed: @PART[advSasModule] { @node_stack_top = 0, 0.1990267, 0, 0.0, 1.0, 0.0, 2 @node_stack_bottom = 0, -0.1990267, 0, 0.0, 1.0, 0.0, 2 }
  13. ferram4
    Sure, I'd be up for using this; I've been thinking about rewriting FAR's GUI thingy anyway. Would it be possible to have a version of this that would work in the SPH + VAB as well? I gather the best way for us to interface with it would be to include the dll as a reference in the project and work from there, correct? I assume that you'd plan for distribution to be handled like ModuleManager, where every plugin using it includes it in the GameData folder, with the most recent version available in your release thread, correct? It looks good; count me in!
  14. ferram4
    There's another issue; you're assuming that Isp changes linearly with atmospheric pressure, when it actually follows a Bezier Curve that has slopes of 0 at vacuum and one atmosphere. It's a small error, but it might account for the problem.
  15. ferram4
    Like this: You need to place the mass of the capsule offset by a little bit to make it work. The best way to do this is to add something like this to your a config file for ModuleManager to pick up: @PART[Mark1-2Pod] { CoMOffset = 0, 0, 0.1 } Of course, now you have an unbalanced pod, so you need to counterbalance the service module or it will cartwheel in space.
  16. ferram4
    Depending on the rocket, I've seen it range from 400 m/s to 900 m/s; that readout's not perfectly accurate, since it's based on the current drag coefficient, and drag coefficient is a function of Mach number, and Mach number is a function of velocity, but it becomes more accurate the closer you get to terminal V. Yes, it does seem ridiculous compared to stock, but think about it, would you really expect a fully fueled rocket to be limited to only 335 mph by drag if it was at airplane cruise altitude? Because that's what 150 m/s at 10 km works out to.
  17. ferram4
    Delta V is somewhere between 3000 - 3500 m/s, depending on what you're launching; more aerodynamic payloads tend to be less due to lowered drag and better ascent profiles. There's a terminal velocity readout in the Flight Data GUI, but you'll have lots of stability issues if you actually try to increase your velocity meet those numbers, so don't bother.
  18. ferram4
    Alright, I've been messing with things and I think I might be making some progress on reducing the effects of the physics jerk on load. Could anyone provide good, solid reproduction steps for the "crashing into phantom launchpads while in orbit during physics initialization" issue? I want to have a perfect reproduction case for testing, and I've only suffered this issue twice (and both while in solar orbit with RSS).
  19. ferram4
    There are two problems here; one is with Stretchy Tanks, which NathanKell is working on fixing (it should also fix some of the wobbliness, particularly with KJR, since it would also involve the node positions). The second is that the procedural interstage has the wrong size attach nodes, and will need to have them resized in the same way as the stretchy tank one. A quick way to fix it is to resize the attach nodes to be equal to part RoundUp(diameter / 1.25) for stock KSP or RoundUp(diameter) for RSS + RO. Should be easy to fix with the interstage by making a few copies of it at the proper sizes with the correct node sizes; the part data itself doesn't seem to cost too much in terms of RAM, so that shouldn't cause any issues. I'm not happy about it either to be honest. I worked out the attach node drag system back before stretchy tanks existed, so I hadn't planned for this. I think I might know a way to get away from it, but I'll have to do a lot of testing to make it work, since it could fail in really nasty ways depending on the part mesh.
  20. ferram4
    Would it be possible to add some type of quick "flying in atmosphere" type of experiments for Eve-Venus, of an early Venera descent probe variety? That would add a lot of science benefit to sending a descent probe there and add a nice reward for actually handling a serious reentry on another planet.
  21. ferram4
    I suspect that this issue is the result of physics initialization being wonky. I'm going to look into scaling the joint stiffness up from zero during physics load, with a corresponding scaling of gravity from 0 to whatever it should be at that time if it's landed or on the pad. Hopefully that will fix the issue when combined with throwing part strengths and crash tolerances through the roof for the duration of the "easing." It's probably related to the way that ships have a g-force jump when coming out of warp.
  22. ferram4
    The discrepancy between what Andrew Hansen did and what everyone else is doing has to do with where stock KSP measures the velocity of the wings. It calculates the velocity of the wings at the wing root (attach point) rather than halfway down the span. This means that Andrew Hansen's design has the wings essentially "not moving" for aerodynamics purposes. If simple beams were used to push the wings further from the axis of rotation it would take off fine.
  23. ferram4
    I want to see a video of this. Either there is something wrong with your FAR install, or you're running into a bug in the physics simulation that I can't fix. There are only two forces applied to a wing by FAR: lift and drag. Drag is in the direction opposite of movement, while lift is applied completely perpendicular to movement, which by definition can't increase the magnitude of the wing's velocity. Based on that, the wing must lose energy. Go into the B9 files, find the HW21 wing and remove the winglet parameters from it. Then try again and see if the error persists. Edit: You're certain that you're using control surfaces that are FAR-compatible, correct? If they aren't, then infiniglide will still be caused by those surfaces.
  24. ferram4
    Perhaps it's not stable enough in yaw? Try adding a larger vertical tail further back and see if that helps. Your design doesn't look particularly stable in yaw. How does this behavior start? What are the forces on each of the wings (you can check by right-clicking)? What I meant was that someone recently posted about an issue where very tiny control surfaces attached to very large wings caused some lift / drag issues, in a similar situation to what you have going on. That's why I asked about the uneven control surfaces, since I think that might cause enough of a difference for weird things to happen.
  25. ferram4
    Is it supposed to have one control surface missing on one side? I think the problem might be related to the issue with the B9 huge wings + control surface, where the code freaks out with tiny flaps attached to large wings.
×
×
  • Create New...