Shoey

Introduction A set of 3.75m parts that mimic the 3.75m parts that come with MKS, using kitbashed models from SSPX. Also comes with a patch that adds combined storage for all components needed to manufacture Specialized Parts and Material Kits to SSPX cargo containers to help cut down on part count. Requirements Modular Kolonization System (MKS) and Stockalike Station Parts Expansion Redux. Shoey's Tweaks for MKS is recommended as it contains several other tweaks to make the two more friendly with each other. Parts Added 3.75m 'NER' Agriculture Module ...Agriculture Support Module ...Akademy ...Assembly Plant ...Kerbitat ...Kolonization Module ...Medbay ...Nuclear Processor ...Pioneer & Logistics Module ...Recycling Plant ...Refinery ...Regolith Sifter Installation Simply download the zip from SpaceDock and merge GameData folders. Download Spacedock License: GPLv3

That's probably it, I was using the FFT scoop.

Does anyone have any advice for harvesting LqdHe3 with FFT? I tried using the exosphere scoop in orbit of JNSQ Mun with 0.814% LqdHe3 but couldn't get anything.

Is resource refining/manufacturing supposed to work in the background? It doesn't seem to be working for me.

I was getting this issue too. I switched it over to the Blizzy toolbar and it doesn't seem to happen there.

If I can make a suggestion, making it so that when EC/supplies run out it'll recheck the vessel to see if there are any present then update the counter would be great. As it stands you kind of just have to give long term vessels (bases/stations/etc) a lot of excess supply storage or switch to them frequently. Something that would probably be simpler but equally helpful (albeit usable for cheating) is just a debug option to make EC and supplies last indefinitely on a given vessel, that way you can still have to be constrained by life support on short term craft but can set aside your bases for months/years at a time.

Introduction MKS is great fun. This is a collection of patches and tweaks to bring other mods inline with MKS and vice versa as well as just making it more fun (at least in my opinion). Requirements Modular Kolonization System (MKS) is the only hard requirement. Stockalike Station Parts Expansion Redux and Cryogenic Engines are suggested. Changes Added side nodes to 2.5 and 3.75m SSPXr cargo containers. Changed SSPXr Minerva Deep Space Control Module (5m station core) to mimic the 3.75m Pioneer + Logistics module. Changed SSPXr Harbour Station Control Center (3.75m station core) to mimic the 2.5m Pioneer + Logistics module. Changed SSPXr PPD-F412M Hydroponics Module, PXL-R4NCH-3R Hydroponics Module, and PYV-G2 Villa Cultivation Dome to mimic the 2.5m Agriculture Module. Changed SSPXr PYV-4 Demeter Cultivation Module to mimic the 3.75m Agriculture Module. Changed SSPXr Aquaculture to support 7 kerbals. Added methods to produce Transport Credits with LqdHydrogen and LqdMethane. Changed all fuel tanks to act as planetary warehouses. Installation Simply download the zip from SpaceDock, merge GameData folders, and configure as you like or leave as is. Download Spacedock License: GPLv3

Just realized I never thanked ya. Thanks, it's been good fun playing with this in JNSQ+MKS. I like tweaking stuff for realism over gameplay so I might make some tweaks and share them eventually, but still. Great fun.

Thanks! I've got a pretty solid grip on most of it from the ingame help pages and the couple bases/stations I've set up but I'll take a look at that anyways.

Ahh, okay, I get it now. Thanks for the help, much appreciated.

That is what I thought, but its not working that way for me. I've used the automated Atlas harvester and one of the automated drills but they'd just cap out on water and not push it into planetary logistics. I am expecting it to push from containers on the same craft marked as planetary warehouses. Does it by pass that requirement and push without any containers and I just missed it?

I'm having an issue that might just be me misunderstanding mechanics. How are unmanned mining craft and pushing resources to planetary logistics supposed to work? I've got a few Atlas harvesters set up to harvest water but I can't get them to push it into planetary logistics without having a manned logistics center in the same craft.

Gotcha, gotcha. I'm curious, though. What's it based off of or is it mostly a self consistency thing? Always like talking about this stuff cause it's a good learning opportunity.

Sweet, thanks. While I have your attention I did write a patch to add LqdDeuterium (mainly for Far Future Tech fusion reactors/engines) to the same refining option. I based it off of the percentage of water that is deuterium by mass. OUTPUT_RESOURCE { ResourceName = LqdDeuterium Ratio = 0.0003458128 FlowMode = STAGE_PRIORITY_FLOW DumpExcess = True } if you want to add it you can just copy it from my patch. Don't have to, of course, just thought to mention it.

