PocketBrotector

I'm not a Kerbalism user myself so I can't comment on how (if at all) it would interact with SpaceDust, but this is actually expected for normal use of the telescope. If a given resource is present at a body and you target & scan that body with a telescope that has the relevant detector, you will get notifications after a few days or so that a resource band has been discovered and then identified. If that resource is absent at that body, unfortunately the telescope will keep on scanning it indefinitely. (Apparently kerbals can't prove the absence of something.) I believe you need a fixed version of Dust Bunnies for full compatibility between Space Dust and JNSQ. And regarding the presence of particular resources at particular bodies...

Indeed, this is exactly what System Heat does when the relevant extra(s) are installed.

Make sure you have System Heat installed along with the optional patch that integrates NTRs from KA with SH.

You may want to check out Dust Bunnies which I believe covers liquid methane along with several other resources. RSS support on the other hand is entirely new as far as I know, so that would surely be welcome for folks who use SpaceDust in RSS.

This sounds like it would be more suited to ask on a USI thread. CryoEngines and CryoTanks don’t add any resources themselves if I recall correctly - they instead make use of existing CRP resources. So your question is primarily concerned with USI mechanics.

I can add some comments about a couple of other options here. These are based on trying to fire off probes to Moho in the first couple of days of a new game, when the “zeroth” transfer window is just closing. MechJeb seems ultra precise in calculating exact windows and transfers. Transfer Window Planner seems reasonably close to MechJeb and probably has the nicest interface for planning in-game. I haven’t verified whether it works perfectly with KAC (or the stock alarm clock) to generate alarms, and this might depend on the exact combination of mods and versions in use. (Since TWP was made by the same author as KAC, I suspect KAC’s built-in transfer alarm calculator is similar is similar to TWP, though perhaps less precise.) The browser-based transfer planner in my signature seems to match the in-game Transfer Window Planner well enough to plan dV budgets and departure schedules. I haven’t confirmed if the TWP mod or browser-based planner are accurate enough to generate precise maneuver nodes that don’t require additional correction, but it seems like players have quite a few options overall between the various mods and tools to find one that they like or is at least “good enough”.

Nice - it's good to have working versions of curios and relics such as this. I noticed that most of the country flags from the original mod are missing from your Refilled version. It would be ideal if these were included for the sake of completeness - arguably they're more useful than the soccer balls themselves. Also I'd recommend hosting this on GitHub, which would facilitate any long-term maintenance needed.

Is there any way to have kerbals start EVA with their visors down? I tried the below based on the API docs but no luck. @PART[*]:HAS[@MODULE[KerbalEVA]]:FINAL { @MODULE[KerbalEVA] { %lampOn = true // helmet lights %isVisorEnabled = true // doesn't work } @MODULE[ModuleColorChanger] { %animState = true // Breaking Ground Future Suit stripes } } My guess is that this doesn't work because unlike helmet lights, visor status is stored in the sfs (under "hasVisorEnabled"). And while the main settings menu allows the user to toggle whether kerbals start EVA with the helmet and neck ring on or off, it doesn't provide such an option for their visor.

Does anyone know how CustomBarnKit interacts with the new kerbal hiring cost formula in KSP 1.12? The new cost progression is a welcome change as hiring costs inflate much more slowly rather than immediately spiraling out of control. But I haven't seen any discussion of how hiring costs are now calculated, and whether it's compatible with the variables that are set up CustomBarnKit.

I think the files are available in this post:

This keeps the ugly Squad part and hides the nice-looking Restock part, which unfortunately is counterproductive since having nice-looking parts is the point of installing Restock. Ideally the Restock appearance will be applied to the Squad part at some point, but until that happens the arguably "better" solution is to use the Restock part and just ignore the Squad part.

v0.2.3 release Added support for KSP 1.12.2+ overhauled versions of the Reliant and Swivel Dropped support for old PartOverhauls mod

Heya - wanted to inquire about whether this is still on your radar to be addressed. (Or, for that matter if this was already addressed - I've been taking a break from KSP for most of this year, but I didn't see it mentioned anywhere in the changelogs.) If no fix is planned, may I suggest adding metadata to CKAN so that KerbalRenamer is listed as a known incompatibility for Snacks?

That zip file is still not available.

Does this support other mods that add solar panels?? Clearly it should be beefed up using regex... something like: @PART[*solar,solar*,*solar*] { @title ^= :Photovoltaic Panel:Soiler Panel: @title ^= :Solar Panel:Soiler Panel: }

If anyone here would like to try out SpaceDust configs for GEP, you can test it here. Feedback appreciated.

If anyone here is using Grannus Expansion Pack and would like to try out SpaceDust configs for it, you can test it here. Feedback appreciated.

I think it's just the Emancipator, which is the only open-cycle engine in KA. (That's why it consumes Enriched Uranium as a secondary propellant.) All the others are probably dangerous to stand near, but shouldn't be dumping fallout into the atmosphere.

@JadeOfMaar's compatibility explanation from the Rational Resources thread:

If anyone is trying to figure out which engineers to send to their construction base: Here, have a productivity calculator! (Obviously, this is most useful if you have a spreadsheet of your full astronaut roster...)

Ok, thanks for your reply. I thought this was probably the case and did not mean to "blame" KK as such. It seems like the way that KSP handles destructible buildings is appropriate when there are only a couple of dozen total at KSC, but perhaps starts to become problematic when there are many hundreds of them across dozens of space centers and airports, as there are in JNSQ. The scene change load time is actually a potential concern for me as I run lots of simultaneous missions around Kerbin and its moons, so I am switching between scenes frequently. There's also a lag time associated with loading saves as KSP has to parse every sfs file to generate corresponding loadmeta files. But I recognize this all adds up to a corner case.

During an effort to track down sources of savegame bloat, and possible related performance impacts, I've noticed that ScenarioDestructibles comprises about 20% - 40% of the number of lines in my persistent.sfs file. (In my current savegame it's about 73k lines, and in a previous game it had bloated up to 223k lines). I presume this is from the numerous destructible buildings that exist in JNSQ with KK. Is there any conceivable impact from having all of this virtually unused data in my savegame? And would there be any upside or downside to deleting it?

While looking through my save file for something unrelated, I stumbled upon the likely reason for this. (And looking back through my posts in this thread, I think I had the same issue, for the same reason, back in 2017, but never found out why until now.) SnacksScenario is full of stock kerbal names ("Xyz Kerman"). But I'm using KerbalRenamer, which means my kerbals aren't using those stock names (instead e.g. "Jane Doe"). I'm guessing that the Snacks tracking data is generated for each kerbal before KerbalRenamer intercepts them and renames them; then Snacks loses track of them and they stop eating or getting hungry. Or something along those lines, anyway. @Angel-125, is there a good way around this issue?

Try adding curly brackets at the end of each line: !SPACEDUST_RESOURCE:HAS[#body[Jool]]:NEEDS[GPP]:AFTER[SpaceDust] {} Once you get that working, you can start writing configs for GPP's other bodies as desired. I'd recommend ensuring compatibility with SpaceDustBunnies as well, since that adds more resources to more planets/scanners/harvesters.

It's definitely possible, and has been done for OPM and JNSQ but not (to my knowledge) GPP, yet. Check out SpaceDustBunnies for those examples. Unfortunately the example that you offer is kind of an unusual case... I believe the homeworld in GPP is still referred to internally as "Kerbin" but displayed as Gael (I think this is due to engine limitations). I'm not familiar enough with GPP to know what, if any, issues this may cause in mods expecting a stock installation, as SpaceDust does. At game start the homeworld is supposed to look like this image from the release album. (Spoiler alert: the "?" resource pictured at high altitude there is the discovered-but-unidentified antimatter in the Van Allen belt.) If it doesn't, then there's not native compatibility with GPP for the homeworld. And since GPP uses different bodies with different names from stock for the rest of the system, you'd definitely need custom configs for those as well.