Gotmachine

V1.9.0 is out. Available from GitHub and CKAN. Changes in that release : New bugfix : RoboticsDrift [KSP 1.8.0 - 1.12.3] Prevent unrecoverable part position drift of Breaking Grounds DLC robotic parts and their children parts. New bugfix : DockingPortLocking [KSP 1.12.3] Fix some user-facing inconsistencies with the docking port rotation locking feature and hide irrelevant PAW items when the docking port is locked. New mod API patch : DockingPortLockedEvents (added for KJR, see related issue) PAWCollapsedInventories : Fixed mass/volume info not updating correctly in the group title. Now using Krafs.Publicizer for cleaner/faster access to KSP internals.

The rotating docking port feature is a mess and has several issues. I've given up on my attempt to make it work, and I highly suggest never using it. Use this mod instead : You can enable/disable individual patches either by editing the "Settings.cfg" file directly, or by creating a MM patch (create an empty text file and change the file extension to *.cfg) that you put in your GameData folder (that way you won't loose your changes when the mod is updated). @KSP_COMMUNITY_FIXES:FINAL { @PAWStockGroups = false }

It doesn't apply to 1.12.3 To which KSP versions each patch applies is mentioned in the OP or in the readme. In other new : V1.9.0 pre-release is available You can get it from github (it isn't available on CKAN yet) This pre-release introduce a fix for the BG robotics drift issue. That fix is a bit experimental, so I won't release it "officially" until I get some user feedback confirming everything is fine. Please help me by doing a bit of testing, but backup your saves first. What you should be looking for is part position/orientation changes in child parts of robotic parts following timewarp/physics cycling, scene switches or save/load cycles. For more details on the robotics drift issue, and on the fix, please read this : https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/13

V1.8.0 is out. Available from GitHub and CKAN. Changes in that release : New bugfix : AutoStrutDrift, see issue #21. Thanks to @Lisias for investigation efforts. Improve the overall physics stability when using autostruts and prevent autostrut induced deformations following vessel modification events (decoupling, docking/undocking, fairing separation...). New bugfix : PartStartStability, see issue #9. Fix vessel deformation and kraken events on flight scene load, also prevent some kraken issues when placing parts with EVA construction. The FlightSceneLoadKraken patch is superseded by the PartStartStability patch, which is now disabled by default Fixed a silly mistake with the OnDemandPartBuoyancy patch where it would prevent part buoyancy from running if the vessel is already below water at scene load. Thanks to @DRVeyl for catching that.

onVesselReferenceTransformSwitch is for when the "control from here" part is modified, this is indeed unlikely to help in any way. You could try offsetting the marker.transform.position by the value returned by GameEvent. onFloatingOriginShift, by I have some doubts this will work. The best way to make things work is likely to have your marker object a child object of the local CelestialBody, instead of having it floating around in world space.

The up-to-date "kerbalism page" is here. This forum thread op is unmaintained as SirMortimer hasn't been around in a long time, and I have no intent of opening a new thread myself.

Make sure you don't have special characters in your KSP folder name / install path, there is a KSP bug that make everything go haywire when URI special characters are used in the path. Usually, "+" is the culprit.

Have you tried with a stock engine instead of that one from KSPIE ? Those KSPIE engines have a lot of weird custom logic that likely don't play well with other mods trying to control them.

Kerbalism is balanced for stock system (time)scales. There is no specific compatibility for RSS. The RO folk are maintaining a dedicated fork of Kerbalism, but obviously that mean using RO (and ideally RP1).

