Tyko

@Lisias would you consider adding some additional steps to the default scaling? I've updated the code (below) to add 0.3125 (removed 0.3), 0.9375, 1.875 and 3.125 to the stack scaling options. I also added a 25%, 75% and 150% to the free and surface options. SCALETYPE { name = stack freeScale = true defaultScale = 1.25 suffix = m scaleFactors = 0.1, 0.3125, 0.625, 0.9375, 1.25, 1.875, 2.5, 3.125, 3.75, 5.0, 7.5, 10, 20 incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.05, 0.1, 0.1, 0.2 } SCALETYPE { name = stack_square freeScale = true defaultScale = 1.25 suffix = m scaleFactors = 0.1, 0.3125, 0.625, 0.9375, 1.25, 1.875, 2.5, 3.125, 3.75, 5.0, 7.5, 10, 20 incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.05, 0.1, 0.1, 0.2 TWEAKSCALEEXPONENTS { mass = 2 } } SCALETYPE { name = surface freeScale = true defaultScale = 1 scaleFactors = 0.1, 0.25, 0.5, 0.75, 1, 1.5, 2, 4 incrementSlide = 0.01, 0.01, 0.01, 0.02, 0.02, 0.02, 0.05 suffix = } SCALETYPE { name = free freeScale = true defaultScale = 100 suffix = % scaleFactors = 10, 25, 50, 75, 100, 150, 200, 400 incrementSlide = 1, 1, 1, 2, 2, 2, 5 } SCALETYPE { name = free_square freeScale = true defaultScale = 100 suffix = % scaleFactors = 10, 25, 50, 75, 100, 150, 200, 400 incrementSlide = 1, 1, 1, 2, 2, 2, 5 TWEAKSCALEEXPONENTS { mass = 2 } }

You might want to check here too: https://forum.kerbalspaceprogram.com/index.php?/topic/172187-14-redirect-stockalike-orion-shuttle-derived-launchers-orion-release-131-compatible-v093/

Near Future Technologies collection of mods includes many later tech nodes

I've documented the MH engine specs in a google spreadsheet here. this may help you out. Look for the "Stock" and "MH" lines. The "Tyko" lines are changes I've made for my mod Engine Tweaks for Making History. So you can ignore those unless you're interested in the changes

I don't believe it's a GPP issue. It appears the problem occurs with all planet packs in KSP 1.5. If it's affecting all planet packs could it be a Kopernicus issue? @Thomas P., have you heard about this yet?

It's a really cool idea and I haven't seen it done before. If this is something that really interests you why don't you take a shot at it yourself? There are kind of two levels of difficulty in making new parts. It really comes down to whether you have the skills to make your own 3D models. Simple option - reuse existing parts and just modify what they do - you can make them smaller and you can change just about any stat with a Module Manager configuration file. This can be done with just a text editor and requires no modeling experience. If you use this method for personal use you can use any model you want to. If you want to distribute it to others you just have make sure you have permission to re-use the model. I'd start with this approach and play around with making a few basic parts. You'd only need a Solid Rocket Booster, some sort of Command Pod and a Parachute, so three parts. If you like doing this you can worry about model permissions when you've gotten the basics down. Here's a link to the Module Manager page which has information links and is also a great forum to ask questions. Check out the Module Manager Wiki too More complex option - build your own models and then write config files to make them work. Here's a great tutorial on how to build parts.

I just checked the Tracking Station and Map mode delays aren't in Stock 1.5.1.

Yeah, thanks. Ooh...cool! May I see it to please? Thanks!

@Beale Just answered this up a few posts...

Here's my code...it's similar to @Tonka Crash but applies only to Command modules and mine doesn't overwrite any capsule that already has Supplies. This allows for the possibility of having pods that have more or less than the default value. // Adds 50 Supplies (per kerbal seat) to Command Modules // Ignores parts that already have Supplies @PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]] { RESOURCE { name= Supplies maxAmount = 50 @maxAmount *= #$/CrewCapacity$ amount = #$maxAmount$ } } The code below adds Supplies to crewed compartments that aren't Command Modules - like Hitchhiker and other station parts. // Adds 100 Supplies (per kerbal seat) to non-Command Modules // Ignores parts that already have Supplies @PART[*]:HAS[!MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]] { RESOURCE { name= Supplies maxAmount = 100 @maxAmount *= #$/CrewCapacity$ amount = #$maxAmount$ } }

