Starwaster

No, it doesn't really make it much clearer. Different players have different ideas about difficulty. Even with DRE (for stock Kerbin) I have to go up to at least 150% before I even start to feel challenged. To me, DRE is more about introducing consequences for poor design choices. No matter what the reentry scale is at, you should always be capable of designing something that can survive your mission's reentry. And a good design will survive 100% of the time. A bad design will probably almost always fail. As far as the reentry heating slider goes, I think the best suggestion here is for you to run through several reentries and adjust the the slider each time until you find a setting that satisfies your needs.

Interpreting your question literally, 100% as Deadly Reentry no longer touches KSP physics. Those now are deemed adequate to my purposes (and have been for awhile). So quite literally, heating happens at the same rate as before. The main changes from stock are to the thermal tolerances of every part. The max temperature of everything is capped. Ablative heat shield ablation rate is 10x greater for everything except the Mk1 pod which is 16x greater. The other changes are in how parts react to overheating.

Latest one is the only one I noticed it with. I don't usually use spacedock though.

Not enough information to say, but AFAIK, RSS doesn't actually change science rates or multipliers. What other mods do you have? Also, what exactly did the message say about the science returned? There might be a clue there as to what was driving your science return so low. Edit: Oops, didn't click the Reddit. Ok, 50m is way too close. You weren't going to get anything for that anyway. I think the real issue is the mass. 1.3 tons is probably just not enough to amount to anything. Distance is also an issue; there's a sweet spot between point blank and the other side of the planet where you get 100% .

Banned for being an anti-canner

They really aren't (different in concept), unless you launch from a different planetary body with a different gravitational constant. So then you have to use a different value when setting up your launch profile. ^^^^^^ THIS ^^^^^^^^^^^^ The UI is already too crowded and there's been way too much feature creep over the past few years. There's already a way to limit by TWR that just requires some simple math and does the same thing If having a TWR limiter is your only reason for using MJ then you should do without MJ. And I apologize for being overly blunt but the statement stands.

It's recomputing the lift force but but not changing where it's applied which is still partTransform + CoLOffset. The actual instruction is part.partTransform.TransformPoint(part.CoLOffset) and returns a vector = to the transform + the offset. Not sure that's even needed as I thought the lift vector was already being modified according to angle..... Edit: Oh ok it's a complete override of ModuleLiftingSurface so it has to do that itself. Too early in the morning to look at code...

No, I mean 'Limit acceleration to' 17.676 which will be the same thing as if you were limiting TWR to 1.8

It's already in there. Enable the box next to 'Limit acceleration to' and in the text entry box next to that, enter a value of 17.676

@damonvv Spacedock download keeps halting at 32MB (approx)

@EritoKaio The problem there is that the force is being applied to the part transform (partTransform + CoLOffset ), which doesn't move. So you would be correct in saying that force isn't being applied to the correct point on the flap so: no, the center of lift/pressure won't be correct for the flap part but it is changing for the vessel as a whole. Stock KSP doesn't have a debug display for the vessel CoL so you would either need to code one or use MechJeb, which has debugging displays for the vessel CoM/CoL. As for correcting the problem, because you're using the Tundra Exploration mod for flap control, it occurs to me that one could modify the code to adjust CoLOffset and CoPOffset on the fly (and CoMOffset while you're at it if you really want to be a stickler for detail) What you would do is recalculate the offsets based on flap rotation so that it follows the flap. Edit: You wouldn't actually change the offset value, just track where it would be as it traverses around the partTransform and apply the force there.

Boldfaced and italicized text is not accurate. Center of lift does change as flaps are angled or deployed. Or at least the stock flaps do when attached to the vehicle in the stock manner. If yours are attached differently then that may not be the case. Tundra's flaps ran into trouble because of the way they were attached or controlled. (Caveat: Stock CoL changes are not displayed in the hangar however. If debugging in flight however and you have a means of displaying CoL then you can see the changes. MechJeb has such a )

Banned for making up vowels

