Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    Oh come on. It's STILL not fixed?! All this work to deal with part clipping. You know what, I'll see if I can force an update right after everything loads. Maybe that'll fix it.
  2. ferram4
    @locustgate: Can't reproduce lack of splash, can reproduce sinking Kerbals, but only if they ragdoll. Dev build on github has a fix until I package it up to release. @7499275: Why not test it and find out?
  3. ferram4
    If it's moving above 10 m/s at splashdown, in any direction, there's an effect. If slower, there isn't.
  4. ferram4
    As mentioned on the previous page, there is a dev build that should fix the issue; try it out. Unless I get some confirmation that it works, I'm not gonna push it as a full release.
  5. ferram4
    @Cephalos: KJR does not affect TimeWarp in any way; I'd suggest you check your other mods to find the issue.
  6. ferram4
    And have you tried the dev build?
  7. ferram4
    @karamazovnew: Known issue, fixed in dev build. @Camacha: FAR applies drag regardless of that flag's setting. Reason? The 3.75m decoupler is physicsless, and FAR needs to apply drag to it for decoupled 3.75m stages to make the proper amount of drag.
  8. ferram4
    @S4qFBxkFFg: That is why you should post the entire log, not a snippet. Snippets ultimately just hide useful information.
  9. ferram4
    I'll address the narrowing things down: you do not want to do that. Most modders host their stuff on multiple sites just in case one goes down. Limiting the number of sites basically means that if one goes down for whatever reason, the mod is unavailable. As for the number of sites, 5 isn't really that bad. Most of us do get along. I'm not sure where your complaint is.
  10. ferram4
    @nigelxw: Obviously, they're very draggy and dense enough to be pushed far into the water. @smjjames: Conditions are that the part is in the water and is moving at least 10 m/s. Your craft's current accelerations have nothing to do with it, so quoting those doesn't give me anything to go on; I need m/s, not m/s2.
  11. ferram4
    I believe the current dev build (dll from the github repo, not releases) should fix most of the issues people have reported. Try it out, and if it works, I'll push it as KJR 3.0.2.
  12. ferram4
    Oh, I must have missed it. Well, yeah, it's gonna be really draggy. If you try to set the nodes tiny, they'll be ultra-flexible connections without KJR.
  13. ferram4
    @karamazovnew: There are no errors there. I gather that the log is still truncated. @smjjames: You don't, it's flight only and will remain that way. @bdito: No, that's supposed to happen. If that was really as effective as you think, there would never be any need for a full heavy fairing. Attaching the nose cone does slightly help with the drag, but you've still got those great big dishes that you're doing nothing about.
  14. ferram4
    @karamazovnew: I think that providing the full log, with the stack trace would go a long way to finding the problem, if it is on my end. Never truncate logs. Ever. It leaves out valuable information and you don't help anyone in the process.
  15. ferram4
    Camber isn't really the best idea. There are a few problems with it: Any wing that needs to have multiple parts on the chordwise direction isn't going to get process right, and it'll look like there are a bunch of waves on the surface of the wing. FAR won't simulate single-part-camber right. Not much point, to be honest, since camber only adds lift at subsonic speeds; above Mach 1, all lift effects can be resolved from angle of attack changes. Yes, even control surface deflections work this way. All camber is good for at those speeds is adding more drag. Trying to hack it into FAR by hiding it as a change in wing AoA will cause lots of interaction issues between wings, don't do it. Yeah, this is one of those suggestions that's constantly brought up. There are reasons FAR doesn't bother with it.
  16. ferram4
    @HoneyFox: It should be automatically called in the function that pWings calls when it's cleaning everything up. If it isn't, it should be. @JoseEduardo: Not yet, unfortunately. I have an idea (actually, many ideas) of how to simplify it, but I haven't implemented it yet. @Molot: No, then people complain that they got a warning (see the CompatibilityChecker sabotage from a few months ago). Or they try to get support anyway. Or they go around blaming FAR for win64 issues, and suddenly I've got all these erroneous support requests from all corners burying the ones that I can fix. Win64 isn't worth it. It's such a mess that I think the only reason they keep releasing it every update (as it becomes more and more broken and unusable) is that Squad wants to avoid the PR disaster of having to announce it was a bad idea.
  17. ferram4
    @HoneyFox: No, TriggerPartColliderUpdate() is a method that is used to force the list of colliders that each FAR module uses internally to update. It won't do anything to the part itself. @Sandworm: What's happening is KSP is trying to load a part module that was previously applied, and discovered it doesn't exist in the config file. That's because FAR adds the modules programmatically, not through configs. This is expected behavior, and it is not the cause of your issue, if you even have one. Don't like it? Yell at Squad to give me the option to not save PartModule data, because currently, I can't prevent it and clean up the logspam. @smjjames: Has nothing to do with how anything behaves. That is an expected error, that does not affect gameplay, because KSP does not consider dynamically adding PartModules. @AngelLestat: I am not compromising FAR's focus on realism to balance for Kerbin's tiny scale. Nope, sorry, that's not what this project is about. There are already a few options to change a few very minor factors that are highly empirical, but I am not adding a finagle factor into equations because realistic aerodynamics doesn't feel right to you. FAR is about realistic aerodynamics, and it will stay that way. Other projects may choose to do that, but not this one.
  18. ferram4
    It already provides that. pWings already calls that, it just doesn't call it at the end of everything. It may make more sense to do the scaling in OnLoad, since that must always run before Start.
  19. ferram4
    They're already pretty close to real-life numbers. If there are any changes, they would likely be included in the MM configs bundled with RSS.
  20. ferram4
    And you have also replaced the old FerramAerospaceResearch.cfg with the one from the repo? In any case, that sounds correct; inlets have always had drag areas near that value, but previously their area was based on the inlet area the game used. Now it is based on the actual part size, but the drag coefficient is based on the inlet area. This sounds like expected behavior.
  21. ferram4
    Before Start() is called for the FARWingAerodynamicModel. Later than that means that FAR isn't going to get interactions right.
  22. ferram4
    @camlost: For the control surface itself? Meaning, the wing is at 0 AoA, the control surface deflects to 15 AoA, and it's stalling? If that's the case, it's an issue of the wings not having their colliders set up early enough; ultimately, nothing I can do. @kmacku: Mw wrong means that it's pitch unstable; for your test case, the CoL is in front of the CoM. Yß wrong means that it's yaw unstable; you require more vertical tail. Lß wrong means it's roll unstable; attach the wing higher up / add more backward sweep / add additional dihedral. Also, testing at Mach 1 is a terrible idea. Most planes behave terribly at Mach 1 and you never spend much time there. Check above an below it, but right near it is a regime you'll not spend much time in. @bukschr: Either improper install, in which case the game should have yelled at you, or you're on the win64 build of KSP, which is not supported (and which FAR disables itself on) due to the build's many inherent bugs and instabilities. If you are using the win64 build, then either switch to win32, Linux64, or decide not to use FAR.
  23. ferram4
    Depends. It depends on whether the vehicle is very draggy or very aerodynamic. It depends on whether you have Deadly Reentry installed or not. It depends on what your excess hyperbolic velocity is. It depends on how circular you want the resulting orbit to be. Even in stock your question lacks sufficient data to answer it. With FAR, there's no way to provide a satisfactory answer, besides ones that are blindingly obvious and unhelpful.
  24. ferram4
    Try the dev build, see if that fixes it. If not, I'll look into it further.
  25. ferram4
    @camlost: Define "early." If it stays unstalled until it's above 25 degrees of deflection from the airstream, it's not early. @Wanderfound: If you're gonna do that, nerf the turbojet even more. There's no reason for it to go past Mach 3 if you're gonna produce something else that can do better. @Northstar1989: I offered it to them (through Ted) on IRC twice; once quite some time ago, and again shortly after they announced they were overhauling aero. I have heard nothing from them. Come to your own conclusions from that.
×
×
  • Create New...