Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    Ummm... it would require a bit of math and assumptions, and I haven't done it because I generally thing running around trying to fix other mods is something that will be irritating and take up too much of my time. The way you'd want to do it is to find the area of the brake surface, and then pick a drag coefficient for it (I'd say ~0.7, 0.8 for their size and angle). Then you need to convert that to maximum_Drag for KSP's stock system to function with. So the equation you'll have to solve is: drag_coeff * area = mass * 0.008 * maximum_Drag Then set the drag value for the part equal to the number that comes out of that equation. Standard maximum_Drag should be set to 0. If the wing was somehow an oblique wing (so a straight wing at an angle) you'd be able to get most of the benefits of sweep with the accurate modeling (except in rotor mode, but whatever). Unfortunately, FAR works on the assumption that wings can be set up as a single trapezoidal lifting section with the origin at the wing root. Except for where it can make an exemption for the control surface only parts (which is less accurate, but functions , and that's what you'll be hooking into). Nonlinear PDEs are a pain, aren't they? No, that is only a visual effect. Otherwise, lots of stock and mod parts would perform very badly because they have improper cross-sections for wings.
  2. ferram4
    @AndreyATGB: They should be shielded. They always have been before. That's quite odd, I'll have to look into it. @Flayer: Lower TWR. Start gravity turn early. Stay pointed prograde. Don't put really light fluffy payloads on top of big heavy rockets. Fairings. Fins if you need them. Pictures help with diagnosis.
  3. ferram4
    Is there a FARWingAerodynamicModel PartModule attached to it currently? If not, and you're using FAR, FAR is going to add a FARBasicDragModel PartModule to it, since there's no exemption for FSliftsurface in the FAR configs. And FARBasicDragModel can really screw up on parts like that. FAR does reference the models, but it doesn't go into the complicated mess of "how much is this part inside this other part" unless it's looking at cargo bays and payload fairings. The "stuff in front lowers drag of stuff behind" is related to parts attached in a stack, which makes figuring out how the drag of one thing affects another thing easier. See above. It will have a FAR module attached to it, applied in-game, not in the config. It's perfectly possible for you to attach a FARWingAerodynamicModel to it, but you're going to have to hack it as an unswept wing and add "nonSideAttach = 1" to the MODULE node to get it to center the CoL. If you said you wanted an inaccurate hack to begin with, you should have just asked for it.
  4. ferram4
    @bludclot: Well, thank you for your input. Like I said, if you think the realism of it is questionable, propose a better model and cite the theoretical or empirical basis for it. Data, not feelings. @Tiron: FAR doesn't really have any elegant way to handle that thing. Probably what it's doing is creating a cylinder to shove the entire thing into (axis parallel to the rotor axis), and that giant thing is where the problem comes from. You have to look at it and realize that FAR doesn't know much about the actual shape of the part and functions (for things not given a special FAR wing model to work with) as if the part is some type of elliptical-based frustum. This is why FAR has issues with LLL parts and similar things that move further and further away from stock-like shapes; it just doesn't have any way to analyze the shape in a reasonable way. FAR only works as well as it does because it can approximate and assume away lots of complications that can't be done for a model like yours. Hell, the thing I'm working on to replace FAR might not even be able to handle something like that properly.
  5. ferram4
    @bludclot: Yes, I agree. It's completely arbitrary that 2024 aluminum has a yield strength of 324 MPa. However, this is not my department, and I would advise you to send all complaints to whichever deity your religion has designated as the go-to for complaints/suggestions/requests. Snarkiness aside, if you've got a better model for the failure strength, I'd be happy to hear it, but complaints about a functional system without presenting a working alternative is unhelpful. I've explained why it can't be done through the existing physics simulation, but simply complaining that you don't like it doesn't help. Oh, did I mention that planes should fly apart a lot more easily, but I'm not simulating flutter? Maybe I should get to work on that... @Tiron: Sweep in opposite directions is not supported. You might be able to manage it if you set it up as an oblique or straight wing, but as it currently stands, anything you try will be wrong.
  6. ferram4
    @Tiron: Of course the drag is tremendous. There's nothing there telling FAR not to have a go at adding its own drag model to that thing, and it's probably setting it to have a very large reference area and a decent amount of drag. It's always going to be a no-no because FAR isn't set up to combine two wings with different sweep into one part, and that's not something I'm planning on adding. It would require double the computational overhead for that part as a normal wing part would take. @Dragon01: No. There is no way for me to detect what the animation is actually doing, which means that every single change that happens will need to be defined by the part creator. And that is something that I've been trying to get away from and would only reinforce the need for FAR-specific configs on parts. It's currently necessary for wing parts, but I don't want it to be necessary forever and I certainly see no reason to entrench that further. Especially since most of the things that can be done with Firespitter parts can already be done (and much better, I think) with a combination of FAR's flap settings and Infernal Robotics. @bludclot: Let me explain to you why that doesn't work. First, the aerodynamic forces applied to parts in the recent update did not change at all. But parts didn't break off due to aerodynamic forces prior to the recent update. That's because the new joint system uses the JointDrive parameter to apply forces to parts to hold them in place. The only problem is that forces applied by JointDrive don't count towards the forces needed to break a joint. And the JointDrive spring constant is set to the maximum stiffness that it can hold (Float.MaxValue) and the JointDrive max force value is also set to that value. So basically, barring a physics glitch that causes the parts to shift just enough that the underlying non-drive connection takes the hit, parts will never break due to forces. Have you noticed that joints never, ever fail due to forces applied since 0.23.5 hit? That's why. So it's not possible for the current joint system to handle failures of the type that we would like to have. So I have to work around it. Only way to get them back is to either roll back to the old joint system or to recode the joint system so that PhysX will properly allow joints to break. I'll also note that the "arbitrary" point of failure is based on the kind of loading that a wing would expect to have in flight. A large amount of math got calculated out to figure out those numbers, they're not just completely arbitrary.
  7. ferram4
    It's never going to be balanced with that single Goo canister on the top. And trying to use an RCS tank to balance it is a bad idea, it'll always be off by a bit. The trick when balancing payloads is to remove anything from the payload that is definitely balanced, including symmetry-attached parts and anything that isn't needed to keep the parts that need balancing together. Then balance that, then add all the other parts back. Just double up on the Goo. It'll solve your problem much faster than what you're trying to do.
  8. ferram4
    @Tiron: The way the rotor is currently set up there is absolutely no way for FAR to support it. FAR doesn't include code for turning wings on or off at will, nor does it include code for even figuring out the orientation of lift on a part like that. Hell, you won't even be able to get proper lift out of the thing since it'll all be offset to one end (due to how the wing modules work). Unfortunately, I think that there is no way to make that part FAR compatible without a large amount of code changes on my part that simply won't be useful elsewhere. It'll also add a lot of additional computational overhead to make all that work. Sorry, I think you're going to have to leave it incompatible with FAR. The alternative is to include a ModuleManager patch to the FARPartClassification node to make FSLiftSurface exempt from FAR's drag modelling and then figure out something else yourself. @Cakeoffruit: Not currently supported. Maybe in the future, but not now. @bludclot: Struts have no affect on things breaking since it is meant to model internal failure on the pats, leading to it breaking off of the vehicle, not part-to-part failures. As for what you were doing, without seeing a velocity readout I can't compare what you were doing then to what it takes to cause FAR to break things. For all I know you're flying with a Q of 30 kPa half the time, with the attendant risks in destroying the aircraft. @Yar987: This mod strives to model aerodynamics properly. Location of fuel and CoM on a vehicle, while crucial to building stable airplanes, is out of the scope of this mod.
  9. ferram4
    @Mrsupersonic8: Merging the GameData folders will also bring ModuleManager over. What you want to do is make sure you don't have multiple copies of ModuleManager floating around, since that can cause issues. @Playful1510: Those are disabled by default now. You can change them through the settings menu in the space center scene.
  10. ferram4
    You would want to copy over all the folders in GameData, and you want to make sure that you only have one copy of ModuleManager, which must be version 2.0.x or higher for FAR to function properly. So same as any other plugin that relies on ModuleManager.
  11. ferram4
    DaMichel: That is likely due to the fact that the ElectricCharge tweakable is supposed to be solved by a different ModuleManager fix, which is mentioned by Gwincraft. @Wincraft: I suspect that ModuleManager is not functioning properly; go into your GameData and make sure that you only have one copy of ModuleManager in any of the folders there and see if it works then. @bludclot: Keep in mind that KSP results in a really messed up sense of scale. There are lots of people who think that 300 m/s is slow (for some reason), and that the aerodynamic forces on a vehicle at those speeds shouldn't cause it to break up. When most vehicles stall, they do so at low dynamic pressures (most real life planes never even get above about Q = 15 kPa), and anything higher generally results in overstressing the airframe before stalling ever occurs. Stalling and spins don't occur at high Q, breakups occur at high Q. Stalls and spins are (for the most part) low Q phenomena. FWIW, most lanes should fly apart much sooner than they currently do, since FAR doesn't even bother trying to handle flutter. Oh, and there has been an option to remove it and adjust it. It's been there from the start. Settings menu in the space center scene. What's the point of adding a settings menu if no one ever looks for it?
  12. ferram4
    Without a picture of the rocket (including payload) there's not much we can do to help you. What it sounds like is happening is that you've got some imbalance starting (perhaps the rocket is flexing or fuel isn't draining symmetrically) and that's messing things up. If it's going off course as soon as you launch (right after it goes off the pad when velocity is very low) then it's not FAR, since aerodynamic forces will be very small compared to thrust and gravity.
  13. ferram4
    The current version on GitHub (not the release, the actual GameData folder in the source) has a fix for that, I simply screwed up the regular expression and didn't allow negatives. The errors at 90 degrees I'll have to look into, it's probably a trig error somewhere.
  14. ferram4
    @MunMun: Using a Mac? Learn how to merge folders on a Mac, it doesn't do that by default. Unfortunately, You will have to re-install KSP, since you deleted everything in those folders when you overwrote them. @Motokid600: Deleting all the FARAeroStress categories probably caused everything to break, since I don't believe I'm checking for null there (note to self, add that for people who delete everything). There is a toggle in the debug and cheat menu that first comes up when you click on the FAR settings tab; use that to turn off structural failures. @DaMichel: For some reason those particular cargo bays have slightly larger included areas in the SPH than they should have. Not sure why, since the code works fine in-game. I also don't know what could be causing that particular error with wing parts, since I've never seen that before, though I did fix an issue similar to that a few versions ago.
  15. ferram4
    @DaMichel: I'm not touching mod engines. Ever. If I start having to making tweaks to 3rd party mods I'll end up spending more time on that then on FAR itself. Beyond that, since B9 isn't compatible out-of-the-box for KSP 0.23+ I'll have to make sure that whatever I would come up with works with all the possible ways that someone could fix them, and I'd prefer not to try and troubleshoot that as well. And besides that, thrust is only a function of altitude if you're running low on IntakeAir, so using thrust at altitude is a poor comparison. I also know that I tweaked the turbojet and RAPIER engines so that their thrust falls off at about the same velocity as the B9 SABREs fall off, so they should perform somewhat similarly. @DivisionByZero: Put your spaceplane in a draggy, high AOA configuration. The space shuttle reentered at ~40 degrees AoA, you should be around 20 at least. Anything below that and you're not going to bleed off velocity fast enough. @camlost: Another entry for FARAeroStress... fine, I can do that. However, scaling mass with stress tolerance isn't going to happen, entirely because all the wing parts in game are 1/10-1/5 the mass they should be, so first I'd have to scale all the masses up properly. Lots of balancing work for other mods, and I'm not dealing with that.
  16. ferram4
    Slower takeoff speed. More wing area. Less vehicle mass. Lower thrust. Without seeing a picture of your vehicles, I can only assume what you're doing wrong and give you those general tips.
  17. ferram4
    @thorfinn: Of course, and it's possible to build planes that fly much faster at SL. Hell, the example FAR Hypersonic Demon can manage Mach 2.2 at SL if you fly it right. The problem is that above 200 m/s full control deflections are often enough to exceed the maximum forces on the vehicle and make it break apart. I suspect that taking an F111 supersonic at SL and then pulling back hard won't end well for the plane, just as it won't end well here. But it's asking for trouble, since there's almost no time to prevent the plane from flying apart if you start to lose control or you make too aggressive a maneuver. Everything's happening too fast for normal reaction times.
  18. ferram4
    You are using an old version of FAR that has a bug with some AIES parts, in particular, engines that define a ModuleJettison (which controls the stock engine fairings) but the ModuleJettison does not point to an existing part of the model. Update FAR and the issue should go away.
  19. ferram4
    @Gaiiden: Simple: go slower and fly higher to reduce dynamic pressure, or use more gentle control inputs at high dynamic pressures to reduce loading. Don't fly at high angles of attack. Make sure your plane can take off below ~130 m/s. Anything above ~200 m/s near SL is asking for trouble. @Motokid600: It was the flip that killed it. It flips, severe lateral forces on the vehicle, it breaks up. The default parameters are designed for an Eve lander with enough dV to return from datum altitude to enter Eve's atmosphere at with a 50 km periapsis from a standard hyperbolic trajectory and land perfectly fine; it hits a Q of ~80 kPa during that and it doesn't break up so long as it doesn't flip or go lateral during the procedure. Same principle here. @federally: Well, you didn't ask "how do I prevent control surfaces from ripping off?" you just asked why they do; don't be upset when someone answers a question you asked. Now, to answer this question, reduce takeoff velocity (add more wing area, add flaps, reduce mass). Reduce need for control surface deflection (reduce stability, move CoL closer to CoM). Be more gentle with control inputs and take advantage of the delay between commanding a deflection and when the control surface reaches that deflection. Avoid overspeeding. @Read have Read: No, the transonic regime isn't the area of Max Q, that's often after the transonic regime and into the low supersonic regime. It's just a flow regime where there are large regions of subsonic and supersonic flow and neither region can be assumed away in the analysis. Often the size of those regions results in much more severe lift and drag coefficients, but referring to it as the region of Max Q is fairly inaccurate, since Max Q has no dependence on Mach number itself, simply air density and velocity.
  20. ferram4
    Post the output_log.txt from KSP_Data. I need the output_log.txt to have any hope of fixing the issue, if I can even do anything about it.
  21. ferram4
    What do you mean, the controls were not centered? Did you accidentally turn on trim? You can hit ALT + X to turn that off. Also, many of your mods are out of date, you should update them. For example, your version of FAR was 8 versions ago.
  22. ferram4
    @Klingon Admiral: That would probably be due to the boosters either imparting a slight roll or something flexing in the upper stage. @icecubecookie: Known issue with the B9 Mk2 Cargo Bays. FAR needs cargo bays to be built with colliders in the doors in order for it to determine if the bay is open or not. Those particular bays do not have colliders in the doors, so they can never be detected as closed. This is an issue that must be fixed on the part's side, there's nothing I can do about it.
  23. ferram4
    @MiniMoose12: That feature was always intended to be there, it's only the fairly recent additions of KJR and the stock joint reinforcement that have prevented rockets and planes from coming apart. If you look back through Scott Manley's videos you can find an earlier version of KSP where he attempts to recreate Operation Credible Sport and his plane comes apart from aerodynamic forces all over the place. That was always intended, and will always be intended. Regardless, if you don't like it in the space center scene you can access the FAR debug menu, where under the "cheats" option you can turn off aerodynamic failures.
  24. ferram4
    What?! Okay, I haven't seen anything like that happen before. That's really, really strange, and I don't know what would have caused that to happen, unfortunately. My guess would be KJR and how it affects joints, but I'm not even sure about that, since KJR's silliness tends to happen when coming out of warp or on the pad, so that seems unlikely. I am deeply confused.
  25. ferram4
    That sounds more like a physics engine wackiness-induced failure. When parts change velocity enough in a single frame, it triggers the "crash" explosion thing, but if there's nothing that it has collided with it seems to default to the launch pad; KJR had an issue with this in earlier versions, perhaps that's the cause again? If that's the case, I think reducing the angular drive parameters in the config.xml should fix it, at the cost of slightly less stiff part connections.
×
×
  • Create New...