Jump to content

ferram4

Members
  • Posts

    3,132
  • Joined

  • Last visited

Everything posted by ferram4

  1. Alright, so KJR v3.1.7 is out. This doesn't actually include any changes and is merely a recompile for 1.1.2, and there are no issues in KJR itself in 1.1.2. However the CompatibilityChecker utility uses a bit of code that is known to have changed in 1.1.1->1.1.2 so I would suggest updating to ensure that if CompatibilityChecker triggers that you don't have things break later. @rolls: No, you would want the last version before 1.1 compatibility. Never assume mods are compatible across KSP versions, especially not major version updates. The changelog will tell you which one you're looking for.
  2. Alright, so FAR v0.15.6.3 "Kindelberger" is out, with the 1.1.2 compatible MM bundled and a recompile to fix the editor GUI issues. Also, @Somgosomgo, turns out you found an issue where I derped and somehow broke voxelization on KerbalEVAs, so... good job finding that. Anyway, today's codename is named after "Dutch" Kindelberger, who was an engineer at Douglas Aircraft before leaving to head up North American Aviation in 1934; he was the one who countered Great Britain's request to build P-40s for them with the response that they could build a better design, which led to the P-51 Mustang (designed by a NAA team headed by Lee Atwood, who joined NAA with Kindelberger). Also, I am slightly annoyed at the frequency of updates I need to keep making to keep up with the current KSP version. Not just because of the work and the rat race (which appears to be worse than during the pre-release(!)) but because I like the codenames to at least stick around for a bit before being replaced. These are important people that I'd like to recognize, and having Kartveli disappear in basically less than a day is disappointing, though bitterly appropriate I suppose.
  3. @Somgosomgo: Once again, I cannot reproduce any issues. Do you have more complete reproduction steps? And you are on KSP 1.1.1 and have not updated to 1.1.2, correct?
  4. @Somgosomgo: I cannot reproduce any issues, I suggest you try reinstalling the your mods, particularly FAR without using any mod managers of any kind (including CKAN) and try again. There is nothing in the log that points to framerate issues nor a cause for the crash, and the crash does not appear to be connected to FAR in any way.
  5. Go up, start your pitch over at a certain speed (probably ~100 m/s, with an initial angle of 5 degrees), switch SAS mode to prograde once you've got that, and then make adjustments once out of the atmosphere doesn't exactly depend on luck. Look, I'm sorry that MJ isn't aggressive enough for this, but... FAR isn't gonna sacrifice realism because MJ is being timid in controlling things. Also, btw, last FAR version for 1.0.5 had the same exact lifting body physics, so any difference in control-ability between 1.0.5 and 1.1/1.1.1 isn't on FAR's side.
  6. No, get out of here with that pre-1.0-stock-aero advice. There is no reason to limit speed and he's already got a TWR of 1.2 at SL. Throttling down near Max-Q isn't even an option until initial TWR is already at 1.6, and he's nowhere near that. So, that fairing is better, but it's still too blunt. You'd be hard-pressed to find rockets with fairings that are that blunt, most go for much, much sharper cones instead. Honestly, to me it just looks like insufficiently aggressive control. The rocket needs to be kept closer to prograde the entire time and MJ is just being too timid to do the job; prograde SAS should do it quite nicely. Edit: I tried rebuilding your design, though slightly modified; I'm pretty sure that I gave it a longer (but just as blunt) fairing and didn't give it a payload, so it should be much less stable. This is how far it got before prograde SAS lost control, not much higher up but going a lot faster and clearly not going to space with that shallow of a trajectory. I think your control system just isn't aggressive enough to control it.
  7. Also, your fairing is stupidly blunt, which means that it will make a ton of drag, especially as you approach the transonic regime. Add that to the body lift effects, and your entire design is basically an experiment in "how to make a rocket as unstable as possible." Also, MJ does not appear to be as aggressive in keeping it on target as it really needs to be, which might be part of the problem. And don't sit there and tell me that body lift is too high. Body lift is actually probably lower than it should be right now, tbh, but that's the result of not having very good models for how partial flow separation affects body lift over the cross-section-reducing sections of vehicles, so I assume that the entire result basically cancels out to no potential flow body lift effects there.
  8. Alright, v3.1.6 is up, which fixes the issue Brusura found and includes some optimizations. No idea what problems you guys were having, even v3.1.5 worked on 1.1.1. If it was actually wobble-related I would blame any mod managers you're using for giving you an out-of-date version (much older than v3.1.5), and if it was not joint-wobble related I would put the blame somewhere other than the mod that only handles joint-wobble.
  9. Alright, so FAR v0.15.6.2 "Kartveli" is up, changelog has the details. Today's codename is for Alexander Kartveli, who was Republic Aviation's equivalent to Lockheed's Kelly Johnson. Basically, he was the top guy behind the Jug, the Hog and Super Hog, and Thud. Which if you don't know those nicknames, you should read up on the P-47, F-84, F-84F, and F-105.
  10. KSPedia is planned for much later, I need to overhaul the wings first and replace the Stab Deriv readouts with actually solving for the eigenvalues and presenting those in usable ways. Also, KKS is cool, but given that all of that stuff happens in performance-critical situations, I'm not adding the expense of reflection or adding it as a dependency, so not happening.
  11. @AccidentalDisassembly: Well, I found it. Which is strange, because I know I fixed this issue, which means that something changed between the last of the KSP pre-releases and full release that I missed. Oh well, I'll find it. And as for Hullcam VDS, I'm not surprised that it's breaking voxelization, because it does absolutely nothing besides throw in-game. Seems like it was built against the wrong KSP version or something. Oh well.
  12. @AccidentalDisassembly: As always, I need full reproduction steps with as few mods as possible. I've never had any issues with the stock fairings. @lude: Never use part welding. Ever. It breaks the stock game, it breaks mods. Just don't. And as for Hullcam screwing up voxelization, that's a new one. I guess I'll need to look into that then.
  13. I pushed a possible fix for the wing mass issue to the FAR github if any of you want to test and make sure it works. Didn't replace the base mass of the wing parts, so they're a lot heavier than they should be right now.
  14. @Red Iron Crown: Well, I have to disagree with that, primarily due to the fact that stock greatly underestimates the drag on pods during reentry and on rockets going through Max Q. There are a lot of things that you should be able to reenter in stock that you can't because reentry vehicles are just too slippery. @Ilya: That sounds a lot like a case of "not enough control authority for the TWR" and if the problem only shows up when you have SRBs involved, I'd guess the issue is just that you're outrunning the control authority you have. I'd suggest reducing the TWR at launch, adding more mass / payload, or adding control fins. Or make the payload narrower, this is also something that can happen if the payload fairing is too large (read: more than ~1.5 times the diameter of the rest of the rocket) and creates too much body lift as a result.
  15. @brusura: This is not a FAR bug. All of the values checked in FARVesselAero.Start() and in the above are incapable of throwing an NRE under normal KSP vessel creation conditions, regardless of how complicated. This needs to be fixed on the KIS side through proper creation of Vessels. Nothing I can do here.
  16. @brusura: Turns out that KIS was unnecessary for reproduction, but thanks for including it anyway for thoroughness. Found the issue: when multipart-joints are destroyed, I didn't clean up the lists for them, so when it redocked KJR was checking against joints that didn't exist anymore and that broke everything. Dev build has it fixed if you wanna mess with that now, I just wanna make sure I didn't introduce new bugs in the meantime.
  17. @Kowgan: Repro steps, logs, and mod lists would be helpful here, since I can't reproduce either of those issues.
  18. Well, they should be considering I just reproduced it and fixed it in the dev build. No idea when the ETA will be for it to show up in a release, because I think tetryds was intending to get some more stuff into it first.
  19. @Beale: Looking at the reports, I don't believe that KJR is the issue here. In the video case it appears that there is simply insufficient control authority for MJ to handle the design. It is possible that KJR is responsible for the self-destructs if the joints are under very high stresses, moreso than normally occurs in stock KSP with parts that size, but that should be more than mitigated by the simpler control setup when MJ or SAS doesn't have to handle any flopping around. And it certainly doesn't explain why MJ is being so timid in the video. From my tests, the Proton is fine with KJR and plain SAS. I suspect the problems lie more with either MJ or how the gimbals are set up with that first stage. I don't know which it is, but KJR does not seem to be the issue. Oh, btw, the LF/O ratios are off on the Proton 1st stage.
  20. Stall speed (actual stall speed, and using equivalent airspeed to remove density effects) depends only plane mass and max lift. However, if your design has too little pitch authority it will not even be capable of stalling; it will stop pitching up long before the wings reach their critical angle of attack, and from what I can tell, that design isn't going to stall, it simply lacks the pitch authority to reach the stall AoA anyway. Then the CoM location is a factor because a further forward CoM requires more negative lift from the elevator to keep the plane's nose up high enough, which will hurt your max lift. Oh, and there's another two problems. No plane ever lands at max takeoff weight. Most planes don't even have gear designed to land at max takeoff weight. They fly around and burn off fuel first because landing at max takeoff weight is dangerous. The other problem is that the fixed gear are completely borked; use the retractable ones instead, I've landed on the small retractable ones at 120 m/s with no problem.
  21. @Ser: I know for a fact that wing lift is too high at any angle of attack right now; that's because the wing interactions that you have going on are almost certainly going to result in more lift on that middle wing than should be there. The problems with your plane are at least four-fold: 1) you lack a horizontal tail to provide pitch authority. 2) you lack takeoff flaps on the design, and 3) your CoM is WAY forward of where the CoM on the Phantom would be, since the cockpits in KSP are extremely heavy for so no good reason. 4) your wings have no angle of incidence built into them, so the plane needs to rotate more to take off. While I can't be certain because you've hidden the location of the main gear, I suspect a fifth problem: the main gear is too far behind the CoM to allow for proper rotation. There are a lot of problems there that make your design incomparable to the Phenom.
  22. Alright, so FAR v0.15.6.1 "von Kármán" is out, fixing a critical CPU usage bug that most of you have been getting hit with and a pair of RealChuteLite related bugs thanks to stupid_chris. Today's codename honors Theodore von Kármán, who is known for his work in supersonic aerodynamics and turbulence. Von Kármán was rather prolific, contributing many theories and models to aerodynamics as well as other fields. Here in KSP we primarily know him for the concept of the Kármán line.
  23. Yes please. Let CKAN and the other mod managers handle their sphere, and let us handle ours. Making it a rule should help make the delineation clear to the users who (through no fault of their own) think that modders are responsible for CKAN.
  24. @Quintkat: ...we don't even have the power to make things incompatible on different OSes. I suspect an install error or leaving SAS on to override it. Remember, if you want support, you need to provide complete log files and complete reproduction steps. No ifs ands or buts.
  25. It was not removed because it slipped my mind. Too much other stuff going on.
×
×
  • Create New...