Fraktal

Members
  • Content Count

    206
  • Joined

  • Last visited

Everything posted by Fraktal

  1. Finalized the design of a "reach anywhere in Kerbin's SOI" lander and tested it with a land-and-return flight to the Mun's north pole. Got back with about 200 m/s left, reentry successful. While I'm waiting for a transfer window to Duna for my first ever manned interplanetary flight (I already have a rover on Ike), I've been thinking about looking into station construction for the first time. What do you guys think, should the core module be absolute-barebones with only an OKTO core, structural parts and docking ports, with a separate power/comms module, or should I combine the two into a single module? I don't plan on keeping it, mind you, as I already have better parts unlocked. Also, I'm considering modifying the design of my Duna spacecraft a bit. Current design is a propulsion/lander manned section and an external fuel tank launched in a separate flight and docked in orbit. Mission profile is launching the two separately, docking them together in orbit, using the external tank to reach Duna, undock, land with parachutes to preserve fuel for the return trip, take off, rendezvous in orbit and use the tank's remaining fuel to return to Kerbin. However, I'm thinking of outfitting the fuel tank with a HECS plus relay antenna plus solar panels and batteries for the first flight and leaving it behind as a permanent satellite / possible future station core so that later missions only need to bring fuel and short-range ground-to-orbit antennas. Taking off from Duna should use up enough fuel to fully drain the external tank and leave nothing behind. Should I go for it?
  2. Reaction wheels do not produce nearly enough torque for any kind of meaningful control against the oncoming airflow trying to keep you at low AoA. Tailfins produce waaaaay more pitch and roll torque than what a starter plane needs. Transmitting science on Kerbin is, for the most part, pointless. With the exception of surface samples, any early experiments that do not require a scientist for multiple uses bring back 100% science on recovery and until you have the OKTO core, you can't bring a scientist without tacking on another 1.5 tons for the Crew Cabin because trying to fly long distances without SAS is a waste of your time. And yes, I know people said the Juno isn't meant for long-distance travel, but two Junos with two Mk0 and one Mk1 fuel tanks can reach any biome on Kerbin, including the poles and the badlands. If you engineer your plane so that SAS requires minimal pitch torque to stay level, you can reach the poles at subsonic speed in about 20 real-life minutes using 4x physical time warp. I did this with only starter parts and inside the 30 part limit; took me about 2-3 trips per biome, though.
  3. The KSC doesn't have flying situations. You're either landed in the specific biome, or flying low above Kerbin's shores.
  4. Also. Since the starter landing gear is so rickety, you can spare yourself a lot of headache if you just plain forget about landing on wheels. Bring a radial-mount parachute and pop it when you're above where you want to land; at starter weight, 1 should be enough. If the plane starts rhythmically hopping up and down on the runway, you are too heavy. Lose some fuel or bring another pair of rear landing gear.
  5. No, there's something else going on. I run the game on 4 GB and it works fine for the most part - but when I fired it up today, it became borderline-unplayably laggy to the point where it had 5+ minute loads, the entire window flashing while the game is frozen, Windows repeatedly graying out the screen and throwing up the "application not responding" popup, and the game window minimizing after long flashing sessions. At one point, I Alt-Tabbed out to Task Manager in the middle of one of these seizures without pausing the game; it showed 24% CPU usage, 85% RAM usage and 100% disk usage of the Windows system process hogging the pagefile to the point the game completely froze for nearly 10 minutes because it was waiting for drive access. Even quitting the game took 30 minutes to even show the menu and after clicking Quit, it brainstormed for a few seconds then crashed with this stackdump: I didn't even install Breaking Ground, yet something evidently changed in the executable, as it never did this before.
  6. One leg kicks back with enough force to flip a lander 90° to its side before SAS stops the rotation. You try to get it back up, the instant one or even two legs are holding the lander's weight at about 160° from directly downwards, the leg(s) kicks out with enough force to literally send the lander flying sideways. You somehow get the lander back upright on its engine with legs retracted, then extend the legs, the lander does not rise off the ground, it jumps with enough force to become airborne for a full second under munar gravity. Granted, I've seen this behavior with the micro legs instead of the ones in the video above, but still. It's normal behavior for the legs to compensate for being compressed by exerting more force against the compression. The problem is that said compensation is far too quick and far too strong, resulting in rapid and massive overshoot. But there isn't much choice there: if the compensation is too powerful, it overshoots; if it's not powerful enough, it oscillates (ie. bounces up and down endlessly, mostly seen when you build a plane that's overweight for the starter landing gear) and people were up in arms when the latter happened in 1.5. Getting it just right would take literally hundreds of hours' of trial and error and Squad isn't going to invest that much time into a bug that isn't game-crashing.
  7. They still kick out with excessively disproportional force when compressed, for one.
  8. The problem with this is, what server would that patcher be connecting to? Because if it would be a Squad server, everyone would be hosed as soon as they dropped support for the game and pulled the plug. And rest assured, they will. Whether in 2030 or 2040, doesn't matter. What matters is that core functionality should not be hardcoded to require a single, fixed remote machine. It would be convenient, yes, but giving the devs an instant killswitch to permanently render every copy of the game in existence unplayable with as soon as it's no longer profitable has already killed multiple games in the past. Modding with the Sword of Damocles hanging above your head ready to render all your modding efforts null and void as soon as the IP holder's executives say so is an atmosphere I don't think many modders would enjoy working under.
  9. Can you write one for 10% science returns as well? If not, some observations. Harvesting the KSC is no longer optional if you want to reach the Mun with anything other than an ultra-minmaxed craft beyond the skills of a beginner player to design. Consider getting KEI; I've done without it, but it's really tedious and doing a land-and-return mission to the Mun without a Terrier is so touch-and-go in terms of fuel usage that I'd rather not have to do it again. Focus on unlocking the bottom-most nodes at the beginning. That's where new science instruments are, which in turn will help you unlock topmost nodes. Being able to fly further is nice, but not if you get deadlocked by having exhausted all science options but not having the points to get more science. Three goo canisters are generally enough to not have to land in the same biome again. The Science Jr. is a bit harder nut to crack, as I've found (in LKO) it requires as much as four measurements before it stops giving any more science, but returning that many Science Jr.s through reentry is difficult. Two is optimal, as it means you can finish both low and high orbit in 2-2 flights. However, don't bother putting more than one of each instrument on a probe not meant to return to Kerbin. Transmission loss means you won't benefit from sending more than one package. Of course, you do need LOS or a relay to transmit, so keep that in mind. Speaking of which, three Communotrons (not the surface-mount ones!) or two High-Gains are required for Minmus with a level 1 DSN, if you go with direct connectivity; for relays, the lander only needs one Communotron to reach a relay with the above antenna configuration in munar geosynchronous orbit, and even then the signal is going to be weak. Invest in the first aircraft node early and harvest Kerbin bare. It will return the investment with interest, trust me. Later nodes are unnecessary until after you have a working interplanetary ship design. Probes are optional but highly recommended. Spending 90 points on the OKTO will just barely return the investment to unlock one more node from the Mun, yes, but it will help in building a better lander. Once you've got the OKTO, you can now take a scientist in the lander, allowing you to both transmit and return science in the same flight for maximum yield.
  10. Okay, it's just that I've always been hearing the opposite from everywhere.
  11. Good idea, though I have a question: how to reconcile part size differences? I mean, if there's only an attachment node in the middle, how to attach something half the node's size? Similarly, if there are two nodes for half-sized parts, how to attach a full-sized one? Also, though someone might very well correct me on this, if there are attachment nodes for both of the above scenarios but only one is used (there would be clipping otherwise), wouldn't the nodes not being used cause drag?
  12. Did some experimentation with starter parts and managed to cobble up a three-stage rocket capable of reaching 50 km altitude on nothing but Flea SRBs and actually coming back down safely instead of nosediving into the ground like my previous Flea-only designs did. The key to a safe landing? Squeeze in another Flea between the last stage with the lowest amount of fuel allowed by the game (enough for a 0.9 second burst at 100% thrust) and pointed in reverse. When activated, it explosively decouples the command pod by burning away the girder attaching the pod to the rest of the rocket, allowing the pod's aerodynamics to safely slow it down to parachute release speed. Highly unconventional use of a Flea, yes, but it works and realizing that it does was fun.
  13. The starter wings have such little lift compared to the weight of the aircraft that the plane stalls out before reaching safe landing speed. And once again, mounting more is a no-go due to part count limits. Drogue chutes are suboptimal for landing a plane because you can't toggle them off if you find you're slowing down too quickly and airbrakes are not available until much later. I don't have any problems landing with the retractable landing gear, mind you (I crash with them far more often from tipping over than from the landing gear being destroyed). It's just the fixed, rigid ones that are giving me trouble, hence I only use them for takeoff and rely on parachutes to come back down. Hell, I would stage them off entirely after takeoff if I could.
  14. There's the problem. I'm incapable of landing with anything less than ~160 m/s if I don't have airbrakes (and you don't get those until tech level 6). Wheel brakes are nowhere near enough and make me veer to the side and tip over, braking chutes are just plain insufficient.
  15. I wanted to amend this statement with one situation where 30 parts as starter limitation feels too restrictive: plane design. I've ran into situations when designing early-game planes where I was forced to compromise between payload part count and control surface count in order to stay within 30 parts. The absolute minimalist starter plane design, without payload: Mk1 Cockpit - 1 part 2x any wing - 2 parts Vertical tailfin - 1 part 2x horizontal tailfin or canard - 2 parts 2x Juno - 2 parts 2x Mk0 LF tank - 2 parts 2x Small Circular Intake - 2 parts 3x any landing gear - 3 parts 2x parachute because the starter landing gear is pretty much useless at actually landing - 2 parts 1x Structural Fuselage OR Mk1 LF tank to mount the wings and engines onto - 1 part 1x nosecone to close off the main body's rear attachment node for aerodynamic purposes - 1 part 4x Elevon 1, if I'm not using the FAT wing - 4 parts That's 23 parts, leaving 7 parts for the payload. If said payload is just a Crew Cabin, there's no problem. But if I'm building a plane for gathering science from the polar biomes and would prefer not having to make repeat trips due to how long it takes even at 4x physical time warp, 7 parts is a bit short: Service bay - 1 part Thermometer - 1 part Barometer - 1 part 3x goo canisters - 3 parts 3x materials bays - 3 parts That's 9 parts, 2 parts too many for the level 1 SPH limit of 30, forcing me to ditch the Elevons and rely entirely on the tailfins for attitude control.
  16. Well, he would've figured it out anyway that doing what you wrote would be an unstable configuration once he tried it.
  17. Other way around. Center of mass just in front of the center of lift.
  18. The problem is that the configuration I described above hits the ground at supersonic speed regardless of whether it falls prograde or retrograde. Only if I struggle against aero forces to make it fall sideways will it slow down to the point where the parachute releases, but even then not always - and even doing this is damn hard, as a Mk1 pod with an RT-5 attached to it has no attitude control whatsoever once it picks up speed.
  19. And for your very first solid-fuel rocket, it can be used as a crude decoupler. Firing an RT-5 directly into it overheats and destroys the girder in less than a second even at 20% power, allowing multistage rockets even before you unlock the actual decoupler part. One such design I whipped up consists of six RT-5s on the first stage, then a girder, then a single RT-5 on the second stage set to 20% power. It can reach nearly 40 km altitude, but of course is very hard to control on the way down and cannot slow down to parachute release speed merely by flying retrograde. Of course, you won't be able to decouple the last booster this way, unless you waste weight on mounting an RT-5 upside down.
  20. Don't forget the mismatch between the tech level of fuel tank sizes and corresponding structural parts. Like, why do we get FLT-to-Rockomax adaptors a full tier before the first Rockomax tanks/engines? You don't have anything to attach to it, short of using radially attached girder parts to turn it into a budget engine plate for FL-T engines. Which is a waste of part count because, again, you don't actually have sufficiently large fuel tanks to keep that engine cluster going for long and you're hitting diminishing returns for the FL-T series by this point. Actually, I found that the level 1 limitations of 30 parts @ 18 tons max is enough for any orbital flight in Kerbin's SOI that does not involve landing or returning from a high-inclination orbit anywhere other than Kerbin, as long as you don't overengineer things. At the same time, I feel the level 2 limitations are set waaay too high. Especially the part count.
  21. Which makes one think: do kerbals have the same impact speed lethality threshold against ship parts as they have against terrain?
  22. How about getting flattened by decoupled debris?
  23. FYI, I'm using my 2.5 years old personal laptop for KSP, not my work laptop (that one has a telemetry service that logs the title of the active window at all times, so no way in hell am I using it for personal business). While it does have a GeForce 920MX in addition to an Intel (I wouldn't have bought it otherwise), it's bottlenecked both by RAM (4 GB) and CPU (1.1 GHz quad-core), as seen by the <20 FPS during launches and guaranteed memory access violation crashes after a dozen or so reverts. Anyone more picky than me when it comes to playability would've ditched KSP - and the fact that I didn't is from a combination of how insanely addictive and fun KSP is, as well as the fact that this laptop is the best hardware config I ever owned (my previous one was a 2.0 GHz dual-core with half the RAM and a Radeon HD3470; I used it for ten years). Every single computer I ever owned was way below average spec for gaming and ran everything less than five years old like crap, so I've gotten used to it - but that doesn't mean I won't speak up like above, as running like crap is still better than not running at all.
  24. I hope that 1.8 focuses on quality-of-life improvements rather than a graphics overhaul beyond part texture/model improvements (which are welcome). In fact, as controversial as such a statement sounds in light of the vocal minority demanding stock visual improvements on a regular basis, I think any stock visual improvements beyond part textures/models should be DLC-only at best. The reason for which is simple: KSP's system requirements are already high as it is. Not everyone (in fact, I'd hazard a guess that the majority of the playerbase don't) has the spare cash to buy a whole new PC just for this one game. KSP isn't, and never will be, a AAA killer app for high-end hardware, so stop trying to convince the devs to turn it into one. You have powerful hardware that could run the game much prettier? Good for you... but that doesn't mean the devs should frak over everyone who doesn't, just so that you can be happy. Raising the system requirements would lose more players than in would attract, ergo it would be financially unappealing to the devs to begin with. And in case you manage to rein in your laughter long enough to ask why am I trying to play KSP on a laptop that can barely give playable FPS on below-average graphic settings plus EVE and PlanetShine: because my job requires me to occasionally sleep in the office and I can't quite carry a gaming PC in a backpack, now can I? KSP's graphics are fine enough for us common folk as is, thank you.