• Content count

  • Joined

  • Last visited

Community Reputation

104 Excellent

About Damien_The_Unbeliever

  • Rank
    Spacecraft Engineer
  1. This assumes that the people who created KerbalEdu (as in, the modifications, not the Squad base) would be willing to license their IP back to Squad, which is by no means a given.
  2. Last I checked, hours weren't part of metric. The use of hours is what makes the conversion awkward, not the use of km.
  3. For radio blackout, it's significantly complicated once relays are in the picture - you'd have to model how all of the various orbits will interact in the future to know if/when/how long any particular blackout period will be.
  4. It doesn't have a separate button for configuration. It uses the standard settings dialog for KSP. I'm not in front of a machine with KSP at the moment, but from what I remember, there's a "Settings" button on the Pause menu. You should find a Launch Numbering section within. Similarly, the settings are available from the New Game dialog. I'll update this tonight with correct terminology/paths of buttons to press, if the above is insufficient. [Edit] It's actually a further step beyond "Settings" within the "Difficulty Options". Not how/where I'd choose to describe these particular settings, but that's where Squad gave us a mechanism to automatically expose options from Mods.
  5. Now updated for 1.3
  6. I'd be more interested in a Night-time Eclipse. I mean, what would that even mean?
  7. But as I've tried to point out before, because a **lot** of people don't seem to realise this, is that the more options you add to the system, the more you add to the testing work. Software isn't perfect and every *combination* could potentially throw up new and unexpected scenarios. So, you create a game that, say, takes 45 hours to test. You add a single option to vary the game and, in all thoroughness, you ought to now spend 90 hours to test. Of course, in reality you cut corners and say "of course" some features don't interact and so you only need to check on one of the settings. And then you end up generating all female scientists as your rescuees, or similar. --- Or, to put it another way - a lot of people seem to believe that adding options/checkboxes to software is "free" when in fact it's the opposite - it either adds to the testing costs or it produces more unique combinations that aren't tested.
  8. Isn't any reply to this, in some coded form "I don't like this feature and anyone who uses it is obviously wrong"? I don't think anything should be removed because I'm sure there are plenty of people who enjoy this game in different ways to how I do.
  9. I'd just like to resurrect my original comments from post 4 on this topic:
  10. Helium tank failure appears to be in second stage. None of these have been recovered or planned for reuse.
  11. 0.2.0 should have worked for 1.1.3, if you can still find it (i'm not sure how easy it is to find previous versions on spacedock, but it was there)
  12. Now updated for 1.2.
  13. So, you're already in a situation where you know that engines aren't restarting as you expected them to do. And your solution is to start more engines. Added to which, these are often fuel-starved situations. To be able to start more engines, I believe you'd have to have primed the turbopumps on all of them, despite the fact that you don't expect to use them ~95% of the time.
  14. So, assume one of the engines is contributing 0% of the thrust it's meant to, and it's not the centre engine. If you boost the other two engines to compensate, you have quite a lot of asymmetry to deal with. During normal (ascent) usage, you don't have to deal with this because it's always assumed that (given we're not talking about the centre engine, again) there's another engine opposite each engine and so we don't have to deal with any torque issues. Do you design your entire set of engines to have far more gimbal to cope with that situation, or accept the loss?
  15. Unlike KSP, where you can sum someone up as either an Engineer, Scientist or Pilot, and they're all of equal ability (given equal experience), unfortunately, the real world doesn't work like that. The "Developer" class is a very broad one, and the skills that can come be brought into a situation very much depend on the individual. Added to which, throwing more developers at a problem doesn't necessarily speed up bug fixing - you're adding more lines of communication that have to be maintained to ensure everyone is working on *different* issues rather than duplicating effort