RKunze

In KSP1, it's called "Final Frontier". That mod is even mentioned here on the first page of the thread, as the inspiration for Wayfarers Wings...

If you are referring to the "metal scar" mentioned by @JoeSchmuckatelli then the star in question is a white dwarf and not a neutron star. White dwarfs are dense, but still formed of "normal" (at least compared to the stuff neutron stars are made of) matter. If you were posing a new question: According to most models, neutron stars have a thin crust of more or less "normal" matter (nuclei and electrons), with the nuclei getting gradually more neutron rich with increasing depth (and pressure), until the pressure gets high enough to force all of the electrons into protons. And maybe the inner core of large neutrons stars may be composed of even more exotic matter than that.

Ah, I see - thanks for explaining. Just tried it out, and the "clean slate" now forces me to explicitly enter all the other necessary fields (author, license, download and so on). And since all those optional mods are actually part of JNSQ and included in the JNSQ zip, they share all of these fields with JNSQ and I'd need to duplicate all of it. So, I think I'll go back to the "crufty" version for $kref to automatically fill in the whole JNSQ info and just manually overwrite the parts that not applicable to the optional mods (should mainly boil down to including an empty "provides")... Edit: Seems to work fine with editing just the relations. Will open a NetKAN PR for the optional JNSQ rescale mods now.

Now that you mention it - should have probably seen that myself... Thanks, will try that! OK. Might do it on the main JNSQ repo anyway later on, because declaring incompatibility with their own "provides" is obviously broken and from the context it's pretty clear that the conflict should be with the EVE config for stock instead. But if I get the optional mods to work without it, there's no need to hack around it in NetKAN itself...