This is probably intentional for balance purposes but I feel like I should mention it anyways. Hydrolox refining uses 1.8kg of water per 0.18kg of fuel. Some mass loss makes sense from impurities. refining, etc but 90%... doesn't feel right. Is it based off of something or just balance?

https://dotnetfiddle.net/48IFZV I learned the required C# and resolved this specific issue in less than 20 minutes (floating point errors in 500< of 1000 numbers with 1 digit before and 2 after the decimal, which is what I used "2 decimal" to refer to, not the very obvious floating point error) using functions solely provided by System in various revisions of .NET, fixing all of them. I did make a dumb mistake printing a value twice but it does exactly what it's supposed to. I'm willing to bet that's less time than you spent *arguing* about this. It's certainly less time than I spent typing even just this response. This can (and should) be done better, of course. Using variables to count the digits after the decimal in both numbers involved in addition and subtraction, as read off the disk, and rounding to the one with the most digits, since we know it'll never go past that thanks to elementary school mathematics (x.xx + x.xxx will never equal x.xxxx without it being a rounding error, remaining true even as you shift the decimal place, which you can correct very easily by just rounding it). Potentially optimize by "sanity checking" with known bases (i.e. 0.1 instead of 0, leading into solving it exactly like I did earlier) before rounding though the fact that it can execute 1000 times in 0.08s while printing debug information makes it kind of redundant when it'll never happen more than 100,000 times, and even if it does it'll be cached and those 8 seconds out of an hour (which it'll be far less than) won't matter so long as no module manager patches change. As for multiplication, that one is resolvable in almost the same way as addition and subtraction, just add the relevant digits instead of using the greater. 1.8923 * x.x will never have more than 5 digits after the decimal, unless it's an error. 1.8923 * x.xx 6. Maybe MathF.Round isn't even supported by versions relevant to KSP! It can still be resolved other ways or you can just write a rounding function yourself, though that is obviously more complicated. It's very useful whenever math is involved, even if it's not floating point. Sure, you shouldn't do "if (float = float)" but you don't get much of a choice in ModuleManager patches sometimes. As far as I know, there is no way to round without using regular expression combined with multiple "node edits" and you can't work around having to specify variables as sp floats. But when module manager by default can not do half of "x.xx = x.xx" if math was used to get there that's a problem. Arguably a big one since a lot of numbers in KSP can wind up in that place, one way or another. When more than a quarter of floating point operations have rounding errors, and you can fix most of them by applying the logic of mathematics and a few lines of code (literally less than 20 if you just use the logic, presumably to the 3 functions that handle parsing addition/subtraction/multiplication commands in MM patches), it's worth doing. This isn't anywhere near as impossible as you keep saying it is. I wouldn't even say this was hard, I spent more time talking about doing it than actually doing it, and I hadn't even looked at C#, C++, C anything in years. There's any number of ways to do this. Math is logical, and errors can be accounted for. Sometimes extremely easily. There's a reason dedicated calculators can get it correct, at least far more of the time. Stop arguing in seemingly bad faith. I respect the modding work you've done but you simply aren't correct here. Sure, you can push this solution to its limit and break it but there are a significant amount of errors that can be resolved very easily this way, focusing on number ranges used very commonly in KSP (500< out of 1000 between 7.75 and 2.25, 29000< out of 100000 between -7.75 and 999.25, for addition specifically) , even if it's just making it so you can apply MathF.Round to a value present in a Module Manager patch with a command in the patch itself. If you want to believe that floating point errors are always impossible to correct, feel free to, but don't be so adamant about it, because a lot of them can. All you needed to prove it to yourself is opening the calculator that comes with Windows. This was literally just meant to be a simple bug report with a small desire for Module Manager side mitigation, not some "prove your work" discussion where I honestly feel more insulted than anything else since you don't seem concerned with actually reading and thinking about what I'm saying, just arguing.

That's not strictly true either as there absolutely can be situations where a ModuleManager patch won't apply because it's expecting a value that could've been errored out like this. Maybe ModuleManager accounts for this elsewhere (i.e. every equal condition is actually +-x digit), but it wouldn't be the first time I've seen a scripting engine break from floating point inaccuracies. It's the first time I've seen it happen at 3 digits of accuracy, though. I'm not a professional programmer by any means (not that I would call what I'm doing programming), but there are a ton of ways to mitigate this. The entire point of floating point is enhanced accuracy, and having errors at 3 digits (2 decimal) may be edge case but it's definitely not optimal. If you wouldn't fix it, that's fine. If they don't want to fix it, that's fine. I would fix it, though, which is why I bothered to type any of this up. Look, I get you wouldn't want to fix this. I really do. Being able to write a basic calculation function that has no error correction doesn't prove me wrong, though. Objectively speaking, it is an error, and it can be worked around. You could do as little as calculate the decimal place of both numbers involved and then round to it afterwards, in this specific case, because decimal places will never be added (past those of involved numbers) when doing addition/subtraction. Sure, it doesn't matter when it's 76499 tons vs 76500 tons, but in cases where something must equal something else to work as intended it's worth implementing basic error correction, especially when it only needs to happen for a few seconds (the time spent actually doing these calculations) out of potentially hours (playtime).

