Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    @iamzac: While it's possible that could be the problem, that method is also incredibly laggy. Hence the other method. The CoL that is first loaded is not the one calculated from 0.14.3, they are never saved and are never loaded. @Zeenobit: That is correct. Turbofans, while efficient and very good at producing good static thrust have their thrust drop off quickly as velocity increases. They are not very useful above Mach 1 at all.
  2. ferram4
    @iamzac: I cannot reproduce the issue. The CoL is always in the same location. There are some errors that require my attention, but they don't seem to cause the behavior you're describing. You must still be missing steps, or it is an installation error. @Wanderfound: Maybe? It depends very much on the exact configuration, and I don't keep a log of all the data in my head. You'll also probably find some really old, known issues in the process if you go exhaustively detailing this stuff. In the real world, there wouldn't be much point in adding the nosecone though. And if you have an open-air cargo bay, there's pretty much no way to shield the payload; you have to build it as if it's an open-air payload.
  3. ferram4
    @Patrick Kerbivan: It handles each part mostly independently, with some empirical corrections to try and account for part interactions, but of course that can't get everything. In the ideal case, most of what it simulates can be calculated from the 1978 USAF Stability and Control DATCOM (which is the latest version I could find). @iamzac: I cannot confirm the issue; your reproduction steps are not complete at all. Did you follow all of the instruction steps to the letter (including deleteing the entire FAR folder, as stated in the zip, when updating from earlier versions to 0.14.3+? I'll also need a copy of the output_log.txt @velusip: I don't know what to tell you. No one has been able to provide reproduction steps that work for me. FAR doesn't even set anything for the vessel state, so if that is breaking, then it is likely a stock bug of some kind. Unless someone can get me a working set of reproduction steps, the best I can do is set FAR to not do anything for the first few frames and then hope that the same error doesn't occur when it starts up again. I'd prefer not to do that, but I see no other options besides such hacks. Does the same behavior occur with NEAR? I'll try uploading something to the github repo in a few minutes, but I have no ability to test or know if it will work.
  4. ferram4
    No, it's not. Aerodynamic forces are still applied.
  5. ferram4
    AJE simulates the inner workings of a jet engine. It's not perfect, but jet engines do end up behaving very close to actual jet engines with it. KIDS can optionally switch to Isp varying thrust rather than fuel consumption. It does nothing to jets at all when that setting is selected, because that would result in stupid things. Their effects are not related in the slightest.
  6. ferram4
    @Patrick Kerbivan: No, it doesn't do that, because there isn't enough data known about the part's shape in order to do that. It would require each part to include a bit of info about its shape, which would break the plug-and-play thing FAR has going on.
  7. ferram4
    An aerodynamics mod, with the necessary changes to work around issues that only exist because they are workarounds of issues caused by the stock model. The jets only overperform in stock because it is necessary to fight the stock model has drag that is so high. I'd rather people just use AJE, but most won't, and enough people complained that I nerfed jets to more realistic thrusts. Wings weighing so little is a stock thing... that has never made much sense, and raising the masses is necessary to fix a lot of the floating wing tendencies that people could still get with FAR. FAR has a history of making such changes. It has long shifted the CoM of the Mk1 pod lower, closer to the heat shield, because that is more realistic and is necessary to make it behave properly during reentry. Should I remove that as not being in scope? The basic answer is: if there is some non-aerodynamic unrealistic error that makes flight with FAR behave wrong (like the CoM of a pod being too high, making it unstable, or wings being too light, making them floaty, or jets being too powerful, giving them higher TWRs than rocket engines, somehow), FAR will change them to the smallest extent necessary to make the aerodynamics behave properly. FAR has always been a realism mod. Nothing has changed, though I wish that things were not so messed up that I needed to make these changes in the first place. Edit: And now, the 0.14.3.1 patch is out fixing wing interaction stalling issues, some lag in the editor when going to attach wings, and some GUI funkiness.
  8. ferram4
    The number that is wrong is for pitch control. It's telling you that pitching up will cause the plane to pitch down; your elevator controls are reversed, fix them.
  9. ferram4
    ... well, it's fixed. But given how many problems have been caused by me screwing up the AVC version file, and the fact that I don't use it myself, I'm tempted to simply pull AVC support for the next version. It'll make things a lot simpler on my end and certainly avoid a lot of the metadata hassles with a release. Sorry guys, it's seeming a lot like it's just not worth it.
  10. ferram4
    Problem 1: You have no significant vertical tail to speak of. Add more vertical tail area further behind the CoM. Problem 2: Your plane doesn't look like a plane. The closest thing it looks like is a relatively moderate speed plane, which means it won't really perform well above Mach 0.6. You should redesign it to look more like real-life supersonic designs if you're intent on going faster than Mach 1.
  11. ferram4
    @Shania_L: Yeah, pretty much. For FAR (which has Mach effects that will increase drag a bit), the terminal velocity of a fully-loaded rocket is ~900 m/s at SL. You are going to lose control long before you reach those speeds, so stop worrying about terminal velocity. That people think about it at all is one of the worse effects of the stock model. @Mystique: No, NEAR doesn't have aerodynamic failures explicitly coded in like FAR does, they just come about as a consequence of removing Mach effects from affecting wing lift. Not a thing I can do about it, turn onunbreakable joints if it bothers you. @Sakata: No, NEAR is never getting a GUI. You want a GUI, upgrade to FAR. NEAR doesn't care whether the bay is facing upwards or downwards. The stock bays are symmetrical when closed, so it doesn't matter. Attaching them sideways, now that will matter. @Pokletu: All of the zips are correct. They have NEAR v1.3, which is compatible with KSP 0.25, on all OSes and builds of KSP with the exception of win64, where it shuts itself down. This is the fourth time I've checked it; they are fine.
  12. ferram4
    Then that indicates that you did not install FAR properly.
  13. ferram4
    @Wanderfound: Scratch that, not happening. That requires a dependency on KSPAPIExtensions, and my experience with that is that adding that dependency is a bug no-no. It's pretty bloated and takes a long time to update when KSP updates. I'm not willing to deal with that. @endl: Umm... any of them should be fine. B9 lights especially.
  14. ferram4
    @Wanderfound: Like PP does for its parts? I can try implementing that. @endl: The docking port is not a cargo bay. That's not surprising, and I'm not going to consider making it one, because then I risk getting a lot of false positives.
  15. ferram4
    Please try. It seems to be something related to Linux 64 somehow, but only a very few people can cause it. I have no idea where it's coming from, and the effects don't make much logical sense. Oh, JackY; fixed the issue, I was being a little stupid. The dev build has the fix, and I'm just polishing up some efficiency changes before I push a patch.
  16. ferram4
    @JackY: That shouldn't be happening. I have confirmed it, I'll see what I can do. And it's not the status, it's the wing interactions + stall that's messed up. @velusip: Launching it through Steam? Try without. That worked for someone else. Dunno what launching through Steam changes, but it changed something.
  17. ferram4
    It'll need to rebuild everything after the rescale, since that would be needed to rebuild all of the wing interaction data and a few of the other geometry things. If it doesn't do that, it will not behave the same. No way around it. Oh, and it will probably have to send that message to every wing on the vehicle to make sure that their wing interaction data is updated as well.
  18. ferram4
    Unless Tweakscale specifically has code that calls FAR's recalculate geometry functions after it rescales things, it has never been auto-updating FAR's aerodynamic characteristics in the editor. The fix has to come on the Tweakscale side, because any attempt to do it on my side will make things even more computationally intense in the editor than they already are.
  19. ferram4
    @velusip: Reproduction steps and a log, please? Just saying, "X thing that shouldn't happen happens" doesn't help me find out what is wrong.
  20. ferram4
    @DivisionByZero: No, it only applies to the drag applied to the intakes, not to anything else. They're otherwise just as broken as stock.
  21. ferram4
    @SkyRender: "Phantom roll?" I hope you have a test case for that, because I haven't seen any roll effects that can't be attributed to proper aerodynamics + flexing of the vehicle. And I ran into a lot of actual phantom roll rebuilding the wing interaction code.
  22. ferram4
    SAS has always had problems with FAR and NEAR, because SAS has always had problems with high control authority vehicles. This is why the stock thrust vectoring ranges are tiny, and the stock control surfaces only get away with it because their lift varies with velocity rather than velocity^2. Unexplained rotation is an old problem, caused by uneven flexing of joints, which is a stock issue. It is exacerbated by the fact that lifting forces are higher with FAR and NEAR than in stock, so it's a lot more pronounced. In both cases, complain to Squad. The latter is a bug that's been around forever, and the former was re-introduced after they tweaked SAS following its overhaul.
  23. ferram4
    Well, this plane has really high wing loading (most planes that have wings that size for the body don't have their entire insides filled with fuel like this one definitely does), almost no vertical tail to speak of and way too much dihedral on the wings which is only going to make it fly worse. Give it more wing area, make sure that the CoM is forward enough so you're stable when you head out of the atmosphere at around 1.5 km/s, and use RCS when climbing out for more control.
  24. ferram4
    I would suggest a complete re-install of FAR to check if that's the issue, but I suspect it's something else. Check what happens with the launch clamps set up differently, maybe it's the initial launch kick causing that.
  25. ferram4
    IMO, that's out of the scope for an aerodynamics mod. FAR does have some very simple stability systems, but those were cut from what would become NEAR after user feedback was basically, "NO GUIS!" for a FAR-lite kind of thing. Even so, no amount of control system can save a poorly-designed vehicle, and that's where most of the problems come from. Too much TWR. Too severe a turn. Not enough restraint. If you've built something good, I suspect MJ should be able to handle it. I've used it for launches in RSS so I don't have to wait for everything to finish, it works good enough, though I'm not the best MJ guru out there.
×
×
  • Create New...