RKunze

March 31

3 hours ago, jordanjay29 said:

This is a minor, but significant, mod I'm missing from KSP1

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...

February 27

1 hour ago, Vanamonde said:

Neutron stars are commonly described as being entirely converted into neutrons, but for metals to be present at least some of the surface matter would have to remain in atomic form with protons present and associated with neutrons in nuclei. Is that common for neutron stars? It's not hard to believe but I've never heard it mentioned before. How deep is the normal matter "crust"?

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.

February 18

46 minutes ago, HebaruSan said:

No, it's fine, this is handled by CKAN and common practice for making providing mods mutually exclusive with one another.

Ah, I see - thanks for explaining.

1 hour ago, HebaruSan said:
You most likely want this instead, which will give you a clean slate without all the other JNSQ cruft:
$kref: '#/ckan/github/Galileo88/JNSQ/asset_match/JNSQ\\..*.zip'

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.

February 18

25 minutes ago, HebaruSan said:

That line is wrong. It's causing all of JNSQ's custom definitions to be imported into your mod (except for the ones you're explicitly overriding), including the "provides" property you've quoted, which causes the conflict to be applied to your mod:

Now that you mention it - should have probably seen that myself...

25 minutes ago, HebaruSan said:
You most likely want this instead, which will give you a clean slate without all the other JNSQ cruft:
$kref: '#/ckan/github/Galileo88/JNSQ/asset_match/JNSQ\\..*.zip'

Thanks, will try that!

26 minutes ago, HebaruSan said:

So no, you probably don't need to submit fix PRs to JNSQ or the main NetKAN repo.

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...

February 18

34 minutes ago, RKunze said:

I am willing to fix this (I think this should be as simple as changing the "conflicts" , part to conflict with "EnvironmentalVisualEnhancements-Config-stock")

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...

February 18

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.

February 14

On 2/13/2024 at 2:13 AM, dancingferret said:

Of course I only see the notification after the ReIVA PR is submitted.

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.

February 11

@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.

February 10

7 minutes ago, JonnyOThan said:

This design sounds good. But there is a 4th phase, which is where PCR adds reviva support for all the mods that it knows about. Ideally it does this in a way that makes it easy for other mods to remove it or customize it.

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.

February 10

5 minutes ago, JonnyOThan said:

in which pass though? They have no good way to control when they run compared to that patch.

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.

February 10

56 minutes ago, JonnyOThan said:

Im not sure but I think you might be misunderstanding how the patch ordering works. BEFORE[ProbeControlRoom] runs immediately before FOR[ProbeControlRoom]. It’s a bit of a code smell for a mod to be using BEFORE or AFTER for its own identifiers. Those specifiers are most useful for *other* mods to insert patches immediately before or after some other mod that they interact with.

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.

February 10

10 minutes ago, JonnyOThan said:

Why BEFORE and not FOR

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.

16 minutes ago, JonnyOThan said:

Yeah, I'm basically proposing we invert that - at least as long as Reviva is installed, because the whole point of the ordering here is to not step on the toes of other mods that might want to be adding their custom control rooms.

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.

February 9

On 2/8/2024 at 11:26 PM, JonnyOThan said:

I think the best way to do this would be to add the reviva and b9ps modules alongside where it adds the INTERNAL node. And ideally that would be in a pretty early pass.

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 :cool: ) 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).

February 9

40 minutes ago, darthgently said:

If anything, Voyager-1 has made an extremely strong case that any future extra solar probes should have an RTG isotope with a much longer halflife

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.

February 8

On 12/31/2023 at 9:14 PM, dancingferret said:

I'm assuming you should be able to use RevIVA on the probe cores just like on manned pods, but it doesn't show up.

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?

November 28, 2023

28 minutes ago, sevenperforce said:

But if you had a large space-based power generation array that was collecting many thousands of square meters of sunlight and beaming it directly to individual vehicles, that might work.

It might work technically, but you definitely don't want to. Because concentrating multiple megawatts (i.e. what you get from "thousands of square meters of sunlight") on a couple of square meters (the size of an individual vehicle) results in an energy density that is way out in instant death ray territory...

November 27, 2023

1 minute ago, darthgently said:

That is over a 30% difference. When has a 30%+ efficiency increase ever been considered insignificant by any power engineer?

When taking advantage oft it means you have to pay way more than for just building and running 30% more generators...

Don't get me wrong, there's a lot of interesting stuff that could be manufactured in orbit zero g. But running data centers in orbit is just plain stupid because you can do it easier and cheaper down here.

November 27, 2023

3 minutes ago, darthgently said:

Errm, the dark period is far shorter in LEO than 12 hours.

Yes. Thats why you only need the energy storage on the ground.

5 minutes ago, darthgently said:

The atmospheric loss is very significant

Not really. 1350 W/m² above the atmosphere vs around 1100 at sea level.

7 minutes ago, darthgently said:

What if every next gen Starlink sat had big compute and storage capability on board?

They'd overheat because cooling things in space is hard and computing generates lots of waste heat, and they'd lose stored data like crazy, because at compute center storage densities, every cosmic ray particle that hits the storage hardware flips several bits at once...

November 27, 2023

1 minute ago, Hotel26 said:

Split the difference then: keep it on Earth and power it with nuke. That would be the scientific solution

If you want to use the most expensive way to generate the needed electrical energy, go ahead.

There's a reason almost nobody is building commercial fission power plants anymore. Those things are just too expensive to build, to expensive to run, and too expensive to get rid of after they go out of service...

November 26, 2023

5 hours ago, darthgently said:

