Jump to content

ferram4

Members
  • Posts

    3,132
  • Joined

  • Last visited

Everything posted by ferram4

  1. @jrandom: KJR doesn't use node size in the joint calculations. Stop thinking that it does. It uses the part diameter as a whole. There should be no issue with KJR.
  2. @jcd: Perhaps, but since you've got some ugly biplane stuff going on there, I don't know for sure; the delta wings might be interfering with each other enough that the control surfaces at the back are making a significant portion of the lift. Perhaps you should make it a monoplane and then see what happens. @Donziboy2: It has a help function, which is the button with a question mark. Read through that; it should help.
  3. [YELLING]The Kerbal Isp Difficulty Scaler (see sig) also uses it.[/YELLING] Don't worry about that one. I forgot to mention that it shifted to using the Toolbar Plugin when I initially updated it for KSP 0.23.
  4. Try shifting the horizontal tail back a smidge. The thing is, you should focus less on the CoL and more on the static analysis GUI, since that will give you a lot more data about how stable the craft is than that single indicator.
  5. I think you're too used to how suddenly drag slows you down when you come of the throttle in stock KSP. The stock drag is about 2-5 times as high as it should be, and you need to account for this. Stop being overly aggressive during your landings and take the time to slow down.
  6. Okay, I think I figured out the negative drag issue. It was an attempt of mine to get around the closed drag of intakes being too high; that will be fixed shortly after I look into some other bugfixes and tweaks.
  7. Did you copy over the 000_Toolbar folder? Is KSP in a folder where it has proper permissions?
  8. You should be landing at ~70 m/s. Take the plane in on a shallow glide slope, ~3-5 degrees. Keep the angle of attack low, you don't need as high angle of attack as you're used to. Smaller control inputs, not big sudden movements. Don't start off flying planes with canards, the canards stall easily during landing. Use traditional tail designs for pitch control.
  9. I was unable to reproduce the issue of negative drag, with or without Firespitter. I need more detailed reproduction instructions, since I'm just not seeing it happen anywhere.
  10. @Bugger burger: If you're using the new biplane wings, those aren't affected by FAR; Snjo is using his own special type of lifting module for that, so you'll have to bring it up in the Firespitter thread. @Sirius: That's intentional. How are you supposed to determine the stability of your rocket if the CoL doesn't tell you where lift will be produced in a given direction when you pitch up? Also, why are you putting fins where they will destabilize your rocket?
  11. Yeah, I did, when I was going through and setting up the new way that people can manually specify what part title indicates a cargo bay / payload fairing. The titles can now be specified in the config.xml, but there's no special handling for procedural fairings anymore.
  12. @NathanKell: I think that the wings won't by considered to be inside the fairing in that configuration, since they poke out of the fairing. pFairings are handled the same way as any other fairing, and aren't given special consideration based on their module, so you could handle that by simply renaming the part title. @Bugger burger: Well, you're showing me a NaN error, but FAR isn't capable of causing one of those; it throws the forces out if they're equal to NaN. Could you post a copy of the output_log so we can see what's going on? I highly suspect something else is to blame here.
  13. And there's a version 0.12.2 out to fix a sign error in the sweep code that would push the CoL in the wrong direction. It was particularly noticeable with pWings, and has now been fixed.
  14. Nope, that looks like a FAR error (another one). Fix should be up in the FAR thread momentarily.
  15. Is the log getting spammed with density readings? If so, re-download; I ended up leaving in my density debugging line initially.
  16. It's FAR; version 0.12.1 is out that fixes the issue. Go download it and the decoupler issues will disappear.
  17. Version 0.12.1 is out, and the bug is squashed. Basically what was happening was that I was using the vessel's altitude to determine what the atmospheric density was, but that is apparently set to 0 for the first physics frame that it exists. So every part was getting smacked with sea-level atmospheric density on decoupling. Mea culpa. I should have done more testing; that level of game breaking shouldn't have gotten through. Sorry for that guys.
  18. Yeah, I'm aware of this. Turns out that vessels are set up to have an altitude of 0 when they're first created, which leads to FAR picking the density at sea level every time you decouple things. I'm working on a fix right now, should be out in ~10-15 mins.
  19. I just managed to cause it without KJR installed. It's actually a FAR bug... argh.
  20. Would it be possible for the toolbar position to be unlocked by default? Or to have an obvious lock-unlock icon visible on it somewhere? A lot of new users seem to be confused by the fact that the position is locked by default.
  21. Click on the arrow on the side of the toolbar; that will open a dropdown menu that will allow you to unlock its position. Then move it all over the place.
  22. @nullreference: At what altitude and angle of attack? I've not seen this happen at all in my tests, and frankly, it sounds like something else is causing the issue. @jrandom: Nope, as a result of changes to the way the editor Lock function works. You'll have to stick to v0.11 for KSP 0.22.
  23. Well... I'm unemployed, so I don't have work to take off from. Bright side is that I can get all of this stuff put together in all the free time I have.
×
×
  • Create New...