Jump to content

Autochton

Members
  • Posts

    322
  • Joined

  • Last visited

Everything posted by Autochton

  1. timpossible: Don't go thinking the stock KSP flight model is significantly related to actual aerodynamics. It may adequately model what happens when something moves through something, but it sure ain't planes moving through air! :-) The craft threads have many examples of the kinds of planes that will fly in stock KSP - but my eyes always hurt a little looking at them. If you want a more realistic flight model, I suggest getting a hold of the Ferram's Aerospace Research mod - colloquially FAR - which replaces the flight model wholesale. It causes issues with some mods that use the base drag numbers, but the planes that fly well end up looking like planes more often than not.
  2. If I don't miss my science roll here, having free oxygen is a sign that there is life. Oxidization is a rapid process, and freeing oxygen is energy-intensive - unless that is you are photosynthesizing. So Laythe either cannot support conventional jet engines (which it currently can), or it has photosynthesizing life. Or there's magic oxygen-generators hidden somewhere on it. Of course, said life is not unlikely to be single-celled and microscopic.
  3. That sound you just heard was the sound of a thousand hearts breaking, a thousand dashed dreams...
  4. He doesn't need to. It just needs to be close enough that the error introduced is not sufficiently large, and flying the ascent with MechJeb will do that adequately. Hell, for the purpose of this test, setting the Smart A.S.S. to Surface, 90 degrees off horizon will do. And thus, he can fly very nearly the same ascent many times, record results for each, and then calculate the average and variance of them. And if the results differ by more than the variance (especially if they differ by multiples of the variance), he has significant results. This is the way it's done by real scientists in the real world. Ever hear of an 'error bar'?
  5. I beg to differ. Multiple tests with control input close to the same profile will tend to eliminate random error (i.e. deviations from variance in control input). You will tend to get a bell curve (presumably Gaussian) around the average, which is as good as any control for circumstances gets, anyway. If your results differ by more than the standard deviation, you've found a significant result. Science!!!
  6. Geschosskopf: Reenter belly-down. Basically, line your ship up so that your nose is 30-35 degrees, or potentially even more, over your prograde, and keep it there while you lose speed - your drag should be utterly massive, and as a side effect this flight profile enables you to come in with a mod like Deadly Reentry on too. Preferably you should be down to a stable flight regime (whatever that is for your design - for me it's ~1500 m/s, around Mach=5 @ 25km) by the time you start hitting deep atmosphere. That way, you're not hurtling along at speeds far above your ship's rated maximum (Orbital velocity comes to Mach=8 or 9 at 25km IIRC), but instead you'll be able to fly normally. At the least, this approach worked well for me with my shuttle, although I did have stability issues until I rebalanced my fuel load.
  7. I'd be interested in how that same experiment looked when looking at 300 m/s. The stock drag model doesn't have a huge effect until ~200-250 m/s at lower altitudes, so closer to Mach=1 might yield more interesting results.
  8. Alternatively there's Hooligan Labs' Party Starter, which quite simply fills up all spots a Kerbal will fit (excepting exterior seats) at a single button click. But yes, Crew Manifest is good. http://kerbalspaceprogram.com/hooligan-labs-party-starter-max-kerbals-before-launch/
  9. nhnifong has the right of it if you want to really get into planes and atmospheric flight. Stock KSP's flight model is... creative. I can't use it at all, myself, feels like the planes don't fly so much as magically slide through this non-Euclidean goop, powered mainly by sorcery. So FAR is a must-have mod for me - not though, it does not make things easier, in fact, quite the opposite. But it does make aerodynamics a lot more realistic. Expect your working planes to look more like planes, and less like the wing-and-intake-studded monsters you often see when looking at stock spaceplanes. Disclaimer: I come from a past of really crunchy flight sims where realistic flight profiles are paramount. So my problems with stock KSP probably stem from that.
  10. There's a few tricks you can use to improve stability. For roll stability you can add dihedral (wings tilted so they point a little bit up when viewed along the fuselage), or, I think, if your CoM is below your CoL. I prefer the former, myself. For yaw and pitch stability, add a good set of large tailplanes. I'm prone to V tails myself, and using big stabilator type surfaces - where the whole surface turns to control the air flow - but a set of vertical and horizontal stabilizers work too. But yeah, make those big enough. You'll want to have enough lift. Use the CAS to make sure you have a plane that will lift off - sweeping AoA will give you a good idea of how it'll behave. The higher the L/D line, the easier it is to get lift. If your plane doesn't lift, or needs a too high speed to take off (i.e. runs out of runway), bigger wings are a good way to go. (Or bigger engines so you hit takeoff speed in time - but beware of having to land, then!) The CAS is your friend. I typically use sweep calculator to get an idea of overall performance under different regimes. Sweeping AoA gives me an idea what the typical flight attitude will end up being, and whether it might be worth it to change the angle of mounting, or the gear attitude. Generally, you want the plane to sit on its gear with a little nose-up (or wings-up, in the case where the wings are tilted upwards). That way, you may get a plane that takes off on its own, or which will at least take off easily. Sweeping Mach tells you how the plane will behave as speed changes - expect lift to drop and drag to rise around Mach=1, then things will even out again. AoA sweeps well from 0-25 for a basic calculation - expand as necessary - and Mach usually is good when swept from 0 to 5 or so, if you plan on going that fast. Make sure to set Mach number for AoA sweeps, and AoA for Mach sweeps appropriately for what you're trying to learn. As for stability derivatives, try to match up the suggested signs of each derivative (as given in the tool tip of each one), it'll make the plane a bit more controllable.
  11. I have a minor in astrophysics. Never did any orbital mechanics, though - it was all about large-scale cosmology, universal equations, dark matter, those sorts of shenanigans.
  12. Plus, if I recall the default settings correctly, Minmus is made of Kethane, pretty much. It's ,more or less a huge kethane balloon.
  13. I would suggest Ferram's Aerospace Research with TV Aerospace. Installation if tricky, however, as the newest FAR uses ModuleManager, and TVAero need some changes to it to be fully compatible. However, once installed, jet engines (and wings and everything else aerodynamic) behave in much saner ways.
  14. There's still a lot to be discovered about planets that we know exist. Sure, you might know Laythe is there from before-KSP times - but that it has liquid water, an oxygen-rich atmosphere? Probably not. The existence of smaller bodies (Gilly comes to mind) would likely also be hidden until a closer look became possible. And even then, adding the research game mechanic will give reasons to send probes and rovers out - research might well be predicated on fulfilling certain goals, so that you might not be able to research, let's say, the NERVA and ion engines before you've sent a probe out to Eeloo. Atmospheric research might also see use - unlocking various advanced plane parts research as you fly planes and rockets in more and more dangerous and advanced ways, bigger, better, faster, more, etc. To me, a successful career mode is all about the intermeshing of astronaut training, research, and completing goals.
  15. You do now the adage "If it hasn't flown before it won't fly", right? That one was at the root of how SpaceX are revolutionizing launcher design - by actually using technology developed within the last 40 years. So yes, rocket scientists do actually use old technology instead of newer, it seems. Meanwhile if I turn my programmer's eye (which has training in things like graphical rendering and physics simulation) to the problem of KSP, I make the following judgements (with the disclaimer that I have not read the source, have only dabbled with Unity itself, and do not work for Squad): Memory: KSP uses a lot of memory, and being saddled with Unity's restrictions, is limited in what it has available. This hurts performance - can indeed crash the game altogether. Add to this a suspicion of memory leaks here and there, and a game explicitly designed to have strong mod support being limited by its memory usage, and this is a significant problem area. A solution, at least for some users, would be to find a way to support 64-bit architecture and thereby expand the available memory. This, however, depends on the Unity engine, which, despite 64-bit support on every last one of their targeted platforms (Windows, Mac, Linux, iOS, Android, PS3 and XBox 360), does not support 64-bit architecture. For some reason. It's quite inexplicable to me. Graphics: I don't really consider this a huge problem in and of itself. It's not the graphics of this game that will bring modern GPUs to their knees. Both DirectX and OpenGL are able to highly parallelize graphics computation, and can thus show KSP's level of graphics handily with any modern graphics card. Even high parts-count ships and bases ought to work here - the poly count and shader complexity just does not get that high, unless you use some seriously jacked-up mod parts or custom rendering mods. Physics: The real problem child IMO. Unity's built-in PhysX engine is terrible. It is unsuited to any kind of high-fidelity physics, is prone to bad errors, has flawed colliders and intersection handling, and the list goes on. Especially bad is that it underperforms on non-nVidia computers, as PhysX targets nVidia hardware explicitly, but does not support ATi GPUs for physics processing, for example. But there are options: Bullet is a much superior physics engine which is apparently the target of an integration project with Unity - this would greatly improve performance, especially for non-nVidia users (like myself). Other physics engines exist, and could probably be integrated with Unity to boost its performance on physics tasks - which appears to be the real bottleneck for many-part ships. CPU architecture support: Unity does not support multi-core CPUs. This exacerbates the above mentioned problems with physics for non-nVidia users, as not only will they not get the excess power of the GPU exploited, their processor will be underemployed as well. I take heart at the mention of partial multi-core support mentioned by Squad, but really, this is something Unity really ought to have in the first place. After all, again, every last one of their target platforms support it. In fact, I'd expect Unity to horrendously underperform on e.g. the PS3 with its cell architecture (8 cores supported by an underpowered control core), or on dual- and quad core mobile units, also a major Unity focus. In short: Squad can help themselves a fair bit by using a different physics engine, such as Bullet, and/or fixing any memory leaks in the game, and by hacking in partial multi-core support. But for some of the issues, it's the Unity devs who need to get their thumbs out of their butts and stop targeting 2001's technology. Until they do, it would appear we are stuck with certain issues - particularly the memory problem.
  16. @Geschosskopf: That is a cool name. Also, the part in question is something like (I checked) 4m * 2.5m * 6.5m or so at the current point, and cannot be mounted along its long axis very well, since that's where the off-angle attachments to turn it into a ring are! I already checked against the B9 big cargo holds (S2W and HL) and they were hilariously too small for it. Meanwhile, I'm thinking of trying to brute-force it up there - flat outer face forward, mounted on a bloody huge, powerful launcher with TWR to spare (I'm going to aim for ~3). After all, if I can get up out of the dense atmosphere, maybe I can loft it by a sufficiently big amount of delta-v. After all, it's not heavy, just unwieldy.
  17. That is genius. I call my aerospace company Argonaut Aerospace, Inc., they build my space planes and most of the rockets I use. Despite their initials, I suspect their engineers are drunk most of the time. (AA mainly uses B9 parts.) The space program also contracts with National Orbital Positioning Enterprises, LLC (aka. NOPE) for space station construction and various other jobs. (They're big users of LLL parts and JARFR trusses.)
  18. I tend to use my stability derivatives quite a bit. If they fit their expected regimes (mostly a question of mousing over numbers and making sure that negative numbers are supposed to be negative, etc.), the plane flies a lot better. I do use MechJeb's Smart A.S.S for flight control, though, which helps a lot. A more finely tuned Avionics unit than is currently available would be good for more stable and controllable flight. I'm thinking that overdamping it might be beneficial. Thanks for the well wishes, I expect I've got some work ahead of me on the shuttle, since it currently flies... odd. Also, probably needs a better ascent profile, or alternatively, a bunch more fuel...
  19. OK, thanks, yeah, a bit of experimentation proves that unpacking the part folders in the KSP/Parts dir works. 'Course, making a fairing big enough to fit the curst thing is another job entirely - my first one was nowhere near big enough! Thanks for your help, stupid_chris and Punk!
  20. Is that working as of 0.20.2? It includes a DLL, and some part folders in its download, but nothing in the way of instructions. Meanwhile, I can't seem to get KSP to start with the pack installed.
  21. I am seeking help with launching the sections of a ring-shaped space station I'm planning. It will go up in segments, 12 making up one ring, with the option of adding further rings to the structure later. Each segment is based on one of the big Lack Luster Labs 4x2 habitation modules, which means each segment is roughly 4m by 2m by 5m or so. They're not excessively heavy, as such. However, I use Ferram's Aerospace Research, which means that I can't just strap it to a sufficiently sized rocket and blast off and be done like in stock - I need to loft it with something a bit more aerodynamic! However, no cargo hold or fairing that I'm aware will actually fit around the fairly huge ring segments I ended up with. I want to target it for a 150 km equatorial orbit, but I'd be perfectly happy to just get them up and stable so I could use an orbital tug to boost them up all the way. So now I'm considering if there is a way I could build some sort of fairing for it? Custom cargo hold? Something?
  22. I built one, although I use FAR. It uses the S2W intake section plus a few extras to supply two Sabre Ms, mounted on the LFO 2.5m engine stand. Getting it stable was a trick, and I haven't flown it since 0.9.5 - in there were changes to drag from hull flare, which are apparently pretty tough on the wider B9 parts. I flew it into space, and back down to Kerbin, but botched my landing location (next continent over from the space center!) and had to land in hilly terrain at night. Still, it came down mostly in one piece. Right now I'm working on my passenger shuttle, which uses the standard S2 fuselage.
  23. Cool! I hadn't seen that bit. :-) Yeah, I'm not expecting it to be an easy thing to do, scooping gas - and probably most useful with FAR, where you can present a streamlined aspect to the airflow while scooping, and thus avoid braking too much. I'm guessing it would involve using a rather eccentric orbit, both so your apoapsis stays high even with the braking, and so you can raise periapsis when right near apoapsis, for fuel economy. Your aero-capture scenario, HoY, is intriguing as well. :-)
  24. It's tricky. Depending on your attitude to the oncoming airstream, your drag can vary quite widely. Generally your lowest drag will be nose into the wind, so basically flying straight into your prograde marker. Your highest drag will likely be belly-on (or back-on), so with your craft's vertical axis pointed prograde, since that will present, in most aircraft designs, the largest cross section. Calculating them, though... Not easy. Can't really help there. Edit to add: One thought is to go into the SPH/VAB, and orient your craft the way you expect it to be when doing the maneuver. Then use the CAS to find your Cd?
  25. Majiir, a question/suggestion if I may: Is it possible to have kethane or other material deposit likelihood/size/ubiquity depend on the body they're on? So, e.g. Duna has plentiful metal ore but not much kethane, Eve has more kethane than God, but good luck finding metals, or the like? It might be a part of the resource configuration to set these parameters. Also, it's probably been suggested before (and I apologize if it has), but a kethane atmospheric scoop would be a truly awesome thing. Skim runs at Jool or Eve, for example, would be a very nifty way of extracting. :-)
×
×
  • Create New...