Also putting compute resources in orbit powered by solar (or nuke) is another interest as the projected power requirements for where computation demand is going would put a big strain on terrestrial generation.

Errm - no. If you can power a computing center from solar cells in orbit, you can just as well power it from solar cells on earth. You just need a bit more than double the cell area (double because it's night approximately half the time, and a bit more to compensate for atmospheric loss) and a bit of energy storage (if you put the thing somewhere dry near the equator, 12 hours worth of storage is enough). The added costs for more cell area and energy storage are more than compensated by not having to launch those things to orbit, not having to launch either a repair crew or a replacement computing center to orbit every time some of the hardware breaks down, and not needing extra expensive radiation hardened compute hardware (to keep said hardware from breaking down immediately) and sophisticated radiator arrays (to keep the whole thing from overheating).

November 23, 2023

1 hour ago, JoeSchmuckatelli said:

I commented in another thread that the move fast and break things method might be difficult to justify when using public funds...

Well, politicians (on both sides of the pond) are pretty good at justifying spending public funds, even for basically no results. They probably could come up with a justification for it, if they wanted.

1 hour ago, JoeSchmuckatelli said:

I don't know how similar to the US traditional aerospace industry is the European industry

Not that much different. Big, fat, multinational behemoths that get a big portion of their money from public funds. Yo have the ULA and Boeing for that, we have Arianespace and Airbus. Main difference is the history (the US aerospace firms started out as private enterprises that grew into multinational behemoths by swallowing up competing enterprises, while the european version has been constructed that way on purpose by the EU member states) and the main way of getting public money to them (the military in the US, EU grants in Europe).

November 21, 2023

@Gupyzer0 In https://github.com/Gupyzer0/SkyhawkScienceSystem/commit/bdf729241294c6c3a4851ef32d0474e88bf22fee, you remove the "sss_SoundingRocketCore" (same model as bluedog_ThorAble_Guidance, but nerfed to serve as an intial pod for very simple souding rockets). If you don't have Taerobee or another of the very early rocketry mods installed (like me, as I already have way too many mods), this means that you don't have any probe cores at the start node, which makes for a short and boring game :cool:

I suggest to put the "sss_SoundingRocketCore" back in. If you don't like having the "sss_SoundingRocketCore" when better alternatives are available, maybe do it conditionally depending on whether Taerobee, CNAR, US Rockets or another supported mod with tier 0 sounding rockets is installed...

November 20, 2023

24 minutes ago, adriangm44 said:

How can I find the conflict with this file?

2 Errors related to GameData/SkyhawkScienceSystem/Patches/TankSwitch/TankSwitch.cfg

Have a look at $KSPDIR/Logs/ModuleManager/MMPatch.log - that should have details about what went wrong where (search for the string "ERR" in that file to find the relevant entries).

Edit: Just had a look at the git history for Patches/TankSwitch/TankSwitch.cfg, because I don't have problems with that patch. Turns out that I have the fixes from https://github.com/JonnyOThan/SkyhawkScienceSystem/tree/JonnyOThan-patch-1 installed. That is quite probably what is going wrong with your install as well.

November 20, 2023

3 hours ago, Gupyzer0 said:

I also have a pull for SkyhawkScienceSystem that includes the newer BDB parts of V 1.12 and 1.13 as the original repo doesn't include them. I'm currently working on the tech tree and added a new branch so I'm still working on it, get it here -> https://github.com/Gupyzer0/SkyhawkScienceSystem I know some of the nodes overlap, but I'm still working on it., trying to make a more balanced approach to the location of some of the BDB parts.

Great, thanks - pulled it into my current game right now. Saves me the work of integrating the BDB 1.13 changes myself :-) (Edit @Gupyzer0 I just pushed a version to https://github.com/rkunze/SkyhawkScienceSystem that integrates both your changes and those from @JonnyOThan's outstanding PR on the original repo).

And for all of us hardcore SkyhawScienceSystem fans, just in case you did not know already: Both SkyhawkScienceSystem and SkyhawkKerbalism work great directly from a git worktree in you GameData dir - basically, just change to GameData and do a "git clone" for the repo. Makes it very easy to stay up to date, even with patches from multiple other repos (just add their repo as a remote and fetch/merge from there).

31 minutes ago, symphons said:

My issue with janitor's closet is it simply stops the part from showing up, it does not stop the part from loading or consuming memory. You can do the option of "permanent" in janitors closet, but the author does state that it could be game breaking.

I use the "permanent" option. And it is only game breaking when you prune a part that you already used in one of your builds (and even then, just un-prune the part to get it working again). Basically, the "permanent" option just renames the part config files to something the game doesn't recognize as a config (same as you would do manually), but it gives you a nice UI to manage all the stuff.

What I'm doing (when playing career, but that's pretty much all I'm playing) is basically:

decide which parts I want to use from a certain node and "buy" them (I'm playing with the initial fee to use a part)
Hide the parts I did not "buy" from the VAB (just to declutter the parts list)
Occasionally perma-prune all the parts in older tech tree nodes that I haven't used so far, especially when new and better parts with the same functionality come up.

November 20, 2023

41 minutes ago, symphons said:

Little hesitant to start pruning to much off BDB since the tech tree literally has it as a dependency. But on the other hand, I don't know anyone who keeps all the parts.

I'm using The Janitor's Closet both to declutter the VAB parts list and to (reversibly) prune parts when I'm mostly sure that I don't want to use them (to cut down on load times and memory pressure - my laptop is barely handling the load for my current KSP setup even with the pruning).

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by RKunze