• Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About Hoozemans

  • Rank
    Bottle Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Commenting on one out of a thousand similar questions is probably a waste of time, but I often run multiple instances of KSP so that I can sandbox new designs while editing them at the same time. This is a bit harsh on my not-game-optimized old laptop, though. And my desk is a bit small for having two KSP-dedicated machines on it... Having a standalone VAB/SPH editor would seem a nifty thing to have. The best argument against is is that ' nifty thing to have ' probably does not make it worth the effort of developing and maintaining it. I, for one, couldn't be bothered - I'll just have to get a bigger desk
  2. Unfortunately, the manoeuvre occurs at the very end of the burn to maximize apoapsis, after the vehicle has already left the atmosphere. I probably will, though I suspect that all automated ascent routines will seek to make tiny corrections when the trajectory deviates from the ideal.
  3. Thanks for the carbs. I'm getting an FPS of less than 2 with some of my 1000+ part launches, on a pretty decent i7. I'm guessing we're just scr*wed unless someone comes up with an entirely new physics model.
  4. So, I've been messing around with a huge launch vehicle, trying to get my latest versatile asteroid hunter into orbit in one piece, rather than having to break it up. There's a problem with the design, in that there's a lot of stress on some of the key components of the structure. I got the design to work, as long as there aren't any huge lateral forces applied to the structure. And there's a problem with that. Because each launch attempt takes almost an hour to run, at about thirty frames per minute, and it's nearly impossible to manually control the rocket under those circumstances, I've let Mechjeb do most of the work. But Mechjeb has some peculiar notions when it comes to thrust vectoring. It thinks its a good idea to start its gravity turn by making a sharp turn as soon as vertical speed exceeds 100m/s, applying lots of lateral stress. My game pauses, the program takes a couple of minutes to think about the development, and then I get to see my ship do an extremely slow unplanned disassembly. I've tried to disable thrust vectoring in the editor - but Mechjeb doesn't seem to care. Likewise if I tie thrust vectoring to action groups: thrust snaps straight when I lock engine gimbal, and then, next frame, is vectoring again. ... O. While I was typing this, I was running an experiment with the gimbal not locked, but limited to a few percent. And Mechjeb doesn't seem to ignore gimbal limits. Currently the game is thinking about the next frame. I hope it's just staging, not a SUD. Anyway, my original question remains of some interest, I think: is it true that Mechjeb ignores gimbal locking? v1.7.2 64bit/Linux
  5. Another tip that's been of much use when I first started: Build your rockets top-down, starting at the last stage, and adding each prior stage to the bottom, keeping an eye on the total dV. - For a simple 90km-orbit-and-return mission, start with the part that actually gets to orbit: give it just enough dV to return from orbit, say about 100 m/s. TWR doesn't matter at this stage, just dV. - Then start building the stage below that: give it just enough oomph for a final kick into orbit, assuming you've gotten your apoapsis up to 90 km with a surface speed of some 2200m/s: the circularization burn. If you do your gravity turn right, that's somewhere around 1000 m/s. Again, TWR isn't really important at this stage, as long as you can apply the final 1000m/s before you re-enter atmosphere. - Then you build the part that actually gets your apoapsis up to 90km, and delivers that first all-important 2200m/s surface speed. At this stage, TWR is, naturally very important. If you've got powerful engines (eg. Mainsails), use them. If you don't, keep strapping on boosters until you've got that 2200 m/s And then it's just a matter of using all that dV in a more or less efficient way: start turning to the east as soon as your vertical speed exceeds 100m/s - but don't turn too fast: you're aiming for an angle of approx 45 degrees at 10000 metres. At 30000 metres you should be a few degrees from horizontal. Keep an eye on your apoapsis and periapsis while doing your turn: you don't want to reach your apoapsis too fast, not before you've gotten your periapsis as high as possible: that way, you can have a relatively short circularization burn, and aren't risking re-entry before you get to deliver the final m/s. O, and don't worry about details like max Q or friction: KSP is quite forgiving, and it's easier to just give your rocket a few more m/s of dV than to fine tune your ascent to deal with them. Anyway, that's how I got started. Took me a few launches before I had anything that didn't simply fall apart before getting up to a decent speed, mind you.
  6. I have considered the possibility of hooking a couple of dozens of her up to a water reservoir, so creating a steam powered lift vehicle. I'll start working on the Girlfriend Fury Steam Engine Mod as soon as I've taught myself to program.
  7. Perhaps something like "stress X on component Y exceeding threshold Z", for preset thresholds. But that's for another thread. I've been browsing threads on increasing performance of the game, but other than porting KSP to some as yet not extant experimental quantum computing system, I guess there's no such thing. I've been setting my 1000+ part launches to run overnight, but my girlfriend isn't happy with the noise of CPUs crunching physics...
  8. Thanks for your response! F3 gets me part of the way, certainly. But often enough, the first sign of anything wrong is a reported 'collision', where there should be no parts actually capable of colliding, unless there were some really peculiar sheer forces working on them. I'd like to understand the failure mode a lilttle bit better. I suppose trial and error is the best way for now.
  9. Good morning! I've been searching the forum for a bit now, and I don't doubt this question has been asked before, but it's been hidden so well that I thought it easier to just post a new one. As my contraptions have grown ever more massive, so has launching them into orbit become more of a chore to my CPU, and myself. Especially since the increasing stresses on the various components of my ships make failure at some point during the launch more and more likely. From the KSP.log, I've got a pretty good idea of the cause of most failures, but I'm still lacking a log that tells me exactly what the failure mode is, eg. [2019-07-05 17:39:59] AFF59 Aeroshell ID=237849 failed because number of transverse Gremlins (6) exceeded max design limitations (5 transverse Gremlins). Is there a standard feature of the game that does something like this, or is there a mod or other bit of tooling that might tell me more about the exact failure mode? Playing KSP_1.7.2 64bit on Linux, MH + BG DLCs installed, with basic utility mods, but no parts mods. Thanks!