Yep, it's annoying. In my game I call the Onion a "test capsule" designed to test systems. I run tests on the ground, in low atmosphere and I use a small rocket to boost them into the various nearby biomes. After that I switch to the much better Mk1 and never touch the Onion again. If you're looking to build Russian/Soviet style rockets and don't mind mods just download Tantares. Then you can build entire Soyuz craft plus many many other things.

You may want to take a look at Engine Tweaks. It tackles both of these problems in (I hope) a balanced way:

Do we have to reinstall the updated MH when we patch 1.5.0?

HAHA! I've just realized why the devs will (likely) never give a straight "no" answer...because if they did people like our friend @BadLeo here wouldn't stop asking anyway. As much as I've enjoyed our little chat I'm going to go play my single player KSP game that I love so much and leave you here seething in your discontent with one less person to whine to. Why should I waste my time when I'm already getting what I want Goodbye!

See, this is the challenge. You claim to want a constructive discussion but then demean any opinion you don't agree with. That's not a discussion, that's you randomly attacking people who disagree with you. My argument is perfectly valid. The game has a theme and it's on a development trajectory which doesn't (as far as we know) include multi-player. You're proposing the team divert resources to accommodate your proposal which would necessarily take away progress on the core game development. That's not "BS" or "Peer pressure" or "passive aggressive" or a "bad argument" or a "straw man" - wow, did you realize you attacked my idea in at least 5 ways in just two paragraphs? That's hardly making a logical argument or encouraging a discussion

Sure, mod the heck out of it. Make it any kind of customized hybrid game you want. You're not asking for permission to mod it. You're demanding that the small team of devs reduce their efforts on making the core game better and instead work on your special project. Go play Elite Dangerous, or EVE Online...there are TONS of games that offer real time multiplayer with magical travel methods

KSP isn't a space combat game or a fighter combat game or a car racing game. it's a rocket ship game. it's a tribute to it's flexibility that enterprising players have found ways of doing all kinds of cool stuff, but it's not what the game is intended for. There are PLENTY of combat games and race games out there. There are FEW (mostly) accurate physics simulators. If you want to shoot things or race cars then get one of the hundreds of games designed for that. Don't ask a very small team who's working hard to make the best rocket ship game possible to drop everything and turn KSP into yet another shooty racing game for you.

@UomoCapra, was there a change to the way KSP utilizes CPU cores in 1.5?

Kopernicus was updated yesterday...

Glad to help. I also have a MM config that adds a small quantity of supplies to any command module. If you want it just PM me and I'll shoot it over.

Do you realize you just described USI Life Support almost exactly? They're even called Supplies.

@jrbudda Thanks for keeping this alive! Feature request if you have time - Could you add a readout for Thrust to Mass Ratio? TWR works great around Kerbin, but if you're orbiting a small moon your TWR skyrockets because of the lower gravity. It doesn't really reflect the on-orbit acceleration capabilities of the craft.

Once in Tracking Center it's very smooth. It takes the game longer to open the Tracking Center though. There's a definite wait between the time you click on it and when it actually opens.

The front face of the stock docking ports have a horizontal "window" of sorts offset from the center. It's non-functional, but it's asymmetric. Having a known orientation helps when using an automated docking system, like MechJeb has. @Nertea This was the problem we worked on that involved rotating where the shocks met. With that change it's easy to visually tell the top by looking at the point where the shocks meet. I don't think you've added that modified part to SSPRX yet, but you've already completed the work

In my game the Onion is essentially a test bed for crewed pods and use for landed and low atmosphere crew reports. It's fun to boost out over the water using an SRB, but I don't even try to accelerate it to even sub-orbital speeds. it's just not aerodynamic. If there was a 1.25m fairing available earlier I might consider doing a Vostok style launch.