• Content count

  • Joined

  • Last visited

Community Reputation

3950 Excellent


About Streetwind

  • Rank
    Talks To Boosters
  1. I guess that's what they meant when they said "upper level winds close to the limit" Must have been pretty turbulent there. The TWR isn't actually that high. I personally thought it was a bit more ponderous than I expected. The thing about acceleration is that it doesn't care what object is doing the acceleration, it always ends up making the object move a certain distance over a certain amount of time. Which, in turn, means that if the object is small, it may end up moving several times its own length, whereas if the object is very large, it may only move a fraction of its own length. Even if the acceleration is the same in both cases. Atlas is much larger than Electron. For a rocket the size of Electron, it didn't move off the pad very quickly at all. It probably has similar TWR to the Atlas and Falcon 9 rockets (1.3 to 1.4, definitely not much higher). Another example: Europe's Vega and Ariane 5 launchers. Both are reasonably quick off the pad, thanks to primarily solid fuel launch stages, but Vega is quicker... that is, it looks quicker. But it actually isn't. Ariane 5 has the higher TWR. (In fact, at around 2.0, it has one of the highest TWRs of operational orbital launch vehicles today.) It's just that Vega is a much smaller rocket, so it appears like it covers more distance in the same time. Even though it doesn't. This is also why hobbyist rockets are just gone in a flash. They are so small, you cannot even see the lift-off properly unless you tune them to have practically no acceleration at all. And if you did that, it wouldn't go very high.
  2. RnD Individual Parts

    You sure? Last time I used it, and that was fairly recently, the parts only had a funds cost. First you unlock the node as a whole with science (just like before), and then - instead of all parts getting added to the editor - you have to purchase each part for funds.
  3. Manual Physics Range Edit

    Yes, I understood that. And I assure you, it works Source: my own installs, where I have done this in some form more than once. For example, editing reentry heat and mach effects behavior when using system rescales, and the like.
  4. Nertea has been playing with the idea of limited-at-launch resources in his alpha-state Far Future Technologies mod. In it he has added a custom building to the space center that slowly produces antimatter, and if you want to launch a spacecraft with antimatter engines or reactors, you need to fuel it from that building's reserves before launch. You cannot get pre-filled antimatter tanks in the editor at all. Due to the license, you are potentially allowed to do more than just look at it. Provided you release your mod under the exact same license, and provide clear attribution, you could go as far as lifting entire code sections wholesale out of FFT and into your own mod. Though I'd advise some caution in using code you don't understand - especially since modifying the space center is something only very few modders even know how to attempt. Learning how it works first and trying to make it work yourself can teach you a lot in that regard. Maybe not what you initially had in mind, but maybe it helps?
  5. Manual Physics Range Edit

    Module Manager does not edit files. It overwrites already-loaded values in the game at runtime. So the question is not "can Module Manager work with files outside of GameData", but rather: "Can KSP load config files outside of Gamedata?" Usually, the answer is no. But there are a small number of hardcoded config files outside GameData that KSP always loads. Physics.cfg is one of them. How else would the game find its own physics settings? And after the game has loaded that file, the values from within that file are just as easily modified by Module Manager as loaded values from any other config file!
  6. Yes, because it's basically a form of startup help. NASA likes to help new unproven things along a bit if they think that it's a good investment. They basically said: "Oh, you have a new smallsat launcher that shows promise? Here, have this armload of cubesats from our ELaNa program (education nanosatellite stuff). Then you have at least one customer, and that will let you build trust and attract others." Turns out, although NASA was the first to sign on, others soon followed even without the need to see a successful flight first. Planet and Spire even agreed to put stuff on their upcoming test flight. But I'm sure Rocket Lab doesn't mind the extra money anyway. Mind you, I just checked the wikipedia page for the Electron rocket, and the manifest there shows both NASA and Moon Express for Q1/2018... with Moon Express being first. Maybe NASA already did let them skip forward. I'm all for it
  7. say hello to the VSS unity

    Customers in 2009, by the original plan. So not quite ten years yet, but getting there. And, by the way: all those test flights they're doing are already crewed. Just not with paying customers.
  8. SpaceX Discussion Thread

    Perhaps it got dirty, and needed a good scrubbing...
  9. Let's hope it works, and let's also hope they can get another rocket on the pad by mid-March, and let's further hope that NASA allows Moon Express to skip ahead of them in the manifest. Because as it stands right now, they're the last remaining team that looks like it still has a somewhat realistic shot at actually attempting the Google Lunar X-Prize. In contrast to all other teams, their launch has already been paid for, and I've not read anything anywhere that their spacecraft has been delayed. So I have to assume that they're just waiting on Rocket Lab at this point. Of course, realistically, it's not going to happen... but wouldn't it be cool?
  10. SpaceX Discussion Thread

    You know the most ridiculous thing about this? Saying something like this is unheard of. The DoD has never told the press to "go ask someone else" when talking about launch failures before. It's a completely useless deflection, and of questionable legality to boot when taxpayer money is involved... and the DoD knows it. And still they went and said that. The briefing itself was something like out of a Hollywood movie. Press people grilling the speaker, who tried to politely decline giving details repeatedly... and then a well-dressed officer just abruptly declared the meeting over with a simple "we're not going to tell you anything". Whatever this was, it was so heavily classified that stuff like the X-37B or a NRO spysat launch could be considered public show-and-tells by comparison. So heavily classified that the DoD itself clumsily fumbles its briefings for fear of saying even one wrong word. The only reason we know it exists at all is because it had to be put on a rocket, and you cannot hide a rocket. Even then it was never really announced, it just appeared on the manifest without a word. Ironically, had they launched this via ULA, they probably would have a whole lot less public scrutiny, even if it failed. Whose idea was it to put something this secret in the hands of the most publicly popular launch provider on the planet, anyway?
  11. You don't need to update the game. Just the mod.
  12. TWR Problems...

    Tip: instead of doing thrust / (mass * gravity), you can do thrust / mass / gravity. It's easier to memorize, easier to enter into a calculator, and gives the exact same result. But you still need to correctly set brackets around the addition of individual thrust values, just as @Steel said. IMHO, just do the addition first and then use the result from that as a single number for thrust. Troubleshooting math problems is all about reducing unnecessary complexity.
  13. Olex Transfer Calculator

    Fun fact: Ike's inclination relative to Duna is only 0.2°. So it just so happens that even at Duna you can get "close enough for practical purposes" by using the same cheap trick. It also works at Jool, with your choice of Laythe, Vall, or Tylo. Around Moho, Eve, Dres, or Eeloo, you are definitely out of luck though.
  14. Cooling Convert-o-tron - I have this right?

    Counterintuitively, the "cooling %" readout on the radiators has nothing whatsoever to do with how much cooling capacity they are utilizing. What that readout really shows you is the radiator's temperature. In other words, this radiator is at 48.36% of its maximum temperature limit - probably around 1210K. When looking at radiators, it's important to understand that KSP knows two forms of heat: "normal" heat, which governs the actual temperature of spacecraft parts, and "core" heat, which governs the pretend internal temperature of things like the Convert-O-Tron ISRU modules. Normal heat is handled by the normal physical properties of the radiator part, including its actual size. It is pulled from other parts to the radiator once those other parts exceed (I believe) 400 K; the radiator raises its own temperature by lowering other parts' temperatures. Since it has a very high maximum temperature and great heat radiation abilities, it is much better suited to hold and slowly dissipate all that heat. Core heat is handled exclusively by the "core transfer" stat on the radiator. It is not visibly processed by the radiator at all. It does not raise the radiator's temperature in any noticable way, nor is it affected by any of the radiator's own physical properties. It's a bit more complicated under the hood than the following, but for all practical intents and purposes, you can think of it like this: The game sums up all the "core transfer" values from all radiators you have installed. Then it checks if there is enough core transfer to handle the core heat produced by active ModuleCoreHeat partmodules. If there is enough, then the ModuleCoreHeat will hit their optimal temperature and stay there; if there is not enough, they will grow past their optimal temperature and lose efficiency. In your case, you have three Thermal Control System (Small). Each has a 50 kW core transfer stat, for a total of 150 kW. However, the Convert-O-Tron 250 produces 200 kW core heat for each active process. So you do not have enough cooling to run even one, let alone two processes at the same time (as your screenshot shows). That the radiators' physical readouts do not suggest that they are at full load is completely irrelevant for core heat; those numbers only count for normal heat. All that counts for your use case is the sum of core transfer versus the ISRU's core heat production. EDITed: Oh right, I forgot: the drills also produce core heat, and also need to be factored in.
  15. Yes, this is a known issue. Not sure we know how to fix it though... (Also, welcome to the forums!)