draqsko

https://en.wikipedia.org/wiki/List_of_spaceflight-related_accidents_and_incidents#Non-astronaut_fatalities Only a couple incidents that I could find, one similar to what you describe but for Delta rocket. And the other one was this, for a Titan IV.

Debugging my current modded install and came across this: The multilight module is throwing out NREs all over the place, so I'm not sure it matters much as its happening on every part. However, I think the Lynx_DrillRear is getting turned into Lynx.DrillRear like the ISRU is and then this: is making it lose its mind. I think I remember another mod having an issue like this with underscores being turned into periods and screwing up things.

I went one step further and took that puppy to Minmus with Apollo. Of course I used the 7 segment boosters. And the Big G Tourist bus on the INT 19, for Munar and Minar flybys. Note that is all 2.5x scale so pretty close to something you could do for real. The Apollo one might not have made it to the Moon, it could have certainly flew by but not sure how performance would have been with a fully fueled CSM and LM. Half the fuel load is fine for Minmus, not so much the Moon.

Except the Titan IIIC on that Dynasoar. Shouldn't have fins, I blame Aerojet for that. What the heck did they know, they only made the engines. The illustrations with the fins comes out of Aerojet, Martin and Boeing never had them. Source: https://forum.nasaspaceflight.com/index.php?topic=40012.0 And Boeing's own artwork: https://secure.boeingimages.com/archive/Titan-III-&-Dyna-Soar-in-Flight-2F3XC58754Q.html#/SearchResult&ITEMID=2F3XC58754Q It really doesn't need the fins as the boosters provided enough drag to lower the CoP in relation to the CoM with the Dynasoar that it didn't need them. The Titans without boosters did need them though because the CoP would be above the CoM without them. Plus it might have caused an issue with separation given how the separation motors were aligned: The bottom one is canted just off the shroud which might put the exhaust right into the fin mounted on the other booster, potentially causing the nose to pitch in towards the core during separation and then aerodynamically it would want to fly into the core. The top motor is also canted in the same direction so it would add more push to the bottom than the top. Might be possible if they were canted on opposite sides of the core as the booster would spiral away like this: (Don't ask, I just get crazy ideas sometimes.)

LOL I was going to post that pic in the thread as well but thought it would make the post too long. My comment about it was: But now that you say it, it does look like it's shooting the hurricane. Actually I used that pic to inspire my MOL to MOS setup here: https://imgur.com/a/7teWpbn for my 'What If' space program. But yes, the hardest thing is finding actual MOL stuff that's legit rather than some artistic interpretation. So I took all the artistic depictions and rolled them into one then expanded on it. I do love the result in the end: Historically accurate it is not, but incredibly fun to build and it's got that kludged together Mir quality to it that makes it feel like it really could have happened. That's why I love these parts from the pack, it might not be the most accurate part of your mod but it's good enough to make it feel alive and real. And to me, that's the most important part, how real does it feel not how historically accurate it was.

There's all sorts of crazy ideas with the early proposals or concepts. How about an Atlas wet workshop for the Mercury? https://www.popularmechanics.com/space/rockets/a18469/nasa-first-space-station/ Of course that was in 1958 before Kennedy issued the Moon challenge.

Possibly, but there were a bunch of proposals for MOL that were similar to this layout, heck they even had one for a Mercury MOL launched on an Atlas-Agena. If I can find an official source, I'll post it up. But that one above is straight from NASA's website (early 1960 proposal) so just because it has an empty equipment bay doesn't mean anything. Don't forget those equipment bays were likely to be filled with surveillance equipment for spying on the Russians and I'm sure no one in the USAF or NASA wanted that to be public so they were sanitized. Doesn't mean there never was a proposal like that, just that it'd be harder to find as they were and likely are still classified.

It's not much and I'm having trouble tracking down the original right now but there was a proposal that had the Transtage but not the Dorian telescope section: Pretty sure that was a very early proposal given the mock-up has a Gemini R/V shown which was just a modified Gemini with a crew passage through the service module rather than the Gemini B with the shorter service module. Transtage is also a bit different than the actual Transtage that flew (that one appears to have a boattail around the engines). Could have also been a proposal after the cancellation of Dynasoar given that it combines the characteristics of the Dynasoar satellite inspector with the MOL Dorian.

