[WIP][1.3.1] Sufficiently Realistic Progression Zero

[pap1723]

On 7/15/2017 at 4:06 PM, NotTheRealRMS said:

Version 0.2.8

https://drive.google.com/open?id=0B45cFsYMm_H-OGZGMzlNazJYcXM

Mostly bugfixing this time, a reorganization of the contracts and a lot of wasted attempts to get the Space Shuttle from SSTU(SC-E) to work with Ferram Aerospace Research. On the latter there must be something with their geometry that really will not work with FAR, because during reentry, the shuttle will just roll and spin out of control until its wings and tail shatter, then the main fuselage keeps spinning at absurd speeds as well during descent, and there is no clear voxelization error, nothing obvious that could be making such Space Shuttle impossible to fly this way. This must be the reason SSTU thread explicitly states FAR as incompatible, therefore it's forsaking time. Besides, designing spaceplanes using procedural wings is more fun anyway.

Fixing misplaced attach nodes is something that is only practical when restarting the game over and over while editing a part ModuleManager config is not necessary, and tools like NodeHelper make it practical. Unfortunately that also means one more reason to delay an update for 1.3.

@NotTheRealRMS The issue is with the wings, elevons and tail for the SSTU Shuttle. FAR cannot have wings that are node attached, they must be surface attached in order to work. You should be able to accomplish that through the CFGs with MM.

[NotTheRealRMS]

On 7/26/2017 at 2:44 PM, pap1723 said:

@NotTheRealRMS The issue is with the wings, elevons and tail for the SSTU Shuttle. FAR cannot have wings that are node attached, they must be surface attached in order to work. You should be able to accomplish that through the CFGs with MM.

Thanks, that did it(mostly, might still need to fiddle with CoMOffset for the fuselage to make it fly better). Was away from KSP for a while, only checking occasionally if there was an official Real Solar System for KSP 1.3 . Finally, the coming new version for RSS will feature Ceres, so it's worth the wait. For now, another update for KSP 1.2.2.

Version 0.3.0

https://drive.google.com/open?id=0B45cFsYMm_H-UFNoTU5EbkFWOWs

Lots of changes, but the most noticeable is that now SRP-0 supports the still unfinished RealISRU , noticeable because the way chosen to ensure compatibility was to convert all Liquid Fuel to Kerosene and all Oxidizer to LqdOxygen as a final patch that mostly preserves mass ratios, for there were compromises made because the latest SSTU version for KSP 1.2.2 cannot accept fuel fractions in its procedural tanks as fractional numbers, so generic multipliers to all burn and fuel load ratios of every possible engine, converter or tank with either were rounded to integer numbers, otherwise all SSTU tanks would store excess LqdOxygen or Kerosene. This also could be a barebones framework for perhaps adding RealFuels compatibility in the future, despite it not being the original purpose of this mod, and in that, all the RF details like ignitions, ullage and ignitor resources would require some very detailed universal patching to work properly gameplay and realism-wise.

What RealISRU in its current state already features is everything necessary to simulate something like Mars Direct . RealKerolox ("RealFuels Lite" would be too unoriginal of a name for such a patch) is by default only applied if RealISRU is installed, but it can be set to be always applied  by running realkerolox.bat or .sh . Furthermore, on the ISRU front, as commented by one of the original devs of RealISRU, industrial scale ISRU is much beyond modern technology, so many parts that can be described as such, mostly Stock and from Umbra Space Industries, were moved further up in the tech tree to the "Sci-Fi Tiers". And there were some changes to the tech tree to, nothing really big. The placement of Space Station parts got some much needed attention and all SSTU Space Stations were rescaled up by the same factor SSTU command pods were (~1.3328) while all of them without TAC Life Support patches were given them.

Finally several new Tourism contracts were added, all the way to sending space tourists to Pluto, and the latter requires DeepFreeze because nobody would pay to grow old and maybe even die of old age before reaching the destination they wanted to. They also require a very specific tech for "economical realism", a metaplot/fluff of sorts to explain how space tourists who can afford the price of a grand tour to Saturn could exist. Manned spaceflight contracts beyond Mars also require the same tech, because nothing short of such "Second Renaissance" would raise an economy where there would be a will to invest in such astronomically expensive space missions. All of those missions only show up after researching "Artificial Intelligence and Worker Robots", formerly "Artificial Intelligence" from Community Tech Tree. It also include a handy upgrade that allows some probes to be locally controlled without the usual light speed lag challenges RemoteTech brings. It applies to SSTU and ProceduralParts procedural avionics and should work, however, I did not have a chance to test it yet, if it doesn't it will be fixed in a future version.

[m4gus88]

@NotTheRealRMS I noticed Deadly Reentry is not in the required or the recommended mods. Is it another mod you excluded from Realism Overhaul for simplicity? Is it compatible?

[NotTheRealRMS]

22 minutes ago, m4gus88 said:

@NotTheRealRMS I noticed Deadly Reentry is not in the required or the recommended mods. Is it another mod you excluded from Realism Overhaul for simplicity? Is it compatible?

Because DRE has an universal patch, with a few adjustments it is possible, but not certain. I haven't used Deadly Reentry for a long time because while what RealHeat does by itself to improve realism in stock Reentry mechanics combined with G-Effects might not be 100% realistic, I consider it enough, so I cannot give you 100% certainty the following adjustments will make DRE work fine with this mod.

Deadly Reentry, like any well designed mod that adds new gameplay features, has an universal compatibility patch, but it might be applied before this mod by ModuleManager, preventing its changes inherited from RO and balanced for the Real Solar System from being done because they will look for Stock ModuleAblator. To ensure DeadlyReentry.cfg only switches parts to its own modules after the rebalances are applied, you have to edit such file located in GameData/DeadlyReentry and change this line:

// General config to add / convert modules
@PART[*]:HAS[@MODULE[ModuleAblator]]:AFTER[DeadlyReentry]
{
	%leaveTemp = True
	@MODULE[ModuleAblator]
	{
		@name = ModuleHeatShield
		@reentryConductivity = 0.001
		%lossExp = -7500
		%lossConst = 1
		%pyrolysisLossFactor = 6000
		reentryConductivity = 0.001
		depletedMaxTemp = 1200
	}
}

To:

// General config to add / convert modules
@PART[*]:HAS[@MODULE[ModuleAblator]]:FINAL
{
	@MODULE[ModuleAblator]
	{
		@name = ModuleHeatShield
		%depletedMaxTemp = 1200
	}
}