Point 1 is correct, there is a "physics bubble" centered on the active vessel. Any other vessel entering that range (about ~2.5km in space, but depends on the situation) goes from the unloaded/packed (on-rails) state to the in-physics state. Your points 2 and 3 are wrong. When a vessel in "on rails" (unloaded or packed), its orbit is fixed and the vessel position is computed from the orbit parameters. When a vessel is in physics (loaded and not packed), it's the other way around, the vessel position and velocity is determined by the physic engine, and the orbit is computed from those parameters. So to answer your question, KSP doesn't "deal" with that situation. As long as a vessel is in physics, its orbit will be slightly unstable, as the physics simulation is it a result of is itself always slightly unstable. On a side note, inter-vessel collisions aren't guaranteed to happen. If the relative velocity between two in-physics vessels is too high, there is a decent chance the collision won't be detected at all. Moreover, collisions are entirely ignored when (non-physics) timewarp is engaged, as all vessels are put in the packed state during timewarp. And finally, collisions between unloaded vessels are ignored too.

It doesn't disable the maneuver tool by default. There is a setting for that in the main in-game settings menu.

No, I'm talking about the 1.12 maneuver planner tool. Maneuver nodes are fine. The maneuver planner tool runs a bunch of computations in the background, even if you don't use it, and if those fail (and they often do with various planet packs), this has the effect of freezing the game (or at least giving very heavy stuttering) and eventually crashing it. KSPCommunityFixes adds a toggle that allow you to disable it entirely.

The stock maneuver tool has many issues, especially with non-stock planetary configurations. And due to its fragile multithreaded implementation, those bugs tend to end much more badly than the usual KSP issues. So unfortunately, the only answer I can give is to use a mod instead. MechJeb is a quite good option.

It's not possible because Kerbalism manage transmissions at the vessel level, not at the module level, and IndicatorLights can only interact with modules.

Krakensbane isn't about velocity, it's about making sure the world origin stays centered on the active vessel to avoid FP precision issues. All that component does is to periodically reposition all objects in the world to ensure that. But it's a "low level" component, and any higher level data you usually have to deal with (orbit, velocities, etc) usually abstract that effect away. The only major consequence is that you can't compare positions between two points in time, but this is something that you shouldn't be doing anyway.

V1.7.0 is out. Available from GitHub and CKAN. Changes in that release : New performance patch : OnDemandPartBuoyancy (thanks to @siimav) Prevent the part buoyancy integrator from running when not needed. Improves performance for large part count vessels while in the SOI of a body that has an ocean (Kerbin, Eve, Laythe...) New bugfix : ROCValidationOOR (thanks to @R-T-B) Fix ROCManager crashing during loading with Kopernicus modified systems.

Does that really warrant any "fixing" ? At this point, given the general PAW clutter, one more or less PAW button isn't really significant, and I prefer not to touch something that isn't causing any issue, than risk introducing issues by altering a long standing stock behavior. My stance on KSPCommunityFixes is to be quite conservative in regard to altering stock stuff. As you saw with Commnet Antenna Info, touching seemingly trivial stuff always has side effects once you account for the billions of KSP mods.

I think it also determine what side is the "docked to" one, which might affect what vessel you get control of after undocking. There might be other uses/side effects, by that's all I can think of. Why are you asking ?

Well, not ideal but not very problematic either. Not sure what you want me to do about it, we are both messing with the stock PAW items groups, so obviously this won't end up very consistent...* Edit : to go a bit further, this happen because you're renaming the group instances KSPCF is assigning for each module. If you change your code to instantiate a new PAW group (instead of affecting a new name) and affect it to the items you want to control, your "CommNet" group will only contain those items, and the other items managed by KSPCF will stay in their own "Command" group. ie, instead of doing this : fieldA.group.name = "groupName"; fieldA.group.displayName = "groupTitle"; fieldB.group.name = "groupName"; fieldB.group.displayName = "groupTitle"; do something like that : BasePAWGroup pawGroup = new BasePAWGroup("groupName", "groupTitle", true); fieldA.group = pawGroup; fieldB.group = pawGroup;

