Lyneira

Virtual tanks (could also call them tank groups or metatanks) that can be named would greatly help with fuel transfer between a docked craft and a space station, both of which may have many tanks! But it does lead to new questions such as this one: Suppose you have a spaceplane with a tank group "MunTransfer", what should happen if you dock two identical ones (or two different craft which both happen to have a MunTransfer tank group) to a space station and you try to transfer fuel from it? Maybe you'd want to refill the MunTransfer tank group for both, or maybe just one? One solution could be to treat each assembly's tank group separately in the resource manager, but that might not be what you want if you're creating an interplanetary ship out of multiple launches docked together and you actually want each subassembly's tank group to merge together.

The proposal's purpose would be that changing the ratio would allow 1 pure CH4 tank plus 1 pure oxidizer tank to make the perfect ratio for a methalox engine. But since we have no pure oxidizer tanks, there doesn't seem much benefit to that.

Thank you KSP2 team for your hard work, looking forward to many more bugfixes and improvements!

Spent some time today tweaking and miniaturizing a "Micro Return Pod"... It's very Kerbal. Mass: 0.37 t (kerbal included) 6 parts Parachute Electric Charge: 100 U Torque: 3 kN Delta-v: 397 m/s (can go up to 750 m/s if tweaking more fuel to the tank) The only caveat is that it is somehow denser than water even with the empty fuel tank, so it will sink all the way to the bottom of the ocean after a water landing.

I'm excited to try out the new VAB and Spaceplane hangar editors and see how comfy they are to build with. To play around with vessel colouring, experience the quick load times between building and flying from the preview footage. The music fragments I've heard so far sounded very good to me, and I can't wait to vibe to the music during my space exploration adventures. But most of all, I'm excited to build and fly some spaceplanes!

Accidental doublepost while editing above post, please delete