The other changes done in the removed lines aren't really needed, only those two lines and having it as a final patch. Also, for maximum realism and making non-procedural heat shields from DRE work properly in RSS, you should also save this file from RO somewhere in your GameData folder(using the "Save As" option in the browser), but it is not absolutely necessary :

https://raw.githubusercontent.com/KSP-RO/RealismOverhaul/master/GameData/RealismOverhaul/RO_RecommendedMods/RO_DeadlyReEntry.cfg

[NotTheRealRMS]

Version 0.3.1 for KSP 1.3.1:

https://drive.google.com/open?id=1ws0JbYmgiTwULIsaO_6LkLfOnb0Zhwl8

Switching over at last, but I'm not entirely sure if a regular user can install the mods used. Some of the mods this was designed to coordinate with can only be made available for 1.3.1 with either self-made recompiles or checking the git repositories of their respective projects for downloading unofficial recompiled files from Pull Requests. Links in the OP will be updated to reflect this. To help a little anyone who might be interested in this and the suggested "modpack" in the OP, thanks to the generosity of @Crzyrndm  letting his work become free for redistribution and modification, a version of DynamicDeflection compiled for 1.3.1 is bundled. Originally the plan was to also bundle another mod, an Upgrade Editor that would make it possible to set upgrades separatedly for each part in a craft design, the same functionality as RealFuels engine and RCS upgrades . Unfortunately that proved to be way above my coding skills, if it is even possible. Should creating such a mod prove impossible(which is unlikely), there will be support for RealFuels eventually which is a lot more flexible when setting up engines and RCS than the Stock PartUpgrades, and the modest plugins in this mod are ready for it. ThrottleControlledShutdown.dll will self-deactivate if it detects the RF plugin so it won't be strictly necessary to delete it in that case, while ProceduralAvionics can supports SSTU modular upper stages with or without RealFuels installed. Only a lot of changes to ModuleManager configs to add conditional patches that only apply should RF be installed are required, plus the major universal RealFuels engine setup and SMURFF replacement patch.

Now onto the changes. First, having engines which were left activated in a space station or vessel suddenly accelerating on their own once another vessel controlled by the player rendezvous and reaches the physical bubble where the former is located was one of the limitations of ThrottleControlledShutdown, and the solution was so simple: rather than only track activated engines in the active vessel and anything undocking/decoupling from it, it now tracks all parts in the physics bubble, but will shutdown engines from other vessels because it's a simpler and more efficient procedure than tracking all engines from everything and storing individual throttle limits while overriding them all the time.

The forked RP-0 plugin also got some changes regarding how much percent from the total volume of a SSTU procedural upper stage it will define as available to calculate procedural avionics from. Rather than a fixed number, it uses a bell curve formula, ranging from 11.8% to a minimum of 0.0016% of the total volume . This is important to prevent very large upper stages from having a huge power demand when their avionics are active and a better solution than unbalanced settings for them.

The other major change was rescaling the TKS VA from SSTU to its real dimensions, giving it real stats, and doing the same to other new SSTU parts. There was a new rescale for the SSTU space stations to match the TKS VA with the real TKS service module, the space stations had their names and descriptions changed to more "immersive" ones, together with several fixes involving such parts and all the needed changes to support the latest version of SSTU. As a bonus, patches that make the Skylab from SSTU Expansion Pack and a decent amount of its features work with the latest SSTU are included as well. The extra Apollo service modules from Bluedog Design Bureau however weren't covered by this patch, which is temporary presuming SSTU-Expansion will be officially updated for the latest SSTU and KSP 1.3.1 eventually.

Sort of big yet small change: previously life support in TAC was consumed at only 25% of what would be realistic for humans. It was pure lack of attention to not have included the settings from RO for TAC Life Support back when this mod was just starting.

There was a need to remove some parts. Non-procedural SRBs using SSTU assets were just a thoughtless conversion of RO configs for ModulesEnginesFX. With SSTU having full support for procedural SRBs, both surface and vacuum optimized, they are kind of redundant anyway so it was easier to just ditch them instead of updating their part configs to work again.

And finally as a small detail, with the switch to 1.3.1, if you have Karbonite+ installed, Karborundum will be renamed to Ultra Dense Deuterium by this mod. Now to find a better name for Karbonite, which is... a methane source.

 

 

[Dr. Jet]

KJR should be a recommendation rather than requirement. Stock autostrut functionality works fine. 

[NotTheRealRMS]

Version 0.3.2:

https://drive.google.com/open?id=1zb9EHaZnLqZd6NT7L-PX-3_Bp88DOkr7

There was a mass and resource storage density discrepancy between ProceduralParts and SSTU tanks that lingered for too long already. Fixing it required changes to many patches, disabling SMURFF patches to ProceduralParts and ended becoming a reminder of the greatest realism shortfall in SSTU: the total volume of its tanks has no influence on their dry mass unless RealFuels is installed. Such was a major compromise, likely done for coding convenience, and the only way to work around the fact dry mass is calculated from the contents of a tank rather than its volume is to set up a multitude of different tank types in SSTU, like separate cryogenic tanks for methane that will have significantly less dry mass than the default ones for LH2 to simulate the mass of the extra volume the latter requires, plus a few other cases for mass ratios that differ significantly from RP-1 like a water, a xenon and an argon tank. There could be another way without a big list of tank types in SSTU, but unfortunately something like this:

SSTU_ZEROMASSRESOURCE
{
	name = ArgonGas
	mass = 1.8778947e-8 //This should change the mass ratio on electric propulsion tanks correctly
}

Which was my first attempt to add mass ratios with better realism for SSTU, doesn't really work. Instead of doing like that and having an unified Electric Propulsion tank for Argon and Xenon, for example, it was necessary to create separate tank categories in SSTU for each, but for the propellants that are featured in this mod, I believe the end result was still OK.

Besides that, the other major change in this update are patches for the Stock ion engine and also for NearFuturePropulsion which, most noticeably, convert many NFP engines to use SSTU clusters, which usefulness is questionable given how much electricity  they need. Second, after some small time Internet research, I got some specs for many of the engines in NFP and placed them over the Stock-balanced stats, while creating a generic patch for a few ones that didn't get specific configs and for future ones that may be released in future NFP versions. Now there is a catch: magical kN rated thrust is gone for such engines. Real electric propulsion is terribly slow, making  PersistentThrust and PersistentRotation essential for using such engines because they allow for thrusting them at high time warp while keeping the heading of the vessel constant at prograde or retrograde or another desirable heading. There is a 6.5 kN magnetoplasmadynamic xenon thruster among those created as a copy of the biggest MPD in NFP, the only one with over 1 kN of thrust. Unfortunately it consumes 60.2 MW of power per second at full thrust. There is also a copy of NFE biggest nuclear reactor to generate enough power for that one, but it weighs 58.3 tons and requires tons of radiators.

