Gotmachine

To manipulate the orbit you likely need to pack the vessel first with Vessel.GoOnRails(). This being said, I noticed in the video that the vessel is in-atmo. I'm not sure what you're trying to achieve, but if you're trying to set the vessel velocity while in atmo, I'm not sure this is actually doable with orbit manipulation. You will likely have to manually teleport the vessel first, then apply a velocity to all the parts. I highly suggest that you check the source of existing mods doing similar things, HyperEdit is the main one coming to mind.

Don't remember and I'm too lazy to check I would suggest doing a github search for "UpdateFromStateVectors", that should give you plenty of examples of how it should be used.

From memory, they are relative to the current body frame, but really not sure. Yes that should work.

You need to manipulate the vessel orbit. Orbit.UpdateFromStateVectors() should be the most straightforward way.

I think marking non-patch releases as experimental/pre-release on github (preventing them to be pushed to ckan) is the best solution. It has been my personal release model for while now, and I think it's the best middle ground. For that release model to work, however, there are a couple rules to follow : - You have to advertise as widely as possible the pre-releases, on the same channels where you advertise for the normal releases, because if nobody uses them, nobody will ever report the eventual issues they have, making the whole release model useless. - They should be clearly advertised as pre-releases, with an emphasis on the changes made and potential issues to look for, with a disclaimer that if users don't intend to check on updates and actively try to troubleshot/report their issues, they should use the stable releases. - Always sleep for a good while on the pre-releases. You say you have a weekly dev cycle, that's perfect. It's enough so whoever is inclined to use them has had the time to do so, find issues, and report them, and not enough for you to have forgotten what you were doing. And maybe that's not something that happen to everybody, but personally, I often have bad-lightbulb moments one day or two after a release where I realize I did something dumb without even looking at the computer. It's still a relatively fast release pace and you won't end up with multiple new/experimental changes at once (which I agree makes troubleshooting more difficult, it's easier to know where an issue is coming from when you have fewer changes). A release model with a separate "bleeding edge" branch / distribution channel just doesn't work. People won't actively check it. The only worthwhile cases are when you're working on big features / changes that : - generate enough interest, sustaining a somewhat active "beta-tester" group that actively provide feedback - are backward-compatibility breaking changes, or just in-progress, unstable features I indeed think your current release model isn't very nice for the users, especially since Kopernicus is a middleware mod. Many people grab whatever current release is available at the moment and never update it. You are viewing changes and issues from your own hyper-aware lens, but most people experiencing bugs won't even know they are coming from Kopernicus, they might not even be aware of what the "Kopernicus" mod they have installed is for, since all they consciously installed is a planet pack. It's also worth noting that Kopernicus went from the most "release locked, extremely risk-adverse, months between updates" mod in the ecosystem to "push not really tested changes every week to mainstream". There is probably a middle-ground. All this being said, I fully acknowledge that modding is a personal act, that it's perfectly reasonable to do things in the way that is the most convenient for you, and that users are entitled to nothing. Do what works best for you.

