Starwaster

I have a lot of doubts about what Elon is saying... I can accept the stainless steel skin for a subsonic straight up - straight down testbed... But when he starts talking about the reflective properties of polished stainless steel... that's totally irrelevant when you're also covering it with heat shielding. And then he says that also means less heat shielding? Where is he thinking the heat shielding is going to go? Having an outer skin of steel makes no sense here unless they're going to be doing active cooling. And why is nobody talking about this? (or maybe they have and I just missed it)

The analytic improvements from RF 12.7.3 have been backported to a KSP 1.3.1 compatible download (12.7.3.1) for those who for whatever reasons are still using KSP 1.3.1 It will not be appearing on CKAN. https://github.com/NathanKell/ModularFuelSystem/tree/rf-v12.7.3.1-backport

The analytic improvements from RF 12.7.3 have been backported to a KSP 1.3.1 compatible download (12.7.3.1) for those who for whatever reasons are still using KSP 1.3.1 It will not be appearing on CKAN. https://github.com/NathanKell/ModularFuelSystem/tree/rf-v12.7.3.1-backport

RF doesn't manage engines anymore. You need an engine pack for RF (i.e. RO, RF Stockalike, etc)

It actually is possible with stock parts.... you've got 3.75m parts so you could do Falcon Heavy type launches (but with standard propellant loads since we don't have super chilled propellants, though it's technically possible for RF to handle that) Manned lunar would be harder; no all-up Saturn V launches. So yeah, it's definitely possible but you're not going to want to.

Not sure; functionally they both get checked at one time or another. There's also Many Deployed (if the module has more than one chute and more than one are deployed) Might be better to go with AnyDeployed as it already has a list of all chutes that the module has and if they are deployed so you don't have to walk through everything yourself. (or ManyDeployed if for some reason you thought you wanted to know if it had multiples deployed)

Other than checking if the assembly is loaded, I don't think so Check RealChuteModule.oneWasDeployed

Official updates have been released for both KSP 1.4.5 and KSP 1.5.1 This update contains new analytic improvements for tank temperature for cryogenics. Temperature will increase much more realistically during timewarp > 100 (that is, from 1000 on up) The same issue that made analytic temp increases so slow would likely have made cooldown (whether from boiloff or external sources) also happen more slowly so that has been fixed as well and code to ensure that cooldown happens when it should happen has been put in as well. As soon as CKAN indexes the 1.5.1 update we'll be pushing one out for 1.6.0 as well. For KSP 1.4.5 - https://github.com/NathanKell/ModularFuelSystem/releases/tag/rf-v12.7.2 For KSP 1.5.1 - https://github.com/NathanKell/ModularFuelSystem/releases/tag/rf-v12.7.3

Just waiting for Real Fuels - which is my fault. There's some release and versioning confusion and I'm just waiting for some feedback from @raidernick in IRC before I proceed.

The problem is not FAR. The problem is that your expectations need adjusting. Yes, your speed will appear to go up during the early stages of reentry in the upper atmosphere. You should consider your velocity to have two components: Vertical and horizontal. There is not enough braking happening to slow the vertical component appreciably. Look at your video; I refer you to the terminal velocity entry. Terminal velocity is the velocity at which drag forces exceed the pull of gravity. You will not see noticeable vertical slowing until your vertical velocity approaches or exceeds terminal velocity. There's really nothing unusual happening your video. Welcome to RSS and FAR; don't expect it to behave like stock, otherwise what was the point of installing them? Also, don't deploy your chutes so early. You got away with it but you almost burned them. To give you a real life example, Apollo didn't deploy its drogue chutes until just over 7km altitude (Just under Mach 1 IIRC, but they used barometric pressure as the trigger for deployment). The mains deployed at just over 3km altitude immediately after drogue chute detachment.

Yeah that's incorrectly installed. @Jasseji you need to delete that extra IkRobotController folder that's sitting in the first IkRobotController folder.

A float curve is KSP's wrapper for Unity's AnimationCurve and is a list of key, value pairs with optional tangent pairs for shaping the curve.

Look, I'm not trying to give you a hard time here. All I'm saying is... "Son, we just crossed the street. Let's not throw a party 'til we're out of the city."

Did your 'youtuber' have all of the same mods he had before with his entire ships folder and all his subassemblies? Just what was his testing methodology? Because you can't just take a craft you experienced issues with in one version and import it by itself. Is that what he did or did he actually recreate his old setup for his testing environment?