Do you have ScanSAT installed, only seeing FilterExtensions for it but no DLL? I see you have MKS installed. That config only cares about 3 things, ScanSAT, RSS, and KolonyTools (which is MKS related). I don't have MKS installed yet so maybe that is the issue. Or maybe the fact that ScanSAT isn't loaded and mine does have it loaded. Perhaps the changes for the resource scanner in MKS would break something in ScanSAT's RP-1 contracts which might crash the whole thing even if you aren't using ScanSAT. Oh another thought occurred to me, check your Community Resource Pack, and Real Fuels. The KolonyTools call backs are changing stuff that is typically defined in CRP, and Real Fuels comes packaged with the CRP version to be used with it (and your KSP version) I believe.

I'm not seeing this in a clean install of KSP 1.3.1 and installing RP-1 v1.1.1 with all the RO/RP-1 recommends and raidernick's US part packs (FASA, Probes, Rockets, US and Soviet Solar Panels, and Skylab). Is this something that pops up later in the contracts for RP-1 or does it exist right from the start of a new career? Also looking back at your previous post reporting this problem, are you using CC 1.27.2 on KSP 1.6.1? Because if so, that is your problem more than likely. CC 1.27.2 is a backport of CC 1.27.1 (that's why the version file still says 1.27.1) for KSP 1.3.1, using it on KSP 1.6.1 will probably break things. Try using CC 1.27.1, not the backport, and see if it works with the ScanSAT config. You shouldn't need backports on 1.6.1 (although the 1.6.1 install guide is a WIP so that may change), from the looks of this: https://github.com/KSP-RO/RP-0/wiki/Installation-for-1.6.1-(Very-WIP) you should be able to install everything on CKAN except RSSVE and KerbalRenamer.

Since no one has replied, see here: Posted the fix at the end there, see the edit about replacing :FOR[SVT] with :FOR[rSVT] so SVT loads before Sigma Dimensions.

Hardly miserable, or tedious, it gives my game meaning rather than run the same contracts over and over ad nauseam for the past year plus. Fortunately for you, you aren't required to use this mod to play KSP and some people might enjoy the current functionality, so requesting that some feature be configurable is preferable than asking to remove it entirely because you don't like it.

Personally I think it is more insane that you can throw up something in orbit in KSP and it lasts forever and a year without any maintenance. Or that you can point your telescope directly at the sun without any special filters and it doesn't cook off. But to each his own, which is why @icedown is making it configurable. I was just posting suggestions to ease your pain when using the current version of CactEye, if you so choose.

Hope you aren't trying to do historical missions with those RT configs. Both the RT and the SETIRebalance configs have the same stats for the antennas, and I found that Mariner 1 and 2 are impossible. The ranger dish antenna has an RT range of 50,000,000 m (just past the orbit of Minmus in stock scaled systems) while the stock configuration has an antenna power of 2,000,000,000 which can easily reach Eve. The RT configs are balanced around stock antenna balance rather than actual historical uses. It's part of the reason I dropped using RT for the moment, the BDB RT configs need a serious rework if you want to do historical missions, both in range and data transmission rates (there's a few times I've had to allow partial transmission because the antenna can't even transmit the smallest experiment in one go on certain historic probes). To give you an idea how messed up it is, the Mariner 4 dish in stock BDB has an antenna power of 8,000,000,000 while the RT config has a range of 35,000,000,000 m. Using that ratio the range of the Ranger dish antenna should be somewhere around 9,000,000,000 m (which would reach Eve as long as its on the same side of the sun as Kerbin) instead of 50,000,000 m. So keep that in mind before you launch your Mariner 1 and 2 missions to Eve only to see them lose connection just outside Kerbin's SOI like I did. PS. Eventually I'll rework these configs myself if no one else does and submit a pr on github, but right now I don't want to commit to anything. Just bought a new house and while I'm taking a break right now from doing work around it cause it's too damn hot, I know I'll drop off the face of the Earth in a month or two once it cools down enough to work outside at least until winter sets in. I hate to leave people hanging by saying I'll do something, get halfway through it and then have to stop because of real life.

The only parts that should break from use over time and require service are the gyros, should turn them off when not actually using the telescope to observe a body that will prevent them from burning out too fast. The processors can explode if you point your telescope close enough to the sun, which makes Eve and Moho observations challenging but not impossible, do them on the dark side of Kerbin. Since the FungEye body doesn't have a closable shutter, it's wise to keep it pointed Normal/Anti-normal for an equatorial orbit or Radial-in for a highly inclined orbit when not in use so you don't accidently scan through the sun while turning to point towards a body for observations. I've lost a few processors learning that the hard way. And BARIS would need a MM patch to make it actually break parts in CactEye aside from the probe core and gyros. The processors and telescope bodies don't have resources or modules that BARIS can hook into. The probe core and gyros have the SAS module which BARIS will break. If you don't want your gyros to wear down over time, go into the part configuration files tele_gru1.cfg and tele_gru2.cfg and edit this part: Change lifeSpan part from 25 or 50 (gru2 is 50 for lifespan) to some huge number like 2500 or 25000. It'll still technically wear out over use, but that time limit will be virtually unreachable in normal gameplay since it only ticks down when you have the gyro active and the vessel in physics range. I wouldn't recommend deleting that line to make the lifetime infinite, since the dll will be looking for it and no definition might be treated as 0 lifespan which would break the part instantly on launch.

The configs are really bad, the parachute unit has this: while the stock Mk1 parachute has this: The stock Mk25 parachute is 25 by way of comparison. So the parachute has the drag to slow down something as heavy as the Mk1-2 capsule to safe landing speed. Anyways there were other issues I found in the configs so here's the changes: Parachute.cfg These are just edits except data transmitter module, to bring it more in line with stock parts. You may need to tweak the dragModifier = 6, depending on how your descent goes. Higher will slow you down faster and result in a lower landing speed. 12 is the setting I used for 2.5x which has a much higher gravity well than stock but I used this for Corona which required an aerial recovery and therefore a really slow descent speed once the parachute opened. Either way, changing this will change how fast you slow down with full chute deployment. The other module like this named SEMIDEPLOYED is for when the parachute is in drogue deployment, if it doesn't slow down fast enough to fully deploy the chute before hitting the ground, tweak this setting up a little bit (I use 1 for 2.5x). ModuleDataTransmitter is needed for an internal antenna otherwise you won't be able to control the capsule, since the model has an antenna built into it, I felt it appropriate for that antenna to actually exist. CargoBay.cfg The CoP, CoL offset changes can be added into the part config after the node stack definitions. I had issues with ablator burning off and raising the CoM high enough that it would turn turtle, CoP and CoL offsetting prevents that. Thermal mass modifier is set for normal parts rather than cargo bay like thermal mass since this has built-in ablator, which cools the part as it burns off. Normal cargo bays need a higher thermal mass to protect the parts in them but this cargo bay should never get that hot to need it unless you actually run out of ablator. And if you run out of ablator, you should burn up rather than rely on the thermal mass modifier to keep from overheating. The change to ModuleCargoBay is needed however otherwise parts inside the cargo bay won't actually be protected, the ray casting starts at 0, 0, 0 and is hitting the floor of the cargo bay at 0, 0.0424, 0 before it sees any parts except parts attached to the floor that happen to clip some part of their model through it. PS. I'm still not entirely happy with the settings just yet, there's probably more tweaking involved but this should at least get you a functional return capsule. PPS. After making these changes make sure you delete the ModuleManager.configcache and ModuleManager.configSHA files so that MM loads the changes. If it loads from cache any change you make will not be recognized.

Wild Blue Industries/MOLE/ExperimentResults/BaseandStationBuilding.cfg is only for a surface experiment, changing only that file will produce no resulting change for an orbital lab, it has to be landed on Kerbin, Minimus, or Mun per the situation requirements that I quoted. You could test overall functionality using the edit you tried but you'd have to try the experiment landed on the surface of Kerbin or one of the moons, not in space. MOLEModulesExperiments.cfg is the configuration file for orbital experiments, and you have to add it there to every experiment as well as you can see: There's other issues perhaps in the configuration for BDB as I stated earlier, I'm not familiar with how MOLE operates so I'm not sure if the entire config actually works. From what I can see comparing the BOW to the Hokulani it should work in theory since the configurations are nearly identical, other than the fact that WBI calls back to a template folder for the configurations of the templates while BDB has the templates in the compatibility file of the part. Either method should work equally well with Mod Manager for patching parts.

That experiment only works while landed, if you scroll down a bit past the section you were editting you will see this part: Have to be landed on a body to perform the experiment, and it only applies to The other file in that folder, MOLEModulesExperiments is probably where you want to add in the OWS as a required part in orbital experiments. Also make sure you use the title of the part, so in the case of the Skylab OWS it would be requiredPart = Hokulani-OWS Orbital Workshop Not sure that will fix it though, there could be other issues in the configs and I've never used WBI MOLE so I'm not really familiar with how it operates. But that should at least get you started in the right direction. Also delete the MM caches every time you change a configuration file so that KSP actually loads the new configuration, sometimes MM will just load from cache and that will drive you nuts trying to debug something in configuration files.

They would all be about the same diameter, the only difference is length and dead mass/instrument space really. And that difference is incredibly small for stock or 2.5x scale, using real life numbers: X-242 (which is what I think you based the original model on since it's a Vanguard apogee kick) total mass is 0.217 t, propellant weight is 0.193 t, thrust is 11.6 kN X-248 total mass is 0.239 t, propellant weight is 0.211 t, thrust is 13.8 kN X-258 total mass is 0.275 t, propellant weight is 0.235 t, thrust is 24.8 kN FW-4D total mass is 0.299 t, propellant weight is 0.275 t, thrust is 26.4 kN Star 13 total mass is 0.038 t, propellant weight is 0.033 t, thrust is 5.87 kN Star 20 total mass is 0.301 t, propellant weight is 0.273 t, thrust is 28.4 kN If you scale all of those down, there's really not much significant difference other than aesthetics. The only outlier is the Star 13, and your really tiny solid can be used for that (the one that's the same diameter as the Vanguard 'spin up' shroud attachment on the probe core) or the Pioneer kick motor, unless you need attitude control then the Staara 10 reduced in fuel load and thrust with micro RCS booms attached for pitch and yaw control will substitute nicely.

The Staara 20 is way too big for the X-242, X-248, the Staara 10 is closer to the actual fuel load, thrust and burn times. The Staara 20 can be used for the X-258 and FW-4D but with those rocket designs, you get much more out of it than historical rockets did and the Staara 10 feels like a better fit for trying historical launch profiles. I know you can drive yourself nuts on the early rocket designs and have a million parts to actually build them all to historical accuracy so I'm not expecting you to make every single engine. Either way, deprecating the old model would be helpful so it doesn't instantly obliterate assemblies before they can be updated.

Put the micro RCS booms with built-in MP tanks that BDB includes. All the Staara motors will easily accommodate them and that will give you guidance all the way to payload separation. You technically won't even need electric charge to use them other than the lack of probe control with the lack of EC. Also if you are OCD as myself, you can line up the thruster outlets with the slots on the engine shroud so when you lose your fairing you don't have MP blowing through a shroud (since KSP doesn't treat shrouds as shielding a component, soon as you eject the fairing, they'll start working). Same thing I'm currently using the Staara 10 LYC motor for, could you deprecate the old motor so it doesn't break subassemblies? That one particular motor is quite heavily used with tweaks to thrust and fuel load as an approximation of all the upper stage solids in early rocket launches. I use it as a placeholder for the X-242, X-248, X-258, FW-4D, TE-M-516, so it's quite a lot of rockets that actually have that part.

I use them a lot, basically for any payload that just had to make it to space within a certain min/max altitude requirement. Also in 2.5x you'll need them for the early rockets to even get a payload into space (specifically Vanguard which is even borderline at that, if you don't use the 0.25 lever on SMURF or BDB's own SMURF configuration it won't make the historic orbital height in 2.5x). Yes, on the second question as well, since they are used in the Athena, Antares, Minotaur and others and those are very nice low cost to orbit disposable rockets (one half to one third the cost of an LFO rocket with comparable delta V). Basically anyone doing historic builds will be using those solids, doubly so if you are using KCT where construction costs can increase with needing multiple launch pads to launch simultaneous missions due to pad refurbishing, or using BARIS where the incremental changes between the early rockets can really help your finances since test benching and static firing can get expensive when starting a whole new rocket design. That's primarily how I play KSP, running a somewhat realistic space program, and your mod with the upper and lower stage solids allows me to leverage the other mods I use to fully realize that.

@Tiankay Ok I can see your point with the ELT. But if a new one is created, it would be a good idea to split it in two with one tank slotting between the 360/380 and 860/880 and the other being the difference. Pretty much all the common tank sizes (1.25m, 1.875m and 2.5m) all have quite a few options either covered in stock or by this mod. However the 1.5m size is pretty much limited to the Delta parts, something around 500-600 in size would slot in nicely. I assume that quote you posted is from @CobaltWolf? If so, just because it has ribbing doesn't mean it'll always look terrible: I probably should have flipped that small tank above the LTT or put it on the bottom, but as you can see the ribbing doesn't really stick out. I think it depends more on how tight the ribbing is and how wide it actually is. It also helps when you do like I did here and match the ribbing up against another color instead of the same basic white tank texture. Another tank that doesn't look terrible with ribbing being in the middle of the rocket, but again it is bordered by the orange stripe with a darker grey below so it looks more like a transition to the adapter tank than a sore thumb even though the adapter tank doesn't start until the black stripe. Actually that white/light gray line at the joint sticks out more than the ribbing does.

If the tanks are balanced around stock, then wet mass to dry mass ratio shouldn't change no matter how many or what tanks you add unless someone messed up with the dry mass. Obviously service modules aren't going to have the same ratio but just plain fuel tanks with LF/O should all have the same dry mass per tonne of fuel. Personally the only thing we really need is an extension tank to go on the LTTAT that will make up the proper length for the ELTTAT rather than a dedicated tank for ELTTAT. It would also be a bit more fitting for this part pack which tries to maintain a Lego like variety of parts to mix and match how you desire and it would slot right in between the 360/380 and 860/880 tanks giving users another option for the 1.5m class. PS Leave a message when you upload them to KerbalX, I always like to check out real world rockets other people make with these parts and to see how they would compare to ones I build.

Delete the :FOR[SVT] in Kerbin's cfg file, it's overwriting SigDim's changes somehow. So far that seems to work for me. @Galileo Here's some information on this issue, perhaps you can suggest a better fix for now that users could edit into their files until you get a chance to update it (or if you like just suggest how you'd like it fixed and I'll submit a PR on github). Here's my Mod Manager cache with SVT 2.1.4 as installed (I cut out the bit between Material and Ocean to shorten it a bit, no real difference in that section anyways, just to show that something is being overridden since the position of SpaceCenter changes and loses it's rescaling and I believe that is the culprit for this bug): AtmosphereFromGround { outerRadiusMult = 1.028571428575 innerRadiusMult = 0.971527777774318 transformScale = 1.05714285715,1.05714285715,1.05714285715 } } PQS { Mods { SigmaDimensions { Resize = 2.5 Rescale = 2.5 Atmosphere = 1.1 dayLengthMultiplier = 1.5 landscape = 0.76 groundTiling = 1 atmoASL = 1 tempASL = 1 atmoTopLayer = 1.038961039 atmoVisualEffect = 1.142857143 lightRange = 2.5 scanAltitude = 1 geeASLmultiplier = 1 resizeScatter = 1 CustomSoISize = 2.5 CustomRingSize = 2.5 reEntryHeat = 1 resizeBuildings = 1 changeScatterSize = 2.5 changeScatterDensity = 0.4 } } Material ..... Ocean { Mods { SigmaDimensions { Resize = 2.5 Rescale = 2.5 Atmosphere = 1.1 dayLengthMultiplier = 1.5 landscape = 0.76 groundTiling = 1 atmoASL = 1 tempASL = 1 atmoTopLayer = 1.038961039 atmoVisualEffect = 1.142857143 lightRange = 2.5 scanAltitude = 1 geeASLmultiplier = 1 resizeScatter = 1 CustomSoISize = 2.5 CustomRingSize = 2.5 reEntryHeat = 1 resizeBuildings = 1 changeScatterSize = 2.5 changeScatterDensity = 0.4 } } } SigmaDimensions { Resize = 2.5 Rescale = 2.5 Atmosphere = 1.1 dayLengthMultiplier = 1.5 landscape = 0.76 groundTiling = 1 atmoASL = 1 tempASL = 1 atmoTopLayer = 1.038961039 atmoVisualEffect = 1.142857143 lightRange = 2.5 scanAltitude = 1 geeASLmultiplier = 1 resizeScatter = 1 CustomSoISize = 2.5 CustomRingSize = 2.5 reEntryHeat = 1 resizeBuildings = 1 changeScatterSize = 2.5 changeScatterDensity = 0.4 } SpaceCenter { groundColor = 0.444,0.494,0.294,0.23 groundTexture = SVT/textures/PluginData/grass00.dds } } And this is what it is with :FOR[SVT] removed from the Kerbin.cfg file: AtmosphereFromGround { outerRadiusMult = 1.028571428575 innerRadiusMult = 0.971527777774318 transformScale = 1.05714285715,1.05714285715,1.05714285715 } } SpaceCenter { groundColor = 0.444,0.494,0.294,0.23 groundTexture = SVT/textures/PluginData/grass00.dds radius = 18750 Resize = 2.5 } PQS { Material As you can see, somehow SVT is overwriting the changes SigDim is making to the radius for the SpaceCenter and likely drawing the textures too low due to that fact. That is literally the only difference I can find so far. This seems to be happening because SVT loads after SigDim, forcing it to load before SigDim resolves the issue. Edit: I think I have a better fix, at least temporarily for this issue. Change all the callbacks from SVT to rSVT in the config folder to maintain loading hierarchy. So, Change @Kopernicus:FOR[SVT] to @Kopernicus:FOR[rSVT] Change @Kopernicus:BEFORE[SVT] to @Kopernicus:BEFORE[rSVT] Change @Kopernicus:AFTER[SVT] to @Kopernicus:AFTER[rSVT] That will let it load before SigDim and then SigDim can modify it correctly.