This isn't really a "type of joint" problem. The different joint types you see in the Unity documentation aren't different implementations, they are just presets of the "configurable joint", which is what KSP actually uses. The issue is not really in the "joint", but it's an intrinsic limitation of the type of solver implemented in PhysX, and the same limitation exists in all other similar physics engines (Havoc, Bullet, etc), and although other engines might be better at mitigating that specific issue, it will still be there. To really get around that issue, there are only two options : Use a solver that doesn't have those issues. For example, PhysX (and Unity since very recently) has an alternative solver based on the Featherstone algorithm, which is specifically designed to have physically accurate joint behavior. Implementation in the context of KSP could pose a few challenges, but that solver have shown impressive results by the the very KSP-like Mars First Logistics Get ride of the whole "1 part = 1 function = 1 structural unit" paradigm. That paradigm is mainly a consequence of the original KSP going for the easiest technical solution available for a wanabee solo game dev 15 years ago. It never really was a conscious or intended decision, and while I agree that it is part of the KSP identity, I think the game scope has evolved in such a way that this "feature" is now largely getting in the way of the game achieving its full potential. Objectively, the 1 part = 1 rigidbody linked by non-rigid joints doesn't lead to a significant or remotely realistic "structural engineering" gameplay, and doesn't even succeed at preventing players from building structurally impossible vehicles, as due to the fundamentally un-physical behavior of the joints, they had to make them virtually indestructible. That paradigm is also responsible in a very large part for the overall jankiness of the game physics, as well as some of its performance issues. If they really wanted to have a "structural engineering" aspect to the game, it could be something like user-configurable connections strength (with a mass penalty to balance it), then have a relatively simple solver that compute cumulated forces/torques applied on each connection, with the connection simply snapping if the forces become greater than the limit. The only thing that bendy joints objectively provide is a visual feedback, which could be replaced by a cool "stress overlay", scary sounds of metal bending and particule effects of things starting to snap. Doing that would add an actually interesting, predictable gameplay element, and would get ride of a good chunk of the core issues the game has.

So, as someone that has a bit of technical knowledge on how things are actually implemented, I thought I could maybe give a bit more insight. This isn't the primary reason why things aren't accurate. The primary reason is that the joint solver isn't designed to be accurate in the first place, and has a core limitation in that the behavior is fundamentally not accurate when connecting parts that have a large difference in mass. Said otherwise, and to simplify (it's actually a bit more complex than that), a joint with a stiffness value X connecting a 10 tons part and a 0.1 ton part will be a lot less rigid than the same joint connecting two parts of equal mass. This is why parts like decouplers or reaction wheels are "weak points", because they are usually very light parts used to connect very heavy parts. KSP actually does this. For node/stack connections (not surface attach ones), KSP (1 and 2) actually generate multiple physical joints evenly positioned on a circle centered on the node. This is why larger node connections are stronger than smaller node connections, despite all joints using the same stiffness values. You're preaching to the converted. Unfortunately, given the level of coupling between the builtin Unity PhysX implementations and almost every other subsystem in the game, the chances of them doing such a redesign and refactor are very slim.

As of now, we have zero evidence that any of the specific technical challenges of a game like KSP have been solved : - Rigidbody physics are still the good old PhysX joints, with the same limitations as in KSP 1 - Aerodynamics are still the good old dKSP 1 drag cubes system, with all its limitations. - Keplerian orbits are extremely unstable and buggy, and we haven't seen any demonstration of the 3-body solver. - The background processing / thrust under warp / while unloaded system has bugs and massive performance issues that will be a significant bottleneck unless they do a radical refactor. - Thermodynamics and resource chain handling are the difficult things to get right at massive timewarp speeds, and those aren't implemented yet. Funnily enough, that system was put together by an external contractor, Jason Booth : https://medium.com/@jasonbooth_86226/my-approach-to-optimization-bfcafc1f8768

KSP is fundamentally a casual game about quick-and-dirty putting together goofy contraptions in a vaguely physically accurate sandbox. The main reason KSP 1 ever was a commercial success is because of the goofy kerbals, the weird elastic joints, the explosions and the vague promise of a space adventure that was mostly virtual. The majority of people that ever bought the game barely made it to orbit, and 90% never got past the Mun. Judging from my personal network, I know a lot of people that bought the game, played 15-30 hours, had some fun, and barely ever touched it again. It's not a bad thing, but it's important to realize that the only reason T2 spend big money buying the KSP IP, and the only reason why KSP 2 is a thing is because that casual player potential exists. The concept has very little commercial value as a simulation game, it's indeed way too niche for anything else but a small independent team trying to make a living out of a passion project.

That is fully expected. The reason they did that inertia tensor scaling hack is because there is no other way (beside spamming more internal joints) to prevent PhysX joints from becoming loose springs when connecting Rigidbodies of largely varying mass. The problem is that scaling the inertia tensor is basically breaking the laws of physics (conservation of energy), the result for the end user being random phantom forces/torques.

