Jump to content

CobaltWolf

Members
  • Posts

    7,370
  • Joined

  • Last visited

Everything posted by CobaltWolf

  1. The new stock switcher is horrendeously coded. For my use cases, B9PartSwitch does everything I need and then some, while being easier to set up than others; not to mention the dev is very responsive - not to say that any other switcher authors aren't, mind you!
  2. Yeah I never understood that one... what's with the shroud around the Agena tanks? It doesn't seem to do anything.
  3. I know myself and @Beale have wanted something like that for a long time.
  4. I'm not sure, what's going on?
  5. EP-25? Is that one of the new stock parts? In any case, I am glad someone noticed I added that part! I definitely want to try and finish the Delta part revamp before the next update releases. It's really just the first stage and SRBs left; maybe some touchups on the adapter. I know some people are probably upset that I currently have no plans to implement the upper stage, but I always thought that the Centaur G' or G'' (pictured below) make great substitutes. Thanks everyone! I might mock up some options for this sooner rather than later. If people still wish to continue the discussion I am interested in it. Doing the 'barrel shaped' Big-G is actually pretty easy - it's basically just a 3.125m cylinder with 2.5m adapters on each end and Apollo RCS. It's the conical one that is the issue, and I am not looking for a crazy solution to it. @MeekCJ's first google drive screenshot makes me think that just doing the conical the obvious way might work. @Dutchbook if you didn't see, the sciencedefs are uploaded to the Github. Thank you! To explain things a bit more for people that may not know, part of the proposal involved making this system somewhat modular. Theoretically, it should be possible to attach the Apollo CM to any of these with minimal work, or to put the Apollo SM on the Big G (obviously that eliminates the rear docking capabilities). Here's a 'Big Apollo' which i won't do, but gives you an idea of what an Apollo with the Big G conical SM would look like. Of course, some drawings DO show a change in wall angle for the conical SM... And of course, there's a number of configurations of the original Gemini spacecraft that would be nice to have, like this one and the others present in the document linked by @Abrecan the other week. I would love if our Gemini was made like that, unfortunately when we created it the idea of keeping it easy to use was really attractive. Right now I don't feel it's a good use of my time to rebuild it. Would take a lot of new modeling and texturing. I asked @Jso and he said we previously tried RealChute for the Apollo chutes, but it made them clip together above the pod rather than spreading out correctly. If I remember the H-1s already are operating at their max capabilities (for reference, BDB uses 25% of IRL thrust and real ISP)... if they are not perhaps someone could make a pull request? I imagine there's other parts that could do with the upgrade modules. Some speculative ones for things like the Apollo service engines also would not go amiss. I don't believe I've talked about it on the forum, but this is something I've been planning as a 'eventual' thing once I finally want to get the 4x engine mount for the Saturn 1 with E-1 engines. I'd like to redo the bottom of the existing mount to take 4 E-1s, and create and entirely new model for the Saturn 1B's 8 H-1 mount, that is closer to the cylindrical one that flew IRL on the later S-I stages. For some background, remember I made the Saturn 1 first, and thus the stage was meant to represent that configuration originally. I wasn't really thinking to the future too much at that point. Saturn 1 Block 1 S-I stage: Saturn 1B S-I stage: And what a date for it too What do you mean they're breaking in the atmosphere? Can anyone give more information, or better yet experiment and find a solution? Not a bad idea, and I could probably make it with existing textures fairly easily!
  6. @NESD sounds like the same issue that @blowfish found with B9PartSwitch. The switcher code, because it runs AFTER the part is compiled, essentially can't access other modules. When the game starts and the part is assembled, it 'bakes' the transforms into the part. Those modules would have to be rewritten to be accessible by switchers after game load.
  7. So, what the heck is it then? This isn't the first time I've seen that mod brought up.
  8. The BDB ones already have RP configs in Bluedog_DB/Compatiblity/RealPlume - that patch can just be altered to use the internal name I set up for these (it's "MAH_Descent_RL10" right now - @bcink you need to figure out a clean, consistent naming scheme!) and then put in the MAH/Compatibility folder. Of course, @hieywiey I'd appreciate if you did that since I have a full legal pad page filled with little 'to-dos' for people around the forums atm. @bcink I'll shoot you a video I made on using Github for KSP modding. Takes about 3 minutes to set up and only a second or two to upload changes.
  9. Yeah KSP loads everything into ram at startup, not on demand. That's why most people have such long loading times...
  10. Those panels are neat! I love the extending ring design.
  11. If I remember the trick is to use faceted construction that mimics the topography of vertex models. So instead of cylinders use X-sided polygons, etc
  12. Ctrl+F this page and go to Solar Panels, should have everything. I do not believe you can specify a max angle.
  13. The mass of the part is added to the overall craft (meaning the part will still affect DeltaV, for instance) but does not affect the center of mass, amongst some other peculiarities I can't remember. The big thing is the CoM - you can mount instruments to a probe without making it crazy unbalanced, and adding RCS won't compound any torque issues.
  14. Chiming in to say I have never once had an issue or gotten a virus in the 6+ years I've been using Defender as my main antivirus (with full scans every month or so from Malwarebytes and the usual crew).
  15. It would be keeping with the in-universe explanation to have the taller hab module include an integrated laboratory space for processing samples (since the Orion missions are longer, but the amount of samples they can bring home is roughly the same). So, off the top of my head: RCS for the descent stage Orion-type Hab Ascent engines Whatever you're putting on the top deck of the descent stage.
  16. @Snark my solution is usually to just fall back on mesh switching, with duplicate (but separately named) meshes that have different textures assigned to them. Maybe inflates the .mu ever so slightly but shouldn't matter much during gameplay.
  17. If I may interject, shoutouts to @N70 for whipping up a Kerbalism compatibility patch for SEP. It's available now on Github if you use Kerbalism and think you need it - I don't want to draft a new release just for that patch, especially since we have a couple possible fixes for other issues in the works I think..?
×
×
  • Create New...