Gotmachine

Not really, for the same reason Squad couldn't do it either : this would imply major breaking changes in core legacy code, breaking ton of other code down the line, including mods. Squad already did what they could in terms of "afterthought" optimization, there is actually not that much left on the table given KSP technical debt and desire to ensure backward compatibility with the existing modding ecosystem. I don't see how you can keep joint strength limits if you merge everything into a single PhysX RB, unless you roll out a custom implementation for that. At this point, if you have that custom implementation, you've already reproduced most of what PhysX is used for in KSP. Side note : KSP relying on PhysX joints at all is quite questionable, since : - it has to use a floating origin (which cause a significant overhead on the PhysX side) - it doesn't use jointed RBs collisions (no "intra-part" collision) - it has to spam hundreds of extra PhysX joints to be vaguely successful at implementing a "lightweight parts should result in as much rigidity as heavy ones" behavior - it has to compute a significant proportion of the RB physics results independently - it has more generally to do tons of dirty hacks to avoid various issues On the other hand, it gives KSP its distinctive "noodle rocket / wonky physics" touch. Depending on your POV, this is either a bug or a feature. My personal stance is that the KSP lego parts paradigm fundamentally can't result in a good "structural strength design" gameplay element. This isn't a bridge construction game, there is fundamental conflict in trying to mix the "parts are functional elements" and "parts are structural elements" paradigms. The whole "joints structural gameplay" is vaguely fun for the first two hours you discover the game, then it just become a constant annoyance. This being said, rolling out a completely custom joint/RB physics implementation is no trivial task, and it imply loosing a lot of "standard" features from the Unity ecosystem, for example the wheels/legs physics plugin KSP relies on (VPP). I don't expect them to take that path. Even though it would likely be the better option in the long run, it imply a massive upfront development cost. So yup, maybe they will partially disable the per part RB PhysX simulation we are used to in some cases. If they do that, I wouldn't qualify that as "optimization", but more as another hacky workaround, in the same realm as spamming PhysX joints to make large vessels vaguely rigid. There are several technical options there, merging multiple parts in a single RB is one. For vessels, which are frequently subject to part reconfiguration events (staging, docking, collisions, etc), it would induce a lot of complexity and overhead. But I can see that happening for the "semi-static" large bases/stations, which will likely be different technical entities than regular vessels. Alternatively, there is the possibility of switching the vessel parts RB to kinematic mode and handling vessel forces/torques manually to update part positions (KSP already does this when vessels are in the packed state, minus the forces/torques handling). This is a relatively straightforward way to opt-out from joint physics (and the bulk of the performance cost) while keeping some useful RB stats (like per-part CoM), and as I said, they will need to implement all that for being able to do out-of-physics/in-timewarp engine thrust and vessel attitude control, unless they decide to use a dumbed down "just aggregate all engines as a single CoM aligned thrust vector" model for that. The only remaining piece is having a collision prediction thing, so they can switch out of kinematic mode before a vessel-vessel or vessel-terrain collision happen and have joints behave as expected in that case. And side note, that "physics LOD" rumor comes from a 2019 "leak" from somebody that used to work on KSP 2, and what he said was just that : they will try to keep vessels in the packed (ie kinematic RBs) state more often. But in any case, as long as they keep the flexible joints feature, those always will be temporary optimization opportunities. There will always be a point where full per-part RB physics have to be enabled. So this would result in an user experience with massive FPS variations for the same vessel depending if said optimizations are applicable or not. Not to mention it would introduce (more) discrepancies in physics behavior. So the whole thing is a quite questionable decision, and I have some doubts that "physics LOD" rumor will actually materialize into something very significant. As for the stuttering on docking/undocking/staging/collisions/vessel becoming loaded, there is little they can do here. Those events fundamentally imply initializing and re-initializing a lot of stuff, which is always a costly operation. If your CPU already has no breathing room when those happen, the stuttering is unavoidable. They can use some strategies and good practices to limit the effect, but it always will be here. There is also a tradeoff between stutter during those events and performance the rest of the time. Outside of those events, there are usually a lot of opportunities to cache some costly computation results instead of redoing them continuously. But this mean that when those results become invalid because the vessel state has changed, you need to perform all those calculations at once, inducing temporary stutter. Anyway, I agree with the OP, I would love to hear some information about what the KSP 2 developments and plans are in regard to this stuff. "Vessel physics" (be it RB physics, aerodynamics, thermal simulation, resource simulation...) are the main pillar of KSP, what make it distinct from any other game. It's also the most technically difficult aspect. As a seasoned KSP player, I don't really care about the new planets or scifi engines, all I want is a KSP 2.0 that provide good solutions for those core features.

