CobaltWolf

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

It works fine. I even marked it as tentatively compatible on Spacedock for the CKAN people, since we haven't identified any (game breaking!) bugs.

IVAs are pretty time intensive for how much they are used (most people occasionally look at them for eye candy and that's about it), and so most of the parts don't have IVAs, and some of the ones that do are taken from other mods such as the Apollo IVA. I wish we had some dedicated IVA creators but most people seem to back out once they realize what kind of time investment it will be. One of the only parts with a real IVA is the LEM, which was recently made @bcink . Similarly, I don't really fiddle with the stock FX for engines since we natively support RealPlume and encourage it. It used to be that we would have a lot of community contributors that were able to help with all the config stuff and keep things like our compatibility files updated, but that help seems to have dried up. Well then what does your ksp.log say? The one in the root directory. Ctrl+F and look for AARDV till you find the error message.

I will say, that is VERY dependent on the parts in question. For example, many stock parts use horribly inefficient textures - no reuse, horribly high amounts of pixels used for a given surface area. However, many mod authors like myself (and I think some of the newer stock parts) use large textures as atlases that can have numerous parts which have reasonably pixel/surface ratios. In that case they are most likely desperate for every single pixel of those sheets, and won't respond well to being crunched down. With all that said, you sound like you know which ones needed the treatment - when I first read the post I was afraid it was just batch converting every 4K texture in your GameData but after re-reading I don't think that's the case. And at any rate, it is of course up to the user to decide the balance between performance and quality

As far as we know everything is more or less working fine. At least, nothing game breaking.

Should be; it's just parts.

Indeed, basically inside Gamedata/Bluedog_DB/Parts/, you can safely delete any of those full folders without doing any worrying. If you want to prune stuff out of individual folders (let's say, delete the Saturn parts that aren't relevant to Eyes) then it's a bit more involved.

I forgot to post the final dev picture of the E-1... here is the finished engine!

Some quick work while snowed in this morning... finally got around to making that inline LR-101 vernier!

I just opened up the IHP in Unity and think I see the issue - it goes back to the previous issues we always had with some of these parts, stemming from my own user error when making these parts. I've uploaded a test fix to Github - can someone download the master (the green button on the SEP GitHub homepage) and see if it helps? ***WARNING - it will likely break any Interior Heat Probes that you currently have on the surface***

Another Tuesday night, another dev stream about to go live on Twitch...

One thing I've noticed, that concerns me a little. In the screenshot @Jarin posted above, the tank appears to have kept most of its detail. However, below in @Snark's screenshot, it appears to be missing much of the diffuse and specular detail. Note the missing horizontal (well, vertical with the tanks sideways) paint strokes, and moreover, the shading around the corrugated parts (most noticeable at the left hand side of Snark's screenshot) - it appears the normals are still present, but there is no complementary shading in the diffuse to help sell the effect. Again, it seems that they were present in the screenshot Jarin shared above. Is there a reason for that? Ignoring the complications presented by the black stripes on the original textures, I believe with some slight adjustments the the original textures can be overlaid using the 'multiply' blend more to add at least the dark shading back? In any case, @Jarin your retextures are very cool! The two longest tanks in particular are nice. I think the stripe in the small corrugated tank looks a bit out of place however, and the shortest tank I feel would look best fully green. Are the green/orange tanks using custom specular maps as well?

Yup! A proper stack mount LR-101 (or just, perpendicular to mounting surface...) never got made during the revamps. That's something I keep meaning to fix... Cool! I'll definitely keep it in mind. That goes along with needing to fix the standalone LEM antennas (they have messy UVs...) and making proper standalone LEM legs... Yeah, I don't have much of an intent to properly make a Delta Cryogenic Upper Stage, but it does work pretty decently with a stretched Centaur-G` (G``?) and a stock-fairing-interstage type dealio.

It does now! Apologies to all - SEP is now compatible with KSP v1.4.1! @DMagic sent me the files several days ago, but I completely forgot to push it as a release! But, all should be good now on both Spacedock and GitHub.

There was an issue, it's up now, go check.

Ven's Stock Revamp

Is it not under, well, payload? Negative, that would make the engine huge! The ring is 0.9375m - I did not want to make it bigger than the bell, for clustering. What I do need to do, however, is make it so you can use the engine fairing from a Titan 1 on it... @Pappystein you're right, I was thinking about that the other day. I have never seen mention of it, but I believe the design probably would have used dual LR-101s. I just wonder what sort of mounting they would have had - side mount, like Atlas? Or bottom like Thor...

Currently working its way down the pipeline... E-1 rocket engine, perfect for a single-engine 1.875m stack.

Do the ones currently in the mod actually help? I did not do any real research on them, or make sure that they actually 'worked' - I just modeled it from a picture and stuck it on. If they can be changed to be more useful that would be good feedback. Also, if I remember the Apollo docking port should do angle snapping and only dock at specified angles anyways?