If you really would rather have a VASIMR performing like a torchship, there is a .bat and its equivalent .sh shell script to disable the nerf of ion and other electric engines. Finally, besides fixing some bugs, Upgrade Editor is now bundled and to reflect this change some duplicates are now available as part upgrades instead, specially for nuclear thermal rockets, which also got new methane variants like the partly pebble bed reactor based Timberwind 45 replacing the regular Bimodal NTR and a Methane - Methane/Ox  version for the same. With the dry mass changes for methane tanks in SSTU, which have much better mass ratios than LH2, it is a real option now.

[Shadowmage]

18 minutes ago, NotTheRealRMS said:

the total volume of its tanks has no influence on their dry mass

 

18 minutes ago, NotTheRealRMS said:

dry mass is calculated from the contents of a tank

Yep.  Naturally makes LH2 tanks lighter, and LFO tanks heavier.  When I was studying into balance for it, I charted out the tankage % for many different real world fuel tanks from the data I had available.  In the end it worked out that most fuel tanks, regardless of contents, were between 5 and 10% tankage mass.  Large Hydrolox tank?  ~5% tankage.  Large Kerolox tank?  ~5% tankage.  Bump that up to 12-15% for the stock solar system, and it fit in with the stock balanced parts quite well.

So the volume does have a very real impact on the resultant dry mass of a tank, it is one of the two contributing factors.  The other, as you stated, is the contents of the tank (volume * density * tankageFactor = dry mass).  Yes, it was done deliberately this way, but not to simplify coding, rather to specifically solve the problem of over-weight LH2 tanks that are present in every other mod out there.

 

I think you are correct in that the only way to allow for different tankage %'s on a per-resource basis is to create a specific 'Tank Modifier Type' that sets the 'dryMassModifier' values properly.  Unfortunately, there is no enforced tank-modifier-type->resources-allowed mechanics (that was done to simplify code, and configs), and it would still fail when the user customized the tank contents (GUI access can be disabled in the config though).

 

If you wanted to put up an issue ticket/feature-request, I might see about adding alternate methods to specify/calculate tank dry mass.  No guarantees though, as what currently exists works perfectly for my needs.  (Would depend entirely on how much code I would have to change and rewrite to allow the multi-specification setup)

 

[NotTheRealRMS]

On 11/21/2017 at 6:24 PM, Shadowmage said:

I think you are correct in that the only way to allow for different tankage %'s on a per-resource basis is to create a specific 'Tank Modifier Type' that sets the 'dryMassModifier' values properly.  Unfortunately, there is no enforced tank-modifier-type->resources-allowed mechanics (that was done to simplify code, and configs), and it would still fail when the user customized the tank contents.

The game doesn't fail when an user cheats an orbit through HyperEdit. I see such cases under the same light and given there is no official multiplayer, there is little point to completely cut off exploits. The reasonably realistic tankages were made available for those who care and also to give a point for the existence of liquid methane engines given this mod makes methane cryogenic as well(the way it is in reality), but why bother trying to stop those who don't care about how unrealistically lightweight the dry mass of a huge volume balloon tank filled with LH2 would be despite its size?

And here is another update, with even more custom engine clusters, this time for KerbalAtomics:

Version 0.3.3

https://drive.google.com/open?id=11E5tD_-xn6JmKuheioIWUiOzv-nSo-l2

Did you know that making gasses into cryogenic liquid propellants is absolutely useless for electric propulsion? After realizing that two more fuel types were added, Hydrogen and Methane stored as gasses for the VASIMR from NearFuturePropulsion. There were also two duplicate parts converted into switchable upgrades for their parents from the Apollo LMAE and LMDE.

After checking the amount of fuel options, at this point there is no way to hide this is a kind of "RealFuels Lite", and with the patch that converts LF/Ox to Kerosene and Liquid Oxygen, some historical rockets available through parts from Taerobee, FASA and Bluedog Design Bureau were not being given fair treatment. Being the first American rocket to launch an artificial satellite in orbit is relevant enough, plus the significant performance differences between Ethanol, Hydyne and Kerosene justify having the first two specified, even if they only apply to a few very early game rocket engines. Then X-15 is a big deal too and RealISRU support already drove the optional inclusion of Liquid Ammonia, so why not have it as well? The difference to RealFuels? Pretty simple: unified propellant ratios and omitting details like the presence of HTP in some of such mixtures, still "abstracting" together hypergolics, solids and monopropellants. But this is as far as it's practical to go without the features of RealFuels. By the way, very early rockets like the Juno I had much more dry mass(from the specs in that link it's almost Stockalike) than modern ones, to the point matching the Explorer 1 launch required switching its first stage SSTU tank to a "Service Module" tank type.

All of that done to improve the early game. Besides that, now the probes from Bluedog Design Bureau are almost 100% converted to their real counterparts, including Sputnik-3 and others. Sputnik-3 was made into a gold mine of early science, the changes to its original config gave it 7 different experiments, so there is a point to launch an over 1.3 tons satellite without integrated avionics guidance in it. Now there is only the OSO-1 left. And then I'll just use procedural probe cores every time and wonder why I bothered doing this besides the Sputnik-3 as a 7 experiments in 1 part package.

But the really major deal of this update is adding SSTU engine clusters to nearly all parts in KerbalAtomics and changing some of them to what should be more realistic specs. It's hard to extrapolate on technologies like gas core NTRs which only exist in theory, but normally the theoretical tends to veer on the optimistic, and the TWRs for some of those in KerbalAtomics were incredibly overpowered compared to their theoretical specs. One peculiar thing is that instead of implementing more and more mostly identical performance parts, model swaps are done in some cases, like for example this patch replacing the Stock NTR model used by the same part if KerbalAtomics isn't installed:
 

Spoiler

 

@PART[SSTU-SC-ENG-BimodalNTR]:AFTER[SRP-0]:NEEDS[KerbalAtomics]

