Tyko

Good thought. I'll check that tonight

I'm confused about how the mass of two parts interact. I'm trying to pair the Multi-Spectral imaging system and the orbital telescope opposite each other but keep neutral torque on the ship. I had already increased the MSIS up to Mass .03, so it's mass is the same as the Orbital Telescope. When I put them opposite each other I'm getting torque even though their mass is the same. What other factors would play into this? Here's a pic of a probe with the parts offset enough to achieve 0 torque. You can see I had to offset it quite a distance. My best guess is because the telescope is larger (sticks out close to twice as far) so it's mass is creating a longer lever arm. Looking for confirmation or another answer

Does the "efficiency" benefits of having an engineer present improve the ratio of input ore to output fuel or does the efficiency only affect the speed of the conversion process? UseSpecialistBonus = true SpecialistEfficiencyFactor = 0.2 SpecialistBonusBase = 0.05 UseSpecialistHeatBonus = true SpecialistHeatFactor = 0.1 ExperienceEffect = ConverterSkill EfficiencyBonus = 1

Great info @Snark This is my favorite method - after I figured out precision landing. I used KAS pipes which allowed a little margin for error on where I landed. After a few (okay, maybe more than a few) tries I got pretty good at landing where I wanted to. I chose Minmus and made sure I had nearly empty tanks when I landed. The low grav let me hover pretty easily and use RCS to scoot around. I was able to get pretty close in using this method - the solar panels and radiators are closed during landings..

can you post pix of the craft?

I'm seeing odd pixelation of Earth from a 100Km orbit. Any idea why? I'm using RSS 8K textures, don't have Scatterer installed (not sure if that would matter) and SSRSS High-Res clouds

I've been playing around with free return trajectories around The Moon (SSRSS 2.5x). Nailed it tonight Moon flyby at 34,998m Periapsis and then a return to Earth re-entry with a 35,750m Periapsis Flyby Sampler with Sample Return Capsule up front and 2 each Goo and Compact Material Samplers (custom). Ven's Stock Revamp'd parts

There were interesting points all around the equator. I settled on Brazil because the Atlantic ocean makes a really great splashdown zone

I set all the moons inclinations to real world relative to the ecliptic. The moon is at 5.145 degrees. I discovered a spot at exactly 0.0. Happens to be in the state of Para at the Amazon river delta. Just guessing they didn't actually build there for ecological reasons, but it's perfect for Kerbals. I didn't do KSCswitcher just because it was fun to make my own

Thanks for the additional detail. I feel like I'm at the "just enough knowledge to be dangerous" stage. When I made the adjustments I decided to leave the SSRSS special setting for Kerbin in place and just tweak the global @atmosphere level until Kerbin looked right. Ultimately I fudged it so that atmosphere was a nice, easy to remember number. I'm pretty sure it's close, but playability trumped precise accuracy @OhioBob what is the correct scalar for atmospheres at 1/4 scale to get Planets to a true scaled atmosphere height?

I learned this trick from @Aelfhe1m over the weekend...you can search in your game logs for which mods are changing parts. The example below is for parachuteSingle, but you can put in the location of any part and use the Find function in your text editor. Try searching your output_log for " to Squad/Parts/Utility/parachuteMk1/parachuteMk1/parachuteSingle" that will tell you all the patches that are being applied to that part.

That's an amazing troubleshooting tip! Thank you very much

Thanks for confirming my config..must be a mod conflict.

I'm trying to adjust the default deployment parameters for parachutes, but I'm not having any success. Any suggestions? @PART[parachuteSingle]:FINAL { @MODULE[ModuleParachute] { @minAirPressureToOpen = 0.2 @clampMinAirPressure = 0.2 @deployAltitude = 500 @chuteMaxTemp = 750 } }

This LOL....I wasn't looking in the right place and didn't expect them to be in the Life-Support category. Thanks for clearing this up. When I looked at the config I didn't see where it moved them to LS category...

I have a completely fresh install of KSP with only Tokamak and USI-LS plus their dependencies installed. I'm pretty sure setting the category to "none" is the problem. When you have only Tokomak and USI-LS installed are you seeing those parts?

