Tau137

Here is a feature request that should have been implemented already a long time ago: science experiments should not give full science if similar results have already been obtained from another biome on the same planetary body. 1. First science report (specific to instrument) should give full science return, as it is now. 2. Any subsequent science experiment (specific to instrument) from the same body but different biome should only give ~1/2 of science return (i.e., C*2^(-N) outcome, where N is number of biomes already explored prior with this particular experiment). This does not require much change - even if keeping track of "science values" could be tricky, post-factum processing is easy ("you received only 1/8 science from gravity scan of surface of Mun Midland Craters, as it does not bring as much new information compared to the gravity scan results your have already obtained on this planet). This change will curtail the desire to grind science on easily accessible bodies and will subtly force player to explore further, providing a lot more depth and challenge to tech progression (btw, it is not about "hardcore challenge", it is about keeping the player's interest in exploration and not routine/boring/repetitive missions). Please consider this, as it is a major factor in player's enjoyment of continually exploring the game, as opposed to boredom of continually doing the same thing over and over again (the latter is more cost-effective in the current implementation, and that is a problem). P.S. Mods!???? Please? Pretty please? P.P.S. This needs more consideration for surface/flying/low/high/space/etc. biomes, but it should not be difficult to come up with a proper formula (in the first approach, altitude-related biome variations can just be considered separated - i.e., gravirty scans on surface in various biomes are treated independently of gravity scan while in space over the same biomes. That is not perfect but is already quite good.... and simple).

Neat-o, but power production and fuel consumption do not match the thrust. On the other hand, fuel consumption at this point is irrelevant, the whole mod needs to be tweaked (with 40hrs of flight time on a couple of these plus something else for vacuum you can fly around the whole system, land on every planet and return home without having to maintain the engines; refueling LH2 is another story though).

Yeah, I noticed that, waiting for update (or can it be tweaked in cfg? ) I wanted to say that quicker heat-up (on smaller motors) would be nice... but I would be contradicting myself here, NTRs do need a big weak spot (or why use anything but nuclear?), and this fits the bill just right. One more thing/question: FissionRadiator, how exactly goes it work? Does it link up with exhaust for cooling, or just vents to beyond the looking glass? And why do we need to turn it on, can it be on by default? Or does that serve a purpose of keeping reactor hot after shutdown and use heat with engines (but, on the other hand, in only kicks in after optimal temperature)? Beyond that - GGRRREAT mod, big thank you! Now I can actually start using NFE without feeling like I am willingly taking a handicap. P.S. Fuel consumption seems a bit low, it would be nicer to keep run time to below 5hr, not 50, otherwise it will effectively never be a concern for a player (12.5hr under acceleration under x4 timewarp? Really?) Even for a NTJ, 5-10hr is plenty, unless you want to circumnavigate Jool in atmosphere (a whole day of playtime, btw). I'll play around with tweaking consumption and reserves to keep in line with reactors (considering size, output power and core temperature differences). RSS users may have a different point of view though, but, fortunately, most KSP users are sane

First comment, and it is a about a small typo: In KerbalAtomicsNFE.cfg, for LV-N it reads INPUT_RESOURCE { ResourceName = EnrichedUranium Ratio = 0.0027 // should be an order of magnitude lower FlowMode = NO_FLOW } OUTPUT_RESOURCE { ResourceName = DepletedFuel Ratio = 0.00027 DumpExcess = false FlowMode = NO_FLOW }

I am about to do some play-testing for this, just need to re-fresh my mod library first. But so far it looks great!

Neat and simple, thanks! For those using NFE - replace ModuleResourceConverter with FissionReactor (copy from NFE), add ThermalLoad to output and balance other parameters to taste/balance. Next step would be to make ThermalLoad production proportional to reactor temperature (requiring time to spin up), but that does not seem possible with just a MM... or am I wrong?

Thank you, Ferram - both for a great mod (stock is still... stock, really inadequate and unrealistic), and quick response to reported issues, despite absence of logs and detailed info in the complaint!

FAR + inflatable heat shield == really slow accent Stock aero + inflatable heat shield == ok

Thank you!

This is what I get with latest version (posted in RT contract pack thread as well): Exception occured while loading contract 'RemoteTech.RT_EverythingSat': System.Exception: No ContractRequirement with type = 'CelestialBodyCoverage'. at ContractConfigurator.ContractRequirement.LoadRequirement (.ConfigNode configNode) [0x00000] in <filename unknown>:0 at ContractConfigurator.ContractRequirement.LoadRequirement (.ConfigNode configNode) [0x00000] in <filename unknown>:0 at ContractConfigurator.ContractRequirement.LoadRequirement (.ConfigNode configNode) [0x00000] in <filename unknown>:0 at ContractConfigurator.ConfiguredContract.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0

This is what I get after updating to last version (1.11.5) of Contract Configurator: Exception occured while loading contract 'RemoteTech.RT_EverythingSat': System.Exception: No ContractRequirement with type = 'CelestialBodyCoverage'. at ContractConfigurator.ContractRequirement.LoadRequirement (.ConfigNode configNode) [0x00000] in <filename unknown>:0 at ContractConfigurator.ContractRequirement.LoadRequirement (.ConfigNode configNode) [0x00000] in <filename unknown>:0 at ContractConfigurator.ContractRequirement.LoadRequirement (.ConfigNode configNode) [0x00000] in <filename unknown>:0 at ContractConfigurator.ConfiguredContract.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0

Yep, fags explode on load even in vacuum (when switching to flag itself or nearby vessel - only flag explodes, vessels ok). "Burned from overheating".... Game may break instead of explosion (black screen but UI still active).

riocrokite: Just FYI, download link in the OP points to v1.2.3, not v1.2.4. No big deal, downloaded proper last version, will give a go (seems like fun!)

Yes, using with UKS (although slightly tweaked/truncated to my taste) EDIT: Eurica! Found that extra config, THANK YOU for pointing this out!

Question (bug??): Did something change in the latest update in terms of supply consumption rates? Are they hard-coded now? The reason I am asking is that I edited consumption rate to ~2kg/24hr with matching changes to greenhouses (as find it ridiculous that a kerbal would consume 64kg of supplies in 24hr), but I am still seeing 64kg/24hr consumption rate in the game (used to work correctly in .40.2.0). Also, excluding vets from ill effects does not seem to work any more. Here is my config: EDIT: Yep, it seems like the settings.cfg is totally ignored.

Ok, so it was the intent (my results are about the same ... Not complaining, mind you, I will take what I can get I did install properly, and no, I did not mess with physics except for raising re-entry heat to 120% in start-up options (started on stock).

Great, thank you! DR is a must-have for me, but one thing I noticed though is that it is not nearly as deadly as it used to be (~6 months ago), practically comparable to stock (have not managed to burn-up yet, except for tumbling mishaps involving timewarp; even 25km re-entry from Minmus is a joke, did not even go through ablative shield). Was this intentional or is it just waiting for re-balance?

It's alive!!! Nice and deadly style... Thank you for quick response, back to enjoying DR!

Great to see the (pre) release, but there is something royally wrong with G-forge damage - I just had my entire crew killed within 90 seconds of launch (never exceeded 2.5G, mostly 1.5-2). "Reaching G--limit" appears almost instantly from launch. Edit: Yep, pretty consistent - seems like minimal G at which effects start to stack is 0. Eagerly waiting for the update, back to stock for now.

Randazzo suggestion (Heat Management mod) will work, but please note that Atomic Age (love it for almost-stock play) is ONLY A PARTS MOD, so you can easily edit heat production and such in the config files to properly correlate with current KSP 1.05 Nerva values - problems solved. P.S. I hope to see this mod come back in 1.1... please?

Testflight.... failure rate, reliability and such... Oh, DangIt! This is an opinion of just one player, but it would be so nice to have a simple damage (visual AND functional, or at least functional) mod, without all the complexity of others. If I have 2 hrs to play the game, I would like to be able to finish a mission relying on my construction, planning and piloting skills (and [lack of] stupidity during the mission) - not on some random chance of failure. Unrealistic? Absolutely! But I am definitely not installing Testflight or Dangit - not until I quit my day job.

3 is... bad, really. 2 is nice but a little too complicated, too many stats - there are enough mods that make playing KSP miserable already (unless a player is a guru and/or can spend 10hr a day playing) 1 is little bit too simplistic, but I would DEFINITELY prefer that - simple, easy to track, and easy to understand for any player level. May be add +-10% RNG on each check ("if you hit it enough times, maybe, just maybe you'll fix it"). Also, for "repair workshop" - nice idea, BUT ALSO you could use spare parts and/or tools using KIS to increase engineer's performance. May be even give pilots and scientists a minor boost (e.g., up to 10-15%) if they have "proper tools", and may be limit engineer's ability even on top level if they do not (e.g., up to 50% max at level 5, +25% for tools, +25% for repair supplies, or just +xx% (times engineer skill + 10%, for example) single-use "repair kit" for simplicity). And please limit the damage meter to 100% , if possible Anyway, just ideas (and personal opinions), I hope this mod sees the full release (and subsequent updates).

Eureka! I had Copernicus+OPM but deleted it after starting this career (crashed too often). Thanks! I guess I will restart yet again Tourism: for the "tour of the facilities" mission all nav points were (did not try in this save) close by in the field near runway, not at the corresponding buildings (took me a while to figure it out).

Here is the save with modlist included: http://uploaded.net/file/ojfgx81w Cancelling and accepting the contract resulted in exactly the same problem (same offset locations). Terrain detail is high already. P.S. I had seen similar problem with Tourism contract pack a couple of weeks ago - no saves for that one though.

Strange, for Island Airfield waypoints show up a couple of hundred meters South-West-West, making them essentially inaccessible (except by helicopter or parachute). Was fine in the last version (I checked - coordinates are the same in contract files. something else is off).