{
	%node_stack_top = 0.0, 2.32669, 0.0, 0.0, 1.0, 0.0, 2
	%node_stack_bottom = 0.0, -2.030804, 0.0, 0.0, -1.0, 0.0, 2
	@MODULE[SSTUModularEngineCluster]
	{
		%engineModelName = KerbalAtomics/Parts/NuclearEngines/ntr-25/ntr-sc-25-1
		%transformsToRemove = Shroud
		%engineScale = 0.6 // https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20040182399.pdf ;  2004 presentation, with a 1.56m diameter BNTR
		%diameterMainIncrement = 0.5
		%defaultEngineSpacing = 2.5
		%engineMountDiameter = 2.5
		%engineHeight = 4.357494
		%engineYOffset = -2.32669
		%smokeTransformOffset = -2.2
		%partTopY = 2.32669
	}
	
	@MODULE[ModuleGimbal]
	{
		%gimbalTransformName = GimbalBone
	}
	
	//Delivering the deploy animation to SSTU modules
	MODULE
	{
		name = SSTUAnimateControlled
		animationName = NozzleExtend
		animationID = deploy
		animationLayer = 1
	}	
	MODULE
	{
		name = SSTUDeployableEngine
		engineID = Mode1
		animationID = deploy
	}	
	MODULE
	{
		name = SSTUDeployableEngine
		engineID = Mode2
		animationID = deploy
	}	
}

 

 

 

And animations for engines which have collapsible nozzles in KerbalAtomics can be easily converted to SSTU modules, so all parts that weren't redundant(no need to have 1.25m, 2.5m and 3.75m variants of the same engine with SSTU, and those sizes don't even apply here) were improved.

Edited November 25, 2017 by NotTheRealRMS
typos

[NotTheRealRMS]

Version 0.3.4

https://drive.google.com/open?id=1A4wGlFbXHKjwu3vQ_0efPIEnEQtpYlx3

Further bringing the "Near-Future" part of this mod to where it should go, with the Atomic Rockets site being very useful as inspiration. The most noticeable addition is right above. Scaling up NearFutureElectrical reactors and its NFP electric propulsion to the extreme. There is no solid real source to draw from because fission reactors that large may never happen and by the time technology evolves to the point such things could be built fusion power capable of generating 1 GW with only a fraction of the size and mass could already exist, same on 1 GW magnetoplasmadynamic thrusters. I wish I was good at 3d modelling but already been there, tried and gave up. Stretched NearFutureElectrical reactor models will have to do for these extremely powerful reactors, at least for now. Besides the stretched trefoil symbol, it's mostly serviceable. Maybe even cool in the same dank way MLG videos and Sanic "original characters" are.

Not as much of a showoff but perhaps far more important is the improvement to RealKerolox. Just a plain conversion of LF to Kerosene and Oxidizer to Liquid Oxygen won't give engines fuel ratios close to real Kerolox engines, but an unrealistically fuel-rich burn that would be terribly inefficient in reality due to most of the fuel not going into combustion because of the lack of enough oxygen. It may be argued converting LF/Ox to Aerozine50/NTO would make more sense, but then there would be no RP-1 rockets at all without specific configs. Now it also changes the fractions to more realistic, oxidizer-rich ones in the engines, SSTU tanks, non-procedural tanks using RESOURCE and ProceduralParts tanks. In fact maybe it should be activated by default regardless of RealISRU now, but there are a few details that could still be improved.

Support to NearFuturePropulsion now includes its RCS parts. Making electric RCS with enough thrust to be useful without cheating the laws of physics was tricky. Suffice to say, there is no way to run the RCS parts from NFP with this mod for more than a few seconds without a nuclear reactor now, because they ended becoming versions of real electric propulsion with the electrical power they require scaled up by orders of magnitude, for their real counterparts are way too puny in thrust for RCS purposes without high time warp, and RCS with timewarp is impossible. They also received ModuleEngines* through the patch so they  can be used as main propulsion and, most importantly, work with PersistentThrust acceleration under high time warps. I also removed an unreal design choice from these parts and now all electric propulsion have roughly the same diameter because the real way to make an ion thruster more powerful doesn't involve doubling its diameter at all.

Besides some magnitudes power leveling of NearFuturePropulsion engines, resistojet RCS and engines that require no additional mods to be created are included. However, mods that add nuclear reactors are strongly recommended for them. These are much simpler electrical engines that heat a mono-propellant through a resistor coil(AKA heating element) to generate thrust, sort like NTRs but replacing the heat of the reactor with heat from electricity passing through a resistor. There are not many freely available sources about them in the Internet and some sites mix them up with arcjets which are not the same thing at all. The real ones operate with a few hundreds of watts at most. These are either Near-Future or Hard Science Fiction tech and also scaled up to megawatts of electrical power, very high chamber pressures and temperatures only carbides with extremely high melting points could withstand. They are not necessarily better than ion engines or NTRs, it all depends on the mission profile. But for use as RCS, these are way better than any plasma or ion thruster. The choice of RP-1 as fuel for such resistojets might be dubious though, but at the temperatures involved it probably won't leave unburnt residues.

All these things generate a lot of waste heat, and the Stock radiators aren't really designed for this level of power. As seen in the images above, scaled up radiators, in some cases truly gigantic, are also included in this update. There is something about radiators KSP doesn't simulate: the hotter the coolant flowing through them, the more heat a radiator can dissipate, which means a reactor designed to withstand high temperatures and send hotter coolant to radiators would, paradoxically, require less radiators than lower operating temperatures ones. This fact is abstracted in the new patches for nuclear reactors and in these scaled up Stock radiators, which should also have a darker color to match the higher melting point materials they are made of, but until SSTU features radiators with recolors it would be tricky to do this.

The Tech Tree got more changes. Among other things, Ion Propulsion was made more attractive, requiring Nanolathing and Specialized Electrics instead of its previous tech requirements to be researched, which in my opinion makes more sense than the way it is set in Stock and Community Tech Tree. The radiator tech nodes were preserved only to serve as a convenient separated listing of large radiators for the new 100+ MW reactors and now have drastically smaller research point costs because there is not much of a need to "research" radiators at all in the first place if the materials science to build them already exists.

And as finishing notes, a few more SSTU clusters, this time for the unique engines from Cryogenic Engines SSTU doesn't already feature: the RD-0120, the LE-7 and the Vulcain. The long neglected LVT-30 which was utterly useless compared to real engines at its tech level finally was converted in something which could be handy in early game, plus a batch of bugfixes that removed every error involving modified engines from either Stock or other mods, or at least almost all of them, both with and without SSTU clusters.