That ruling doesn't look so simple as that. In a number of places it contains language that would nullify such a EULA or at least the portion prohibiting decompilation. "software code without infringing the Software Directive. In a judgement of 6 October 2021 in the case C-13/20, the Court of Justice of European Union (CJEU) ruled that insofar decompiling is necessary to debug the software, regardless of whether it is prohibited by the license agreement" Further, the area that you seem to be talking about is specfically addressing the presence or absence of procedures for decompilation for the purpose of correcting errors and not a blanket prohibition of decompilation. In other words, a EULA can't prohibit decompilation if it is done soley for the purpose of correcting errors. Recital 18 of the Software Directive prevents IT developers to contractually prohibit both the loading and unrolling operations necessary for the use of a copy of a legally acquired program and the correction of errors affecting the operation thereof, meaning that parties cannot contractually exclude any possibility of making a correction of these errors; however, the parties can stipulate the procedures for exercising the right to decompile; for example, the parties can agree that the rightholder must ensure corrective maintenance of the program concerned; and in case the parties did not provide for any specific contractual provisions, the licensee shall be free to decompile the program insofar as this proves to be necessary in order to correct errors affecting the operation of the program. Of course, the licensee shall not be permitted to decompile for other purposes than correcting such errors.

Debatable. The game as a whole might work ok but specific part module have bugs that have persisted for years and are not 'working fine'. For some of them mods have been necessary to fix the bugs.

It's amazing that gaming companies are still struggling with this after more than thirty years of dealing with their respective gaming communities. The concept isn't particularly new or limited to modding and they still have trouble getting it right.

That looks like missing meshes. Only time I've ever seen something like that was when I ****ed up an installation.

So, station security won't allow items inside the habitats?

It's a double edged sword to be sure. H2 is the most efficient propellant, all other factors being equal but yes you will be consuming a lot of it by volume. Usually though, mass is the main consideration, not volume. Actual conceptual designs revolving nuclear rockets see a mass reduction by not having to include oxidizer. The H2 tanks can be made lighter as well. (Real Fuels takes lighter H2 tanks into consideration so give that a try if you're not already using it) All that said, nuclear rockets using ammonia or methane have always been my preference. You'll definitely want RF for that but I'm not sure if any current mods or configs offer those propellant choices for nuclear. Not anymore.

@WindupHero7 you did get some exceptions from WBIContractScenario. Twenty-two. Those were happening when it was processing destroyed vessels. That's not likely to be the cause of your problems. The bulk of the exceptions were from kOS; 2584 ArgumentOutOfRangeException and were continuously spamming the log for a period of time. That right there is likely why performance dropped and yes, CPU usage may well have dropped as writing the log was taking priority over execution of game code.

To add to what has been said already, also make sure your RCS placement is balanced. When doing rotational movements, your ship should only be changing angular momentum, not introducing translations. The reverse is also true. Also only keep your relative velocities between the station and your ship small. Go slowly

There are other dividends to be had: Public Relations. Stimulating public interest in the space program. Every space probe should be carrying cameras. Microphones are cool too; for planetary bodies that have atmospheres. Totally worthless as far as actual science returns go but people eat that stuff up.

In the posts for his other mods, @taniwha mentioned he would get to updating those but didn't know when that would be, so he's probably just busy right now. I'd just give him some time. In the meantime the mod seems to work in KSP 1.12 aside from some UI issues.

Minmus. That is, Minmus is what got me to buy the full version. I was playing the demo and I thought it was kind of neat but not good enough to spend money on. All I really saw was Kerbin and Mun. But after a few launches I noticed a bright thing on the horizon. Every launch. I started wondering if it was a large piece of space debris from a previous launch. Then I caught a glimpse of something green on the map. Holy crap it was another planet! I realized its position coincided with the thing I’d been seeing on all my launches for awhile. i started wondering what else I’d missed so I learned to work the map and I saw that there was an entire star system waiting for me. That’s when I decided to go ahead and pay for the full version.

It opens on my iPhone. What browser are you using?