"physics" is a rather vague term. If you're talking about rigidbody/joint/collision physics, this is handled by the PhysX engine and there is little they can do to optimize that. Unless they decide to roll out a 100% custom rigidbody physics engine, which would be quite justified as PhysX (or any "standard" physics library) is quite inadequate for KSP use case. But I doubt this will be happening, this would be a huge investment for not that much immediate gains. As mentioned, the most likely optimization they will do is just to disable RB physics altogether in some cases. RB physics are essentially useless when there are no external forces (collisions, gravity, atmospheric drag...). The most likely case will be bases and stations, and other vessels beside the active one. Or even anything that is in space, since they intend to have "unloaded" vessels being able to produce thrust, this mean they are planning to handle thrust/attitude control forces without relying on the RB simulation (but how coherent the simulation will be between active and unloaded vessels remain to be seen). Also, contrary to popular belief, the rigibody/joints physics is NOT the main KSP performance issue. The KSP other "physics" subsystem are the main bottleneck : the aerodynamic and thermal simulations. Each of these subsystems consume about as much CPU time as the PhysX RB simulation. Using modern Unity features (jobs/burst), those could be massively optimized without that much effort. There are many other potential optimizations in various specific subsystems like the orbit solver, the resource flow/request system, the engine thrust solver, various partmodules... This being said, I don't expect a paradigm shift in what is possible in term of part count. The current KSP "playable" threshold is somewhere between 300-400 parts. If they do a decent job at optimizing the various subsystems compared to KSP 1, we could maybe get a 3x improvement on that figure, but don't expect being able to have thousands of parts without lag.

You can use both. This being said, I believe the KSP-Recall patches that aren't covered by KSPCommunityFixes only apply to old KSP versions, and are only for fixing TweakScale related issues. If you don't use TweakScale, KSP-Recall is more or less useless and will likely just bloat your game for nothing.

CC is designed to be extensible. You can create whole new custom parameters, requirements, etc from your own plugin.

CC works just fine. Yes, there are some quirks here and there. And yes, it's definitely far from optimal from a performance standpoint, but this has very little to do with how "old" it is. It's not very optimized because it's a huge codebase and maintainability / ease of programming was prioritized over performance. At this point point, "fixing" it would require a lot of work. But I disagree with you. There are no contract packs because nobody is making them or actively developing the existing ones, not because of CC limitations. RP-1 has a huge and very refined career progression system based on CC. The sad truth is that the KSP modding scene is slowly dying since a few years now. At a few notable exceptions, most KSP plugins are just kept barely afloat and aren't under active sustained development. I can count on my hands the names of the active plugin developers, and large proportion of them are from the RO/RP-1 community.

There is a fix for that (KSP) issue in :

V1.5.0 is out. Available from GitHub and CKAN. New bugfix, KerbalTooltipMaxSustainedG : fix the kerbals tooltip giving wrong "Max sustainable G" information (thanks @NathanKell) Fixed (again...) some patches not being applied

IMO, it's not worth breaking every mod currently using the CLS API. As long as everyone "play by the rules", using a common redistribuable API assembly is fine. I also strongly advise against putting together a reflection based API. Reflection comes with a huge performance penalty. It also becomes a mess to work with when you need to pass custom data around. In any case, the KSP 1.12 assembly loader issue will continue to plague the modding ecosystem, we just need to cooperate and spread the awareness. Also, I've not entirely given up on the possibility that this silly issue get fixed in an hypothetical 1.12.3 update...

May I suggest contributing to KSPCommunityFixes instead of starting a separate but similar mod ? This being said, some of your ideas are already covered by other mods, and some others could be improvements to existing mods. Maybe you should consider contributing to those mods instead : Bring the builtin alarm clock up to par with KAC (add encounter mode, auto select the timer type, better pre-naming of timer) > see https://forum.kerbalspaceprogram.com/index.php?/topic/204404-112x-alarm-enhancements-102-26082021-automatic-alarms-and-better-naming-of-alarms/ More filtering options in the tracking station, such as listing only objects landed at or orbiting a specific body, showing only asteroids of a specific class > see https://forum.kerbalspaceprogram.com/index.php?/topic/172162-19x-dmagics-evolved-mods-tracking-station-evolved-60-5-4-2018/ List of nearby vessels to switch to > see https://forum.kerbalspaceprogram.com/index.php?/topic/141180-minimum-ksp-version-111-easy-vessel-switch-evs-v23/

