antra

The problem is `PartComponentModule_DockingNode` module state of the `dockinport_vX_inline` part has ModuleData.DataObject.CurrentState incorrectly set to "Docked" when it should be "Ready". The exact cause for this is unclear, but in my testing it involved previous docking and undocking with a separately launched craft. In some circumstances undocking does not cleanly reset the CurrentState to "Ready". The immediate workaround involves editing the save file manually. Its fairly tedious, but not hard if you are comfortable with JSON. It can probably be automated in a community fix mod. The steps would be as follows: Identify the two craft with difficulty docking. Note their craft names Locate the JSON dicts corresponding to the craft names. Search for `"assemblyName": "your_craft_name"`. Optionally note the Guid.Guid in the beginning on the dict containing the AssemblyDefinition found. The guids make the dicts easier to find if you need to look them up again. Copy the entire craft dict to separate file. It is easier if you use something like VSCode to enable folding of JSON dicts and lists. In the craft dict search for `dockingport_v`. This may produce multiple matches if there is more than one docking port. For each docking port dict search for `"CurrentState":`. If this dock port is showing `Docked` when it shouldn't, change it to `Ready`. You can examine the attach points to see if there is anything attached to the 'top'. If there is a null part with 0000 guid, that means that there is nothing attached, otherwise you will see a proper part link. For resolution it would be very helpful to test various docking and undocking scenarios. One interesting case to test is the following: Launch 2 crafts, craft A and craft B. Craft A should have a pair of docking ports in pre-docked configuration. Separate the pre-docked dock ports in craft A after launch. Bring in craft A and craft B to immediate vicinity and dock. Optionally conduct resource transfer, but not likely to matter. Undock craft A without switching control to craft B Leave the vicinity in craft A (so that craft B is no longer rendered or shown as a marker on HUD). Check the save-file state for the CurrentState of docking port of craft B and craft A. It is possible that the issue is related to incorrect state initialization after the craft is loaded from save file and then undocked.

The original post matches my intuition fairly well. The controversy around Star Theory may be one of the reasons, although I doubt its the only reason: https://www.bloomberg.com/news/articles/2020-06-03/kerbal-space-program-2-release-disrupted-by-corporate-strife#:~:text=A few joined their former,until the fall of 2021. It looks like at least some some heavy hitters / architects / 10x engineers didn't cross over. This must have set the project back. I'm pretty sure the publisher miscalculated during the "negotiation", as it often happens. The business people negotiate on what is, to a large extent, a highly technical issue. Technically minded executives are a rare commodity, they usually can make a better living running their own business rather than working for a large company. In the end the publisher execs pushed to save pennies, have cost the company years and millions, probably got some political points out of it in the process. I kinda blame the ST founders the most for not getting the right lawyers for dealing with T2. Don't mess with a large corp and don't take their business if you don't have an idea how to do it. Not having anti-poaching agreements in place seems like significant incompetence, you don't sign that stuff even if you are getting pushed, you won't get the money anyway (yes, anti-poaching agreements exist, even where restricted, they are just called differently). Overall, in my experience drama of this caliber dramatically lowers the output of a team for about a year, even if "resolved" to a reasonable level. Creative people don't work/collaborate well when the interpersonal environment is that unstable.

There are serious issues with planet surface shaders, they right now make up the bulk of draw call time. This cannot be addressed by mods, since we don't have the shader sources. However, there is a solid chance that the developers can fix it in a reasonable amount of time, this does not look unsolvable.

I’d like to work on the asset loader, building UIs from code is annoying. I have my own loader working, but it would make more sense to move to the community loader the sooner the better. Do you use discord?

It is a call that has to be made on an individual basis. Nothing I write is legal advice, and I can be wrong, but my understanding is that a EULA is not technically different from a waiver or a contract in the sense that it cannot restrict things that are explicitly allowed by law. Courts have previously ruled that reverse engineering for compatibility falls under fair use. However, reverse engineering for purposes other than compatibility is likely illegal. In any case, if I was on the Private Division legal team, I would be reluctant to provide an explicit permission in any case because it would reduce the options for potential litigation in the future. Given that the developer has already declared future support for mods, and given that the mod infrastructure present in the current build of the game relies on the same assemblies, I don’t think that the threat of litigation is very high. This is how most games without mod support are normally modded. More context for this topic can be found here: https://www.eff.org/issues/coders/reverse-engineering-faq

The asset bundle didn’t, but the Bepinex plugin did. It used the assemblies from the Managed folder, which contains a lot of functionality of the base game. Basically, the asset bundle can be used to bring in prefabs, UI prefabs in my case, while the logic stays in the Bepinex plug-in. I can access maneouver node logic, which is what I’m aiming at. Basically, the bulk of the game logic one way or another referenced by the GameInstance singleton. All KerbalMonoBehavior components include a reference to it. You can iterate through the root objects of the active scene and most of them contain components that extend KerbalMonoBehavior, giving you access to the core singleton. I’m not sure if you can get access to parts logic this way, but the core game seems to be accessible and the assemblies provide a pretty straightforward API, including comments.

I've loaded an AssetBundle exported from a regular Unity editor. Everything loaded up. I'm using Bepinex to inject code and then calling AssetBundle.LoadFromFile. I believe that reverse engineering to ensure compatibility with the software that you are developing cannot be restricted by a EULA in both US and the EU as its explicitly allowed.

Bepinex works. You can get it here: https://spacedock.info/mod/3255/BepInEx for KSP 2 There are no binaries on Bepinex nuget yet, but you can load assemblies copied straight from the Managed folder and they work fine. A custom asset bundle has loaded great, no issues. The Unity version is 2020.3.33, you can download it if you want to package your own assetbundles. If you are fine with code-only plugins there is no need. The KSP2 architecture looks pretty good, you can get a reference to the GameInstance singleton from any KerbalMonoBehavior, just iterate through the active scene root objects to find the first one. The singleton contains pretty much everything, you can get a refence to the UI system and start drawing new windows. I'm pretty sure the APIs will change often, but so what? Let them break the mods, we'll fix them. Right now the game is in a rough state, the maneuver nodes are close to unusable, no way to see orbit parameters after an adjustment, the interplanetary travel is almost unusable. This can be patched with reasonable effort with mods, then the developers can catch up with proper fixes at their own pace.