Edited December 13, 2017 by NotTheRealRMS
Lost images removed.

[Nightside]

@NotTheRealRMS, that ship pictured is awesome. If you can get it into orbit, you should put it up on the OP. Is it a pusher or a puller?

Thanks for your work on this, I haven't had time to play with it lately because of school, but its finals time, so hopefully soon. 

Also, let me know if you'd like help with resizing any fictional/speculative parts mods like MKS (that might not need per part realistic sizing).  I've recently figured out a patch that does a good job of resizing stock-alike parts .

[NotTheRealRMS]

On 12/3/2017 at 4:05 PM, Nightside said:

@NotTheRealRMS, that ship pictured is awesome. If you can get it into orbit, you should put it up on the OP. Is it a pusher or a puller?

The thrusters are located above its center of mass, therefore it is a puller, but it got scrapped because there is a better way of designing nuclear electric propulsion with manned 40+ km/s delta-v and total burn times lasting a few weeks at most instead of months or years: never using more reactor power than what is strictly needed. To that end, it was necessary to add a config for yet one more rescaled Near Future Electrical nuclear reactor: an even bigger, 1 GW reactor with 12m diameter that weighs less than the two reactors from that 1 GW thruster test design, plus a radiator large enough to dissipate its heat if placed in 2x symmetry. As seen here:

Spoiler

Version 0.3.5

https://drive.google.com/open?id=1SrCO1IDak5K3kYy-xi0wNWTDzq-P7fF5

Speaking of big nuclear things, a specific config to rescale USI Orion to the real 10m diameter USAF Orion and change its specs accordingly is in. Recommended payload mass for it is 50 tons, and the changes, supposing the specific impulse specs in its ModuleEnginesFX have influence in the way it actually works, make both the Orion and the Medusa drives vastly more powerful in atmosphere than in vacuum as they should be in reality. By the way, in case you didn't already know, Extraplanetary Launchpad recipes for building nukes for the Orion from USI do exist, so there is a way to build nukes in outer space, which would have very big consequences if this game was a Cold War simulator as well, still interesting anyway.

Now the engines from Near Future Launch Vehicles also are supported. The rescaled Merlin-1D and Merlin-1DV models that otherwise would get in as placeholders for the Raptor are replaced to its models for the Raptor and Raptor Vacuum, its BE-4 and RD-0234 Methane engines got SSTU clusters, real specs and rescales, but the rest of this mod, except maybe for docking port and RCS parts, is mostly redundant with procedurals. By the way, this mod will still use the 2016 Raptor concept for the ITS rather than the less powerful, newer prototype currently under development for the BFR.

It's been a while without checking the layout of the tech tree. After seeing how it was looking like, which was the initial drive for this update, it was critical to rearrange it into something that looks better. Furthermore, the later plasma propulsion tech nodes were too expensive and offered too little for their research costs, for even at 1 GW power levels their thrust still is kind of weak and almost as high Isp gas core NTRs were previously cheaper to research. Thus their R&D costs were slashed significantly. Fusion rockets also have more research requirements than their default ones in Community Tech Tree, which previously made them ridiculously cheap to research for the kind of performance they deliver.

Those are the only new things in this version besides the patch that converts Liquid Fuel/Oxidizer to real Kerosene and Liquid Oxygen being active by default now. There were bugfixes too. A typo in the Aerozine50 upgrade alternative for resistojet RCS parts was corrected, same on mistakenly using "techRequired" instead of "TechRequired" because Part Upgrades for some unknown reason use the former instead of standardized field names for everything and I got them mixed up in the patches of the really big radiators for the nuclear reactors so they wouldn't be placed in the correct tech nodes before.

Fixed a minor detail involving the Open Cycle Gas Core NTR from Kerbal Atomics having 2 ModuleEnginesFX and previously only one of them was updated to use methane instead of hydrogen if the upgrade that did so was chosen. And finally another batch of improvements to the SSTU cluster patches, which is sort of technical, involving "CONSTRAINLOOKFX" and their correct assignment to the SSTU counterpart module which may not have any major, noticeable in-game effects.

Edited December 13, 2017 by NotTheRealRMS
Added screenshot of 1GW Xenon Thruster craft

[NotTheRealRMS]

Version 0.3.6

https://drive.google.com/open?id=1RqY_jNVZR29HYsuDi0ac9clrVyVpgBpx

Mostly bugfixes and a significant improvement in the way ThrottleControlledShutdown.dll behaves for anyone trying SpaceX styled first stage recovery landings or genuinely suicide burns using engines with limited throttle. It won't wait 1 second before running a check on whether the throttle is at 0 or not when altitude is beneath 25 km. The reason this was missed is simply because I did not try landing using an engine that cannot throttle down enough to give its vessel a TWR below 1 before, and with this it should no longer be impossible. Regardless of this improvement, landing using engines unable to throttle down until TWR is lower than 1 remains very difficult unless you use MechJeb or run your own kOS script for it where only coding the script will be difficult and once it's done it can be reused multiple times.

The fixes happened to a few bugs that were missed before, typos in patches, a single part throwing NREs that is not done by this mod directly but by SSTU Expansion + Bluedog DB, one duplicate patch and some small things in most cases, except for the mentioned duplicate patch that had its double removed so it won't multiply entry costs for parts without specific specs in tree.yml to absurdity.

Finally, this mod by itself should be fully compatible with ModuleManager 3.0.1 now, but some of the mods it depends on or recommends may still have patches that won't work correctly in it. I'm still using MM 2.8.1 just in case. Also somewhat important, the bundled Upgrade Editor in this version is the first one that works well enough to be considered "stable", besides issues with part symmetry.