It is broken, and it is a problem. There is a KSP 1.12 bug in the plugin loader, triggered when two (or more) *.dll with the same name exist in the GameData folder/subfolders (https://bugs.kerbalspaceprogram.com/issues/28036) It cause the plugin loader to either : - outright crash with an ArgumentOutOfRangeException and KSP getting stuck on the "loading part upgrades" loading step - silently remove random assemblies to be loaded - continue without side effects. Which outcome you get depends on the alphabetical loading order of the dlls, and consequently can't be predicted. It also can't be fixed with a plugin, as this happen before any plugin has any chance to execute. LGG implemented that warning in ZeroMiniAVC to detect the second and third cases, but it can't cover the first one. From a mod author POV, there is a workaround : if your redistribute a *.dll that has any chance to also be redistributed by another mod (API, external library...), rename it to something reasonably unique. So in your case, you can rename the "CLSInterfaces.dll" redistributed by Ship Manifest to something like "CLSInterfaces_ShipManifest.dll" Internally, it doesn't matter if those dll have different names. Only one assembly (by assembly internal name as defined in the AssemblyInfo.cs file) will actually be loaded, and all other assemblies will correctly get that common reference. This was actually discussed extensively in the CLS thread recently : https://forum.kerbalspaceprogram.com/index.php?/topic/192130-111-connected-living-spaces-adopted-2006-2020-12-29/&do=findComment&comment=4048902

And more issues... sorry again... V1.4.2 is out. Available from GitHub and CKAN. Fixed ModuleIndexingMismatch patch causing issues with modules dynamically adding/removing resources. Specifically, the patch was causing part resources to be loaded before (instead of after in stock) the PartModule.OnLoad() call when loading a ShipConstruct. This notably fixes RealFuel resources being lost when reloading/launching a craft file, but that mistake likely had consequences for other fuel/resource switchers mods (B9PS, Firespitter...)

Aaah, silly me... Sorry for the borked release, and thanks to @Arrowmaster and @YellowApple for the reports V1.4.1 is out. Available from GitHub and CKAN. - Fixed UIFloatEditNumericInput patch causing various errors and generally not working as intended.

@Arrowmaster@YellowApple Which KSP version are you using ? Can you upload a full KSP.log (or better, use https://github.com/KSPModdingLibs/KSPBugReport) ? I can't reproduce it, neither in KSP 1.12.2 or 1.10.1 It seems strange that it happen with the Photon Corp SRBs, since they don't use a FloatEdit control. If they have one, it probably was added by another mod. In your working game, do you see such a control (something looking like that : [<<][<][---slider---][>][>>]) on those ? If so, can you identify what it's for / from which mod it comes ?

V1.4.0 is out. Available from GitHub and CKAN. New QoL patch : UIFloatEditNumericInput [KSP 1.8.0 - 1.12.2] Allow numeric input ("#" button) in "float edit" PAW items Fixed some patches not being applied in KSP versions below 1.12 : PAWItemsOrder, TweakableWheelsAutostrut, ModuleIndexingMismatch, FlightSceneLoadKraken. PAWStockGroups patch now applicable to KSP 1.10.1 (min version was 1.11.1 before)

Changing the home system has no effect on how coordinates are computed, what matters is the distance from the original KSP sun. This being said, the real cause of that issue remains a mystery for everyone. All we know is that it happen more frequently the further you are from the original sun, and that preventing some of the MakingHistory DLC functionality to be active seems to further reduce the probability of that issue. Edit : I might be wrong, actually. Does the GU home switch work by replacing the Kerbol system with a custom one ? In which case you are right, distance has nothing to do with it, and the issue is caused by something Kopernicus is doing (or not doing). Which would make at lot of sense. The whole issue seems to be caused by the Unity collision ignore matrix becoming somehow messed up.

V1.3.0 is out. Available from GitHub and CKAN. New bugfix : PAWItemsOrder [KSP 1.8.0 - 1.12.2] Fix PAW items position randomly changing and flickering This should fix the issues @Poodmundand @Dominiquini were taking about in this thread a while ago, although I suspect that there are a few other item ordering related issues lying around in the PAW code.

More or less. However, KIS 2 will override and be mostly incompatible with the stock system, which mean that other mods that want to expand on the stock system will likely be incompatible with KIS 2. I had a lengthy discussion with @IgorZ on the topic, but we more or less agreed that we are disagreeing. The stock system has many shortcomings, but IMO it still is a decent "common base" for mods to work on. IMO, those shortcomings can be fixed without throwing compatibility away like KIS 2 intends to do. I am massively relying on the stock inventory system for some features in another mod, so my intention is to "fix/expand" it from a user facing POV, but also to provide a better modding API for it in the process. This stock inventory "extended modding API" is the reason I would prefer to release it as a part as KSPCommunityFixes, but the KIS 2 plans have made that a bit problematic. In theory, what I'm doing shouldn't cause issues in KIS 2, but having to verify that is a lot of extra work, especially since KIS 2 is a in development moving target... This is a bit messy to implement while keeping compatibility with KSP versions prior to the introduction of the vessel naming feature. This is quite minor in any case...

Yep, that's a good summary. Although it should be noted that the "less/more stability/kraken" bit only apply to a few corner cases. Specifically, it only apply when a part is "instantiated" : flight scene loads, previously unloaded vessel entering physics range, EVA/Boarding, and possibly EVA construction. The current KSPCommunityFix patch only apply to the first case (flight scene load). I have a more "technically sound" fix, but I'm reluctant to release it as it alter the default KSP initialization sequence, and there is a small chance that this have unintended side effects on other KSP stuff/mods.

"Part" group : sameVesselCollision, AimCamera, ResetCamera, ToggleAutoStrut, ToggleRigidAttachment, ShowUpgradeStats, SetVesselNaming "Comms" group : ModuleDataTransmitter PAW items "Command" group : ModuleCommand PAW items "Control" group : reaction wheels, RCS, gimbals, control surfaces PAW items I guess I should make a screenshot and add it to the OP. Yeah, it also doesn't always properly update when you manipulate stuff in the PAW. I have a much more refined stock inventory overhaul in preparation, but at this point it probably belong to a separate mod, as it somewhat goes quite beyond the simple "Bugfix/QoL" category. In a nutshell, what it does is : - Automatically compute cargo parts volume instead of requiring config definitions - Properly handle volume for part variants - Remove the inventory slot count limit (only mass/volume limits matter) - Always allow stacking up to 10 items, as long as cargo parts are technically identical, don't contain resources and aren't specifically excluded from being stackable in the configs. - Overhaul the stock inventory UI with a "pages" system, and make the grid user-resizable so it doesn't take so many space in the PAW While this is technically entirely compatible with the stock system, it is nevertheless a deep modification and can potentially cause compatibility issues with other mods relying on the stock behavior (especially the in-progress KIS 2 mod). So I'm not sure what to do with it yet.

Likely not so easy to do. The crew assignment stuff is quite messy, and messing with it might have unintended side issues with other mods... I will try to look into it.

V1.2.0 is out. Available from GitHub and CKAN. New QoL tweak, TweakableWheelsAutostrut [KSP 1.8.0 - 1.12.2] : Allow tweaking the autostrut mode of wheels/landing legs. Still default to "heaviest part".

I'm not pessimistic, I'm just saying that what KSP 2 is focused on isn't what I personally want to do in a KSP game. They obviously are making the "lets assure a commercial success" choices, I'm fine with that, but it isn't the "rocket game" I personally would like to play. I don't want things to be simple. I want game that I can play for hundreds of hours, with complex gameplay elements, and a less emphasis on the "derpy toy/scifi world" aspect, and more emphasis on the "real world rocket/space program simulation" aspect. Which is a much more niche genre. It isn't. If there aren't any branches, it isn't a tree. If you want a comparison with a commonly used game mechanic, it's like a "Level up ! Choose a new ability to unlock" thing.

Problem is, there isn't much choice to give. Every "technology" is mandatory at some point. You need parachutes, landing legs, heat shields, fuel tanks, RCS, reaction wheels, thermal control, solar power, batteries, etc... The only potential strategic choices are choosing between a handful of advanced propulsion systems, plus maybe the "nuclear power or not" choice. If they really want to give those choices, that would still work with a "single line" progression : when you reach X progression points, you can choose one tech between the 5-6 "advanced techs", and at the next "progression threshold", you can choose another, etc. But I don't see the need for a "tree" of any kind. You're missing the point of the "very few tech nodes". Those situations wouldn't happen because there is no such granularity, and because there are very few milestones before unlocking the vast majority of parts and functionalities. The progression revolving around what the player accomplishes (base/station construction, supply runs, etc) is enough, no need to create arbitrary and hard to balance low granularity "tech gating" on top of that. What I describe isn't what I would like. It is what I think we will get. Personally, I would definitely prefer an in-depth "space program management" sub-game complete with funding, a proper contracts system, time based rocket construction, time base science, individual part unlocks based on time based research, a proper life support system... But that's definitely not what we are gonna get. We are gonna get a "guided sandbox" with interstellar fluff, scifi propulsion, colonies, and multiplayer. All things that I absolutely don't care for.

We can't do much but speculate. But based on what they said and what I think would make sense, this is what I mean by a "slightly part availability gated sandbox" : A single "progression point" variable, where those points are acquired : Passively, on reaching various milestone (like the "world firsts" KSP 1 system) : distance traveled, speed attained, reaching a body SOI/orbit/landed/biome, using a mechanic (ISRU/in situ construction...) for the first time, colony achievements/bloom events, finding special places/easter eggs, stuff like that. Actively, by transmitting or retrieving part experiment results (same mechanics as for KSP 1 science points). Very few different experiments (~5-6), available from the start. A single branch, linear "technology" progression, with maybe ~20 "nodes", each unlocking a large batch of rocket/colony parts. Basically, one node for every major technological milestone : one for each propulsion technology, one for each major colony/station capability, a bunch of extra nodes at the start for not overwhelming new players with tons of options. They unlock passively, when the total acquired "progression points" reach a given amount. To spice it up a bit, that system could also have an "actively spend progression points" mechanic for : Launching rockets from KSC, with the progression point cost based on the rocket mass. Launching the special colony/station "core" parts. Hiring new kerbals. KSC upgrades, for example to increase launch mass limits or DSN range. Spending points wouldn't change how the "tech progression" works, it would be purely based on the total points ever acquired. This avoid the "part availability mismatch" issue of the KSP 1 tech tree where you inevitable end up doing silly designs due to parts being both categorized by size and function. This also avoid having to balance a per part "tech cost". The only limiting factor is vehicle launch mass, all part sizes are available once the corresponding technology node is unlocked. In that system, the vast majority of parts would be made available in the first ~5-10 tech nodes, designed to be achieved quite quickly, including all structural/utility/control/aero parts.

It is fundamentally linear. Launch a basic rocket, reach orbit, go to the moons, go interplanetary, go interstellar. Arguably, the 4-5 "technological steps" for doing so are quite linear : first chemical, then chemical++, nuclear fission, nuclear fusion and finally sci-fi exotic stuff. There isn't really enough there to build a meaningful "tech tree choice" gameplay around that, unless they actually develop a whole in-depth "space program tycoon" sub-game, which at this point we know won't happen. This is why I doubt there will be any significant depth to the "adventure mode" mechanics. They gave strong hints that they won't repeat the same mistake as KSP career mode : introducing "tycoon/strategy" like mechanics without having any significant gameplay elements to back them. Moreover, a "player decisions" gameplay will already exist through colonies/stations building/growth and associated gameplay elements : ISRU, colony growth, offworld vessel construction, resupply lines... Arguably, this is the progression gameplay, directly involving the core "lego building / piloting vehicules around" element. Why would they need to add complex abstracted progression concepts on top of that ? To satisfy the 0.1 % of players that will play the game more than 100 hours ? The fundamentals of KSP are about building rockets, flying them and reaching space and distant worlds in a somewhat physically accurate way. This is the fun part. They will succeed if they get that right, and this in itself is a huge task. At some point, some of the KSP 1 devs commented that when analyzing the collected statistics, they discovered that vast majority of people that bought the game didn't ever get past Kerbin orbit. The "forum population" is NOT representative of the player base. They are the 1% advanced, noisy, nerdy players. If the KSP 2 devs are doing their job right, focus will be accessibility of the core gameplay elements : building rockets that work and piloting them to their destination so Kerbals can go interplanetary/interstellar and build distant colonies, and making exploration interesting by making beautiful worlds, with more variety and unique features. It would be a much higher payoff to introduce "lore" stuff (kerbal artifacts, alien/kraken stuff...), then create some sort of "quest/story" gameplay element than building a pointless progression system. They have given a lot of information on the accessibility/core physics/stuff to explore topics, but they have been quite silent on the "adventure mode" mechanics. Likely because there isn't much to it, and the "KSP 1 nerds community" has huge misplaced expectations on that front. But I wouldn't be surprised if that is because they have a "lore/story" progression element they want to keep secret until launch. Advanced progression mechanics are the realm of mods, or DLCs / extensions. Which are an essential part of the economical model of a game like KSP. But it certainly won't be a launch-day feature.