Additionally search for the word exception because not all errors say error - a lot of the really bad things that can happen will say exception though. (especially my personal favorite, the NullRefException.

Well there is an issue with placeholder textures (essentially blank textures) needing to be a minimum resolution... and that will cause compile fail errors but no such errors exist in your logs and it should affect everyone, not just a few.

There isn't a KRE update that would resolve the problems with the legs. That's a KSP issue that happens when any changes are made to your KSP installation and I posted above how to work around the problem until KSP 1.6.1 (hopefully) resolves the problem.

Maybe read some of the posts on the very page you posted on

@NightSky not seeing a ITSLeg-M related issue from those logs. Your post kind of made it seem like they just weren't there (craft not loading) but I don't see anything that would explain that. WAS that the problem or was it something else such as was talked about earlier?

lack of ModuleManager.ConfigCache means that there are MM patch errors happening. It probably isn't responsible for your KRE problems but needs to be addressed at some point. The logs will say why it's happening. I'll take a look at those and see if I can figure out what your problems are. (though I'm also trying to do other modding related work so if someone else has the chance to check out his logs, feel free) KSP 1.6.0 has its own set of problems when installing mods but those would't stop the legs from appearing. (they would cause other problems with the legs as detailed on this page and the previous page) You should also see my post on the subject here: @NightSky [ModuleManager] Cannot parse node name as tag list: tag can't start with [ on: Mk2Expansion/Patches/MK2-USILS/@PART[M2X_SmallLab]NEEDS:[USILifeSupport]FOR:[Mk2Expansion] That's why you have no ModuleManager.ConfigCache MK2-USILS.cfg has an error in it. You should report the above txt to the appropriate mod author.

You said previously this was in 1.5.1 right? You should provide your log files and ModuleManager.ConfigCache file as well. (latter is in GameData)

On the RF front, here is what is holding that up right now. Analytical thermal issues have been mostly resolved for awhile now (since MLI was implemented) but the solution also introduced another analytic issue where internal temperature is too slow to change. Including when trying to cool down overheated tanks in analytic mode. And AFAIK I'm the only active RF developer that really understands what happens in analytic mode that affects cryo tanks and why. So I'm still trying to work that out right now... Edit: So, there's a big gap between being where you know what's happening during analytic and being where you know what you need to do to manipulate the system into doing what you need it to do. I think I'm a good bit closer to that point now.

The right click menu is not a mod compatibility issue. It's a KSP 1.6 issue that occurs when the PartDatabase file is changed for any reason, including adding mods, removing mods, Module Manager patch changes, deleting the PartDatabase.cfg file and troubleshooting. Note that last part. Troubleshooting the problem can cause the problem to persist. (where troubleshooting means uninstalling or altering mods or MM patches) The problem can also occur if some of KSP's files did not properly update. Verifying file integrity of KSP through Steam can help except keep in mind that this may also cause the problem to happen again. What this all means is that after installing a bunch of things that you want, you should run KSP one time and then close the program as soon as you reach the main menu. Don't play the game or check to see if things are still broken because if you do then you will be tempted to troubleshoot. After you have closed the program run it a second time without installing, uninstalling or troubleshooting anything. If you still have weird right click issues or animation issues then you probably did something wrong, like trying to troubleshoot something. Please look at the images below. This is the legs in KSP 1.6.0 - they do work. (and by work I mean they animate properly; legs and wheels in KSP still need attention from the devs, especially legs this large... spring and damper values still need work)

It depends on the part that you are putting things on. Those struts are very hard to center surface attachable parts on the ends

On the subject of broken mods, that largely depends on how dependent the mod is on KSP code. For instance, we are long past the point where something that is purely a parts pack is going to get broken by a KSP update as long as it is not itself dependent on plugins (*.dll) which could be broken by an update. The less reliant a plugin is on KSP code (has to access some KSP class, field or property) that might change then the less likely it is to be broken. Deadly Reentry for example is mostly immune to such breakakge. The last time that happened was when the old particle FX system was deprecated and that was something that was warned about for over a year. Some plugins however specifically have code that checks for KSP version changes and Unity version changes and will deliberately disable themselves if that happens. That is purely dependent on the detected versions and doesn't actually have anything to do with whether or not there were KSP changes that could have broken the plugin. Sometimes the compatibility checker just issues a warning. How it behaves is entirely up to the individual modder. This last bit is important because it means that a lot of mods out there are not actually broken by KSP updates but instead choose to disable themselves until the modder has time to evaluate the situation and decide what needs to happen to make the mod compatible. Sometimes it's as simple as updating the Compatibility Checker (there is actually common checker that we use) with the new versioning number and recompiling. Finally there are plugins which depend on certain KSP code such as accessing celestial body code or manipulating resources and those can and have been broken when the underlying KSP code is overhauled. (a life support mod for instance can be easily broken if the resource code is rewritten leaving the old methods invalid even if 99% of the life support mod uses its own code for logic) It's a complex situation and KSP's developers just aren't always responsible for the impact an update has on the modding scene. (when taken on a case by case basis - though there was a situation a few major updates back where every single mod plugin could break KSP with hard exceptions and crashing just by virtue of not having been recompiled for the new version - that situation seems to have been corrected in the recent KSP updates)