PocketBrotector

@Snark , I'm getting some exceptions from BCA in KSP 1.11, accompanied by heavy UI lag in the VAB whenever a crewable part is added. KSP.log Video of issue My crew assignment configuration: //Default all crewable parts to empty by overwriting BetterCrewAssignment’s configurations @PART[*]:HAS[@MODULE[ModuleCrewAssignment]]:FINAL { @MODULE[ModuleCrewAssignment] { @defaultAssignment = Empty } } Mod list: Please let me know if there's anything else useful that I can add to my report. Thanks!

It looks like LqdHe3 doesn't appear on Kerbin, Mun, or Minmus with RationalResources. This has considerable consequences when trying to use e.g. FFT with JNSQ. It looks like there are a few different things at play here... FFT includes its own overrides to CRP for LqdHe3. These are specified at both the planetary and biome levels but appear to be oriented towards stock and RSS systems, so there's limited compatibility with other systems (JNSQ, GEP, etc.) Rational Resources then culls and overrides everything before it (at this point that's both CRP and FFT, since FFT doesn't include "tag = spared" or similar anywhere). Rational Resources isn't set up to place crustal LqdHe3 anywhere on Kerbin or its moons. In particular the config for Mun includes an entry for LqdHe3 but it lists "PlanetName = None" - I'm guessing this is not intentional. I imagine there are a few different ways to address this, but I don't know what solution would be preferred in order to maximize compatibility between various combinations of mods. Edit: Here's what I'm using to spare FFT's distribution and convert it to use JNSQ's biomes. Seems to work pretty well.

I'm inclined to say yes if this will improve the mod long-term. Less painful to do so when the mod is relatively young and fewer people will be affected. The release notes will warn users of a potentially breaking change.

I know that the people who use JNSQ may be very interested to hear about the latter feature...

FE is highly configurable so I think one would be able to set up a category that includes most of these checks and captures deprecated parts regardless of how they were deprecated. That way even if a mod that has not been maintained in a long time and uses some old, subpar deprecation style, its deprecated parts would show up in the filter.

I'm sure I'm not the first one to notice, but the extra metal textures for SSPXr are quite nice for a Jamestown recreation. I could probably make this a true replica instead of just a "reinterpretation" if I borrowed some engines and greebles from BDB, but my RAM wouldn't like that very much.

The newer v0.3.3 release of SpaceDust seems to work ok with Bunnies installed. I say "seems" because I presume that Bunnies' configuration issues to which Nertea referred haven't been fixed, but SpaceDust itself was updated so that they don't outright break everything. I've confirmed that scanners and telescopes work now with Bunnies installed (i.e. I can discover, identify, and display resource bands, and telescopes correctly animate). But I haven't figured out what the config errors are in Bunnies, or what (if any) gameplay impact they have. If I do I'll probably submit a PR to fix.

Been playing with this today, and while the parts look very cool, I'm not sure everything is working as intended for me. I have both SpaceDust and SpaceDustBunnies installed alongside JNSQ and RationalResources; NFP is installed but I haven't installed FFT yet. I sent a gas scanner into 300km polar orbit to see what I could discover around Kerbin. However, it says it is disabled even when it is enabled: The telescope has two slots available to scan twelve different resources, so naturally I stuck six of them inside a 5m fairing so that I could scan all resources at once for a given body. However, most of them display one or zero spectrometers when surveying, and most also don't open when activated: Log file. Please let me know if there's anything I can do to troubleshoot - thanks.

Happy New Year! I've been wondering what type of material KH's RadiationShielding might represent - partly out of curiosity, but partly so that I can plan how it might be manufactured in-situ using Extraplanetary Launchpads and/or RationalResources. (Both mods have their way of producing non-transferable resources in the right place - Recipes for EpL, and Blacksmith for RR.) The literature that I've seen commonly cites hydrogen-rich plastics such as polyethylene as an effective shielding material. Is it reasonable to assume that RadiationShielding is polyethylene or something like it?

The CelestialBodies pdf and dV maps included with JNSQ are probably the best resources. Or you could pull raw values directly from the cfg files. I also recommend the transfer window planner in my sig

You beat me by two hours... though I imagine several of us all discovered this independently. Mine is only 73 bytes though!

I agree that this should be implemented. Now that in-flight construction is possible, the first thing I wondered about it was "how can I extend the inventory and propulsion limits of an EVA kerbal"? Command seat-based craft are the obvious choice, whether that's on the surface (rovers) or in orbit (MMUs).

Everything in RS+ that is disabled by MH is basically duplicative of the MH parts. If you use RS+ with MH, it will make your MH parts look better, which may make you like those parts more. Try it and see.

