Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    That's... odd. I would think that it would be fine. Go into the KJR folders until you get down to the config.xml; open it in notepad and set debug = 1. Then cause the issue again and post a copy of the output_log.txt so I can see what's happening.
  2. ferram4
    Lemme guess; the adapter has no specified part strength, right? If that's the case, then it's using the far too low default 22; try adding "breakingForce = 100" or some higher number to the config and see what happens. Basically, it's falling apart on physics load with the higher forces caused by the stiffer joints. I've got some stuff lined up for the next release that should fix that, which should come out after KSP 0.23 is out and I've confirmed compatibility.
  3. ferram4
    @Dragon01: Well, ignoring the end points, you'd just set it to have an area of ~0.254 (since it's just the outer area of the cylinder), which is the only thing affected by radius. The rest is taper-based stuff. So, since there should be negligible pressure drag (which is what is handled by the drag curves) set that to 0, ranging from -1 to 1 so that it gets all directions. Lift and moment curves should also be near 0, since it's really not that large a part, so just set those to zero as well. That should handle it fine. @azza276: Have you set up the control surfaces properly? How about the vertical tail? If those aren't set up properly there might still be issues. FAR is only affected by scaling on the fuselage parts, but those you shouldn't need to mess with.
  4. ferram4
    What kind of craft are you flying? It sounds like you just need to shift the wings back a little bit and set up separate, smaller control surfaces for roll so that it isn't capable of doing 10 ailerons rolls per second. If you're building your plane out of nothing but control surfaces, you're going to have a bad time; use unmoving wings more then.
  5. ferram4
    The TWR issue is that Modular Fuels sets the engine's Isp variation to control thrust while keeping fuel consumption constant, as it does in real life, unlike in stock KSP, which varies fuel consumption while keeping thrust constant. KER is unaware of this change, and is still assuming that engines will make the same thrust on the pad as they do in vacuum; you can calculate your TWR by multiplying your current TWR by atm Isp / vac Isp. Basically, the tool is making a foolish assumption, and so it's producing a bad answer. The stretchy tank fuel issue is the result of continued errors in the exact amount of fuel that can be carried as the tanks are scaled. Basically, what's happening is errors are accumulating to the point of serious inaccuracy. If you reset the fuel in the tanks after every resizing it will get rid of the error.
  6. ferram4
    The rolling issues sound like a slight asymmetry in the design, normally caused by the vehicle flexing unevenly. Add more struts to fix it. If your planes are to twitchy under control inputs, either reduce the number of control surfaces, make the plane more stable, or use FAR's control surface GUI to set a lower deflection angle for the control surfaces. The SAS jitters are caused by the same issue; your plane is too responsive, and the solution is to reduce the amount of control surfaces. If the SAS jitters are primarily in roll, remove the number of roll control surfaces. All of the issues sound like design issues mostly.
  7. ferram4
    Well, I will say that it looked like the longer side tank went up to almost the top of the tank. Maybe it's just my perception, but that screams wrong. What I meant was that the shroud didn't fit to the mercury capsule or the adapter below in the config you posted. So there was this magical floating ring around the mercury-atlas connection.
  8. ferram4
    @NathanKell & Dragon01: Took a look at it; I know what's wrong. FAR's screwing up on the decoupler calculation, since it's a very large change in diameter from top to bottom on that part. The best solution would be to manually define a FARBasicDragModel to handle it; look in the FAR readme for what to put in the config file. Give it very low drag, but a non-zero area so that things don't break. Since the strap decoupler is a very strange case, I don't think it deserves me trying to code in some type of special exception. Also, some of the models didn't resize with that config, or resized too much. The shroud around the Mercury retropack was too big and one of the side tanks on the Atlas was much taller than the other. I don't know if that's the way it's supposed to be, but it looks wrong. @azza276: You need to define a surface attach for both wings, so that the CoL is placed correctly. Then, if the CoL is offset with both attached, you need to "mirror" the surface attach on one of them so that the CoL is shifted properly. What it sounds like is that the right wing places the CoL properly, but the left wing places it in the proper place if the wing was clipping through the fuselage. Does that make sense? So if you flip the direction of the surface attach FAR will know to fix that. @SnappingTurtle: If you think that you can find some way to reduce gravity losses from 1 km/s and raise drag losses above 100 m/s, more power to you. The thing is though, you won't be able to reach terminal velocity without risking a loss of control on your rocket by going ridiculously fast. There is no reason to reduce throttle except for control purposes, the atmosphere does not eat all of your dV anymore.
  9. ferram4
    Yeah, that's what I said, except wings only use the surface attach nodes to calculate the offset of the CoL from the wing root. After that, wings don't do anything more with it. Every part has attach nodes. That is how the ability to attach parts to each other are defined. The stack nodes are a subset of attach nodes, used to connect a specific section of one part to a specific section of another (top of tank to bottom of another). Surface attach nodes are another subset of attach nodes used to define radial attachment of parts (fuel tank slapped on the side of another fuel tank), used on all parts, stacking and non-stacking. I dunno what you managed to do with the config, but I guess that works. I haven't played with attach nodes too much.
  10. ferram4
    @azza276: The angle values aren't used anymore for anything but the surface attach (I believe) on any parts, so FAR doesn't do anything with them. That said, the node values (other than the surface ones) do nothing for wings. Fuselage and wing parts use completely different aerodynamic models; the former makes use of attach nodes for drag characteristics, the latter only uses the surface node to figure out how the model is oriented. @SnappingTurtle: Yeah, it'll make quite a bit more drag, but you'd be surprised how much lift you can make while still stalling something; it's just a lot draggier. It's probably good for landing.
  11. ferram4
    No, that would be because you don't have the CoL on. Without having the game run aerodynamic calculations it can't estimate the stall angle.
  12. ferram4
    @azza276: In the configs you'll see each stack attach node specified, as well as a surface attach node (node_attach). That's what I meant about the tail fin and delta wing nodes. Unconnected stack attach nodes are used by FAR to detect large, relatively flat surfaces in the airflow; this is how it handles a fuel tank without a nosecone, for example, or the drag of a relatively flat command pod bottom. The "new" attach node system hasn't been added yet, and currently they still use the "old" data that you found. Don't worry about questions. No worries. @SnappingTurtle: They'll make more lift if they're placed on larger wings, but ideally you want them near the plane's center of mass for pitch-control purposes. Deflect them as much as you want, so long as they don't stall; you can probably get away with ~20 degrees and you'll be fine.
  13. ferram4
    The offset robotic arm attach node probably causes some issues for the cargo bay; attach something to it and that should clean things up. The nodes on the wings wouldn't matter if the wings were set up to use the FAR wing code, but since they aren't the standard FARBasicDragModel module would be applied to them instead, which would cause the nodes to be used in calculations and the wing to be treated like a fuel tank or engine or something like that. It's okay if the regular attach nodes stay there, so long as the FARWingAerodynamicModel is applied in the config. The wing's part origin needs to be at the midchord point on the wing root for the CoL to be placed properly. Further, the wing needs to have some type of surface attach node specified so that it can be surface attached correctly; this is how FAR figures out which direction to offset the CoL in so that it is halfway down the wing span. Take a look at the differences between the stock tailfin and deltaWing parts and you will see how they are actually flipped, but with flipped surface attach data as well to counteract that. The part origin can be offset by using a MODEL{} block. I can't think of any examples offhand, but if you toy with PartWelder the resulting models are offset using the same type of logic.
  14. ferram4
    @azza276: Camlost got a lot of the basics down, but the main problem is that the Tiberdyne Shuttles aren't set up to work with FAR. Depending on where the part origin for the wings is placed it may not be possible to make them work. FAR's wing code is designed to function well with wings designed like the stock wing parts; reversible, surface attached, symmetric. Anything outside of those parameters may not be capable of being set up to work. @toadicus: I'll check out the craft in my dev build; I've changed how some of the wing code works, so I may have already fixed the issue. I think removing the non-airbrakes from the action group is just a result of the placebo effect.
  15. ferram4
    Considering that the standard "rating" settings assume that the Mainsail (and the Skipper too, IIRC) are rated for 1 atm. This means that KIDS calculates things so that the Mainsail makes 1500 kN on the pad, but then thrust increases above that as altitude increases. This allows you to easily figure out TWR with the heavy-lifting engines when you're designing your launch vehicle. Essentially, it applies real-life logic to the thrust values state in the editor for each engine.
  16. ferram4
    @BrickedKeyboard: Ultimately, the only way to measure that would be test flights. Most of the reasoning behind picking one aerodynamic configuration over another isn't so much to reduce the drag losses but more to protect the rocket from becoming unstable or breaking under the loading. @rosenkranz & drtedastro: Yeah, MJ currently doesn't know how to handle FAR's aerodynamics, nor does it even detect that it's there and that the stock aerodynamic model it's using is wrong. I think that's currently being worked on for MJ, but any type of FAR-internal landing prediction is out of the plugin's scope. It would also be horribly inaccurate due to how much user inputs can change the trajectory in-atmo.
  17. ferram4
    Obviously, you have an older version of modulemanager.dll floating around somewhere. You only need one copy of Module Manager in the GameData folder for things to work, and the most recent version is yelling at you to get rid of the old version so that aren't any conflicts. Go through the GameData folder and get rid of any modulemanager.dll's that are there, and leave only the modulemanager_1_5.dll. When you reinstall things, make sure that one of the older packs that you are installing doesn't have an old copy of modulemanager in it.
  18. ferram4
    @ZobrAA: IIRC, DRE uses raycasting to detect whether a part is exposed to the airflow. What's happening here is that the part is raycasting from the part origin (in the pod) and is hitting the heat shield model (which is still part of the pod) and so is being assumed to be shielded. I guess it could be fixed code-wise by going until the raycast hits a different part, but for now the welding is a problem. You need to understand that most plugins are designed around specific assumptions about parts to make the calculations simpler and faster. Welding allows you to easily violate those assumptions and break the plugin. In this case, the assumption would be that each part has only one collider, which happens to contain the part origin.
  19. ferram4
    Probably not. The level of calculations that would have to be done to properly account for the area rule would introduce a very noticeable amount of lag for everything, since it would have to be done in real time to handle how the physics would change as the vehicle sideslips. Also, since we don't have parts that we can properly contour to properly area-rule our crafts, it would essentially be a feature that couldn't be properly taken advantage of.
  20. ferram4
    @localSol: Well, it requires spaceplanes with the fuel to return to land at Mach 1. I was able to bring the FAR Velocitas down at Mach 0.7 once, and the change in the speed of sound should be enough to bump that up. This was at one of the low points on the surface. Don't make the mistake of assuming that gases and liquids behave the same way. Density largely doesn't affect the speed of sound of gases since the density of a gas is generally much lower than that of a liquid, and it is primarily dominated by temperature and the gas compositions. Ultimately, if you assume a calorically perfect gas, the speed of sound is only based on temperature and gas composition. And real gas effects aren't strong enough at most pressures to be worth modeling. @Camacha: Ah, yeah, I should add the ability to choose the gas composition in the editor analysis to make sure that things are handled properly. I'll add something to the GUI that states the atmospheric composition with the specific gas constant for reference. The actual pressure numbers aren't changing, but I'll look into changing the density numbers so that the pressure-density relationship makes sense, and that will still be available in the GUI. If you want to actually know what's happening pressure or density wise somewhere, you'll have to send a probe down. @Starwaster: Collision isn't used except for cargo bays, to determine whether they are open or not. @Goozeman: Yep, sounds like we found the same solution. NASA contractor report 187173. As an aside, I'm thinking that instead of making Laythe have the same atmosphere as Kerbin, that I'm going to cut in some portion of sulphur dioxide to explain the relatively high temperatures out there and make it more "alien." Now I just need to figure out how much is necessary to keep the same mass fraction of O2 in the atmosphere so that there isn't a discrepancy between the intake air and the atmosphere.
  21. ferram4
    Atmospheric composition will be listed in the config.xml and can be modified at whim (though I'd prefer it if you didn't). Automatically adds an entry for each body id#, and if a body is loaded that doesn't have a composition preset explicitly stated it defaults to using air. I don't know how it will work with Planet Factory, but it will handle the expansion of the stock solar system perfectly fine. Whether it works with Planet Factory is dependent on the order that things start up in. Fairing determine what pieces should by calculating the bounds of the fairing object and then searching through the vessel's parts to see if the part origin is inside the fairing. Since KW Rocketry parts have their origins placed at the center of the engine, they should be shielded perfectly fine; I'll investigate and see if I can find any errors.
  22. ferram4
    Well, it turns out that at 300K, here's what you get for sound speeds: 21% O2, 79% N2: 347 m/s 100% CO2: 269 m/s 100% H2: 1316 m/s Sound speed is calculated as: a = SQRT(T * γ * Rgas) where a = the speed of sound in m/s T = temperature in K γ = ratio of specific heats Rgas = 8.3145 * J / (mol * K) / M M = molar mass of the gas, in kg / mol The ratio of specific heats is nearly constant and is largely based on the molecular shape and arrangement of atoms. For a diatomic gas, it's ~1.4; for CO2, it's ~1.28. For water, it's ~1.33. For a monoatomic gas (argon, xenon, other noble gases) it's ~1.66. This is the number that controls a lot of supersonic phenomena, such as the maximum pressure coefficient, shock angles, pressure behind shocks, the maximum angle that a supersonic flow can be turned through in an expansion fan, etc. Overall, I haven't done too much testing to see what the big differences are, but suffice to say that the different atmospheres (with the exception of Jool, which is weird) feel different, but not horribly different. It does require spaceplanes to land at Mach 1 on Duna though. Which is a serious win.
  23. ferram4
    It indicates that he's working with an old version of FAR; that's a deprecated KSPEvent that was used to update the CoL data and some other editor stuff, as well as existing as something that could be called if it was absolutely necessary to reset the drag parameters. There's no point to it being there now, it doesn't do anything.
  24. ferram4
    No, because I'd prefer to keep my clumsy mistakes to myself, thank you. It's not polished enough yet.
  25. ferram4
    I think I'll be able to get that to work... Now I have to research the details of how these things are set up so I can model them correctly.
×
×
  • Create New...