Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    @knicewar: Could you elaborate some more on the particular qualifications and skills that you're looking for? I've gathered quite of bit of experience coding in C# as well as quite a bit of experience handling physics simulations through my FAR aerodynamics plugin and KJR physics stabilizing plugin and I would like to be able to showcase those skills in a relevant manner.
  2. ferram4
    @Hyomoto: U0 is supposed to be horizontal velocity in steady, level flight so that seems about correct. @Surefoot: Leading edge flaps should also be as close to the CoM as possible, but they won't affect the pitch moment as much, so they're less important. Control surfaces should be as far from the CoM as possible so they have as much leverage as possible. Generally, delta wings and flaps don't seem to get along too well, though I haven't checked real life planes to see if that's perfectly correct.
  3. ferram4
    @Miltitrace: That's close to correct, but it's mostly due to the size and shape of procedural fairings, which are less blunt than the nosecones, reducing drag quite a bit. If your rockets look anything like that test rig, they're too short and wide and need to be made taller for them to be stable. @Hyomoto: Odds are that you don't have enough flap surface, combined with the flaps being too far behind the CoM. Most flaps do cause a pitch-down tendency, but the elevators have enough control authority to counteract this. Ideally, you want a plane where the flaps are exactly on the CoM, with the tail making it stable. A good way to figure out how much lift you need is to go to the Derivatives tab and take down the wing area. Then go to static analysis and take down the maximum Cl that you can achieve without a tail strike (you'll have to use your judgment for that). Multiplying them will give you lift area; multiply that by 0.5 * 1.225 kg/m3^3 * velocity^2 and you'll get the total lift at any velocity on the runway. Then take the plane's mass in tonnes (also in the Derivatives tab) and multiply that by 9.81 m/s^2 * 1000 kg / tonne and you'll have the plane's weight in N. Lift has to equal weight for liftoff; you can solve this out to get you: velocity = Sqrt(mass_in_kg * 9.81 m/s^2 / (0.5 * 1.225 kg/m^3 * Cl * Area)) And it'll tell you the velocity you can take off at.
  4. ferram4
    @Elthy: Yep, it should. It's just another part, just like any other. @Surefoot: Probably highly-stressed joints. We'll see if it still occurs when I get v2.0 out. @Damaske: You had a part that broke off and the part clipping caused things to explode. Yeah, part clipping causes bad things to happen. @Dragon01: I can look at that. I'm going to guess it has something to do with the mass of the the thing compared to the part it's connected to.
  5. ferram4
    Well, I gather that the Wren is the WAC Corporal and the Fat Albert is the Tiny Tim, but I'm not finding the actual significance of "Wren" as a name, besides it being a type of small bird. What happens if you cluster Fat Albert boosters? Can you produce a 3 stage rocket that will get it high enough?
  6. ferram4
    Actually, the latest version of FAR includes a fix to the config that hotfixes the Mercury retropack decoupler. So I don't know what his issue is, I've flown the Mercury Atlas into orbit quite fine.
  7. ferram4
    Launch clamps do weird things with RSS. They can jump around a bit and no one's really sure where that comes from, though it's probably some floating point issue during initialization.
  8. ferram4
    I'll add the negative deflection amounts back, but it'll require some testing to make sure that it clamps to certain values properly.
  9. ferram4
    The issue with that is that the solar panel covers have a really strange set that confuses FAR; it kind of thinks they're giant cylinders sticking out of the side of the rocket due to the way that the attach nodes are set up. The solution for special cases like this (as with all special cases) is to define a special drag model to take care of it. Go and add this to the config file for that part: MODULE { name = FARBasicDragModel S = whatever it's surface area is; you know more about the Dragon than me, you can figure this one out CdCurve //This gives it the properties of a flat plate with flow over it or into it, depending on orientation { key = -1 0 0 0 key = 0 1.2 0 0 key = 1 0 0 0 } ClCurve //Approximate lift of a flat plate in newtonian flow { key = -1 0 key = -0.5778 -0.462 0 0 key = 0 0 key = 0.5778 0.462 0 0 key = 1 0 } CmCurve //It really shouldn't have strong moment characteristics { key = -1 0 key = 1 0 } upVectorName = up //force it to use "part up" as the reference axis } That should help, though not too much if you get it far off of prograde.
  10. ferram4
    You've got two options: Pitch it up at a slightly higher angle of attack (~5-10 degrees) than the main wing. That offset in AoA will help make the canard stall sooner, but it won't help too much if you get the main wing to stall and will be detrimental if you get it to stall during a pitch-down maneuver. This is your only option if you're working with stock canards or B9 canards. The better option is to use pWings to make a canard with a much higher aspect ratio and less sweep than the main wing; this will make it stall at a lower angle of attack overall, but it will have a better lift slope to compensate. This method will help even if the main wing stalls and doesn't care about pitching up or down. This is also the proper way to do this sort of thing. In general, if you have two lifting surfaces on a plane, you want the forward surface to have less sweep / higher aspect ratio than the rearward surface, since it causes the forward surface to stall sooner and push the plane out of the stall.
  11. ferram4
    Yeah, I guess they are completely useless. After all, it's not like this asparagus rocket worked nicely: And it's totally not like two separatrons were sufficient to push those 3 jumbos with the mainsails and nosecones away from the rest of the booster: It honestly sounds like you're not using them properly, since I was able to make them useful in the same design you said they were useless in. There is no need for additional larger decouplers. This sounds like you're demanding new parts to make up for your own shortcomings in rocket design.
  12. ferram4
    Why not? Seperatrons work great for pretty much any staging situation. I've gotten rid of a lot of huge boosters using separatrons and I haven't needed larger radial decouplers.
  13. ferram4
    Changing breakTorqueperMOI shouldn't affect that; the affected parts should be breaking off instead of remaining attached. If that hasn't been happening, then it's probably the very high angular drive values, which I've backed off in the latest private version. And to my knowledge, DRE uses the acceleration on the part, not the acceleration of the ship as a whole for determining g-force damage, so that just means that it was jittery.
  14. ferram4
    Actually, assuming that you're coming in at a very high AoA, the baboon nose cones aren't that bad from an aerodynamic perspective. It presents a very large radius at the nose to reduce aerodynamic heating, and on the back face where less heating occurs it has a much smaller radius, while the combination has the smallest nose possible at low AoA for better performance at low supersonic speeds. I'd have to run CFD on them to be sure, but that's my initial thoughts on the nose. I like the left-most one to be honest. Make the nose itself grey, the bottom surface and the bits just above that black, along with the defined lip for the nose, make the rest the HL fuselage color. It'll look great.
  15. ferram4
    @DaMichel: A known issue where the drag of very short adapters is much higher than it should be. I've had a lot of trouble coming up with ways to fix it though. The docking port error is due to the fact that the origin of the docking port is just slightly inside the bounds of what the cargo bay checks for parts to cancel drag on; it should only affect small parts in that exact situation though, and the alternative is that things that are on the ends of the cargo bay that should be shielded aren't. @rhoark: You'll find more information Googling either longitudinal or lateral stability and looking from there. There is a relatively new Scott Manley video posted in the OP that covers a lot of stuff. There's also the help windows, added specifically for this purpose.
  16. ferram4
    Yeah, just go back to v1.7 until I get v2.0 fully worked-out. It only needs some polishing and then I'll release it. I tested with LameLefty's ship and it's solid as a rock in the latest dev version.
  17. ferram4
    @Surefoot: I keep meaning to set up something like that, but I never get around to it. @camlost: I've got a prototype bit of code that will calculate the cross-sectional area of a bunch of parts as a function of body station, but it only works for purely convex cross-sections. I need to extend it to concave sections, and then properly account for hollow sections. And then add code to figure out how to divide up the vehicle into various bodies so that their properties can be calculated, since a pure aggregate approach will swallow the entire CPU whole and demand more. Once that's done I need to figure out how to handle rebuilding the cross-section map when staging occurs, especially if the body should be modeled as being in a completely different orientation. It's going, but slowly, since I'm working on other stuff as well. No serious issues yet, but I suspect those will crop up once I start to take the cross-section map and send that to another thread to calculate aerodynamic parameters; I've never done multithreading before. @likke_A_Boss: Bug in an earlier version of FAR; update and it will be fixed.
  18. ferram4
    As a side note, since we're talking about aerodynamics in KSP vs. real life, the actual density, pressure and temperature parameters are close to correct for a real life atmosphere (though density and pressure following a linear relationship is wrong). The problem is that the drag area of parts in KSP is much, much higher than it should be; either the surface area is too high or the drag coefficient is too high. Whichever it is, it results in drag forces in KSP that are somewhere between 2-10 times as high as they should be in real life, at least for rockets and planes.
  19. ferram4
    @sjgold: Let's do some math, shall we? Your vehicle is a Mk1 Pod (0.8 t), a Mk16 Parachute (0.1 t) and an RT-10 SRM (0.5 t dry, 3.7475 t gross). So burnout mass is 1.4 t; initial mass is 4.6475 t. Assuming that it spends its entire burn with sea level Isp (225s) this rocket has: dV = Isp * g0 * ln(m0 / m1) dV = 225s * 9.81 m/s^2 * ln(4.6475 / 1.4) dV = 2648 m/s So the speeds you've gotten it up to are completely reasonable, given that it actually has slight more dV due to the decreasing air pressure. I suspect you're confused because normally the atmosphere just sucks away any velocity like mad; this is not physically correct, unless Kerbin's atmosphere is actually made out of pudding. This is what is supposed to happen.
  20. ferram4
    You probably managed to get the beginnings of a stall on one of the fins. Or managed to get into highly nonlinear flow regimes.
  21. ferram4
    ModularFuels is up to date then, right? There was an issue involving them awhile back. With so many mods it's almost impossible to figure out the source of the issue.
  22. ferram4
    Fins aren't angled at all? Angle of attack is always less than 10 degrees? Using FAR v0.12.5.2? Picture of the rocket?
  23. ferram4
    Well, it depends on what level of symmetry you attached them on and how far off prograde you're taking the rocket. 3-way symmetry in particular can cause uneven lifting forces on either side of the rocket when the sweep of the fins is taken into account.
  24. ferram4
    The null is being thrown by RealChute. Go make sure you're using the most recent version; if you are, go and provide reproduction information to stupid_chris in his thread.
  25. ferram4
    Without an output_log.txt from the KSP_Data folder, no one has any idea what's going on. Odds are it's a bug with another mod though; make sure to state a complete list of all the mods you're using and their respective version numbers.
×
×
  • Create New...