Jump to content

blowfish

Members
  • Posts

    4,559
  • Joined

  • Last visited

Everything posted by blowfish

  1. @Youen A few points there AJE doesn't do any scaling of that engine to bring it to to the indended size and performance of the real SABRE. The part in question has a diameter of 2.5m, the real one is about 3.8m at the intake and 5m at the nozzle. This sort of scaling is RO's domain, not AJE's. Static thrust is going to be much less than 2 Mn. Depending on which of REL's sources you use, it's somewhere between 600 and 800 kN per nacelle. Thrust will of course drop off if you climb, but it will increase if you gain speed. If you're hitting 15 km and haven't even passed mach 1 yet, you're doing the ascent wrong. If you look at REL's simulated ascent (xls file), you will notice that the SKYLON barely climbs at all before going supersonic. It takes a very shallow ascent path which increases drag but also thrust, meaning that the ascent happens quicker and probably results in net fuel savings. Also note that the SKYLON is intended to have a very long takeoff roll, longer than the 2.5km stock runway allows (I think the intended runway length is 4 km). For a shorter runway you need a higher TWR to achieve takeoff speed before you run out of space.
  2. The root part is the first part you place in the editor (unless you use the select root tool to change it). But it sounds like that's the issue ... let me know if it ends up being something else.
  3. Sure, and we also have compressors and precoolers and rocket nozzles (REL had a successful test of their precooler technology recently). In both cases, you don't really figure out all the details until you actually try to build one.
  4. Do you have a switchable part as your root part? If so, use a different part as the root - there's a bug that causes various exceptions when that happens (fix will be released with the 1.1 version).
  5. Thanks for the detailed support request ModuleManager 2.6.21 is for KSP 1.1. You should get 2.6.20 or earlier.
  6. Conceptual stats, sure, but no visual references.
  7. Well so far it's not actually a real engine. And there are precisely zero references for what it will actually look like (believe me, I've looked - every image that comes up can be confirmed to be of something else).
  8. Probably not the exact UI control you want to use with TweakScale, but I've never really looked at TweakScale's code before.
  9. There's really not much to it - it just uses the stock UI_ChooseOption to display the part switching sliders. The relevant file is here, but if you're trying to understand it, you're probably better off just reading this post:
  10. Well since I haven't released any official versions yet, issues like this are bound to happen (AKA use at your own risk). But I did fix that bug, so re-download B9PartSwitch.
  11. What version of KSP, B9, and B9PartSwitch are you on? Also, your spoiler tag didn't work.
  12. The folder in GameData still has to be called B9_Aerospace. Alternately, you could go into each of the part cfg files and update the model paths.
  13. @nablabla That does seem odd, since if the mode is deleted then none of the contents matter. It might just be a typo, ! and @ are right next to each other on the keyboard.
  14. Sorry, I referenced the wrong person. I think what you had originally is correct.
  15. You probably just have a broken or outdated version of Interstellar Fuel Switch. E: And welcome to the forums
  16. I think @Bit Fiddler has it right. IIRC, comma is equivalent to &, so @RESOURCE[LiquidFuel],@RESOURCE[Oxidizer] would match a part that has both LiquidFuel and Oxidizer. | means or. Also @ identifies subnotes in a HAS clause.
  17. Wanted to see if I could do this using the new inflatable heat shield in 1.1. Turned out to work pretty well. A mid-air recovery would be impractical in KSP, but there's no penalty for splashing down.
  18. You can have multiple, but they will only look at the first Animation component they find. This is a bug that has existed since 1.0.5.
  19. I'm guessing the relevant code moved to OnUpdate(), which is the KSP equivalent of Update() (both are called). SurfaceLights shouldn't have to intract with FixedUpdate() or OnFixedUpdate() at all. Also, for the Unity methods (Update and FixedUpdate), I'm pretty sure that calling the base isn't necessary at all - Unity will call everything in the inheritance hierarchy up to MonoBehaviour. These methods can even be private and Unity will still call them.
  20. Why are you calling base.FixedUpdate() from Update() ? Those methods really shouldn't be calling each other (Update should be used for graphical updates, FixedUpdate should be used for physics updates).
  21. As Jimbodiah mentioned, that's just how the RL10 works (IRL picture). It extends when you activate it.
  22. Kind of. It's a test release and it sounds like it still has some issues to be sorted out.
  23. I think it works (see stock Panther), but maybe all of the animations have to be on the same component? I forget exactly what the limitation is.
  24. @Eskandare You don't need to specify all the range parameters. In your case setting (gimbalRange = 0, gimbalRangeXP = 10) or (gimbalRangeYP = 0, gimbalRangeXP = 10) would be sufficient - the positive range updates from the regular range if it's not set, and the negative range updates from the positive range if not set.
  25. Makes sense, I figured it was just worth mentioning so that people know what the expected behavior is.
×
×
  • Create New...