Jump to content

ferram4

Members
 View Profile  See their activity

  • Posts

    3,132

  • Joined

  • Last visited

 Content Type 

Everything posted by ferram4

  1. ferram4
    @Bekiekutmoar: I think it would be somewhere around 5.5 km/s of dV, based on low Eve orbital velocity (~3.5 km/s), the gravity well (probably ~1.5 - 2 km/s) and then atmospheric drag (for Kerbin, it's ~100 m/s; I'd scale it with air pressure, so ~500 m/s). So then bring margin. The real trick is to have a rocket that will be stable while landing that will also be stable during takeoff, since they'll probably want to flip. Also, your terminal velocity will be relatively high; in RSS, on Venus (so only ~1g of gravity, but 92 atm of pressure) macallo had a rocket that had a terminal velocity of 150 m/s, so on Eve it will be much higher, since higher gravity and lower air pressure. You'll need a decently sized descent stage.
  2. ferram4
    @NavyFish: I found the error; it's actually not on FAR's side, it's merely a consequence of the NaN/ElectricCharge bug. When that bug occurs, it sets the mass of the part to NaN, which them propagates through all of the calculations, corrupting everything it touches. I believe that there is a fix for it floating around somewhere; I wish I could point you to it, but I only remember skimming over it at some point.
  3. ferram4
    @NavyFish: Post a copy of your output_log.txt, something might be breaking in there.
  4. ferram4
    @Dragon01: It's my own, built using config tweaks for the engines to get exact performance (according to Astronautix anyway) and stretchies + pFairings for the shape. I'll probably release it in the Realism Overhaul thread once I have it account for the H2O2 to run the pumps properly, and once I get the boosters to separate closer to the way they should. Currently, the top pops away too quickly, so I think I'll add a thrust ramp-up delay on the LOX valves to compensate. Especially since it includes functional verniers, and I know the realism fans like that sort of stuff. @Aedile: Aerobraking itself should be fine. Mad aerocaptures from 7 km/s entering Kerbin's SOI, not so much. @localSol: Fairings are pFairings, based on blackheart's changes, and colored orange. Tanks are stretchies (see StretchySRB or Procedural Parts), using the included SoyuzGreen and White textures. @MNSRSkittles: That looks like an awful lot of thrust for the payload you've got there; you could probably benefit from reducing the TWR, which would make the rocket a little more stable. Turn earlier than you're used to. Another thing to look at is how much empty space is in your fairing; that means that the fairing is making a lot of lift / drag, but there's no mass inside to compensate. Get rid of the 3.75-2.5m adapter so you can use the "R" button to downscale the pFairings to a reasonable size. You might also want to shift the LVT-30/45 boosters on the payload forward a little bit to shift the CoM further forward to make the craft more stable. Consider shifting the Monopropellant tanks into the fairing, where they won't make any drag. Finally, consider adding fins if it seems necessary.
  5. ferram4
    Things to look forward to: Aerodynamically-induced structural failures! Before: 30 degrees off prograde at Mach 1.2: Aftermath: Rockets won't go off course and just flip, they'll flip and then break apart!
  6. ferram4
    I mean, take this: <string name="exemptModuleType0">WingManipulator</string> <string name="exemptModuleType1">SingleGroupMan</string> <string name="exemptModuleType2">KerbalEVA</string> And replace it with this: <string name="exemptModuleType0">SingleGroupMan</string> <string name="exemptModuleType1">KerbalEVA</string>
  7. ferram4
    Do they flex more than the stock wings? KJR purposefully ignores pWings because it always made them worse, due to an order-of-operations thing going on with pWings resizing. You'll simply have to use struts, I'm afraid. Edit: Actually, try this: Go into KJR's config.xml and find the line that excludes "WingManipulator." Delete that, and renumber all the other lines so that the exclusions start at 0 and increase sequentially. See if that helps.
  8. ferram4
    Why does each engine need two connected tanks? Each tank can hold multiple resources with Real Fuels, you shouldn't need two tanks for fuel and oxidizer. I'm diagnosing a combination of unsound design, overuse of struts and launch clamps leading to very large forces on the pad. The stock v2.3 settings are enough to make this rocket stable, and that's a lot more than what you're looking at doing, so you don't need to change the settings.
  9. ferram4
    @Read have Read: Hmm... I can believe that a Mach number of 0 would break things; it's not like that's actually possible in reality. I'll look through the code and try to find a fix. @wasmic: Doing your gravity turn based on altitude markers doesn't make too much sense, since it's your velocity that matters. You should start your turn somewhere between 50 m/s and 100 m/s for TWRs around 1.4 - 1.7, but if you want to keep a TWR of 2 and not throttle down you can try giving it a slight kick right off the pad. If you're still having stability problems, the fairing might actually be the issue; fairings are very low-density, but do add a lot of surface area, so that can help make the rocket unstable; you can try putting whatever service module you have for the payload at the top of the fairing (upside-down, so the heavy engine is at the top) or you can try counteracting it with fins on the first stage. And most non-wing parts are already FAR compatible, it's only the ones that are very, very different from stock that tend to be a problem. In that case, those need their own FARBasicDragModel Module defined, and the info for that can be found in the README. For wing parts, those need a FARWingAerodynamicModel or FARControllableSurface module, and the documentation for that can also be found in the README. As a development note: I figured out why landing gear (at least the B9 gear) made so much more drag! It wasn't the gear, it was the struts attached to them; when a strut's first point is attached to a part, it adds another attach node to that part, which could mess up FAR's orientation detection algorithm. So there's a way around that in the current build on GitHub.
  10. ferram4
    It does not take 2 seconds. It takes 0.5 seconds, and is done to prevent the player from taking advantage of the craft's indestructibility when coming off of rails, and that is done to prevent crafts from being destroyed by phantom forces when physics loads. While it is happening, a message is displayed in the top-right corner of the screen so you know what's going on. It's not a problem, it is an integral feature of the mod.
  11. ferram4
    There's nothing I can do about that; the stuff that fixes the "physics dancing" is already maxed-out, which is why the settings for that were removed (they're maxed out in the stock game as well). Since you're using mod parts for this, you should bring it up with the mod authors and make sure that their parts are set up properly to take advantage of the new joint physics. KJR can't fix the effects of a part having its node size set to 1 when it should be larger, since that causes there to be only one joint connecting the parts when there should be 3. That said, IIRC those are very high thrust engines being mounted in a very compromising way. They should flex around a bit there.
  12. ferram4
    Looking at that, either there's a broken reference to a part in the Vessel you're loading up, one of the parts has a mass of NaN or something equally broken. Problem is, FAR doesn't go deep enough into the game's code to do that. Odds are that another mod corrupted a saved ship and that's the problem; delete the corrupted ship and the problem should go away. The first culprit I would look at is RemoteTech, since it's not working for KSP 0.23.5, so if it's in your game it's probably going to break something. Then for some reason Near Future includes copies of Assembly-CSharp-firstpass.dll and UnityEngine.dll (which are files from the stock game), which means that there could be some sort of conflict stemming from that. Final Frontier shouldn't actually break anything in-game, but ti does throw a ton of exceptions during loading, which does make me worry about that as well. But besides that, there are too many mods in there to diagnose what's specifically causing the issue.
  13. ferram4
    Not anymore!
  14. ferram4
    Well, what do you mean by "FAR acting up and failing?" Does that mean that FAR didn't apply its aerodynamic model to all parts? Does it mean that it did apply aerodynamic properties to each part, but you think that they're wrong? More info would be much appreciated. It's possible that something got saved improperly for a given ship, but I doubt that, since FAR does its best to not save anything to the current game state. Whatever the case, I'll need a copy of the output_log.txt in order to diagnose the issue.
  15. ferram4
    For all the players here who use KJR, a new version is out. Also, slightly related: 5000 tonnes to a 300 km LEO. The 0.23.5 update broke it. But now, Eotena lives again!
  16. ferram4
    Version 2.3 is released, marking the source being shifted to GitHub, the re-introduction of the stiffening functions, and some simplification in the config.xml. Rockets will now be much more stable, which will be well received by RSS players.
  17. ferram4
    @Motokid600: That would be due to the fact that FAR (for some reason, likely my own foolishness) has been including the size of the "airlock" and "ladder" objects in its geometry calculations, and for the Mercury pod it's large enough to push the CoD off 0.5 meters from the pod center. It's fixed in the current build on Github, if you want to go about downloading the dll from there. @Frizzank: I've played around with the various Apollo stuff, and it's all very cool; I really like the way the fairings for the Saturn rockets detach. That said, the way that you've modeled up the bottom plates for the S-II and the S-IVB, with the straight section of tank and stringers right above the exposed tank and thrust structure basically throws FAR out of whack completely. The parts taper enough that they'll make stupid amounts of drag when they're exposed, but the small straight section of the part is enough to bring the centroid of the mesh outside of the area scanned by FAR's payload fairing code, so the Saturn IB and Saturn V have terrible amounts of drag as a result. I can try and come up with a fix for it to throw into FAR's config, but a better solution would be to re-model the bases to make things work properly. I assume that you don't want to put in the work to re-do them, so for now it probably makes sense to declare FASA Apollo to be FAR-incompatible (with no plans to make them compatible) somewhere in the OP so that people don't flood the thread with complaints about it.
  18. ferram4
    @Ralathon: That looks pretty good! The only thing I'd suggest is a setting that allows you to add some smoothing to the top and bottom of the cliffs (they look a little too sudden compared the the rest of the terrain, if that makes any sense). That would be good for simulating some types of erosion, so setting it up so that setting can be easily changed would probably be useful for differentiating, say, Duna cliffs from Tylo cliffs. Perhaps look into adding some noise to the top and bottom of the cliffs as well, since they look to have a surprisingly uniform height once you're away from the cliff ends. Just my 2 cents anyway. FWIW, the shallower canyon looks a bit better in terms of variation in height, so you might want to look into making these setting relative to the magnitude of the cliff.
  19. ferram4
    @thorfinn: It works by having the physics-less part define one of the other parts as the body that handles the physics for it, and then any joints / forces that would be applied to the physics-less part goes to the other part instead. So when you connect two things using a cubic octagonal, the joints don't attach to that part, they simply use the cubic to determine which parts to actually attach to. It works surprisingly well. @a.g.: I think we're going to discover that however this stuff works out, lots of mods are going to break in the process. @Motokid600: I just did a flight-test of the Saturn V with FAR 0.13.1, and it flew just fine. The LEM fairing didn't do anything to protect the LEM, but it was still perfectly stable on the way up. There's nothing I can do about the S-IC's fins though, since they're built-in to the stage, so FAR can handle drag properties for those.
  20. ferram4
    @not-a-cylon: The best option would be define custom drag models for them using the documentation in the readme. I'll look into adding something to make it easier to deal with. @a.g.: Primarily because the new size-3 decoupler counts as "physics insignificant" and I suspect that's on purpose, and that more and more parts will be declared physics insignificant to reduce the physics overhead. With that in mind, FAR has to start applying drag to physics-less parts (or more properly, to their parents), which means that there will be some hiccups as everything is suddenly accounted for. @Motokid600: I haven't looked at it yet. If the parts are set up in any way similar to the way that Frizzank's are (in particular, the way the S-IVB is set up), there won't be much I can do, since that part will create a huge amount of drag if I don't define a nice special drag model specifically for that. The problem with part mods like that is that the way the parts are set up has too much of an effect on the drag properties, and modellers never make them like the stock parts are, they always combine things that should be separate together or separate things that should be together, making applying drag properties far more difficult. I suspect I'm going to find a lot wrong with it, and besides, it won't be aerodynamically stable without the 1st stage. The configuration without the first stage was never intended to fly inside an atmosphere, so there's really no way to make it stable for Kerbin flight. For RSS, sure, but it's always going to be wrong for Kerbin. @jrandom: The non-wing parts you have to change from "winglet" to "Part" so that FAR actually applies drag properties to them. The wing parts need to have modules defined like for the stock wings, which can be found in the ferramaerospaceresearch.cfg; since most of the parts seem to be the same shape you should be able to copy the modules over.
  21. ferram4
    @Andrewmacor: There are some things I'm working on that help, but most of the big helpful changes are already in KSP, namely, the changes to MaxAngularVelocity and inertia tensors that really help tighten things up. If you're using mod parts, make sure that the nodes for those parts are the proper sizes, and if they aren't, yell at the mod author to provide proper support for 0.23.5's joint upgrades, since it actually matters now. Other than that, for now you can try re-enabling things in the config (see Readme file) or be more gentle with your vehicles.
  22. ferram4
    @NathanKell: Yeah, as part of handling the issues with Interstellar stuff all parts with animations update their drag properties when the animation plays. I thought I fixed it, but it seems to be interfering with a bunch of other code that's in there to make sure that a bunch of other B9 parts don't have their drag messed up. For some reason the same exact part ends up having different surface node orientations (as in, part local, the surface node is defined differently), and I don't know why; I might have to try grabbing something slightly different to make it work properly, at least for landing gear, since everything else seems to work properly.
  23. ferram4
    @Starwaster: Oh, that explains it. I'm already running that. @Tommy59375: Readme file has the documentation you want.
  24. ferram4
    Yes you can, however you have to optimize the amount of science you can get at once. So the first thing you want to do is to just drop Jeb on the pad in nothing but a Mk1 pod, collect the crew report from the pad, the EVA report + sample from the pad, the EVA + sample from the grass beside the pad, and then recover all of that so you can get to the next node. Then throw a bunch of Goos on the pod and a small rocket so that you can get Goo on the pad, Goo in the air and Goo on the KSC grass. Then expand down the science path so you can start getting more experiments. Do your initial launches to orbit, but don't go into equatorial orbits, so that you can come down at different latitudes so you can easily collect as much Kerbin science as possible once you land. Then for your Mun and Minmus missions you're going to want to manage many missions all at once so that you can have as much science coming in as quickly as possible from each "biome." Make sure to keep track of which biome you're heading towards, and remember that if you send Kerbals you can have them pull the experiment out of the Goos and Matbays so that you don't have to return those things. You'll probably want to send a craft to just out of Kerbin SOI to get some quick science that way. Through all of that, you will certainly have enough science to max the tree, and can probably get most of what you need in a few launches to the Mun / Minmus. If you really push it as quickly as you can you should be able to get all the rocketry, docking and grappling nodes in ~10 days of game time, which will give you plenty of time to figure out a game plan for that asteroid.
  25. ferram4
    @White Owl: Do you want me to work out IAS too? I know it's less useful, but it might be fun for giggles and more "real life" piloting, and it just works out to another few calculations to do. @AndreyATGB: Really, EAS is a way of measuring the dynamic pressure Q, which is equal to 0.5 * air_density * velocity2. All aerodynamic forces scale directly with Q, so knowing that tells you how strong aerodynamic forces will be. The only problem is that Q isn't very intuitive, for either the pilot or the engineer; what do you relate it to, and what meaning does 50 kPa have? EAS on the other hand, can be easily related to how fast you're going, and it's easier to connect to the same forces as at 202 m/s at sea level. @Schilcote: Out of the scope of this mod. Especially since it increases the number of things that it could conflict with. It's not happening.
×
×
  • Create New...