[Mike`]

Hey, thanks for sharing your work with us.

Few issues i noticed in the current release:

1) The I_sp-curve of the M-1 is broken, Vinci and probably all other engines that modify the I_sp of an SSTU upper stage engine are affected aswell. You cannot patch I_sp-curves by just changing key 0 and 1 from the original part, because the part might have more keys defined, like all SSTU upper stage engines (except the J-2) now do. (They now have more realistic curves that do not work at sea level.)

2) In sandbox mode, part-upgrades don't seem to be applied correctly. On first try, none seemed to work. On second try, fuel tank diameter upgrade was applied and thus i could make large fuel tanks, but the upgrades for the MUS, SRBs etc still weren't applied so i couldn't make them large.

Edit: Oh, it seems to be caused by the upgrade editor. Even though i don't see any diameter-related updates in its list for SRBs, toggling the shown "number of segments" updates and after that creating a new srb from the editor panel, diameter upgrades suddenly were available. Weird. Yep. Upgrades apply after touching one available upgrade in the editor, then closing it, deleting the part and recreate it.

3) Realplume-configs for the M-1, LR-87-LH2 and Aerobee Sustainer seem to be broken. The M-1's plume is tiny, the LR-87-LH2 seems to have 2 plume effects, and the aerobee flare is far too far behind. It seems that many if not all plumes are not rescaled to match the increased engine size.

Edit: Removinbg SSTU's original configs seems to fix  the scaling issues. However the M-'1s plume is still tiny, and the LR-87-LH2 has an interesting behaviour, when you use them in a cluster, each of the clustered nozzles has a plume, but there's also a wrong, additional central plume.

4) There still seem to be some errors with the new modulemanager version:

2 errors related to GameData/SRP-0/000_GeneralPatches/RO_General.cfg
1 error related to GameData/SRP-0/Compatibility/RO_RemoteTech.cfg
4 errors related to GameData/SRP-0/Compatibility/FASA/FASA_LifeSupport.cfg
1 error related to GameData/SRP-0/Compatibility/Procedurals/ProceduralAvionics.cfg

5) The fairing on the VA capsule seems to have not been rescaled, while it's fine for the apollo capsule.

6) The MSRB-D1-5 upgrades don't appear in the techtree, even with the old modulemanager version. Trying to figure out what's going on here.

Edit: Seems i found the problem, it's the partIcon used: %partIcon = SSTU-SRP0-ENG-SRBGen seems to not work anymore, once i changed that to SSTU-SRP0-ENG-SRBC the icons appeared again in the techtree.

7) The Procedural Telemetry Unit and Pressurized Procedural Avionics don't have any electric charge, probably because you converted the procedural avionics to use the sstu support tank to store the EC and forgot to adjust the other two.

8) The Tiny Tim SRB doesn't work, somehow the renaming of the ModuleEnginesRF to an FX doesn't work, once i changed the RF to an FX in the original config file the Tiny Tim worked.

Also, your tech tree does not yet contain the new lander tanks, SSTU-SC-TANK-MFT-LV. The old -L tanks will probably be removed sometime soon.

Another problem i noticed is that you can set the diameter of parts to 0.00, which apparently leads to problems at least in the case of the MUS and shouldn't really happen, but that might be an SSTU issue.

Edit: It looks like setting the min diameter to 0.1m instead of 0.01m fixes this. As 0.1m really should be small enough anyways i suggest setting that as a new minimum?

Edited January 4, 2018 by Mike`

[NotTheRealRMS]

Version 0.3.7:

https://drive.google.com/open?id=1iY7tFV7z5NaKU5G4z0hzSWiyQ3MqCg4R

Yet more bug fixes. I tried to fix all reported bugs mentioned above but some of the plumes may still be glitched and something else could have been missed. As for the Upgrade Editor, unfortunately the way it stands now is probably the best I can do. It's likely I won't do much more than recompiling it whenever a new KSP version is released and most mods this one depends upon are already updated for it.

There were some other changes besides trying to get those issues solved. Testing in a late game, finally realized that module upper stages lacked the "Artificial Intelligence" upgrade for RemoteTech which puts an end to light speed lag difficulties and gives a purpose to the otherwise completely empty Artificial Intelligence tech tree node inherited from CTT. Other fixes include scale fixes to some of the very, very large radiators scaled up for nuclear electric propulsion or powerful laser beams for laser propelled spacecraft if there is any mod featuring them. Such a laser would also be useful to melt even the biggest spacecraft because any laser beam powerful enough to propel a photon sail also is an extremely powerful weapon, same on any torchship grade propulsion. 

There was a very important rebalance for heavier dry density tank types in SSTU to ensure they won't be excessively costly and one more tech tree rearrangement from "Meta-Materials" to what hopefully will become full of custom parts based upon the waterskiing spacecraft concept, but I haven't found many yet and given that such stuff would have to be assembled in orbit or in some cases even constructed in-orbit to work, it probably won't exist. As a proof of concept, a copy of the procedural structure from ProceduralParts was made, which config makes it unable to withstand more than 0.375 atm (Extraplanetary Launchpads are required to use it), but its density is incredibly small, likewise the advanced "balloon" tanks in SSTU are supposed to only be reusable in negligible atmospheric pressures and as tension members, but there is no way to enforce that in-game and it's not really worth coding a plugin for.

Without the dangers of radiation poisoning there aren't many applications for such stuff(like a super-lightweight cable keeping an unshielded and very powerful nuclear reactor a very long distance away from the crew), and the only mod that simulates it besides Kerbalism(which I'm not particularly interested at), Radioactivity, seems to be in a hiatus that may be permanent. But whatever, waterskiing spacecraft look unique and cool and there is that.

Finally, after redoing some maths the almost and practically closed loop life support systems added for TAC Life Support in the two biggest SSTU centrifuge habitats now are effectively closed loop, for very, very late game interstellar generation ship designs and alike. Some water will have to be converted into O2 once every year/decade though because of the way real human metabolism works.

*Edit: On the Nanotechnology-grade diameters, I fixed that issue in the proper way: the minimum got increased to 0.05m for convenience reasons mostly, while still being less than the starting 0.1m minimum so the upgrade that changes it has a reason to exist. 0.05m because the "diameterIncrement" setting on SSTU procedurals cannot be larger than 5x such minimum for it to be reached instead of 0 diameter in the Editor when setting up very small parts and a 0.05 diameter increment(meaning the part would only be increased by 0.1m per click max)  would make setting up large diameter parts after applying the nanotech upgrade incredibly annoying.  With this it only takes twice more clicks than before, which might still be bothersome so this particular upgrade is not longer set to be ignored by the bundled Upgrade Editor and can be enabled only on parts meant for a nanoprobe or alike. Forgot to include this in the Changelog.

Edited February 4, 2018 by NotTheRealRMS

[Risa123]

I have a bug delay is enabled but in the flight there is no delay.

[roun1]

I don't think the procedural wings are supposed to be this expensive. Is this a config oversight or some sort of bug?

[NotTheRealRMS]

Version 0.3.71:

https://drive.google.com/open?id=1qTmPpB1cRSrFnFekDOHnopyaCxJLvFtm

 

On 3/6/2018 at 3:45 PM, Risa123 said:

