Gotmachine

There is probably a better way to achieve what you want, but hard to say without seeing what your DoFailure() method does. Depending on how you disable the SAS module, I suspect you might run into the SAS level being available again after certain events (decoupling/docking for example). As for implementing a delayed callback, you can use a coroutine : public override void OnStart() { base.OnStart(); if (failed) StartCoroutine(DoFailureDelayed); } private IEnumerator DoFailureDelayed() { for (int i = 0; i < 20; i++) yield return null; DoFailure(); }

https://github.com/Kerbalism/Kerbalism/wiki/TechGuide-~-Supporting-Science-Mods

MonoPropellant and XenonGas are both defined with flowMode = STAGE_PRIORITY_FLOW, which mean they ignore "no crossfeed" parts, it has always been like that. If you want them to behave like LF or Ox, you can MM patch the resource definitions to use STACK_PRIORITY_SEARCH

V1.6.1 is out. Available from GitHub and CKAN. Changes in that release : Updated for KSP 1.12.3 DockingPortDrift bugfix doesn't apply in 1.12.3 (identical fix was ported to stock) Moved KSPCommunityFixes in-game settings to a dedicated category in the KSP settings menu New QoL patches : DisableManeuverTool [KSP 1.12.0 - 1.12.3] Allow disabling the stock maneuver tool in the in-game settings menu (it can cause severe lag/stutter, especially with Kopernicus modified systems) SceneLoadSpeedBoost [KSP 1.8.0 - 1.12.3] Reduce scene switches loading time with large/modded saves by caching the current save in memory instead of loading it from disk. That's definitely doable. I might look into it when I get some time and motivation...

Do we really ? The last time the public bugtracker saw any official activity was 4 months ago, it has become an untriaged mess, issues fixed in 1.12+ weren't even closed there. I've posted a few issues or comments on existing issues with full details on the exact cause of some (rather major) bugs. Some of those have trivial fixes. If anybody was giving a look from time to time, those issues would have been noticed, I think... That's fine. KSP 1 development has stopped and no resources are being dedicated to its development anymore, life goes on. But those kind of statements are misleading, and the right course of action would be to make the bugtracker read-only, disallowing adding new issues until someone has the time to triage it. An unmaintained bugtracker is worse than a closed one.

Yeah, I should have been more specific. I meant not using PhysX RB joints, but rolling out a custom "rigid but breakable" part joint implementation. There is zero justification for not using PhysX colliders and not reusing RBs CoM computations. In other words, KSP could be handling forces and part positions by itself, instead of relying on the wholly inadequate for the purpose PhysX joints. But yep, this would be a complex hybrid implementation, and as you said, it's unlikely they have the resources for a low return on investment project like that. KSP1 joint physics are from ideal, but they still kinda work from a gameplay perspective, are (unfortunately) a huge part of KSP perceived "identity" and again, there are other much lower hanging fruits in terms of performance optimization. I'm' not aware of any "kill switch". Those two systems are quite deeply interlinked, you can't really have one without the other. They are also quite strongly interlinked with the orbit solver, and many various subcomponents (not to mention mods). I doubt it's possible to disable meaningful pieces of code there without cascading side effects everywhere.

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.