It is also a pretty limiting factor in that we are limited to what the "API" is made to expose for stock KSP needs. There are massive holes in the stock API. I definitely hit that wall many times, and I can also say with some confidence that it has been a rampant issue in the KSP 1 modding scene at large, resulting in plugin authors having a tendency to use weird, convoluted, underperforming, buggy solutions to simple problems. I'm pretty much in agreement with @bbepis here. A community driven modding library/API has many benefits (as long as we don't have 10 competing ones) : - The extra layer of abstraction of stock codebase mean that when the stock codebase does breaking changes, it's a breaking change that has to be dealt with once at the API level, instead of a breaking change for every single mod. - We can add whatever we need to it without having to rely on the goodwill, plans and ability of the devs to do it. There definitely wasn't any official channel during the KSP 1 lifetime for requesting API additions.

Simple keplerian orbit ("patched conics") is analytic but it doesn't have a closed-form expression either, it's also an iterative algorithm.

Sources and evidences that we aren't allowed to discuss in these forums.

In some vain efforts to make PhysX joints to be more rigid when connecting parts of vastly inequal masses, KSP 2 is implementing a silly hack in the form of scaling the Rigidbodies inertia tensor according to the connected parts mass ratios. This is a well known "trick" in the Unity community, however, this has the consequence of fundamentally breaking the physical behavior of Rigidbodies. Excerpt from the PhysX documentation : Now, I haven't tested what KSP 2 does in depth nor attempted to prove the consequences of KSP 2 scaling the inertia tensors, but given how many people are reporting issues with phantom torques/forces resulting in vessels spinning out of control randomly and orbit instability, it's tempting to connect the dots. This could also explain why reaction wheels and RCS appear so weak compared to KSP 1, despite not having being nerfed. Since the parts providing RCS or RW torque are usually very light, they might be disproportionally affected by the inertia tensor scaling hack, resulting in their ability to provide torque being artificially reduced when connected to heavier parts. For anyone that has some issues with stuff spinning out of control and other phantom forces issues, I would suggest disabling that KSP 2 "feature" and to report back if things seems better. You can disable that feature by going to the KSP user data folder and editing the physics settings : Paste the following in the windows explorer bar : %USERPROFILE%\AppData\LocalLow\Intercept Games\Kerbal Space Program 2\Global Hit enter to navigate to the folder Right-click on the PhysicsSettings.json file and select Open with... > Notepad Locate the "ENABLE_INERTIA_TENSOR_SCALING": true, line Change true to false Save the changes and restart the game

Background processing of unloaded vessels (and other stuff like colonies), assuming they intend the players to be able to have a moderately complex space program going on, entails running a large chunk of the game logic on thousands of entities. To make that possible without tanking performance, there are only two possible strategies : - Don't actually run the same game logic and aggregate entities into higher-level abstractions and/or reduce the update rate to cut down computational cost at the expense of simulation precision/coherency. - Architecture these entities around data-oriented programming paradigms, making the data cache-efficient and allowing to leverage parallelism and SIMD instructions. As of the current EA release, KSP 2 isn't doing anything like that. All they have done is to separate the objects game logic from their loaded representation, which is the bare minimum required for the background processing concept to work. Now, each unloaded vessel/part/partmodule is doing a lot less work than when loaded : no joint physics, no collisions, no visuals to push to the GPU... But even taking the estimate that each unloaded part does around 5% of what a loaded part does in terms of processing, if for example you have a game with 20 vessels made out of 100 parts, that still is worth the computational cost of 200 loaded parts. The only thing they can possible do without basically throwing away the whole thing is to dial down the unloaded vessels update rate, but this has direct consequences on the simulation quality, especially on some subsystem that are time-step sensitive like solar panel evaluation or thermodynamics. It might be possible given the current architecture to implement some limited parallelism, but currently there is no provision for any of that and it would already require a quite large refactor.