I have a bug delay is enabled but in the flight there is no delay.

Is it in sandbox? There is an upgrade near the end of the tech tree called "Pre-Sentient Algorithms" for procedural unmanned command modules that disables the light speed delay in RemoteTech. All upgrades are enabled by default in Sandbox, so, for that purpose, it's necessary to disable such upgrade.

On 5/20/2018 at 11:48 PM, roun1 said:

I don't think the procedural wings are supposed to be this expensive. Is this a config oversight or some sort of bug?

 

This is based upon the pricing for procedural wings in Realistic Progression Zero, pretty much the same, no changes, and AFAIK such pricing wasn't changed in RP-0 recently either. Finally, the upgrades that give the wings enough heat resistance for atmospheric reentry will increase their cost. Disabling such upgrades when flying subsonic or supersonic planes will lower the cost and in the case of subsonic wings, their dry mass.

 

Now, when it comes to updating to a new version, reading the change logs of the latest patches for KSP and knowing a botnet was added then recently removed from it only due to backlash, I don't really expect any patch that will truly improve the game after version 1.3.1. Besides, the latest official version of Ferram Aerospace Research still supports only KSP 1.3.1. So, a minor bugfix update because of a months long hiatus on anything KSP-related, partly due to getting tired of it and partly due to very pessimistic expectations on what T2 would do. RedShell is not as big of a deal as it would be going Steam-exclusive and forcing DRM in a future patch, trying to shove a real money store in a single player game or paid mods on Steam workshop followed by mass C&D of the free modding community, but it is one first small step towards the direction where such changes are made, or perhaps it was just a test to check how much they could get away with, if so, hopefully they got the message and won't keep trying. Time will tell.

Again, this is the "I just got back to doing this" kind of update, so don't expect much changes compared to the previous version, except for a very important bugfix for the procedural SRBs with upgrades from SSTU. This might be updated for compatibility with SSTU latest version if necessary once FAR gets an update to the latest KSP version. The bundled Upgrade Editor also got a minor fix to one of its MM patches so max segment upgrades for SSTU procedural SRBs will be ignored by it, but that is not important enough to be worth updating its specific thread about.

[Risa123]

No it wasnt .

[NotTheRealRMS]

Version 0.3.8:

https://drive.google.com/open?id=1zhbTzqEeUrlaE_ySYNnmB8-lHn_RCUDE

A more significant update but perhaps not really big. Just fixed one critical bug involving the Raptor methane engines and Near Future Launch Vehicle model swaps, a few other minor bugfixes, and most importantly, fixes and improvements to existing contracts.

More important are the new contracts, both unmanned and manned, for Ceres, Vesta and the five moons of Uranus added in the latest Real Solar System, plus more solar system colonization contracts for the late game, including building a permanent base to extract water and make rocket fuel in the form of liquid hydrogen and oxygen in Ceres(RealISRU is needed for this contract), a permanent manned research base with closed loop life support in Vesta because there would be a point to researching a protoplanet in-loco should technology ever make such a thing feasible, and also contracts for permanent bases in either Triton, Pluto or both that can produce a surplus of life support, rocket and nuclear fuel to resupply future interstellar colony ships. If you're in need of parts for life support, both USI Kolonization and Civilian Population, in addition to the larger SSTU centrifuges which would probably be inconvenient for a surface base anywhere except perhaps for Phobos, Deimos or a random asteroid, feature parts to create artificial biospheres with food production(for water and oxygen any planet or moon with Hydrates or Water is enough, just bring some ice drills) and while the former is focused on USI-LS it nonetheless provides decent enough support for TAC Life Support.

PS: I'm biased against Mars and consider the dubious concept of its colonization,at least in the manned sense of the word, overrated techno-utopian blindness. Any contracts that may be added for it will follow the same theme of the existing "0.01% mega billionaire wants to live in a luxurious Martian manor with a closed loop life support system" one.

 

On 7/17/2018 at 4:36 AM, Risa123 said:

No it wasnt .

 

Check your RemoteTech settings. Whatever the cause, this mod probably isn't the reason for such issue, with one exception: soil sample return capsules bypassed RemoteTech restrictions. Not much more to tell with such extremely limited information.

[CaribeanSoul]

Will playing without remote tech break everything?  I've fallen in love with the CommnetConstellation mod and it only works for stock commnet.  Just curious if I could work around the RT requirement.

[NotTheRealRMS]

Version 0.3.9:

https://drive.google.com/open?id=1lb2EkT4O8d8y2Nwr8_0VxqgRbtOYjb_X

 

Finally, the entirety of the USI Kolonization suite gained the scale it deserves for the Real Solar System. Every part was rescaled from 64% Stock to 100% Real. While the mostly generic mass adjustments may not be perfect, they are completely functional. In the absence of anything real to compare most of this stuff with, they will have to do. With the exception of the Kontainers, which can be used with SSTU through one of the patches in SSTU-OptionalPatches, almost every USI part that comes together with MKS got the RSS treatment. Some of the more noteworthy changes in this include the Microwave Power Transceivers from MKS having their range extended to hundreds of kilometers and a larger version of them with enough range for planetary power grids connected through relays in stationary orbits. The two rovers from USI(Akita and Karibou Expedition Rover) likewise are rescaled. The Skycrane uses liquid methane, with upgrades allowing a switch to hydrogen or even kerosene nuclear electric resistojets, for the latter, that patch to microwave power transceivers can be put to good use.

The previous resistojets using Stock models, as long as the magnitudes increase of the range of those USI Modules for microwave power transmission don't bring unexpected bugs, can be used for Single Stage to Orbit. Also of some interest would be the Methane SABRE engine, which is a smaller, somewhat less efficient but with better TWR(as expected when comparing a methane with a hydrogen engine) counterpart to the real Skylon's SABRE, which also includes an Advanced Jet Engine patch carefully copied then adapted from the one for B9 Aerospace's SABRE-S. The larger inflatable storage module from MKS now uses SSTU modules too. In fact, most Firespitter Fuel Switch modules in MKS parts were replaced with the generally more flexible and easier to edit MM patches for, except for not supporting tank reconfiguration during flight, SSTU alternatives.