Just tested this by Changing JNSQ.netkan from NETKAN to explicitly list the conflicts (copied from https://github.com/Galileo88/JNSQ/blob/master/CKAN/JNSQ.netkan) Fixing the "EnvironmentalVisualEnhancements-Config" conflict to use "EnvironmentalVisualEnhancements-Config-stock" Generating a new .ckan from the fixed .netkan Installing the fixed .ckan no longer shows a conflict from JNSQ with itself, and allows installation of the optional "Rescale" mods. @HebaruSan should I send a NETKAN PR for this fix? I'll open up a ticket/PR for JNSQ as well, but I'm not sure how fast they will fix the .netkan in their github repo...

I am currently trying to set up CKAN support for the optional Rescale mods included in JNSQ that scale JNSQ to stock size (JNSQ_Rescale_1x) or to real size (JNSQ_Rescale_10x). While testing the .netkan files for those, I encountered something strange that I think is a bug in the .netkan file of JNSQ itself. My .netkan file for JNSQ_Rescale_1x is pretty straightforward (and mostly stolen from GrannusExpansionPack-Rescale.netkan which is already in NETKAN and does pretty much the same for GEP): spec_version: v1.4 identifier: JNSQ-Rescale-1x name: JNSQ Rescale 1x abstract: JNSQ rescaled to approximately stock size $kref: '#/ckan/netkan/https://raw.githubusercontent.com/Galileo88/JNSQ/master/CKAN/JNSQ.netkan' tags: - config - planet-pack depends: - name: ModuleManager - name: JNSQ conflicts: - name: JNSQ-Rescale-10x suggests: [] install: - find: JNSQ_Rescale/Rescale_1X/GameData/JNSQ_Rescale install_to: GameData netkan.exe processes this fine, and builds a .ckan file that looks OK (at least to me): { "spec_version": "v1.4", "identifier": "JNSQ-Rescale-1x", "name": "JNSQ Rescale 1x", "abstract": "JNSQ rescaled to approximately stock size", "author": "Team Galileo", "version": "0.10.2", "ksp_version_min": "1.12.0", "ksp_version_max": "1.12.99", "license": "CC-BY-NC-ND-3.0", "release_status": "stable", "resources": { "homepage": "https://forum.kerbalspaceprogram.com/index.php?/topic/184880-*", "repository": "https://github.com/Galileo88/JNSQ", "bugtracker": "https://github.com/Galileo88/JNSQ/issues", "metanetkan": "https://raw.githubusercontent.com/Galileo88/JNSQ/master/CKAN/JNSQ.netkan", "remote-avc": "https://raw.githubusercontent.com/Galileo88/JNSQ/master/GameData/JNSQ/Version/JNSQ.version" }, "tags": [ "config", "planet-pack" ], "provides": [ "EnvironmentalVisualEnhancements-Config" ], "depends": [ { "name": "ModuleManager" }, { "name": "JNSQ" } ], "suggests": [], "conflicts": [ { "name": "JNSQ-Rescale-10x" } ], "install": [ { "find": "JNSQ_Rescale/Rescale_1X/GameData/JNSQ_Rescale", "install_to": "GameData" } ], "download": "https://github.com/Galileo88/JNSQ/releases/download/0.10.2/JNSQ.0.10.2.zip", "download_size": 2046110130, "download_hash": { "sha1": "174A112588399590A22E1AA4EC2FED04E2691871", "sha256": "7384D08FAB73F4952E37085090039340A31E3481BBB9EFC5E0AE5C737B5E5BE2" }, "download_content_type": "application/zip", "install_size": 68624, "release_date": "2021-11-25T17:42:45Z", "x_generated_by": "netkan" } However, if I try to install this in CKAN, CKAN tells me that "JNSQ-Rescale-1x 0.10.2 conflicts with JNSQ 0.10.2", which is strange. I tried to narrow this down, and I think the problem in in JNSQs .netkan file: JNSQ includes support for EVE, and declares this with a "provides" section: "provides": [ "EnvironmentalVisualEnhancements-Config" ], However, later on, it has the same name in its "conflicts" section: "conflicts": [ { "name": "EnvironmentalVisualEnhancements-Config" }, // ... snip ... ] So, as far is I can tell, JNSQ is basically telling CKAN that it is incompatible with itself. Which - strangely enough - does not prevent CKAN from installing it, but seems to prevent CKAN from installing a mod that depends on JNSQ. I am willing to fix this (I think this should be as simple as changing the "conflicts" , part to conflict with "EnvironmentalVisualEnhancements-Config-stock") but as that part of the .ckan is provided by JNSQs online .netkan file, I am not quite sure how: Do I open a ticket in JNSQ github and hope they fix it? or is there a way to fix that kind of stuff directly via CKAN/NETKAN? I hope someone here can help me with this... PS: If and when this issue gets resolved, I'll create a NETKAN PR for including those optional mods, and most probably an additional one for the GrannusExpansionPack 10x rescale as well.

If you want to try it out as is, just grab the MM_MC-Internal.cfg from current master and drop it into GameData/ProbeControlRoom/ The RevIVA support is implemented as a pure MM patch and does not need special support from the PCR DLL.

@JonnyOThan Just created a PR for RevIVA support. Works in my install with DE_IVAExtensions, KSA and PCRIVAPLUS installed, but adds empty kerbal portraits for the mission control crew - not sure if that is expected RevIVA behaviour or not (and what to do about if it is not). Will definitely need more testing.

I plan to use the same setup phase for both (just different parts of the config node), and do two patches in the patch phase: First patch adds standard PCR support to every probe that has no IVA yet (basically what the current FINAL patch does, only tweakable via the config node). Second patch adds Reviva support to everything that has a PCR IVA but no IVA switch. That should give other mods every opportunity to tweak every aspect of PCR, handles all the tweaking in a consistent way, and should work out of the box with existing IVA mods.

Ah, I think I see what you mean now. I want to set it up so that patching runs in three phases Intitial setup: Just a blank insert of the default config node. "Runs" even before :FIRST Tweak default: that is where every other mod - including the builtin mod support in PCR itself - can either change the default config or any parts it wants to handle itself (or both). Patch: This is where the default config is inserted into every probe part that does not have an IVA yet. This currently runs as FINAL and will probably run as LAST in future (might run as FOR if that works out with existing IVA mods, but LAST is probably safer given that existing mods expect it in FINAL). What we are discussing is the "Tweak" phase - and what's important here is just that everything in the Tweak phase runs before the Patch phase. Actually, there is a "cleanup" phase as well, but that is just for removing the config node again and can run in the Patch phase, after the actual patching is done.

That last is exactly why I wanted to run it as BEFORE - so that other mods can simply copy the snippet. For PCR itself, it does not matter (and yes, it is a bit of a code smell). On the other hand, if the actual patching runs in LAST, the setup stuff of other mods can run in the standard pass as well, since the only thing that matters is that setup is done before patching.

Mostly so that other mods can just copy the setup andcadapt to their own IVA name an description, and do not have to worry about intra-pass ordering by patch name. For the integrated support in PCR itself it doesn't really matter. OK, then I'll change the whole patch procesd to a "setup config/modify defaults/apply" pattern, with setup early and apply in LAST. Should be doable without breaking existing MissionControl IVAs and makes it easier to integrate with PCR in the future.

Ideally, yes - but PCR uses "@PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*]]:Final" to add the internal which is pretty much the opposite of "early". And all modules that I have looked at of that provide alternate mission control IVAs (DE_IVA, KSA and PCRIVAPLUS - which happen to be the PCR-IVA modules in my current game ) expect it to and explicitly add their own IVA version in an earlier pass so that the one from PCR itself does not run... And I don't really want to change that and risk to break things (even though I think the way PCR uses :FINAL is a bit iffy). I think I'll go with a slightly different approach: set up a config node with an IVASwitch module at the start which contains just one subtype with the default MissionControl internal from PCR add subtypes for all mods that we want to support out of the box by modifying that config node in the BEFORE[ProbeControlRoom] pass. Those patches can also serve as a template for other mods that we don't support out of the box that want to hook into the PCR RevIVA support. Copy the (now filled in) IVASwitch module from the config node to everything that has a MODULE[ProbeControlRoomPart] but no IVASwitch module in the LAST[ProbeControlRoom] pass. That should handle any modules that add their own mission control IVA but do not handle RevIVA for it on their own And finally, extend the existing :FINAL patch to also add the IVASwitch module (need to do it here as well, because those parts do not yet have a MODULE[ProbeControlRoomPart] in the previous step).

The problem with that: Longer halflife means less decay, which means less energy from decay per kilogram of RTG, which means more mass to satisfy the energy budget. And "more mass" is not what you want on a deep space probe. Besides, the PU-238 in the RTGs of the voyager probes is still putting out a respectable amount of energy. With an output of 2.4 kilowatt at launch, the three RTGs on board are still delivering more than one KW each (should be quite a bit more, but I'm too lazy to calculate the output after approximately one half of the half-life time). The problem: That is thermal power, not electrical. And the thermo elements that convert it to electrical energy never worked at more than 6.5% efficiency (the 6.5% was the efficiency at launch, and thermo converters don't get better after being in constant use in space for almost half a century). Which means over 90% of the raw RTG energy output is just waste heat.

As far as I can see, ProbeControlRoom does not have support for RevIVA. Yet. I'm in the same situation as @dancingferret and about to cobble up some MM patches to add RevIVA support to ProbeControlRoom - I'll post here as soon as I have something that can be tested. @JonnyOThan: Would you prefer that I integrate the RevIVA support into ProbeControlRoom itself and send a pull request for it once it is done, or should I do it as a standalone Mini-Mod?