Well, there definitely are workarounds or better ways of doing it, as I couldn't get this error on any other calculator I tried. On top of that I ran into the exact same error again a third fourth time after I had completely changed what I was doing. To be clear, it's happened 4 times on 6 parts that have had no calculations done with more than 6 digits. It's definitely fixable, which is why I bothered posting about it, even if it may not be worth fixing. Since setting up module manager patches happen once per session at maximum, it may be worth doing higher accuracy calculations, for example.

I ran into 2 of the strangest arithmetic bugs while working on a greenhouse mod. @PART[*] { test1 = 0 @test1 -= 7.75 @test1 += 7.65 test2 = 0 @test2 -= 3.125 @test2 += 3.15 } test1 will consistently be -0.0999999999999996, test2 will be 0.0249999999999999. Probably just a floating point error, I guess? I don't imagine there are many situations where something like this matters but I got this to happen on 3 very different KSP installs so I figure it's worth reporting anyways in case it can crop up somewhere else and has just not been noticed. More details: I would've tried another Windows 10 install before posting if I had one handy. Usage of variables outside of this don't appear to matter, I was able to get this result with or without them (I was writing a set of patches to automatically configure greenhouses for various life support mods and discovered this happening to 2 out of 6 parts). Adding/subtracting any value before and after seems to work around this, i.e. adding 0.1 before 7.65 and subtracting 0.1 after. I can post log files if needed but I'm not sure they'd be of any help.

FSR has been modded into some other titles, like Fallout 4 VR. I don't believe DLSS has yet. I'm not sure how feasible/likely it is to be modded into KSP, though. Most people's bottlenecks are likely in their CPU or RAM and not their videocard, unless they are playing at 4k, which won't be helped that much by FSR or DLSS.

I just want to share my appreciation for what you guys have done here. As someone who has no real issues in stock scale other than getting off of Eve it was refreshing to have real design challenges to do as little as manned Mun landings and has generated great excitement to explore the Kerbin system for the first time in a long time.