Besides perhaps doing some custom patches for the GoingUnderground mod once and if it gets done, this mostly wraps up the MM patches for Colonization components. Now, getting a generic convert every LF/Ox to Kerolox with close enough to real fuel ratios patch done was one thing, but ultimately, it would be a waste to have a generic patch that converts everything to use real fuels instead of generic Liquid Fuel if a complementary and optional RealFuels patch isn't added as well to take advantage of it, yet stuff like defining every fuel mixture precisely sounds like the difference between defining anything crafted from wood on abstracted yet sufficiently varied levels of resistance vs. defining the same like Dwarf Fortress to me. It's not the arguably negligible difference between NTO and MON3 as storable oxidizers, but rather the challenging realism on rocket engines that would require too much reinventing of the wheel to be done without RealFuels, like ullage and limited ignitions, the reason I'm considering to eventually try implementing such a patch. Ultimately, in my opinion, there is a certain threshold of realism past which Orbiter Space Simulator, besides the lack of simple ways to craft custom rockets, will always be a better option than any realism mod for this game could ever manage to be.

On 7/31/2018 at 12:32 AM, CaribeanSoul said:

Will playing without remote tech break everything?  I've fallen in love with the CommnetConstellation mod and it only works for stock commnet.  Just curious if I could work around the RT requirement.

Only realism and maybe some inert modules in part configs from patches that add RemoteTech modules without checking whether it's installed or not. This is most likely playable without RemoteTech, but there are no changes made to stock commnet to accommodate the larger scale of RSS, unless RSS itself has patches for commnet. I never tried commnet so I'm not sure if this would cause issues for unmanned flights.

[NotTheRealRMS]

Version 0.3.9.1:

https://drive.google.com/open?id=1sattXadYjtk3Yla1feovgj2dL2dLGZEt

The custom MM patches added for USI engines were done with a few typos and other small but consequential mistakes. Now they should all work properly, and RealPlume fixes again, I'm really inept at getting those plumes done right, heh. To make this tiny update a tad better, the RO patches for Kerbal Attachment System and Inventory system were adapted because the default masses aren't very realistic, in most cases by being too heavy. That's all for the moment.

Reasons to not do much more include but are not limited to playing KSP less often in general and this being mod then play rather than done for its own sake. For now I did not have another "I really need to improve this" moment -- the rescale and patches for USI parts were the most recent of such moments in this project's development.

[NotTheRealRMS]

Version 0.4:

https://drive.google.com/open?id=1DGJ2pludLBIbKQFSInvtr7RILbyPieJL

A substantial update again. What began as just some Quality of Life changes taking into account the very important detail that KAS pipes do not generate crossfeed, so ISRU bases built using them can be tricky unless some key gasses for ISRU ignore crossfeed, expanded into a little more than that. Aerozine50/NTO ISRU is possible now, but it is tricky because it needs Nitrogen, which means that only in Titan 100% ISRU production of Hydrazine, UDMH and NTO is possible. Furthermore, because it is required for NTO production, Hydrogen Peroxide(HTP) is in too, and therefore, having one fuel type available just for that? Nah, so, with no modelling skills meaning all that can be done is to re-scale SSTU models and improvise, this update brings in, besides several other fancy, near future(sort of) combustion engines, a Sea Dragon inspired booster burning Kerosene and HTP rather than Liquid Oxygen, for a simple reason: while such combination has worse specific impulse, it allows, in addition to some arguably Hard Science Fiction detail in this same fictional engine(it's placed in the final tech node for combustion rockets, so it's not such a stretch), for the design of a Sea Dragon with only a fraction of the original's diameter thanks to such mixture being much denser than Kerolox, and to an upper stage on Methane/LOx in a small part as well. Besides it there were other additions, but in any case, because bigger is better, here a loose try at a "replica" of the Sea Dragon "small" enough for its launch from a conventional launchpad to be practical:

The real deal in these new fictional engines is that all of them were designed for reusable launch vehicles. This example sketch design for 550 tons to LEO is sub-optimal: an optimal Sea Leviathan would be fully reusable and that engine has more than enough power to lift maybe more than 1,000 tons to LEO and still have a reusable first stage, if not all stages. Wish I knew how to do models and textures to really make the concept of rocket engines made of diamonds shine, but I don't.

Furthermore, this update includes some small adjustments to make Kerbal Reusability Expansion work better with the Real Solar System, and some beefed resistojet RCS to also help with reusable stages, if the same won't drain all their batteries before touchdown, because reckless use of resistojets powerful enough for RCS causes that, and putting huge nuclear reactors to supply them with enough power at all times is impractical for anything besides interplanetary manned missions with resistojets instead of NTRs(worse thrust due to reactor mass but less radioactive and better Isp), provided they can be lifted off to LEO by something about as big as a Sea Dragon. And of course a Kerosene/HTP setting in SSTU for the same engine, in addition to Nitrogen tanks if for some reason making Hydrazine/etc in the Moon through ISRU and Nitrogen brought from Earth is a space program strategic objective.

[NotTheRealRMS]

Version 0.4.0.1:

https://drive.google.com/open?id=1mOLcnGyXYqOIdBj3sN9jGznbaPwNcHUS

A series of small improvements and fixes.

There were a few gaps in making patches for Kerbal Reusability Expansion to work better with RSS and FAR such as the mass and cost of the grid fins and lack of FAR support in their part configs, which I found necessary after losing reusable stages using them as control surfaces when trying to land them all the time. Mostly solved now.

The tanks of the lander capsules from SSTU are no longer stuck to a very limited set of fuel types. Just missed that from never having used them a lot before.

Now onto Science Fiction-grade tech, probably(whether such process could be adapted with current technology to work in space or not is beyond my knowledge), to complement ISRU capabilities, a Steam Methane Reformer unit was added. Combined with a Fischer-Tropsch reaction, it adds a new method to produce synthetic kerosene, from methane and water. It's also useful for producing hydrogen, though many RealISRU liquefaction arrays will be needed in any base using it to avoid a serious bottleneck in the cooling of hydrogen to liquid hydrogen. In addition to that, all parts from RealISRU that can adsorb gasses from an atmosphere now support hydrogen and methane as well.

Something like simultaneous Aerobraking and ISRU in Jupiter still is likely folly unless perhaps it's a manned vessel using the VASIMR which does not require liquid hydrogen or methane so it can just dip in, scoop hydrogen to refuel the tanks, burn prograde to a stable orbit again and proceed with its mission. However, realistic VASIMR is really weak in thrust for a manned mission. Orbital stations that temporarily dip in Jupiter's upper atmosphere to scoop hydrogen, then cool it into liquid hydrogen are possible too, but it wouldn't be easy to pull that.

And besides some small fixes, that is all for now.