Hi! thanks for keeping this going (along with all the other work you're doing on mods ) There's a conflict between USI-LS and Tokamak that's causing four parts to disappear from the game. When I just have Tokamak and dependencies installed I see the inflato1, inflato2, centrifugesmall and Munox all in the Utility tab. If I add USI-LS and it's dependencies those four parts are gone. The problem looks to be in the Tokamak_USI.cfg. Those four parts all have their categories set to "none" which disappears them from the VAB. commenting out that line in the four parts makes them all reappear. @PART[centrifugeSmall]:NEEDS[USILifeSupport] { %tags = cck-lifesupport USI MKS LifeSupport habitat inflat @category = none MODULE { name = ModuleLifeSupport }

Do the failure times take into account lengths of days/years of Sigma Dimensions scaled systems? I'm trying to parse the Lifetime stats...Batteries have a lifetime of 87600 - if this is "hours", then it works out to 10 years. Is it using the KSP day calculation which is configurable in Sigma Dimensions?

LOL, that would be interesting to see the actual NASA data. I've read about early Mercury and the before that...all the issues with boosters especially. Just my 2 cents, but from a fun/grind ratio perspective I think that it's safe to assume Rockomax or Jeb's Junkyard, etc are doing initial testing and only delivering relatively reliable parts .The chance for failure should be threatening enough to force players to build / plan for it, but not so high that I'm spending hours and hours running test flights before each actual mission.

Here are the results of a 10 launch series again - completely new game to avoid any benefits from the previous 10 launches. I added a few more parts to get more data too. I also extended flight times out to 6-8 minutes L1 L2 L3 L4 L5 L6 L7 L8 L9 L10 Parachute 21 2 1 1 1 1 0 0 0 0 Probe Core Battery 16 10 7 5 4 3 3 3 2 2 Probe Core Reaction Wheel 16 10 7 5 4 3 3 3 2 2 Probe Core Tank (there is no tank though) 16 10 7 5 4 3 3 3 2 2 Capsule Battery 4 11 7 5 4 4 3 3 2 2 Capsule Reaction Wheel 4 11 7 5 4 4 3 3 2 2 Capsule Tank 4 11 7 5 4 4 3 3 2 2 FLT-200 Tank 3 15 10 7 6 5 4 4 3 3 FLT-800 Tank 16 5 4 3 2 2 2 1 1 1 Swivel Engine 19 0 0 0 0 0 0 0 0 0 NOTE: I had zero failures over the 10 tests - does physics warp prevent UPFM from registering failures because I was using physics warp x4 during many of the slow portions Watching these numbers and thinking about it, I'm not sure making it all random and stretching out the number of tests before 1% is reached is actually more fun (it is a game after all). I don't think you want to turn this into Kerbal Engineering Program Randomizing a number that's already a % randomization is kind of unnecessary and makes your formulas and balancing more difficult Giving players the ability to swap out a particularly bad part in the VAB is just adding clicks because who's not going to throw out a bad part? While you want to introduce a chance to fail and that failure chance should be higher for a new part, it should drop really quickly - Your 1 player is representing a whole team of engineers and QA people, making the player go through 10 launches to get a reliable part is just throwing the fun/grind balance off. Consider this progression: 24%, 12%, 6%, 3%, 1.5%, 1%...stays at 1% - (you could add a difficulty level function to set this higher or lower) Starting at 24% supports the idea that your hardware teams are doing a reasonably good job before delivering parts to you. Anything with a 25% + failure rate would have been screened out in bench testing before it made it to the pad Dropping by half each time means that by launch 5 or 6 you have a very reliable piece of hardware - consider how much your players will be using parts in a Career or Science game players will be upgrading to new parts fairly rapidly early on so it's good to see these parts become really reliable before they're dust-binned in favor of newer parts. In a Sandbox game players often already use a smaller portion of the available parts. Making it too time consuming to increase reliability of other parts could just further reduce the pool of parts a player is choosing from.

I'll do some more testing this morning One thought about base failure chances. It seems like the two things that NASA has the hardest time with are electrical systems (batteries) and reactions wheels. In your model these are the 2 most reliable types of parts, but in the real world this was the opposite. The ISS, Hubble, Dawn, Kepler - have all had reaction wheel failures, just to name some big ticket projects. Saturn 1 had the biggest electrical failure, but there have been many others and "batteries" are really your indicator for the overall power system and wiring of a craft. If possible you might want to have the failure window shorter for engines and control surfaces. During a boost most engines run on the average of 2 minutes or so before they're jettisoned (that's a WAG, not an exact number, but in most of my craft that use staging 2 minutes seems like the sweet spot)

I ran 10 identical launches from a new save. I captured the failure % (below) on the launch pad. Launched each rocket and let the engine burn for 1 minute. I then separated the pod, did a parachute descent and recovered the pod. No parts were re-used, so each rocket was entirely of unused parts. I can see the numbers decreasing and also the effects of the randomization. L1 L2 L3 L4 L5 L6 L7 L8 L9 L10 Parachute Failure 21 17 12 10 10 9 7 7 7 7 Capsule Battery 7 15 12 10 9 7 7 7 7 7 Capsule Reaction Wheel 12 20 17 15 14 12 12 12 12 12 Capsule Resource (monoprop) 9 18 15 12 11 10 10 9 9 9 FLT-800 Fuel Tank 19 23 18 15 14 17 11 10 10 9 Swivel Engine 38 15 14 12 12 11 10 10 10 10 I think failure chances should drop more rapidly though and I'm surprised they plateau'd so high. I think your previous failure model roughly halved the chance every launch and got down to 1%(ish). This felt more reasonable. Having a 10% failure rate after 10 launches seems really high. As an interesting side note, I had zero parts failures over my 10 launches. Each flight lasted about 3 minutes with the first minute being the boost phase and the last 2 being descent.

@severedsolo this is progressing nicely. I like the new dialog box. The new model feels odd though. It seems like you're really focused on modeling re-usable parts, but most parts aren't actually re-used and the new model seems to start parts off with a "new part" failure rate even if I've used the same type of part before. The 50th Swivel engine I build should not have the same initial failure rate as the very first I ever built. I thought your old model for new versions of the same parts - in which subsequent builds became more reliable - felt more correct.

I scaled Sigma's @Atmosphere = 0.88312 - so Earth's atmosphere was 85,000m SSRSS default value for @Atmosphere = 0.8

I re-downloaded...Now the engineer can repair the parts, but several parts showed 100% chance to repair and the repairs failed. Also, the glow is back for some parts, but other damaged parts still don't glow.