Introduction In my opinion, Nertea makes some of the best KSP mods there are. They look and feel very consistent with the stock game, and have added much enjoyment and life to KSP for me. However, they do have some short comings sometimes. This mod was made with a relatively simple concept in mind: rebalance fuels and tanks present in Cryo Engines as well as some of those in Near and Far Future to be more consistent with both themselves and real life, providing more use to various engines throughout your Career save whilst keeping everything notably stock-alike. Do note, however, this mod was designed with harder-than-stock in mind and is still in development, as a result further changes may be made that will impact difficulty as well as the delta-v of craft in flight, and is mainly for people who want harder-than-stock-but-not-Realism Overhaul. Examples of Changes and the Reasoning Behind Them By default LqdMethane, with its fuel mixture referred to as Methalox, costs over 6x as much per ton compared to LiquidFuel, mixture referred to as Kerolox. This is somewhat balanced by the fact that methalox engines burn more of the much cheaper Oxidizer in comparison, however this still results in it costing 3x as much to actually use without providing a comparable performance or ease of use benefit over kerolox or hydrolox (LqdHydrogen), making Methalox launch vehicles inspired by the likes of Starship almost completely unviable in harder-than-stock Career saves. In real life, this was not far from reality... back when Community Resource Pack, the source of Cryo Engine's LqdMethane, was designed. Nowadays, however, methalox mixtures actually cost about the same per ton as kerolox does while retaining those notable-but-not-significant performance benefits. In the future, this may change, but it likely will not be in kerolox's favor as we see more methalox engines both in development and commercially. By contrast, hydrolox launch systems cost about the same or even less than kerolox without reflecting any of the many difficulties associated with using them, aside from the sheer volume needed and being more expensive to store per ton. Boil off is so low in non-cryogenic tanks that you won't even notice it before launching interplanetary missions and the insulation cost is so paltry that you can power even the largest non-cryogenic tanks with a single solar array at almost every stage of the game, let alone nuclear powered systems, completely negating what little boil off there is and just adding an ultimately minor dry mass and cost tax. In real life, liquid hydrogen is downright awful to work with. It has a boiling point so low that as much as half your reserves vanish in a week even with dedicated cryogenic storage. It takes a ton of electricity to even try to maintain what you do have. It's so cold that launch systems can't be cleared out the same way as other rocket fuels. Not all of these problems will be perfectly reflected, but some of them will take stronger influence, with non-cryogenic storage costing significantly more to insulate and boil off being increased to noticeable, and potentially mission impacting, levels. Other fuels, like Nuclear Salt Water and Fission Pellets from Far Future Technologies, are also balanced with this same kind of reasoning behind them, raised to better reflect the cost of the Enriched Uranium used in their production. Requirements This mod does almost nothing without at least some of the following mods and their dependencies. CryoTanks Cryogenic Engines Near Future Technologies Far Future Technologies Overview of Specific Patches Note: some parts of this mod will influence the costs, delta-v, and viability of craft, both saved and in flight, so you may want to read carefully if installing this on an existing save or updating. If installing on a new save, you don't have to worry about this, but can read on for a better overview of what's been changed. I've designed it so that the distinct changes are in separate clearly named patches, so you can keep what you do want and discard what you don't from CryoFutureReQuoted. Or you can throw caution to the wind, install them all, consequences be disregarded (not that there are many). A_TanksFlagged.cfg - Simply tells the following patches what tanks are and aren't cryogenic. This one can be left alone as it makes no gameplay changes and may be relied upon by some of the following patches. CryoFuelsRequoted.cfg - Adjusts the price of LqdHydrogen and LqdMethane to values representing real life more closely, lowering both of them, with Methane being lowered significantly. CryoTanksReMassed.cfg - Increases the dry mass of LqdHydrogen tanks to better reflect the complexities associated with storing it compared to LiquidFuel and even LqdMethane. Though this change will likely not be noticeable on any craft that aren't just a fuel tank, a probe, and an engine, it's kept separate from the others as it can impact delta-V. I would recommend assessing any LqdHydrogen using craft that are in flight before using this one on an existing save as you may inadvertently strand one if you do. FarFutureFuelsReQuoted.cfg - Raises the price of FissionPellets and NuclearSaltWater significantly, to bring them inline with the cost of Enriched Uranium and incentivizing player refinery even in Kerbin's SOI. NearFuturePropulsionFuelsReQuoted.cfg - Significantly reduces the price of ArgonGas to much more realistic levels. NearFuturePropulsionTanksReQuoted.cfg - Brings the cost of Argon tanks inline with Xenon when applicable, otherwise changes them the best that I can. TanksBoiloff.cfg - Significantly increases the boil off and insulation cost of LqdHydrogen as well as slightly increasing the boil off and insulation cost of LqdMethane on non-cryogenic tanks, essentially requiring the use of dedicated cryogenic tanks for LqdHydrogen and incentivizing the use of them for LqdMethane even for short term missions. Also increases insulation costs on cryogenic tanks moderately to encourage use of nuclear power for large quantities of LqdHydrogen as near to Kerbol as Duna and LqdMethane or electrical propulsion for early missions to the outer system. Installation Simply download the zip from SpaceDock, merge GameData folders, and configure as you like or leave as is. Updating Best practice when updating will be to delete all old patches and reinstall the ones you want, even if installing them all, to account for potential renaming of patches, as well as rereading the patch overview. Download SpaceDock License: CC-BY Potential Future Changes Further refinement of propellant to dry mass storage for Hydrolox and Methalox tanks. Further refinement of cryogenic and non-cryogenic storage of aforementioned fuels. Balancing of several fuels present in Near Future Technologies to reflect the current market. For explanations of my specific changes, click here to view a development log of sorts, consisting of my thoughts and research as I'm having them/doing them respectively. Do note, however, this is very raw and may, at times, contain misinformation that I find while researching the changes I desire to make. I am very fallible, and should be treated as such, though I will note sources I find and explain why I think what I do.

If I may make a suggestion regarding USI-LS support, the aqua culture module is 10.74t and is set for 81% recycling for 4 kerbals at 36.25 EC/s. The closest comparable part from USI-LS itself is the RT-5000 at 3.75t and 79% recycling for 3 at 18.75/s. Maybe the aquaculture module should be configured for 7 kerbals? Their recycling per kerbal is practically identical and this change would make it much more desirable since the science experiment and kerbal seats aren't really worth 7 tons. More reason for this change would be: the RT-5000 has 1.25t of effectively 80% recycling per kerbal and the hitchhiker container seats 4 kerbals at 2.07 tons, or effectively 0.5 tons per kerbal. 1.25t * the 7 kerbal recycling + 0.5t seat * 3 seats = 10.25t with the remaining 0.49t for the science experiment. Plus, just changing the recycling count wouldn't affect any existing craft for the worse or necessarily better. Won't change their delta-v and might only make them generate more EC if they were using multiple AC parts. I really like using all these parts in general for stations and long term interplanetary craft. It would be nice for the AC to be worthwhile using in comparison to the RT-5000.