Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    @evsey2003: The only "cheat" with FAR is disabling aerodynamically-induced structural failures. Since NEAR has that removed entirely, that "cheat" is always activated, in a sense. @Alshain: Because the basic jet is a turbofan intended for heavy vehicles at subsonic speeds and the turbojet is an OP engine for pushing you faster than the SR-71 on a lot less fuel.
  2. ferram4
    Depends. Lots of those things depend on if I can separate out the Unity classes and their methods, since those can't be used outside of the main thread. I'll admit that I'm somewhat confused by your complaint; this certainly doesn't work by using magic method names, you need to register each of the methods before they will be called, because I think Unity's magic method name stuff is silly. Would you mind pointing to where you'd like to see a change?
  3. ferram4
    @Wanderfound: e comes from calculus; e^x is its own derivative and the natural log (log base e) is the solution to the integral of 1/x from 1 to any value. But yes, you're doing it correctly. @TheGatesOfLogic: They are perfectly rotationally symmetric. That is the only symmetry you get from the VAB. That doesn't prevent them from gaining some net amount of twist that would cause roll. Then again, I'm confused; 0.24.2 has engines thrust vectoring to provide roll control now, so you should have ample roll control unless your design is not radially symmetric to the degree where it should be visible. You will want to check your design for misalignment of parts.
  4. ferram4
    I dunno, I didn't test with IR. You can try though, and unless you've got really funky collider issues going on, everything should be fine.
  5. ferram4
    Density falls off roughly exponentially; it's much more affected by pressure than temperature. Since Kerbin has a scale height of 5 km, you can work out the reduction from a SL 1.225 kg/m^3 fairly easily. Temperature will be ~300 K at SL, which will steadily decay until it's around 260 K or so at ~10 km, and it stays roughly constant there. IIRC.
  6. ferram4
    Only collisions within parts. Preventing collisions between parents and children would be self-defeating. The reason it exists is because Scott Manley asked if it could be done as part of dealing with issues of parts clipping through cargo bays and payload fairings.
  7. ferram4
    The Colliders Strike Back ------------------ What it does: This disables an optimization / improvement made early in KSP's history that disabled all intra-vessel part collisions. Parts will not collide with themselves (to avoid issues with landing gear or cargo bays that are dependent on this functioning well), but will collide with other parts on the vessel where they previously did not. Part-clippers beware! This can be used for experiments into the nature of collisions, avoid issues with payloads clipping through payload fairings / cargo bays, and general mayhem. Download v1.0.1 from KerbalStuff!Download v1.0.1 from Github! Source at Github Licensed MIT Warning: This has the capacity to destroy any vehicle that includes part clipping as an integral part of the design. Any and all vehicles launched / created before this was installed may spontaneously explode if they are dependent on intra-vessel collisions being disabled. It will also make part-induced framerate drops and time slowdowns a lot nastier, due to the extra expense of all the collider calculations. You have been warned.
  8. ferram4
    @Wanderfound: You would have to refer to the stock pressure and temperature functions, and then density can be calculated from the ideal gas equation. @Volt: Reproduction steps and a log please? Bug reports without that basically just tells me that I have to stop continuing development until I can get information to try and fix the issue.
  9. ferram4
    This is why you use tweakables to prevent control surfaces from acting on certain axes where they will not help. However, if they are deflecting in a certain direction, it is because they are in fact helping the plane to orient itself in the direction you have chosen. The control surfaces are behind the CoM, and are deflecting as if they are behind the CoM, and are deflecting to push the nose of the plane up. If they deflected in the opposite direction they would hinder the pitching motion of the plane, which is what you are actually controlling.
  10. ferram4
    By using them with the stock model, where they top off at that speed. FAR and NEAR make half-hearted nerfs to the velocity curves because reaching orbit on jets is stupid, but I didn't want to deal with the hell that would come from taking away the magical toys that everyone had gotten used to.
  11. ferram4
    @Camacha: Well, yes. FAR v0.13 and lower didn't have aerodynamic failures beyond what could be applied to the stock joint system, which has been made too much with the 0.23.5 stock joint changes, and especially with KJR. You can go and disable them in the debug menu in the Space Center scene or change them to something else if you want. @Volt: Well, it shouldn't change much physically. That sounds a lot like stupidly high dihedral effect with almost no yaw stability; make your vertical tail larger / give it a larger lever arm and reduce your dihedral effect with less-swept wings or some anhedral.
  12. ferram4
    It's not any specific mod. It's memory usage above ~4Gb on x64 that causes issues. It doesn't matter what mods they are, so long as they use a lot of memory, crashes are inevitable, though exactly when they'll happen is somewhat difficult to predict. I'm saying this as someone who's seen KSP win64 be highly unstable with modlists that are perfectly fine under KSP win32 and can get win64 to crash at will while win32 remains stable. Most modders don't say that it's incompatible, just that they don't want to be bothered with the stock issues with KSP win64, since there's absolutely nothing they can do to fix those issues, because they aren't caused by the mods.
  13. ferram4
    Exactly? Of course not; that would slow your computer to a crawl, and even then, the best simulations we have can't achieve that. A decent approximation? Sure.
  14. ferram4
    @Surefoot: If you've got pitch-down tendencies at Mach 2, that's not Mach tuck; Mach tuck is specific to the transonic regime. What you've got going on is a design that is too stable at supersonic speeds because the CoL is too far behind the CoM; you will need to reduce the distance between them in order to compensate. Unless it's getting stupid pitch-down tendencies only around Mach 0.7 - 1.1, you're not getting Mach tuck. Also, nerfs to the jet engines still leave them with higher thrust and lower fuel consumption than real life ones at altitude. Trust me, they haven't been nerfed enough, but people still complain. Finally, KJR has never done anything wrt pWings, because trying to get the sizing of those parts is impossible, and allowing KJR to do anything to them simply makes it worse. You are seeing the effects of stock joint forces there. @Camacha: Consider that Surefoot's flexing problems are due to the stock fixes, and then come to your own conclusions.
  15. ferram4
    @brusura: Known issue with pWings and a fix to some issues with odd CoL with B9 parts. A fix is in the works, but until then, please use GitHub to report dev issues instead of here. @Surefoot: If the last time you flew it was in 0.23, then it's quite possible that improvements to the flight model have caused this and that it is proper. Look into shifting your CoM and making sure that your wing loading isn't ridiculously high. @Voculus: Well, for one, 350 m/s is ~ Mach 1, and having thrust increase there will ensure that it can reach stupidly high speeds. You'd want thrust to fall off by that point. Ideally, you would abandon stock-based airbreathing models since they're complete garbage and wrong, because jets and props do not act like rocket engines. @mossman: Why would any other parts show a drag of 0? Only intakes have the maximum_drag indicator displayed, so I don't know how you're reading it from anything else. Even still, those numbers must be set to 0 unless you want drag proportional to mass. FAR's indicators can be re-enabled in its debug menu in the Space Center, and the numbers that come from those will not be 0. You are not suffering any issues, everything is working perfectly fine.
  16. ferram4
    @mossman: Oh, why didn't you say it was for intakes only? That's on purpose, because those numbers go into the stock drag model. @Camacha: Added back in 0.9, IIRC. @Surefoot: I'll need to see the output_log.txt. Did this fly in FAR previously, or only in stock aero? @nli2work: Aero failure numbers are forces to cause failure per unit surface area. Higher means higher force before failure. @AccidentalDisassembly: Noted and acknowledged on the previous page that it was noted and acknowledged the page before that as a known issue that was fixed in the dev build. Read / search the topic before posting, please.
  17. ferram4
    What about when taking such liberties not only result in something that is inaccurate, but is also more computationally expensive than doing things correctly? You and I both know the game suffers from crippling performance issues, why not make a change that will lessen the computational load and provide a slight change in reality as well? Honest question Sal, what is the benefit to leaving things as they are? It's less accurate and it's more expensive to compute. The only change is that suddenly, we need to be given SL thrust as well as Vac thrust, but considering that the stock game doesn't provide TWR or dV readouts anyway, that lack of information shouldn't be anything new to players, and providing it would, (if I remember the quote correctly) "remove the mystery and fun" of trial and error gameplay. So why not make the change?
  18. ferram4
    Even more so, it'll make the engine module less computationally intensive. Currently, it solves T / (g0 * Isp) = fuel_mass_flow. With this change, it'll solve g0 * Isp * fuel_mass_flow = T. Since multiplications are faster than divisions, this will be an overall performance boost.
  19. ferram4
    Well, with a plane that small, 30 kN is more than enough to get it up to Mach 1. Could you show a picture of the drag readouts? Are you attaching lots of payload fairing parts everywhere that are shielding those parts?
  20. ferram4
    @NocTempre: KIDS affects all engines by scaling Isp without much regard for realism (except changing thrust instead of fuel consumption, if you set that). AJE tries to model jet engines properly. There's not much overlap except in the "it changes engines somehow" department. @tater: Then you did not install it correctly / something is interfering with it. Follow the steps in this sticky.
  21. ferram4
    @yohuan: You go into the FerramAerospaceResearch.cfg and remove the block that reduces engine thrust by 1/2, and then you don't complain about having too much thrust ever. @brusura: Was acknowledged as a known issue that was fixed in the dev build on the page before. @Voculus: Solution is to keep dynamic pressure low. Other solutions are to place the lights so that they are less of a sudden protrusion into the flow, which makes them more likely to be torn off.
  22. ferram4
    The is no way to dumb down the GUI like that without also making it completely wrong in enough cases to make it worse than having no GUI. There are no easy ways to rate aircraft like that. There is no way to measure anything about flap performance without going into FAR's level of GUIs. NEAR will never have GUIs, and that is final. You wanted simpler, you get simpler.
  23. ferram4
    @Diazo: I have no idea to be honest. @cxg2827: Flipping means that they're aerodynamically unstable, which implies that the CoM needs to be put further forward. As to the shielding error, I can look into it, but it's a very funky edge case caused by the fact that the parts aren't put together in symmetry, which makes determining the exact shape for shielding a great deal more difficult. It's really kind of disappointing it needs to be set up that way when the only difference between upper and lower halves is a texture that doesn't do anything.
  24. ferram4
    @nli2work: There isn't a way to do that, simply because there are not any parts that shouldn't apply drag ever. The best way to get around it is to define your own FARBasicDragModel and set it's S (area) to 0, but make sure to set CdCurve, ClPotentialCurve, ClViscousCurve, and CmCurve to something non-null or else it will be cleared out as a "broken drag model." @Diazo: I already fixed that issue in the dev build awhile ago.
  25. ferram4
    Well yes, that's why it's the dev version. I alreayd have that one fixed, but I haven't pushed that version yet.
×
×
  • Create New...