Is there a way to transfer resources to/from parts that are in cargo? This behavior breaks when kerbalEVA is patched to use a propellantResourceName other than "EVA Propellant". In some ways this is actually a good thing (we don't need the EVAfuel mod to stop the unlimited free magic refills of jetpack propellant) - but I don't see that it leaves any way to refuel jetpacks or extra canisters.

You probably don't want to, since they will appear identical to the Making History engines you already have installed. If you really insist, you could find the part config for each and delete "MHReplacement = True".

Your parts list indicates you have Making History installed. Those engines you listed have a note next to them stating they are disabled when Making History is installed. Instead of separate engines, you get better-looking versions of the corresponding MH engines.

Looks like this was suggested back in 2018... It seems like certain part actions have been arbitrarily left out of the action group assignment system. Surface scanners, for example, can't scan the surface using an action group... instead you have to play "track down the tiny click target" every time you explore a new biome.

Looking at how Kerbalism accomplishes this, I see that the propellant type is defined (and modified) in the kerbalEVA config. So like the other parameters, you can override it but it will affect every kerbal in the universe - no variants allowed. You’re probably right that jetpack variants would have a niche purpose, but that’s exactly why the parameters should be exposed. Modders who are interested would be able to access them without unwanted effects to “regular” jet packs. @Starhelperdude has some nice ideas above. I’m also interested in a semi-realistic version that’s suitable for spacewalks without being so super-powered that it can also be used for e.g. Minmus landing/ascent. I imagine there’s also the possibility of an atmo-optimized version, or more fancifully, a pack that has air intakes and fans or true jet engines for atmospheric flight.

1.11 introduces the EVA jetpack as a discrete, removable/swappable part, which is an improvement in customizability over the old system where it was built directly into each kerbal's EVA suit. However, most of the jetpack's characteristics (linear and rotational thruster power, propellant consumption rate, etc.) is still specified in the kerbalEVA config rather than the jetpack config. It would be good if these were part of the jetpack rather than part of the kerbal, as this would open up the possibility of customized, specialized jetpacks in mods or stock: Different jetpacks could have stronger or weaker thrusters. Want to fly on Tylo? Or maybe you want more realistic thrusters that are only good for maneuvering in microgravity? Different jetpacks could have different effective specific impulses, and/or different propellant capacities. We could specify that a jetpack uses a fuel other than generic "EVA Propellant," e.g. Nitrogen or another realistic cold-gas resource from CRP. All of these factors together, along with total jetpack mass, could provide multiple EVA propulsion systems with different capabilities. This in turn can be used to provide more interesting choices when planning mission architecture, etc.

Just to clarify, what is meant by "new scatterer" here? Is that v0.0722 specifically, or some other version range? I don't mean to sound dense, I just want to make sure that I'm not accidentally inviting trouble by mixing potentially incompatible versions of different mods.

I think that this was an intended feature in the extreme early days, which is why command pods contain an amount of monopropellant too small to be useful for docking. I don't remember that it was ever implemented in stock, though.

Nah it was massless before. The new system is definitely an improvement. Fair point about the density, though I don’t think we’d get realism or consistency regardless... real-world MMUs provided 25 m/s of dv using cold nitrogen gas, while the ones in KSP gave upwards of 600 m/s using their magical propellant. I don’t know if the new EVA propellant has an assigned volume value, but if it’s 5L/unit like the other stock fuels then I don’t know where the backpack has room to store 25L of it... best not to look too hard under the hood.

I'm using KSP 1.10.1 with the newest Near Future mod suite. According to the version files and CKAN, this should be fine, but actually this is Fine. Parts that have had ModuleCargoPart added to them can't be clicked in the VAB and suffer from severe z-fighting if they have multiple variants available. I created and tested a quick and dirty hotfix and it appears to fix the problem: @PART:HAS[@MODULE[ModuleCargoPart]] { !MODULE[ModuleCargoPart]{} }

Looks like that patch makes changes to parts based on their manufacturer name. In the case of NFLV, the manufacturer is Post-Kerbin Mining Corporation, so try creating a config file with the following: @PART:HAS[#manufacturer[Post-Kerbin?Mining?Corporation],!MODULE[ModuleB9PartSwitch],@RESOURCE[LiquidFuel]]:NEEDS[B9PartSwitch,RationalResources,!ConfigurableContainers/Parts,!ModularFuelTanks]:BEFORE[RationalResourcesSquad] { refVolume = #$RESOURCE[LiquidFuel]/maxAmount$ @refVolume += #$RESOURCE[Oxidizer]/maxAmount$ !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} MODULE { name = ModuleB9PartSwitch moduleID = RRStockSwitch switcherDescription = RR Fuel switchInFlight = True baseVolume = #$../refVolume$ } } If that works, you can do the same for SpaceY by changing "Post-Kerbin?Mining?Corporation" to whatever manufacturer name is used for SpaceY tanks (substitute spaces with "?").

@JPLRepo Does Glykerol have a presumed volume (liters per in-game unit)? The resource definition in CRP does not define it. I was trying to figure out if it was more like typical stock resources (5L/unit) or most CRP resources (1L/unit)... but if the density of Glykerol (0.012 metric tons per KSP unit) is similar to real-life glycerol (1.261 kg/L), then it would be 10L/unit. Having a defined volume for glykerol would facilitate adding tankage for it to parts in other mods. Thanks! Edit: Found some clues regarding the original design/intent back in ~2014... Evidently it's supposed to be 1L/unit (five liters per freeze) but also one-tenth its implemented density. Want me to submit a pull request to CRP?