CobaltWolf

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!

@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.

So, what the heck is it then? This isn't the first time I've seen that mod brought up.

Mein gott.

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.

Yeah KSP loads everything into ram at startup, not on demand. That's why most people have such long loading times...

Those panels are neat! I love the extending ring design.

Oh... poop. @akron where's your cheat sheet?

No, it never was supported in the end.

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

Ctrl+F this page and go to Solar Panels, should have everything. I do not believe you can specify a max angle.

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.

Ooph. I LOVE this!

W-whoa, @Foxxonius Augustus is that what I think it is? The missing PDF from 2 years ago?

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).

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.

@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.

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..?

(Getting to this somewhat late) I've thought a lot about this, and definitely have been on both sides. In the end, I feel I've come down firmly on the side of Apollo, for a number of reasons. Simply put, yeah if you want basically a cramped 2-person capsule with some limited maneuvering ability, yeah Gemini is fine. But, Apollo is so far an above a more capable system I think that it definitely outpaces Gemini pretty quickly. There isn't really much you can do with Gemini past what it did IRL - certainly nothing that Apollo couldn't do better. Maybe there's a case for Big G, if you're just concerned about getting men/payload to stations. I've always been fascinated by the similarities between Big G and TKS. But, in general with Gemini you need to remember that all the 'what-ifs' for it are essentially McDonnell marketing materials that have survived in our memory, and almost none were seriously considered. Actually, speaking of Big G, what are people's thoughts on how I should (eventually!) build it? I kind of default to assuming I'll do the conical one, but because our Saturn is a bit narrower than IRL, the proportions don't quite match. I've been able to find an image that can illustrate this. Now, remember the wall angle for the Big G is constant - the Gemini itself, the expanded crew capsule, and the service module all have the same slope. Because it has to meet a larger diameter IRL, the slope continues much further. In the image below, please imagine that the service module ends at the bottom of that middle band, the one with the tan RCS quads (sans thrusters). The net effect is the service module is maybe half as long as it should be. Now, of course, there are other options. I could change the slope of the SM (not ideal either), I could go with the cylindrical-looking one which presents its own set of problems - that main body of the cylinder isn't 2.5m and certainly isn't 3.75m! So, no real easy solution which is honestly we we don't have a Big G yet, but it's certainly something I'm interested in. Some might remember I said this would be the update where I finally finished the Gemini stuff... I guess that is still postponed. Another question becomes, how will the rear docking port, with the long snoot adapter, work? I remember FASA having it as one part so that you could animate it extending. I don't see anything in any of the diagrams that show that sort of behavior - it seems to be fixed in the extended position. In general, if anyone has thoughts on this I'd also like to hear how you think the parts should be divided up. Remember that we already have the Big G crew capsule courtesy of @Beale. We have made some comments to ourselves about moving to maintaining the manual on our Github's wiki, but I don't think either myself or @Jso have sufficient time to take a crack at it at the moment. I didn't have much of an answer, do you have any more information? When did it happen (before hard dock, after hard dock...)? Usually stations tearing themselves apart is because you left too many reaction wheels / SAS modules enabled and they wind up fighting each other's forces and tearing the station apart.

Alright, if the heat probe explodes again can you try and compare it to the revised/fixed one from the Github?

(sorry, you didn't ping me so I didn't see your reply! ) The launchpad isn't a very good test if I remember. IIRC the best way to check is to quickly build a rover and drive clear off the KSC grounds (ie to where the normal terrain takes over from the 'fake' KSC grass) and then test things.

Gotcha. I'll see if I can whip some up tonight. As for sciencedefs, here is an issue on Github but I'm not sure if there are more experiments that needed to be added to that list. Here is the file in question where the experiment result texts live. The syntax etc should be self explanatory. If you're not comfortable trying to make a pull request on Github that's fine, if you just send me a pastebin or something that is fine. I only ask that you keep the definitions kind of 'kerbal', with the tone similar to the stock science defs.

I've mentioned it in passing, but the level of support BDB has had from previous contributors has waned a bit. I know that @DiscoSlelge and @minepagan are both pretty busy with school, for instance. Me and @Jso have been talking about moving the manual to the wiki on the BDB Github. I don't see why we shouldn't make an effort to start maintaining the craft files. Any requests to start with?

@Deus Zed Machina I'd look at the assets from Porkjet's unfinished part assets and see how he did his. They're basically as @sarbian described, with one ConstrainLookFX, but one end of the gimbal struts (and several pipes!) are instead skinned bones.

No it doesn't. We need the ksp.log that lives right next to the game exe.