I've managed to get the pack to load with 1.4's Kopernicus with only a minor config change for Tidus. I would recommend getting the latest New Horizons source by downloading it from the github page with the "Clone or download" button and installing only the New_Horizons folder to GameData. Find your KSP directory and go to GameData\New_Horizons\KopernicusFiles\Vanor\Tidus.cfg and comment or delete the following block of config: SharpnessNoise { seed = 11746 deformity = 0.00100000004749745 octaves = 4 persistance = 0.5 frequency = 0.5 //Noise //{ // frequency = 0.5 // lacunarity = 0.5 // quality = High // octaveCount = 4 // seed = 33127 //} } If not commented, that Noise block will cause Kopernicus to throw an Array out of bounds exception and causes planet loading to fail. After this change I was able to start a new save and look at the New Horizons system in the tracking station, including Tidus which seems to look fine. A quick launch of a test vehicle also didn't reveal any problems. Tidus might not completely be its usual self (I haven't gone there to verify) but at least we can play in New Horizons again.

Thanks, updated to the latest Kopernicus and all planets/moons are present and accounted for!

@KillAshley I've had a recent update of Kopernicus to release 1.3.0-5 (Full disclosure, I am using NH 2.0.1 from CKAN) and it took me a while to notice but while looking at Vanor I noticed Tidus was no longer there. A helpful IRC user mentioned the latest Kopernicus breaks some things, so I uninstalled Kopernicus and manually installed release 1.3.0-4. Tidus is now back where it belongs, but the pack probably needs a fix to make it work with the latest Kopernicus release. I'm also happy to manually apply a MM patch if the issue and solution are known already. I did a cursory search through the relevant KSP log file but could not find any error messages related to the loading of Tidus so I'm afraid I can't offer much help there.

@Nertea Thanks for the link, that was an enlightening read! So 0.001 is the minimum value I can work with in my patch, that's good to know. I look forward to the next CRP release with the new values, and I can use my patch in the meantime. In that context I'm satisfied with my choice for a number that's readable in the tracking station (even if it is unrealistically high) and tuning converter efficiency to scale back the harvest rate again. Still have no idea what the original intended harvest rates are for Argon and Xenon, but if the values in CRP were defined independently from the Cryogenic Separator's Efficiency maybe there never was one? In that case I might just keep tweaking until I find something that's a bit challenging but also fun for me.

Thanks for your reply, I did encounter your Near Future tutorial a little while back and it was a good read. Though I think you may be misunderstanding my angle where you say I'm approaching the problem all wrong. I'll answer the remark of flying with the Separator first: I'm aware the Separator's intended use case isn't for flying, it does however increase its harvesting rate with speed. It was a fact finding mission and gave me an idea of how low the default rate is even with an exaggerated harvest rate at high flying speed. If I do seriously start harvesting Argon and/or Xenon, it would be with a ground based rig with multiple Separators and plenty of power. But I will also look at Karbonite's fuel scoop configs (perhaps mod up a stock part to do the job) if I do feel the need to scoop Argon at a very high rate while flying! As for the abundances, you suggested to increase the minimum abundance to get a better value in my save. However in CRP's configs, the abundances were lower than realistic by a factor of 100 because they were expressed as a fraction from 0-1, where CRP expects a value between 0 and 100. A factor of 100 due to a config error is far more significant than the range between min and max abundance for Argon at Kerbin. (a factor of 10) Before my patch, Argon's concentration read 0.0% in the tracking station and 3.4% afterwards, which is somewhat low in the range of 1-10% but makes much more sense and is probably high enough that I can work with it. For Xenon, the problem was that the Separator did not harvest Xenon at all. Not even when its abundance was absolutely defined (not multiplied via MM) as the correct 100x higher value. Something in KSP's resource system seems to truncate it to zero, and as a result you don't see Xenon at all in the tracking station, nor on the atmospheric sounder or the Separator. The only way I could get Xenon to appear as a resource in the tracking station and on the Sounder/Separator at all was to artificially increase Xenon's abundance well above a realistic value. I don't know what boundary the cutoff is at, but for reasons of readability in the tracking station, I set the abundances in the order of 0.09%-0.2%. That's far too high, but as I said in my original post, I offset it by reducing the Separator's efficiency for Xenon so that it harvests a lot less by mass than Argon. It's not the approach I would have liked to use, but it's the only one that I could get to work at all. Technical config details aside, I'm mainly interested in the following question: What sort of resource rates for Argon and Xenon, in terms of units per second or grams per second, are (or should be) the intended reasonable harvesting rate for a stationary Separator on Kerbin? Perhaps @Nertea or @Streetwind could weigh in on this?

Hi all, First of all I'd like to give my appreciation to the developer(s) for your work on these mods, I've been using NFE and NFP and the models and part balancing are well done. There's one part that I've been experimenting with in Career, the Cryogenic Gas Separator, that doesn't seem to be balanced well though. The argon harvest rate is rather measly, in the order of about 0.1 u/s even when flying at around 280 m/s just above sea level. Considering argon's tiny unit density, that's about 0.0001784 grams per second. The Xenon harvester refuses to deploy, saying there is nothing to harvest. The atmospheric sounder also stated no Xenon was present. I did find an earlier conversation in this thread about this and apparently the CRP values for abundance were off, examining them it looks to me like they were expressed in ranges of 0-1 when the comments say they should be expressed in the range 0-100. Since it was also said that CRP changes are slow to get done, I decided to roll my own ModuleManager patch (which you can find below) which increases all abundance values for Argon by 100x, which gave a more reasonable Argon harvest rate of ~ 10 u/s while flying at high subsonic speed. Still only 0.01784 grams/s but at least that seems like a value you can wait a few weeks for if necessary with a larger ground based rig. I also tried multiplying the Xenon values by 100x in the same way, but this did not seem to have any effect at all. The tracking station reflected my argon changes (about 3.4% now instead of 0.0%), but still didn't list Xenon and the Sounder and Separator still said there is no Xenon. Because the abundance values, even multiplied by 100, are so tiny I thought there might be some kind of cutoff happening in the resource system, so I decided to multiply them by another 1000 and assign them absolutely instead of multiplying the original values. That put them in the range of 0.09 to 0.2% for Kerbin so it would be some readable value in the tracking station and on the atmospheric sounder. It worked, the Cryogenic Separator would harvest Xenon now but of course the harvesting rate was too high, especially compared to Argon. I ended up reducing the Cryogenic Separator's efficiency for Xenon by 100x to end up at something that I thought reasonable, if not entirely realistic. With this patch and my save (3.41% Argon and 0.162% Xenon and 100x reduced harvesting efficiency), the Xenon Loop works out to about ~10% funds/s compared to argon harvesting (which itself is less valuable than monopropellant mining if I'm not mistaken) so it's certainly not going to be a gold mine, and about a 1/64th harvesting rate by mass. That doesn't reflect its true rarity but neither did I want to force silly amounts of timewarping to get a half decent amount from one of these units. I am however curious what you balance experts on this mod originally intended as reasonable harvesting rates for these two so I can fine tune the patch though. For the interested, here's my patch, would appreciate to hear feedback and suggestions: // This patch fixes the abundance of Argon and Xenon in atmospheres, as they were specified too low by a factor of 100 in the Community Resource Pack. @GLOBAL_RESOURCE:HAS[#ResourceName[ArgonGas]] { @Distribution { @MinAbundance *= 100 @MaxAbundance *= 100 } } @PLANETARY_RESOURCE:HAS[#ResourceName[ArgonGas]] { @Distribution { @MinAbundance *= 100 @MaxAbundance *= 100 } } // Atmospheric // Set this artificially high to avoid being truncated to 0, fix this in the cryoseparator later @GLOBAL_RESOURCE:HAS[#ResourceName[XenonGas]]:HAS[#ResourceType[2]] { @Distribution { // The commented values are the corrected values from CRP before artificial inflation //@MinAbundance = 0.000005 //@MaxAbundance = 0.00005 @MinAbundance = 0.05 @MaxAbundance = 0.5 } } // Oceanic // These are the corrected values from CRP, not modified further because they're not low enough to get truncated @GLOBAL_RESOURCE:HAS[#ResourceName[XenonGas]]:HAS[#ResourceType[1]] { @Distribution { @MinAbundance = .01 @MaxAbundance = 1.0 } } // Set this artificially high to avoid being truncated to 0, fix this in the cryoseparator later @PLANETARY_RESOURCE:HAS[#ResourceName[XenonGas]]:HAS[#ResourceType[2]]:HAS[#PlanetName[Kerbin]] { @Distribution { // The commented values are the corrected values from CRP before artificial inflation //@MinAbundance = 0.000009 //@MaxAbundance = 0.00002 @MinAbundance = 0.09 @MaxAbundance = 0.2 } } @PART[cryoseperator-25] { // Fix artificial Xenon concentration by reducing harvesting efficiency... Not entirely realistic but based on roughly equaling funds/s of argon harvesting so as to not make the player timewarp unreasonably long to fill some tanks @MODULE,0 { @Efficiency *= 0.01 } }

I've been playing on and off with New Horizons since about 1.2 and am enjoying the new system, haven't made it out of the Sonnah system yet as interplanetary planning has gotten a lot more complicated, and the usual mods that can help with transfer window planning are having some hiccups. Got a research station orbiting Serran with an SSTO shuttle for science runs to the surface, although landing a plane on the surface with FAR is pretty difficult. I've been looking at the other different planets with atmospheres that I'd be interested in visiting like Titanus and Tidus and also Arin and to my surprise the tracking station indicates all of their atmospheric pressures at 0.6 atm (this also goes for Serran), despite the description of Titanus having huge atmospheric pressure. If it's a display error, can it be fixed somehow? It would be nice to have some sort of estimate from the tracking station from gravity and pressure how hard plane flying will be on a particular planet. I've dug into the config files and found that they have different molar masses for their atmospheres and pressure curves, how do I estimate how well lifting surfaces will work on a planet from pressure and molar mass? It would also be useful to have the reference values for Kerbin, which I could not find anywhere in NH or Kopernicus' config files. Edit: So I scoured the KSP wiki and it looks like it has some info on pressure at different altitudes and also lists the molar mass for the stock planets, I am still curious if/how to combine those two to estimate lifting surface effectiveness relative to Kerbin though.

I like this mod, this will make rovers useful for a lot more things! Scaling down the speed at which a rover will travel based on the gravity is a good thing, though I would suggest lowering the speed further as there are other factors to consider: The maximum speed that wheels will reach can be over 20 m/s for some wheels or even higher. While you can drive relatively safely on Kerbin at that speed, this only goes for flat terrain with no sudden bumps. A rover that's designed to actually carry something with it will not reach this maximum speed due to the rover's mass. Even when going downhill, you wouldn't want a safe autopilot to go above its regular driving speed because it is harder to brake or turn for obstacles. It is reasonable to assume the autopilot would not merely drive a straight line from A to B but avoid obstacles, cliffs, valleys, travel up slopes at an angle to maintain speed. All of this reduces the average traveling speed. For short distances, it leaves the player with a reason to still drive something themselves because they might be willing/able to take risks that the autonomous pilot wouldn't. To summarize, lowering the max speed will make it a more believable abstraction, but also importantly, it doesn't hurt the player's time significantly because as with the rest of the game's space travel, you can timewarp through it.

Thanks for your suggestions! After a bunch more tweaking and testing I think I've struck a good new balance for the craft. Offsetting them down as far as possible without looking detached got me a little bit of extra height, I made them physicsless in return to avoid drag and CoM issues with the racer. I brought the spring strength from 2.4 up to 4 and set damping to max which seems to have done a wonderful job of making the craft both safe to fly and have very little bounce. I think it's actually safer than before despite the reduced overall height! I've issued a new release now where the current 3 scenarios should be properly playable again with the current Kerbal Foundries.

I installed via CKAN, the version is Beta_19.b, the punctuation is off but the numbers seem to match up! Edit: A couple more questions while I'm here, for Race Kerbol I'm tweaking a craft which is intended to fly at about 130-150 m/s as closely over the terrain as the player can manage, but without crashing. Is there a way for me to change the maximum possible "ride height" for the repulsors with some modulemanager magic? I wasn't able to spot a way to do it at first glance in the module's source. It feels like the height used to be a fair bit higher (previous setting of 60/100) in the previous release I played with, which gave some much-needed extra leeway in the angle you could hit the terrain at without crashing. To compensate for the reduced maximum height I've had to crank it up to 100 but it doesn't give quite the same safety margin. I've also been playing with the spring strength and damping values, I increased spring strength to 2.4 to help with safety but this has made the craft very bouncy on small bumps. Would appreciate some advice on how to tweak those values for a little bit more safety as well as reducing bounce.

Hi, I updated KF recently and just finished updating and testing one of my craft using the shiny new antigravity repulsors, whenever I fly over water and sometimes when I crash there is a giant white square visible though, just thought I would let you know.

Try Flight Manager for Reusable Stages, it lets you do stuff like fly a first stage rocket or plane back to base after detaching in the atmosphere with some save file snapshotting magic. In my latest career game where I added an MKS/OKS module to my space station, I try to launch everything I can with SSTOs, my largest one can get about 46 tons of cargo in a Mk3 cargo bay to orbit but that plane gets a bit close to the limit I'm comfortable with for part count (8 rapiers) and also wing usage. (big-s delta wing clipped partially into the big airliner main wing)

Race Kerbol (the sun) in a series of scenarios from start to finish while trying to keep as close to the ground as possible to get a higher score! Your craft is solar powered, so make sure to keep your panels exposed to the sun as much as possible. Includes a plugin that counts your score, a few custom parts that use no new models and a number of scenarios to race in. How scoring works: Gain score by keeping the craft's antigravity repulsors on the ground. You get a bonus for traveling on steep slopes so try to catch some ground time on those hills and mountains but avoid crashing into them! Requires: ModuleManager Kerbal Foundries Download Or install via CKAN and have dependencies resolved automatically! Changelog: 1.2.2 (16th of August 2015) Various tweaks to increase safety. Craft is a bit harder to crash and less bouncy. Made repulsors physicsless. Significantly increased default spring strength to compensate for KF's reduced antigrav height. Moved repulsors down a bit to give a little bit of extra height. Updated scenarios with new Solar Racer craft. Repulsor power usage should be roughly back up to previous levels (was significantly down in v1.2.1) 1.2.1 (15th of August 2015) Update scenarios, solar racer craft and repulsor for compatibility with the new Kerbal Foundries. 1.2 (14th of August 2015) Added a new scenario: Race Kerbol 03 - Island Hop LandDistance plugin is now RaceKerbol - Please delete your previous RaceKerbol folder from GameData! New toolbar icon Now measures distance traveled on the ground as Score. You get a bonus for traveling on steep slopes. The steeper the slope, the greater the bonus for traveling over it. 1.1 (9th of August 2015) Added a new scenario: Desert Pass Fixed a bug where Land Distance would calculate distance incorrectly when not traveling along the equator. 1.0 (9th of August 2015) Initial release with the first scenario, Westbound License: GPLv3 (only source code) CC-BY-NC-SA (other files) History: This addon is inspired by the game Race the Sun. After playing it, I started mucking around with building a little plane that vaguely looked like it and stuck antigravity repulsors from Kerbal Foundries on it. After trying it out racing across the ground and having quite a lot of fun with that, I figured maybe this could be made into an interesting challenge. The original version used small electric ducted fan engines from RoverDude's excellent Exploration Pack, but I wanted something more high-tech looking. One thing led to another and now the addon has a custom rescaled and welded high-tech engine for the racer, a plugin which tracks how far you've traveled across the ground and a few scenarios which set you off to a flying start! Future: Fine tune the scoring system and come up with a final score calculation for scenarios that values checkpoints and speed. Fine tune the Solar Racer craft and its power balance. More scenarios!