[Feature] KSP2 support plans

[HebaruSan]

Motivation

KSP2 has been announced:

• https://forum.kerbalspaceprogram.com/index.php?/topic/187313-we-are-excited-about-kerbal-space-program-2/
• https://forum.kerbalspaceprogram.com/index.php?/topic/187315-kerbal-space-program-2-master-post/

This raises the question of how CKAN should handle the sequel. I'll assume for now that we want to index mods for it and will be able to do so. (If we decide we want nothing to do with KSP2, or if we can't due to some hypothetical exclusive deal with Twitch, then that's obviously far simpler.)

This is a WIP issue to track discussion and hash out a concrete plan. Please reply with further thoughts, considerations, etc.

Questions

• Will mods still work the same way? Unzip files into a folder like GameData?
• How can we determine the installed version? Is buildID.txt still there?
• Will KSP1 ever release a 2.0 version within its numbering scheme?
  • 1.9 will be followed by 1.10
    https://forum.kerbalspaceprogram.com/index.php?/topic/193978-kerbal-space-program-esa-110-update-sharedhorizons/
  • 1.12.3 is the final update of KSP1

Issues

• Shouldn't have to download 20+ MB of metadata for KSP1 that you'll never use (see Proposal: Introduce CKAN-meta-Legacy #1975)

Tasks

Client updates to support the new game:

• Version detector
• Game folder paths

Infrastructure:

• Split NetKAN metadata into NetKAN/KSP1 and KetKAN/KSP2 subdirs?
• Split CKAN-meta somehow so you only download the metadata you need

[politas]

We already had plans to split CKAN-meta up to lower the download burden. I'd like to see a system where there is a separate metadata file for each major point version, downloaded according to KSP version compatibility settings and merged as required. That would make supporting KSP 2 pretty seamless.

[techman83]

There is an unmerged branch in the old bot where I came up with some logic for this. That was extendable based on some JSON config. It will need a slight re-think, but I reckon we could come up with something with the new architecture (though we've got a bit of a backlog to clean up and get merged in).

[HebaruSan]

New timeline from the devs:

https://forum.kerbalspaceprogram.com/index.php?/topic/210187-kerbal-space-program-2-release-into-early-access-feb-24th/

• 2023-02-24 (time of day unknown)
• $49.99 (subject to change by vendors), to be increased for 1.0
• Early access
• Windows-only (Mac and Linux on the "extended roadmap")
• Missing most of the big headlining features originally announced (still in progress, to be added when ready)
• From Steam, Epic Games, and KSP store

Players may be expected to treat this as a full release in terms of expecting CKAN support. So we'll probably have to cough up fifty bucks to keep up with that, unless we can get onto some kind of closed beta team.

[sundhaug92]

Could it be an idea to rewrite the history on the metadata repo so that you have one branch for each game? Then you could do a dumb pull to get the refs for each branch and only download the data for each. Could also move older versions of mods to a separate repo.

[HebaruSan]

Summary of current situation:

• The game supposedly has an incomplete built-in mod loader that doesn't actually run the mods yet
• To work around that, there are two third party mod loaders competing for early internet fame and glory
• Supposedly mods using the built in loader will have to be packaged in Unity addressable asset bundles, so ZIP files may or may not still be viable for distribution (the third party ones look like they allow loose files put into specific folders)
• The built in loader parses a new JSON mod info format, which Netkan might be able to scrape for metadata (if we can figure out how to peer inside Unity addressable asset bundles)
• There have also been reports of an in-progress built-in list of mods, which some people are comparing to CKAN, but it's not clear whether they know about all the behind the scenes stuff that CKAN does to maintain the mod metadata or whether the game's devs plan to take on that challenge
• There are some rough early mods already on SpaceDock:
  https://spacedock.info/kerbal-space-program-2/browse/top

It should stabilize significantly once the official mod loader is completed and released.

[HebaruSan]

A user donated me the game!

• There's no buildID.txt; the main folder contains only:

  • KSP2_x64.exe
  • UnityCrashHandler64.exe
  • UnityPlayer.dll

  That's a problem for selecting a file to add an instance and for determining the game version. I don't see any fallback sources for version info, either.

• There's no GameData, consistent with the bundle thing

[HebaruSan]

The KSP2_x64.exe file has the version info in the Properties window:

This might be how to access that programmatically (not tested yet):

• https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.fileversioninfo.getversioninfo?view=netframework-4.7.2

I'm going to call that a silver lining; it's potentially a lot nicer than having to parse buildID.txt or a readme file. We won't have to maintain a builds.json file!

[HebaruSan]

Of the mods currently on SpaceDock, 3 use BepInEx and 10 use SpaceWarp.

They install mods at:

• <GameRoot>/SpaceWarp/Mods
• <GameRoot>/BepInEx/plugins

So if we try to support these, we'd effectively need to have two replacements for GameData.

Of course, we'd also need to be able to install SpaceWarp and BepInEx themselves, into:

• The game root
• <GameRoot>/SpaceWarp
• <GameRoot>/BepInEx

[HebaruSan]

Wow, that more or less works!

[HebaruSan]

Oh lovely, SpaceWarp and BepInEx have a file conflict! They both want to create <GameRoot>/doorstop_config.ini, with different, conflicting contents (excerpts only here to show up to the target assembly arguments):

[UnityDoorstop]
# Specifies whether assembly executing is enabled
enabled=true
# Specifies the path (absolute, or relative to the game's exe) to the DLL/EXE that should be executed by Doorstop
targetAssembly=BepInEx\core\BepInEx.Preloader.dll

# General options for Unity Doorstop
[General]

# Enable Doorstop?
enabled=true

# Path to the assembly to load and execute
# NOTE: The entrypoint must be of format `static void Doorstop.Entrypoint.Start()`
target_assembly=SpaceWarp/Core/SpaceWarp.dll

So if you try to install both manually, presumably only the second one you install will work. And CKAN would just barf during the second install, if these were both CKAN modules.

[Grumalg]

Scroll down to a post by rofl47 discussing a possible solution. BepInEx seems to have a SpaceWarp loader inside it. Mixed results in following posts below, but it might lead to something...
https://forum.kerbalspaceprogram.com/index.php?/topic/212355-bepinex-for-ksp-2-adding-modding-support-to-the-game/

[HebaruSan]

I guess if these were to be added to CKAN metadata today, we'd:

• Index BepInEx as-is
• Index BepInEx Space Warp Plugin with BepInEx as a dependency and call it SpaceWarp
• Ignore the standalone SpaceWarp (which is currently the most downloaded file for KSP2 on SpaceDock by a factor of ~2.5), since it conflicts with BepInEx

[HebaruSan]

@techman83, after hacking on this for a couple of hours, I think we should createhave created two new repos:

• https://github.com/KSP-CKAN/KSP2-NetKAN
• https://github.com/KSP-CKAN/KSP2-CKAN-meta

This creates a nice clean separation between the two games. Then we should be able to configure new instances of the Scheduler, Inflator, and Indexer to use these once the Inflator is updated with multi-game support (in progress now).

[HebaruSan]

One wrinkle that'll likely need massaging: GitHub gave us main branches instead of master for the new repos, which might cause some complications for the Infra. We talked about making that change anyway, but it looks like now is the time.

Also the User Guide will need some attention to incorporate the differences between the games.

[techman83]

Sounds like a sensible plan. And yes, I agree, time to move us to main. From a git perspective, it doesn't care what name we use for our primary branch. I think the only challenge would be how we handling downloads of metadata by the clients

https://github.com/KSP-CKAN/CKAN/blob/master/Core/Games/KerbalSpaceProgram.cs#L201

[cgruber]

For historical compatibility, if you want to change the historical versions to use main it's entirely possible to just regularly sync master so that it's always up to date with main. Just do a fast-forward merge and push. This could be done as a part of github actions pipelines. Could keep that running indefinitely, or for a long while to ensure older clients work for however long you want them to.