You can do that with a MM patch, but there is no 100% guaranteed way to identify if an experiment is a sample or not. In stock, "conceptually not transmittable" experiments are configured with "rerunnable = False" (meaning you need a scientist to "restore" it). However, this assumption might not hold true in experiments from various mods. This being said, here is a quick and dirty MM patch that should do the job : @PART[*]:HAS[@MODULE[*ModuleScience*]:HAS[#rerunnable[True]]]:FINAL { @MODULE[*ModuleScience*] { @xmitDataScalar = 1 } } @PART[*]:HAS[@MODULE[*ModuleScience*]:HAS[#rerunnable[False]]]:FINAL { @MODULE[*ModuleScience*] { @xmitDataScalar = 0 } } @PART[*]:HAS[@MODULE[*ModuleScience*]:HAS[~rerunnable[]]]:FINAL { @MODULE[*ModuleScience*] { @xmitDataScalar = 0 } }

Vessel.ctrlState.mainThrottle

RDController.OnRDTreeSpawn is the callback you're looking for.

Depends what you mean by "mod friendly". KSP 1 "entry level" modding is really easy. The base framework provide a lot of handy shortcuts, and the general "straightforwardness" of the codebase make it accessible to anybody having a minimal coding experience. I'm speculating quite a bit here, but I expect the KSP 2 codebase to be primarily focused on performance and to use more "serious" coding practices. It doesn't mean the game will be "less moddable" (as long as it's a Unity game that doesn't use IL2CPP, moddability is near infinite), just that it might be less accessible to people with no coding background. There is no need for that. KSP1 / Unity has all the UI APIs a modder need. Those issues are actually non-issues if you use the proper UGUI framework. It isn't used for a variety of reason, the main one being that the other framework, IMGUI, is perceived as easier to use, implement and understand. This is a trap tons of mods tend to fall into. IMGUI quickly become a mess to work with as your UI grow in complexity, but once you've poured hours of UI coding work in the wrong framework, you are kinda stuck with it.

There isn't much they need to do, other than keeping the general code architecture extensible by making the relevant stuff virtual, and providing various code entry points like KSP does. But from the top of my mind, those are my top items : - A built-in mod installation/metadata manager like CKAN - A built-in configuration and dependency manager like ModuleManager (apparently something like that has been confirmed) - A better serialization framework - Do not obfuscate the assembly - Ship the game with all "optional" .NET packages A good dynamic code based UI framework would be nice. KSP has one, but it's quite clunky to say the least. Designing and coding a good dynamic UI framework is no small task, so I have some doubts we will get something significantly better. Unless they decide to integrate a third-party framework, but that wouldn't change the main issue, which is that UI making difficult, time consuming, not much fun, and usually not the part someone working for free want to spend time on. The issues with UI in KSP 1 mods mostly come from the fact that most of them are using the IMGUI system, which is an old legacy Unity thing for making development tools UIs. The few mods using the UGUI system don't have the issues you mention. The reason IMGUI is used over UGUI is that it is very easy to work with, but it has many functional and performance issues. Said otherwise, the main issue with KSP 1 mods UIs is that mod authors are sacrificing UI quality/performance/usability to cut on development time. On a more general note, I somewhat expect KSP 2 to not be as easily moddable. There are some "shortcuts" is KSP 1 that are extremely convenient and noob friendly from a coding perspective, but have very detrimental effects on performance and internal code complexity. I also expect some subsystems to use "advanced" techniques/tools like Unity Jobs/Burst, which are great for performance but introduce a lot of complexity and are a lot less straightforward to work with. And finally, there is the multiplayer aspect, which also introduce extra complexity and restrictions.

There is a PartResource.hideFlow bool. If set to true, it will hide the button that allow the user from toggling PartResource.flowState. So setting the following should completely lock the resource : resource.flowMode = PartResource.FlowMode.None; resource.flowState = false; resource.hideFlow = true; Edit : you will likely run into the issue that when setting hideFlow, if the PAW is already opened (or has been opened previously), the flow toggle button will still stay visible or hidden. You will likely need to manually trigger a PAW rebuild when your "resource locking" event is triggered : if (resource.part.PartActionWindow != null) resource.part.PartActionWindow.displayDirty = true;