This is not a bug, it's a feature. The visible, physically interactable with representation of the vessel is not loaded. However, the core logic will stay loaded, because that's a feature of KSP 2 : vessels are able to use their engines in the background, while unloaded. To make that work consistently, this mean a large chunk of the core logic is kept running : resource requests and conversions, solar panels, thermodynamics, etc... This obviously add a lot of overhead, but with a good core architecture, this would have been doable without impacting overall performance too much. Unfortunately, the way KSP 2 is architectured is absolutely not up to that task, at least in the current state of things.

Due to the nature of the problem, that doesn't really solve anything, it would make it even worse. As I mentioned, the main issue is that PhysX joints become less rigid when the mass ratio between connected parts is higher. So for example having a single huge procedural fuel tank part connected to a decoupler is actually worse than several smaller fuel tank parts connected together and then to the same decoupler.

The short answer is that PhysX, the physics engine KSP 2 (and 1) uses is not capable of simulating infinitely rigid joints. That's not what it's designed for. They will always flex to some extent, and additionally, it's dependent on the mass ratio between connected parts. Said otherwise, a joint connecting a very heavy and a very lightweight part will flex (a lot) more than a equally strong joint connecting two parts of equal mass. This is why you get a lot of flex in KSP 1/2 when you connect a several tons fuel tank to a 100 kg decoupler. And to be clear for all the people thinking having wobbly joints is a design decision and a physically accurate challenge, it's not. The behavior is unphysical and largely unpredictable, it exists because PhysX is the default physics engine available in Unity and requires the least effort to implement. The only workaround is to spam more internal joint connections between each part, which is what the KSP 1 autostruts does (badly) and the KerbalJointReinforcement KSP 1 mod does (a lot better).

Per the EULA, mods aren't allowed, so this doesn't really matter...

Well, in that respect, it's a total failure. While the overall UI takes a ton of screen real estate, many critical elements (text, icons) are tiny and barely readable. When you want to make an UI that work for all uses cases, you make it as uniform and space efficient as possible so it can be globally scaled up and down.

Yes, in an ideal world, KSP 2 would have a proper mod manager that define and handle packaging, semver, dependencies, metadata, etc. My little finger tells me we aren't in that world, and that we better handle all this by ourself. As for using an external / community maintained modding toolset / modloader / injector, there are several benefits at doing so, regardless of if the game if using the Mono or Il2CPP backend. But frankly, I don't see how they could possible have made the "KSP 2 will be more moddable than KSP 1" statement if the game is using IL2CPP. I know that personally, that would probably kill all motivation for me to develop mods for KSP 2.

Nope, that couldn't be further away from reality. I can say with 99% confidence now that KSP 2 is using the Unity vanilla PhysX joints implementation. Why so confident ? Because the floppy joints is a well known intrinsic limitation of that implementation, and all you can do is "spam more joints" workarounds, which KSP 1 does in two variants : - For stack nodes connections, it actually create multiple joints, usually 3 joints put 120° apart on a circle centered on the node. - Autostruts This is also what the KJR mod does. KJR is basically just a smarter and fully automatic autostrut implementation, spamming additional joints using some heuristics based on connected parts mass. The point is that floppy joints as they exist in KSP 1 and now KSP 2 are not a game design choice and never were. They are the result of using a physic engine that isn't designed to handle what KSP is trying to do with it, and that decision itself is the result of not enough skill/resources to implement an alternative.

We don't need anything from the devs to start modding KSP 2. There is a quite dynamic community and toolset ecosystem allowing to extensively mod any Unity game. The most popular/advanced of these tools is BepinEx. In fact, I would argue that given how overwhelmed Intercept seems to be with trying to put the game together, they should probably let the modding community handle everything on their own.

I'm excited about KSP 2 being a new thing !

@king of nowhereYou're missing the Harmony dependency.