Starwaster

Just thought I'd share this again:

I only play 64 bit myself and it works fine. I don't know what a 'crazed atmospheric plunge' is.... do you mean you're coming in very steep? Aerodynamic damage is what, G forces due to high drag? Too steep and G-force damage will become more of a concern than reentry heating. Not enough time for thermal levels to reach dangerous levels and not enough time for aerodynamic braking so you'll get high G forces in the lower atmosphere.

I just pulled the keys off and there was a bunch of cat fur built up under them. It's really nasty. I think MAYBE it was just preventing the keys from functioning properly... seems ok now but I think this keyboard is about 17 years or older... probably about 19 years old given that it mentions Windows 98 on the bottom of it. So it could just be failing after all tthis ime and it's just time to get another keyboard. Problem is ha I have horrible luck with USB keboards... crap i's happening again. sigh. well ou get he idea

Even IRL, boiloff (from a historical standpoint) is such a problem that the solution is to just pre-allocate extra such that you'll have enough for your needs. In other words, extra hydrogen that serves no purpose other than to be boiled off and doesn't help get you into orbit so it's basically wasted mass. To put things into perspective, the Saturn V S-IVB boiled off approximately one ton of hydrogen (over 31,000 liters) after about 2 hours or more in parking orbit prior to its trans lunar injection burn. The default tank type is analogous to the tanks used by Saturn and assume the same construction material and insulation (aluminum tanks for H2 and several inches of polyurethane foam) Even after all this time I'm still not sure what real world equivalent would be considered a 'cryogenic tank' but I think we've always pretty much assumed it to be spray on insulation combined with multilayer insulation, that goldish looking mylar film. Probably about 20 layers of it or so. To further put things into perspective, a 20mx10m tank with SOFI + 60-70 layers of MLI is projected to reduce the heat leakage from tens of kilowatts to 78 watts in LEO. (the place where you can expect to receive the most heat leakage into your tanks) A future update to Real Fuels will allow players to configure exactly how much MLI their tanks have and have pricing and mass change accordingly. (not that it has a lot of mass but it might matter for small launchers where ever kg counfr hu s) And i looks like he ke and he ke on m keboard have sopped working. Goddammi

Stock events (which are being fired by Procedural Parts) are throwing exceptions when loading the vessel. Apparently there's a concept of 'too soon' when firing vessel changing events which are needed to force the stock game to update the part's drag cubes. I thought that was something that I'd fixed but maybe not. I'll look into it.

Make sure that the part you are using as a service module is actually tank type service module or else it isn't really a service module. That matters a lot. When mousing over the part in the VAB, it will tell you what the tank type is.

Ignore the message.

That's pretty much standard, can't do a thing without logs

The reason you're having trouble placing parts is because the attach nodes point in the wrong direction (previously, attach node orientation was not enforced and now it is) Here is an example of incorrect node configuration: node_stack_top = 0, 0.5, 0, 0, 1, 0, 0 node_stack_bottom = 0,-0.5, 0, 0, 1, 0, 0 First three comma separated digits are node location. Second three are orientation. In the example above, both attach nodes are pointing UP; the bottom node should be pointing DOWN, as seen below. node_stack_top = 0, 0.5, 0, 0, 1, 0, 0 node_stack_bottom = 0,-0.5, 0, 0, -1, 0, 0

