Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    @ayana: I'll need a copy of the output_log.txt then. I haven't seen this issue in my game, what other mods are you running? @brusura: Oh, your ship is using the RAPIER. Yeah, those got nerfed back to where the turbojet is now. There was no reason to ever use the turbojet over the RAPIER, so I toned down the RAPIER to compensate.
  2. ferram4
    @brusura: Upgraded from FAR v0.12.5.2? Then you were taking advantage of a bugged config for the turbojet engine. But otherwise zero-lift drag at transonic and supersonic speeds is lower, so you don't need as much thrust at those speeds. This doesn't help you if your engines stop producing thrust because their combustion chambers are overheating.
  3. ferram4
    And version 0.13.2 is out, with lots of fun things, such as aerodynamically-caused structural failures. A few other tweaks, and more options set up through ConfigNodes (like Deadly Reentry does) for easy integration with other mods. More info the changelog. For those unaware of what aerodynamically-caused structural failures entail, this is your rocket 30 degrees off prograde at Mach 1.2: May your launches be interesting.
  4. ferram4
    @Fraz86: FAR should handle those just fine, since the parts will be flipped across symmetry, so the sweep line should flip as well. Calculate the sweep angle and taper ratio as if it were any of the other wing parts, FAR will account for thins properly.
  5. ferram4
    @Mmmmyum: Depends on which joint is flapping. If it's the one between the wing and the IR part, it should help. If it's between the IR part and the fuselage, it won't at all, since that would cause KJR to prevent it from working properly.
  6. ferram4
    @AndreyATGB: In the real world, the main reasons for changing the height of the wings has to do with non-aerodynamic constraints. The C-5 has its wings mounted high so that its engines have more ground clearance, so it can land on less-than-perfect runways. Most jet airliners have their wings mounted low so they can save weight by combining the structural elements of the wingbox and the main gear into a single structure. However, it does have some interesting effects on aerodynamics (that FAR currently doesn't simulate) due to the way air flows around the fuselage; it causes slightly different angles of attack at the wing root, which leads to different amounts of lift on each wing. This is essentially another contribution to the dihedral effect (like wing dihedral angle and wing sweep); high wings make the plane more stable, low wings make it less stable. However, more stability makes it more prone to respond strongly in roll to sideslipping, so you generally want to keep the dihedral effect in check; too much or too little can always cause problems. In FAR, often the reason to choose one wing placement over another is to either get more ground clearance, have a good place to mount landing gear, or to control how the plane behaves at higher velocities, where the wing's drag will help contribute to the pitch-stability of the vehicle. For horizontal tails, those are generally used if you've constructed a high AR, low sweep wing that will lift the plane, but it isn't far enough behind the CoM for any control surfaces on it to be effective. Often for subsonic flight it ends up being more efficient to use a horizontal tail than deal with whatever weird wing-interaction effects occur when you're trying to create positive lift at the front of your wing and negative lift at the back (as is necessary for a stable tailless aircraft). However, at supersonic speeds, having the separate tail can often add more drag to your vehicle, so it's better to go for a single wing there. @DailyFrankPeter: Sounds like you've got a vehicle that took advantage of some unrealistic behavior. You'll have to redesign it to be more in-line with reality, I'm afraid. @capran: What softweir said. You appear to be suffering from the standard effects of changing the rules of the game but trying to use strategies that only work using the old rules. As an example, this would be as if you were playing chess and you had changed the rules so that pawns couldn't be promoted, but then in the end-game you race to get your pawns to the end of the board to promote all of them to queens. Consider how much of your earlier piloting and design is focused around dealing with stock "aerodynamics" and then adjust to account for new aerodynamics.
  7. ferram4
    @KerbMav: No, those engines would always make no thrust. The engines are always going to be blocked by the wings on that design due to stock engine behavior. @S.O.P.H.I.A.: Nope, the turbojets were overpowered before. I'll probably bring the RAPIER down to the velocity curve that the B9 SABREs use to balance it out. @SkyRender: Right-click the part. FAR has used tweakables for that since they were introduced.
  8. ferram4
    @Subcidal: No reason it shouldn't. It's not calling anything that requires 0.23.5. @Read have read: Good to hear! Thanks for pointing out the numbers in the Editor, I switched a lot of stuff from floats to doubles and I didn't cut off the digits at the same value. Hopefully I can get the full version out soon. @phoenix_ca: Really, the best way for MJ to handle ascent for FAR is this: Set a turn start altitude; below this it's vertical. Set an initial turn angle, and once it reaches the start altitude the rocket shifts to that orientation. Once the prograde marker drops below that turn angle, the rocket follows prograde until... The safe altitude / dynamic pressure is hit, where it can orient off of prograde to finish the ascent. Because then it can do whatever it wants above a certain altitude, but below that it simply gives up on fighting aerodynamics and goes with the flow.
  9. ferram4
    You can store multiple types of each experiment, so long as they are from different situations. You can't store two instances of Goo Low Kerbin Orbit, but you can store Goo Low Kerbin Orbit and Goo High Kerbin Orbit.
  10. ferram4
    You've got a Kerbal on board, yes? Get out of the capsule, get next to the goo, right-click, take data. Return to capsule, take data in there. Return capsule without goo. Profit.
  11. ferram4
    Let me guess, something like this? You shouldn't have a heat shield attached to the Mk1 pod, it already has a built-in one.
  12. ferram4
    Craft file please? Anything bad in the output_log.txt?
  13. ferram4
    That makes absolutely no sense. KJR doesn't even touch linear springs anymore (it leaves them at the stock behavior), only the angular ones, so I have no idea what could be happening there, unless those engines are attached in a way other than using a stack connection, I don't know what's going on.
  14. ferram4
    @Malcolm182: I actually just fixed that bug last night in my dev build. So what's happening is that the part's you're looking at still use the old Part type ControlSurface for non-FAR aerodynamics; FAR zeroes out the lift and drag parameters to be sure, but the Part type is unchanged. The ControlSurface code ends up setting the control surface's orientation every frame; FAR only sets it if it changes and then leaves it untouched. So what happens is that you'll see the control surface deflect so long as it's moving, and then when it stops it will snap back to 0, thanks to the ControlSurface code. Fortunately, it was easy to set up a ModuleManager line to fix that: @PART [*]:HAS[#module[ControlSurface],@MODULE[FARControllableSurface]]:FOR[FerramAerospaceResearch] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 } You can drop that into your config and it should work. If you're not using ModuleManager 2.0.3, get rid of the :FOR[FerramAerospaceResearch] part. Issue will be removed. @whaaw: Are you leaving any of the FAR control systems on? Keep trying to reproduce the issue, and document everything about what you're doing, like whether you go straight to the Launchpad or head through the VAB, whether it happen after you revert to launch, if you use a mod to skip the Space Center entirely. A seemingly random bug usually means that there's a variable you're not controlling for. Make sure to post a copy of the output_log.txt from KSP_Data when that happens, so if there's anything really breaking in the code it can be traced back to the source.
  15. ferram4
    @Read have read: Unintended behavior, caused by FAR having to apply drag to parts that previously hadn't had drag as a result of how many parts got physics turned off in the 0.23.5 update. The current dev build on GitHub does have a fix though.
  16. ferram4
    FAR only checks within the fairing shape for parts, so the fairing base isn't necessary if you can attach without it. And nose cones don't do shielding like that at all. They simply act as standard parts, like anything else. If they did anything like that your rocket would become horribly unstable since the only drag applied would be that of the nose cone, well ahead of the CoM.
  17. ferram4
    @NathanKell: Still haven't been able to see the behavior you're experiencing. Let me see if I understand this correctly: You set a full control input on some axis and hold that input. The control surface deflects to that input. It then snaps back to 0 deflection, contrary to control inputs. In addition, no other control systems are interfering (no SAS or MJ), the focus has not been moved to a plugin window, away from flight controls and control input thingy in the bottom left corner displays a full control input. Further, thrust vectoring on engines still follows that control input. All of this while you have stayed on the active ship, inside the atmosphere. @BombastixderTeutone: It's Mach number at the altitude that you're currently at. FYI, the speed of sound doesn't depend on density, it depends primarily on temperature and gas constants / properties.
  18. ferram4
    @NavyFish: More gets saved in the craft file than really should. So the MM file updated the properties of all the parts that will be added in the future, but not any of the ones added in the past. Any crafts where you've had this problem, swap the engines out and it'll go away since you'll clear all the problem data out of the craft files. @Malcolm182: So you make a full deflection, you hold the deflection (and the control indicator in the bottom left corner of the screen continues to show a full deflection), but without messing with anything else on the screen (no other windows, mods or anything else that would prevent inputs from going to flight control), the control surface deflection zeroes out? I've attempted to reproduce this, but have done so unsuccessfully; all of my tests had full deflection maintained for as long as I chose, until I did something that caused focus to shift from flight controls and into another window. whaaw: Because gravity tends to pull things towards the ground, so if the rocket ends up offset a little bit on the pad, it will fall over. Of course, that's not the question you're asking, is it? You're asking, "why does my rocket lose control and flip around in the middle of flight?" or more simply, "why is my rocket aerodynamically unstable?" The answers, in no particular order, are: You're overspeeding and aerodynamic forces are overpowering thrust vectoring control. Reduce TWR to ~1.2 - 1.6 compensate.\ You're sending the rocket sideways at a very high AoA. This will make the rocket unstable; gentle gravity turn, keep the rocket pointed prograde, starting shortly after getting off the launch pad, not go up 10km and yank sideways. You've attached something really draggy to the top of the rocket and have a relatively streamlined rear end of the rocket. Shift more mass towards the top of the rocket and more drag / lift towards the back. You're staging in the lower atmosphere, and while your rocket's configuration with the first stage was stable, without the first stage it is unstable. You have a really, really tall first stage (relative to the rest of the rocket) that causes the CoM to shift backwards after the first bit of fuel is burned, making the rocket less stable.
  19. ferram4
    @B787_300: Every time I've tried adding ground effect it ends up being either unnoticeable, extremely expensive, or just plain wrong. It's not simple to model and is too dependent on wing design and fuselage configuration for me to even hope to have a good model in place. At this point, it's not happening.
  20. ferram4
    @crashman1390: That does not sound like an issue that would be caused by FAR, since FAR doesn't make any parts indestructible nor does it mess with anything that could cause ships to fall apart on load. All of your mods are up-to-date, correct? Can you post a copy of your output_log.txt? @Malcolm182 & NathanKell: Under what circumstances? Is this when you make a control input, the control surfaces lag the input slightly? Because that is intended behavior, partly realistic, partly to keep SAS from freaking out and making planes wobble like mad (though people somehow still manage that). I need more information, because I use B9 myself and have never encountered any issue like that. @dbmorpher: FAR or MJ aerobraking and landing predictions on atmospheric bodies: pick one. MJ is (currently) not capable of simulating FAR's aerodynamic properties (though the code is open for it to do so), and even when it will be capable of doing so the predictions are likely to be very inaccurate compared to what you are used to, since the stock drag model is completely unaffected by craft orientation. You will either have to become better at making your own predictions with using FAR or you'll have to abandon it.
  21. ferram4
    @NavyFish: Hmm... can you provide the craft file so I can reproduce the issue? I'm not sure what's causing the problem right now. @PLB: I actually do have some correlations on hand to calculate how exhaust would affect control surfaces, but it's not a huge priority to add those effects; in fact, there are far more important induced velocity effects (mostly from wings) that I'd like to implement first. But yes, it is something that's on the table, if not right now anyway.
  22. ferram4
    @NavyFish: That's not the same exact problem, since all the forces coming out of that shouldn't matter; the NaNs are set to zero when the code finishes to make sure nothing breaks horribly. It looks like the error starts from some divide by zero in the aerodynamic center calculation, which I believe I fixed for FAR v0.13.1. Are you running the latest version of FAR?
  23. ferram4
    @m4ti140: Go to the GitHub repository and download the latest versions of FerramAerospaceResearch.dll and ferramGraph.dll from there. You'll also need to go grab the FARAeroStress.cfg from the GameData folder there and put it in the FerramAerospaceResearch folder. The latest dev builds of FAR have the issue fixed, but there's a lot of work to be done before a full release is possible.
  24. ferram4
    @Jupiter02: Well, if he was using a 0.23.5 only version on 0.23, it's not a bug, it's a lack of backwards compatibility. And there's no way to maintain compatibility across the 0.23-0.23.5 joint fixes.
  25. ferram4
    The fuel drain is likely the main cause of that, and the only solution is to either add fins at the bottom of the rocket, redesign the rocket so that the CoM is above the upper-most tank of the first stage, or flare out the bottom of the rocket with boosters to prevent it from flipping. In addition, remove any sudden changes in the cross-sectional area of the rocket, or put them below the CoM; those will create a lot of drag and make the rocket unstable.
×
×
  • Create New...