Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    @Everyone with cargo bay issues: I'll look into it. I've got some things that I think might help make it work better, but that requires some testing. A lot of it has to do with parts that are radially attached to thinks have their origin at the attach point, and FAR determines shielding based on that point's location. I think I can do something more sophisticated though. @Razorcane: Well, your rocket has no thrust vectoring, and real life rockets have a lot more thrust vectoring than KSP rockets, so the need for fins is to be expected. Even with the Goo Canisters on the top, it should be fine. The only reason that thing should be twisting is if you manage to get an asymmetric stall on the fins, which should only happen if you bring your rocket something like 15 degrees off prograde. There's no antenna hidden on the other side, right? Because that could mess things up.
  2. ferram4
    @kiwiak: Does it occur without KJR? It might just be a problem with the FASA parts. Can you reproduce it without mod parts at all and provide reproduction steps? @jinks: Disabling the KJRLoadLock alone will allow you to do what you want, but will also allow you to fly an indestructible rocket for the short time when it's "easing" physics. In addition, disabling the easing entirely will probably cause Interstellar to destroy everything when parts come out of warp, which is what KJR's easing is intended to do. @merendel: Can you reproduce the issue reliably? Without having reproduction steps all I know is there's a possible bug that may or may not be caused by KJR, which means that I can't fix it if it is.
  3. ferram4
    Well, that sounds like either your vehicle is aerodynamically asymmetric or there's a bug; a picture would be helpful in determining which it is. All of that said, you can install one of the 0.11 versions, there's a link to a mediafire folder with them in the first post of the thread, but you won't be able to use the editor at all unless you downgrade to KSP 0.22.
  4. ferram4
    Ah. I see the problem: 5 km is way too far up to start a gravity turn with FAR. Try when you're going between 50 and 100 m/s, whatever altitude that the rocket is at when that happens. 5 km starts are for TWRs of 1.1 in RSS and for standard rockets in KSP sans FAR.
  5. ferram4
    @ayana: You still haven't told me which cargo bays are causing the problem, which means that I can't reproduce the bug, which means that I can't fix it. There was a reason I asked what cargo bays you were using. @thorfinn: I suppose I could do that... It'll just end up being something else on top of the current deflection parameters. Only problem is that it's likely to break compatibility with planes made in old versions, and then I get to hear all the complaints from that. @Razorcane: Older versions are available from the mediafire folder link in the first post of this thread for that exact purpose. However, you're going to be limited to anything 0.12+ if you want to use the SPH or VAB without things locking up, and you're going to be limited to 0.12.2+ if you don't want game-breaking bugs in flight. If you want to get rid of minor bugs, you'll need to use 0.12.5.2, since all the other versions have issues. That said, your problem is having too high a TWR. Fewer engines, thrust limiter, throttle: use them. Using early versions of FAR will not get rid of these issues, and may simply exacerbate them; your designs need to change.
  6. ferram4
    @Tidus Klein: I'm going to end up nerfing all the jet engines a bit to compensate for the lower drag. Really, you should be using camlost's AJE for proper jet behavior. @Da Michel: Part of the issue is likely due to the way that FAR tries to approximate lots of wings together, which really needs to be redone. Pwings is actually more correct than the stock wings in this case. As for the numbers that are relevant to FAR: b_2: distance from root to tip in meters; this would be the length of the control surface along the wing MAC: mean chord in meters; this would be the distance from the pitching point to the trailing edge of the control surface e: Oswald's Efficiency; measure of how much extra drag the surface makes when it makes lift; lower causes more drag taperRatio: ratio of tip chord to root chord MidChordSweep: sweep angle of a line down the center of the wing connecting the root and the chord; measured relative to the original orientation of the surface Keep in mind that these numbers are defined for the control surface in its local space, not the plane's orientation. @ayana: What parts outside what cargo bays? You don't get to manually define what parts are shielded or not because it's equivalent to being able to cheat part drag out of existence, which isn't happening. @plausse: Most of the shuttle mods aren't built with FAR in mind at all, and the only time I know of someone trying to get Buran to work it didn't behave in any realistic way at all. There's not much that can be done config-wise to make it work if the parts aren't set up ahead of time to be similar to the way stock parts are.
  7. ferram4
    @kiwiak: The only way that should happen is if you came out of warp just before crashing, which would cause the rocket to still be indestructible after coming out of warp, or if you hit using landing gear / landing legs and nothing else hit the ground, since the gear / legs works pretty well as a force-insulator, even in the stock game.
  8. ferram4
    This mod does reinforce docking clamps, but they will not be as rigid as other parts by intention. Docking ports are not as stiff as other parts, and you need to design your crafts accounting for the weak point.
  9. ferram4
    @Orionkermin: Keep the old version on hand for when the next version of FAR comes out; if my solution ends up working, you might want to switch back to your original method. @Amaroq: Unless you've got a very weak connection between the payload and the rest of the rocket, top-heaviness is desirable; it's the equivalent of having the CoM ahead of the CoL on a plane, and it makes your rocket aerodynamically stable. In addition, asparagus staging isn't verboten, but it needs to be more like the Kerbal X has than what most people come up with in order to keep the rocket properly stable and unlikely to have issues. @Naten: Changelog, included in experimental's readme.
  10. ferram4
    @Orionkermin: Currently there's nothing you can do due to the way that FAR uses attach nodes to work out drag. I'm working on something that I think will help with that in the future, but I have no idea if it will actually work. The two bottom nodes do have the same "type" of name, right? E.g. bottom01, bottom02. That will make handling the situation a lot easier in code. @MAKC: A lot of the drag on the wings is due to drag induced by lift; there's not much that can be done about that, I'm afraid. Otherwise, that seems about right, since getting above Mach 1 at very low altitudes is pretty difficult / dangerous. FWIW, at that altitude the F-15 can only get up to Mach ~1.3, but it has a lot more thrust behind it, so I think you're fine. Of course, I'd be worried about the plane flying apart at high gs during that, but that's just me. @Amaroq: Yeah, standard KSP design isn't too efficient with FAR. More modest, sane designs are always rewarded much, much more.
  11. ferram4
    Changelog, not integrated into first page because it isn't a full release yet.
  12. ferram4
    So many posts! Argh! @White Owl: Unfortunately, that feature was removed since it turned out to be kind of inaccurate. I've generally found that deflections above 10-15 degrees cause stalling for pitch canards (depending on the overall AoA of the plane), that 15-20 degrees is generally good for ailerons, and elevators can get away with anywhere from 25-30 degrees. I've been trying to find a way to get the feature back in in a useful form, but I haven't figured that out quite yet. @TeeGee: For the Plane-with-SAS-wobbling question, that's due to how SAS functions with high control authority and some issues with how FAR handles the control surfaces currently. I've got a sort-of fix in the experimental, but I don't know how well that works at the same velocities. @Amaroq: What in God's name are you launching that gets a terminal V of 105 m/s? I think the worst I've ever seen is 215 m/s on the pad, and often it's much higher than that.
  13. ferram4
    @BananaDealer: Bug reports like that without a copy of the output_log.txt aren't much use. I have no idea what's breaking, only that something's breaking and that I've never seen that issue before. Post the log (not KSP.log) and we'll see if anything useful can be found in it. @Andrewmacor: Is the reentry vehicle tall and narrow? Then that's intended behavior; you'll note that no real life reentry vehicles are like that. You need the reentry vehicle to be short and squat with as much mass right behind the shield as possible. @pingopete: Config.xml: change sonic additional drag to 0.2, change incompressible drag to 0.01, change node scale factor to 1. The back end of things makes more drag to make them more stable in stock KSP compared to real life.
  14. ferram4
    Actually, I'm kind of annoyed at the frequency with which you call this trivial. It does take time to collect all the data, make sure that it's correct, and make sure that KSP functions properly with it set (after all, you are requiring it to make the mod function). General trend that I've seen is that in programming, the more someone talks about it being "trivial" to implement and make work, especially when someone else has to code it and make sure it works, the more the person talking has no idea what they're talking about. Repeating that it's "trivial," "minimal" and "reasonable" again and again just makes me think that you don't actually have a compelling argument for this and feel like if you assert your "reasonableness" enough you'll eventually convince everyone against you to agree, despite the fact that you've been implying that all of our concerns are simply unreasonable and can be dismissed. As to the difference between coding changes and this, when the game's API changes there is generally a good reason for it; a new feature got added that required it, code got refactored for performance, bugs got squashed. You're asking for, "do this to make your mod not break," and you still haven't responded to my point about how it will discourage new modders who don't know why their first attempt at a mod doesn't work for no apparent reason. You do have to understand that there currently aren't any mod managers that require such a metadata file for them to work, and arguing that we need one because it could be used that way is really arguing for a solution to a non-existent problem.
  15. ferram4
    Agreed with Greys. You did say in the first post, quoted to make sure you don't change it on us: So yeah, you started this on a negative note and with a tone edging towards controlling how mods are set up; you brought this on yourself. As to the actual subject, why should any of this data required to make the mod run in-game? Yeah, it's a small hurdle for an experienced modder who knows he has to do this, but why should it be forced? It brings no benefit to me by making this required but it does add another thing to check on and possibly screw up when setting up mods for release. It'll also add another thing for new modders to have to deal with when setting up their first plugin; it's a non-obvious hassle for someone with no experience to deal with, and they might just give up when they can't figure out why their small little mod can't be made to work in their own install, depriving the community of mods. Finally, I find the attitude of, "The Greater Good, so modders should be forced to do X," a little irritating, especially since you won't have to put any effort into setting this up and dealing with all the unforeseen consequences (they will exist, don't dismiss it as "trivial" to set up, or you're actively contributing to making sure there are consequences), but I will.
  16. ferram4
    @paju1986: First off, if it's exploding from overheating then that's a DRE problem, and FAR doesn't interface with DRE in any way. Nothing you try to change in FAR will fix that. As for the cargo bays, check to see if parts are shielded when the bay is open; that might mean that something is happening backwards for some unknown reason. It is a fairly out-of-date part, perhaps that is part of the issue. @illectro: Do you mean the stock drag parameters in the config file? Those are zeroed out completely by FAR, and so you effectively didn't change anything; your results are likely a sort of "piloting placebo effect," where you pilot better after making the change and thinking it will help. As a test of my own, I launched that deployable array many times in a payload fairing and saw no sudden rocket dis-assembly due to the payload, but I did find out why the part has so much drag: apparently when deployed the widest end has an equivalent radius 8 times that of the attachment end, and the tapering of the part over a very short distance is the cause of the issue. I've made a few changes that should allow FAR to quickly recalculate the shape of parts if it can properly detect that the part has an animation module, so that'll come in the next full update. So the short answer is that your experiment is likely invalid due to the way FAR functions unless both launches were run on autopilot and followed the exact same trajectory with the exact same longitudinal and lateral forces on the payload.
  17. ferram4
    @theSpeare: It's in the readme, but I'm not going to add it to the main post's changelog until it's integrated into a fully stable release. Here it is repeated though: CHANGELOG:0.13x1v------------------------------------ Features: Integrated numerous code optimizations and fixes from a.g. Rearward-facing tapered parts will produce less drag at hypersonic speeds, as they should; this may affect the stability of some designs Implemented more exact tapering drag based on cones rather than parabolas Wing sweep is better accounted for in multi-part assemblies Updated to Toolbar v1.7.0 Tweaks: Reduction in skin friction drag to more proper levels Some changes to control surfaces to make them play better with SAS Bugfixes: Fixed a typo in the config that would allow turboramjets to accelerate without limit @NathanKell: I'll look into it.
  18. ferram4
    @illectro: Then it's starting with a structural failure somewhere; perhaps the payload is breaking, and then that puts it "outside" the fairing, since the fairing doesn't check other vessels, and then everything goes to hell from there. Moar struts, less acceleration, less aggressiveness. @MAKC: I know about the AC in editor bug, I'm trying to track that down. The Cl numbers are correct as well, body lift can be very strange in some cases.
  19. ferram4
    Alright, there's an experimental that's out that gets a lot of the features out there. Still haven't adjusted the attach node drag system or all of the control surface stuff, but there's enough there to play with.
  20. ferram4
    @illectro: Yeah, unfortunately FAR's drag calculation seems to grab the deployed state of those transmitters, I'm not sure exactly why though. As for the fairing thing, what FAR does ever time the vessel part list is updated is it goes through all of the fairing parts, calculates their bounds, and then goes through the list of every part in the vessel to see if that part's origin is inside the fairing (for wings it also checks the wingtip for thoroughness, or it's supposed to; that doesn't seem to work either for some reason). So the only way the issue you're seeing should happen is if the transmitter wobbles outside the fairing at the same time as you're ditching a stage. FAR isn't calculating if something is inside the fairing every single frame, that would add lots of vector math, comparisons and iterating through part lists that are simply unnecessary. Try right-clicking on the transmitter and making sure that it stays "isShielded = true" the whole way, since that needs to be false in order for FAR to apply drag parameters; it acts the same as FAR detecting zero density and it simply stops running the rest of the code at that point. If the payload is wobbling too much, I'd make sure you're running KJR v2.0 rather than an earlier version if you don't want to wait until the official joint fixes. Things have gotten a lot better since the earlier versions of KJR. But anyway, the video will be good; video documentation of bugs is great, because then I can actually see everything that went wrong.
  21. ferram4
    Unfortunately, the most reliable way of "predicting" is F5, aerobrake, F9 if unsatisfied. Whenever MJ can actually manage simulating FAR stuff even that won't be perfectly accurate because it will heavily vary with how the vehicle is oriented during aerobraking. Aerobraking is fuzzy and not perfect with FAR, just as it should be, unlike in the stock game where you can reliably predict exactly what will happen down to the meter. FWIW, aerocapture with FAR generally ends badly due to heating or aerodynamics tearing the ship apart.
  22. ferram4
    @SSPutnik: I can look into it, but if the drag on the part is that bad then I wonder if there's something wacky going on with the model. @Kenken244: Without more information on each case there's no way to diagnose what's going on. The most accurate thing I can say is that something is causing your plane to become unstable, but if there's no consistent thread through all of it then it's probably completely different things happening. One possibility is that you're causing the plane to stall, and it's not capable of coming out of a stall. Stalls happen above ~15 degrees angle of attack (for each wing), so if you're trying to fly the plane like in stock you might cause that to happen. Another possibility is that the plane is particularly susceptible to Mach tuck and it becomes highly unstable near Mach 1. If that's the case you might have to move your wings up or down on the plane in order to deal with the drag and possibly shift the wings further back and compensate with more control surfaces. It could be that your planes just have some stupidly un-aerodynamic thing stuffed on the front that makes it unstable, in which case that's the source of your problem. You might just be dealing with a shifting CoM as fuel drains and you're not used to the way the fact that drag isn't dependent on mass with FAR, in which case you need to redesign your vehicles to account for the fuel drain. Posting pictures will make it a lot easier to diagnose what's going on with each case, but for until you do that I can't tell you what you're doing wrong.
  23. ferram4
    Hmm... I have been thinking about moving out there to find a job, it's just on the other side of the country... *Ferram eyes bank account and tries to figure out if he can afford to take a trip to SF and the Bay Area*
  24. ferram4
    @Camacha: Nozzles optimized for lower ambient pressures should have a longer, wider divergent section; it's the exit diameter that really matters (that's what accelerates the flow) and the length is only to prevent flow separation on the inside. A nozzle optimized for lower pressures will have (relatively) higher Isp at those pressures, but then will have (relatively) lower Isp at other pressures. Thrust actually increases with larger nozzles, assuming that the exhaust isn't at a much lower pressure than the ambient air. It's just that for most vacuum-optimized engines there's very little demand for high thrust due to being in orbit (or close enough) when they light it, so that complicated stuff is removed to keep the weight down.
  25. ferram4
    Pressure should be included in the constant as well; it's also not atmospheric pressure, but instead the pressure inside the SRM's combustion chamber. The length should remain approximately proportional to the diameter of the nozzle exit; how large the exit diameter is compared to the throat varies with the design altitude of the nozzle (1 atm pressure, 0.7 atm pressure, 0 atm pressure, etc.) and the pressure in the combustion chamber. For starters, I'd just have the entire thing scale with the throat diameter and see how that works out.
×
×
  • Create New...