Try doing something like this: [KSPField] public string animName public override void OnStart(StartState state) { // InflateAnim = part.Modules["ModuleAnimateGeneric"] as ModuleAnimateGeneric; foreach (ModuleAnimateGeneric anim in part.Modules) { if (anim.animationName == animName) { InflateAnim = anim; } } if (InflateAnim == null) Debug.Log("<color=#FF8C00ff>[Comfortable Landing]</color>Animation Missing!"); ... (stuff) Basically, instead of grabbing the first MAG out of the PartModuleList, it walks through it and matches on the designated animation name. Also, fields don't need to be designated KSPField (like InflateAnim) unless you're going to be reading them from a config file or unless you need to make use of some specific KSPField attribute such as persistence. In your case (for InflatAnim) you should be able to get away with not using it. Also, if you ever need to have multiple animations on a single part, you will want to assign each one a different layer. (in the ModuleAnimateGeneric config, just add layer = 0... layer = 1... etc. IIRC you specify 10 layers, or whatever the Unity limitation is, I'm not sure if it's changed recently)

Ok I'll just jot you down as someone to never ever try to be helpful to. Got it.

If you're using FAR then you want realistic lift and aerodynamics, right? Otherwise why are you using FAR? You either trust FAR or you don't. So let's say we trust FAR and the wing lift is reasonably accurate, and that seems plausible given how short and stubby they are compared to the rest of the plane. Look at large cargo planes like the An 225 or the Galaxy C5. Look at their wingspan and surface area. Have you tried longer wings on your planes? You could probably reduce your takeoff speed that way. You'd also gain more drag but that's the price you have to pay.

@blowfish @Tyko You can use PartStatsUpgradeModule to modify part fields through the upgrade system (that's what it's there for). What he wants wouldn't be supported since title isn't actually defined on Part. (and some Part fields are flat out disallowed such as name and other unsafe fields)

Error 404. There's no log files at those links

It's a known Real Fuels issue which has been fixed - just make sure you're updated to the most recent version.

Not going to happen, not on that rocket and you've already touched on the reasons why. Your payload of 170 tons means that you're only going to get about 3000m/s DV before the Centaur stage starts up and whether it goes shallow or steep, most of that is eaten up by gravity losses. The Atlas V Heavy only had a hypothetical payload capacity of 30 tons. 170 is just not going to happen, not even to LEO

@MacLuky Don't do anything that will result in float values for part cost. (not sure about entryCost, that might also be bad, I forget) cost has to be an integer. If the part loader tries to parse a float when it expects an integer it will throw exceptions and smash the parts list in the VAB. You will have missing parts.

@Pappystein First part of that patch: That MATERIAL node isn't going to do any good sitting there by itself in a PART node Second, you've got a bunch of #$/../ scattered around. You MIGHT get lucky and have that work, I honestly don't know how Module Manager will interpret it but basically what you're saying is start at the root level and then go UP. (or UP twice in some cases). MM might just interpret going up from root to be the same as staying in the root level but frankly it's a logical impossibility and if the logic ever gets rewritten to be more strict then your patch will suddenly stop working and the cause won't be immediately apparent. You're better off just saying #$/mass$ or #$/MODULE[modulename]/stuff$ and those will always work.

Deadly Reentry isn't doing any IB specific patching so any patching done to it would be from the same generic patching that all parts get. And it would be getting done at runtime except for a very brief period when I temporarily switched to doing config based. (but again, as part of a blanket patch. So if there were a problem of the nature he describes then it would be every part and it would be so widespread that someone would have reported it long ago)

Why not just snap the existing RTG in place? Do you need a FUR themed one? What would that look like and why? An RTG is an RTG... Its most likely configuration is going to be cylindrical with radiator fins... a Stirling version might appear different or might not.

The insulation value seen in the part description info isn't really right either because it's using the old skin-internal factor and I switched over to using heatConductivity which affects ALL heat conduction including skin-internal. That's how RF determines what kinds of insulation it has and how to handle the conduction and boiloff. The changes went into each mod simultaneously except that the heat pump part info code didn't get updated (it's kind of tricky because it still has the capacity to change BOTH conduction fields) and the part configs didn't change from their test configs. I updated the config files in the repository. The patch file StockRadiatorDuplication.cfg goes in the MM_Configs folder and the other in the Parts/zzz_radiator.SWHP folder (just right click and save links as) https://raw.githubusercontent.com/Starwaster/HeatPump/master/GameData/000_HeatPump/MM_Configs/StockRadiatorDuplication.cfg https://raw.githubusercontent.com/Starwaster/HeatPump/master/GameData/000_HeatPump/Parts/zzz_radiator.SWHP/part.cfg You may notice the configs have a commented out RO line - just ignore that for now. It'll matter later when I fix the electric cost which is too low

Doesn't matter; I see what the problem was. The radiator files that went into production are the wrong ones... they were basically a control version to test radiator performance without insulation (well it does matter; you may need your output_log.txt file some day: it's in KSP_x64_Data or KSP_Data depending on if you're in 64 bit mode or not - unless you're using Linux or Mac. Then it's player.log)

Probably better do the log file too. And a probable cause of your Alt+F12 issue is some nvidia thing binding to those keys. Someone posted about that previously... the fix was to rebind them but I forget which nvidia thing was doing it. I think the workaround was pressing Shift+Alt+F12 or Cntrl+Alt+F12

@wb99999999 Ok let's take a look at your ModuleManager.ConfigCache file. Please put that somewhere I can download it And where is all that other thermal data coming from? I don't recognize that

You need to enable boiloff debugging too. Make a patch file (cfg file, name it something like enableboiloffdebugging.cfg) and paste the following into it: @RFSETTINGS { %debugBoilOff = True } That will give you some additional information on boiloff in the tank's action menu: wall temperature (THIS is temperature being used in the boiloff equation. It has to be higher than the resource being boiled) heat penetration (how much heat flux actually being applied to the resource by RF boiloff code) boiloff loss (how much mass is being lost as a result of RF boiloff code) For RF to be responsible for boiloff then all of the following have to be true The wall temperature has to be higher than the resources boiling temperature A value representing heat penetration has to be present. If condition 1 is false then heat penetration will be BLANK boiloff loss has to have a value. If condition 1 is false then this value will be BLANK