Gotmachine

V1.11.0 is out. Available from GitHub and CKAN. Changes in that release : New bugfix : ExtendedDeployableParts [KSP 1.12.0 - 1.12.3] Fix deployable parts (antennas, solar panels, radiators...) always starting in the extended state when the model isn't exported in the retracted state. This bug affect parts from various mods (ex : Ven's stock revamp solar panels). New performance tweak : TextureLoaderOptimizations [KSP 1.10.0 - 1.12.3] Speedup loading time by caching on disk the PNG textures KSP converts to DXT5 on every launch. Also make PNG @thumbs cargo part textures non-readable to free some RAM. This patch has no entry in settings.cfg, but is opt-in (a popup is shown on first KSP launch) and can be disabled latter in the in-game settings menu. New Qol tweak : HidePartUpgradeExtendedInfo [KSP 1.8.0 - 1.12.3] Hides irrelevant extended info on the part tooltip for PartUpgrades in the RnD screen. Courtesy of @NathanKell (see #29)

Well, this is a completely different thing. Stuff moving around in physics is a result of the physics simulation itself, there is no real way to make it "less slippery", apart from disabling/overriding the physics simulation results altogether. Which could be a solution. Squad kinda implemented something like that for Kerbals on ladders, where as long as you don't actively move on the ladder, the Kerbal is "pinned" to its current position. But in that case, this would be a completely new feature, likely an UI option that you activate to "pin the vessel to the ground". This is kinda out of the scope of this mod and that would be quite some work to implement right. This being said, if you need something like this, there is https://github.com/gotmachine/PhysicsHold Just be aware that this is kinda experimental, that I offer no support whatsoever for that mod, and that it has a bunch of caveats (read the readme carefully).

V1.10.1 is out. Available from GitHub and CKAN. Changes in that release : DockingPortRotationDriftAndFixes refinements : Fixed the stock implementation being unable to handle a rotating docking ports when it is the root part (was throwing exceptions and generally wasn't working correctly) Fixed another stock bug : having a rotationAxis other than "Y" result in the docking port still rotating around the Y axis. This bug affect the 2 "inline" stock docking port parts. Fixed KSPCF bug : parent port not being able to rotate after re-docking Fixed KSPCF bug : things were not working as expected when using a rotating + non-rotating docking port pair Fixed KSPCF bug : prevent rotation being available when about to dock or after undocking when the other docking port is "acquired" but not docked. Various performance optimizations @flartThis should fix the exceptions you had. Let me know if there is still an issue.

There isn't any decompilation involved in any of this. This is using a quite self-explaintory "moduleCosts" public field and public GameEvents that aren't any more or less documented than anything you're using in your plugin. [snip]

[snip] On your specific issue with your refunding thing, I didn't investigate in detail, and I won't. I'm just pointing out that you are spending a lot of time and effort trying to solve side issues that you're responsible for in the first place with that refunding hack implementation, something I warned you would happen. The piece of code I suggested a year ago (team play !) is perfectly within the bounds of any KSP rule or country law, and certainly not any more or less than your own or any other KSP mod. No idea what you're talking about. IMO, refining it (as it is, it has the issue that cargo parts IPartCostModifier costs will be accounted for twice, but there are ways to fix this) would be much less work than trying to fix your current implementation. If you want to keep your solution of tracking IPartCostModifier costs though a PartModule on every part (which is useless since stock already does it correctly, available in ProtoPartSnapshot.moduleCosts), you could at least get ride of the fake resource thing (which is the main cause of the side issues). Just persist your results on the module, then analyze the persisted state of that module in a onVesselRecoveryProcessing or onVesselRecovered callback (you could even keep the injection of your "refunding" resource for UI feedback, but by doing it only just before recovery you're greatly limiting the potential side effects). If you have questions about any of this, feel free to ask.

Simple. The inventory system doesn't allow parts having resources to be stacked, so your Refunding stunt essentially prevent any part from being stacked. The behavior is inconsistent because the check for this is only done in ModuleCargoPart.OnLoad(), which might not be called at all (newly instantiated parts in the editor) or called before you alter the part resources Arguably this check should be enforced every time a part is manipulated, but in KSP defense, altering resources at runtime isn't a scenario that stock support out of the box. Anyway, the only thing you can do is enforcing that rule from your side when you add the resource (setting ModuleCargoPart.stackableQuantity to 1 when it is >1), but that mean loosing the stacking functionality altogether. To quote myself from a year ago : A statement that has never ceased to prove itself over the last year. If I may remind you, there is still a much cleaner solution to that KSP issue available for you to implement lying on a gist.

@Matt77After some testing, I'm don't think this is really "fixable". If you use struts to "close" a loop of parts that include robotic parts, and then move the robotic parts, you're playing on the strut joint flexibility. So if you change the relative position/orientation of each part connected on either end of the strut (using robotic parts in the middle), the strut will somewhat follow as far as its joint flexibility allows while in physics. Thing is, a robotic part is designed to allow a degree of freedom (either on one translation, or one rotation), and is capable of keeping track of its displacement. A strut can't do that. It has a designated position/orientation, and will always keep it. The result is that when saving the vessel, the robotic parts will save their current displacement, but the strut won't (it will keep it's original "target coordinates") So when reloading the vessel, the parts will have moved compared to the original vessel, but not the strut, so its "end target" will end up nowhere near what you would expect. So you could say : "then update and save the joint target !". But that would only solve things on the cosmetic side. In your screenshot, the strut is visually mid-air, but it is actually still connected. This mean every time you save/reload, you end up with a strut that lock your robotic parts in their current positions, with no guarantee that said robotic parts are able to force-stretch back the strut in the original position. In the end, the conceptual issue is that KSP doesn't save the full "in physics" state of the vessel. The original KSP assumption is that it has "original" coordinates for each part, and when you reload the vessel, it put the parts there and recreate brand new unstressed joints between them. The "drift" issue in a nutshell is that when robotics parts are involved, the "elastic" deformation is saved as a "plastic" deformation : the "original" coordinates are overridden with the current in-physics part coordinates. This obviously wrong in the context of that initial KSP assumption, and the end result is the progressive "drifting" of the part positions as you save and reload the vessel multiple times. So what I'm doing to prevent this is to recompute the theoretical part positions resulting from robotic displacement as if there was no in-physics deformation at all. If a piston is extended by 1 meter in a direction, all connected parts "original" coordinates are moved by precisely 1 meter in that direction. This is fine for an "open" part tree, but if you "close" the tree with struts with the expectation that the struts will act as some sort of pivot, this all fall apart. To have that work, it would require KSP to not only save and restore part coordinates, but also the state of each joint connecting them (ie, the torques and forces the joint is currently experiencing) In the context of a "strut fix", even if there was some way to convert back the current forces/torques to obtain a somewhat reliable joint target position/rotation offset, that would register all current forces/torques on that specific joint, so the result would be unusable unless the same is done on every other joint in the part loop. So I don't really see a way to fix this. The "closing a robotic part loop with struts" use case isn't really something that can be handled correctly.

It is definitely in the scope of this mod. I just need to figure out how to fix it Do you mean that you extended them, and after reloading the vessel they were not extended like you left them ? That feels weird to me. Are you sure of that ? Not on docking, but on undocking, the undocked vessel root part will be the docking port. Anyway, that is very likely the cause of the exception, the stock implementation is completely broken when a docking port is a root part. I'm fixing it, that issue will hopefully be gone in the next KSPCF update.

@flartDo you have a docking port as a root part ? The stock code definitely will have trouble handling that.

I'm not sure what I am looking at. What is your issue exactly ? Also, I can't open that craft file, as it uses a bunch modded parts. Could make a simple craft that reproduce your issue with only stock parts ? Edit : I guess your issue is the strut target position not being updated ? Indeed that's an issue, but a completely different one than what the KSPCF patch is for. I will try to look into it...

Well, you think you're right, I think I'm right. Your example is cute, but can't be generalized. But indeed "exact math" can be done, I said so previously. Feel free to do it. That still is pointless for all the reasons I gave, but you won't care anyway, hey ? Lets agree to disagree

You can't expect a reliable result when comparing two previously manipulated floating point numbers for equality (or even "near equality"). That's a basic rule in programming and applies to every standard programming / scripting language, you can't implement predictable conditional logic based on FP number comparisons. So it's not "broken", it just doesn't work like you think. And if you have logic relying on FP numbers equality in MM patches, you shouldn't. Your perceived "accuracy issue" doesn't matter in the context of running the game. It's not an edge case, similar variance will always happen at runtime when FP values are manipulated, no matter how "round" your initial configured values are. And I'm not sure where you're getting your "2 decimal" figure. The error in your example is 0.0000000000000004, which is quite close to the maximum possible precision of a 64 bit float (17 decimal places). The only possible consequence is having the user facing values being "not round" in the UI, but even that is highly unlikely, as most values in the UI are shown with some some rounding applied. Technically, the MM parser could implement custom "exact" math for add/substract which would satisfy your examples (something like https://github.com/AdamWhiteHat/BigDecimal/blob/master/BigDecimal/BigDecimal.cs) However, doing it for the other operators (multiply/divide/exponentiate) would be pointless, as the config format is limited to a 64 bit float string representation anyway (and that is actually also an issue for add/sustract depending on the range of your values). So for example doing something like : val = 1 @val /= 3.15 @val *= 3.15 Would still result in val = 0.99999999999999989 instead of 1, because the intermediate division result will have lost some precision for a round trip after the multiplication. So in the end, anything you can do doesn't provide a general solution to your "I want exact math" issue. KSP (and by extension MM) are backed by FP numbers. No matter what you do, the inherent limitations will always be there. Trying to hide them in a tiny subset of the application won't change anything.

No. It doesn't matter because everything the game does has a similar level of floating-point related inaccuracy. That FP inacurracy at the MM level is just the first one to happen, there will be tons of similar arithmetic operations (with similar level of inaccuracy) done when the game manipulate those configured values. https://dotnetfiddle.net/YpZzvs

Yes this isn't an "error", that's just how floating point types work.

Nothing of relevance for the end user. They implement missing stuff / fix some inconsistent behavior in the KSP "API", and were implemented at the request of other modders (DrVeyl and NathanKell), which are free to enable them if/when their own plugins make use of it. They are disabled by default because since they technically alter the "stock" API, there is a (really tiny) chance they can have a side effect on another random plugin. I checked a possible impact by doing a global github search and didn't found any plugin for which those patch could cause an issue. Making them "opt-in" is an additional safeguard in case I missed something.

V1.10.0 is out. Available from GitHub and CKAN. Changes in that release : New bugfix : DockingPortRotationDriftAndFixes [KSP 1.12.3] This patch contain several docking port fixes, and supersede the DockingPortLocking and DockingPortDrift patches, those patches have been removed. Make the stock docking port rotation feature actually useable : Completely prevent unrecoverable position drift of children parts of docking ports. Fix joint failure and phantom forces when a docking port pair is set to opposite extreme angles. Allow tweaking the rotation in the editor and while not docked in flight. Rotation can now be properly used in a robotic controller. Remove the -86°/86° hardcoded limitation of hardMinMaxLimits, it is now -180°/180°. Fix many issues and state inconsistencies. An optional DockingPortExtendedRotation.cfg.extra MM patch extending rotation range to 360° is available in the Extras folder. Copy it to your GameData folder and remove the .extra extension to use it. New bugfix : PackedPartsRotation [KSP 1.8.0 - 1.12.3] Fix part rotations not being reset to their pristine value when a non-landed vessel is packed, resulting in permanent part rotation drift when docking and other minor/cosmetic issues. This patch is a generalization of a fix previously implemented in RoboticsDrift, and now cover all occurrences of that issue. New QoL patch : FairingMouseOverPersistence [KSP 1.8.0 - 1.12.3] (suggested by forum user @dok_377) Make the "Fairing Expansion" state persistent when reloading a craft in the editor. New mod API optional patch : OnSymmetryFieldChanged [KSP 1.8.0 - 1.12.3] (thanks to @DRVeyl) Disabled by default, you can enable it with a MM patch. Change the UI_Control.onSymmetryFieldChanged callback to behave identically to the UI_Control.onFieldChanged callback : The callback will only be called when the field value has actually been modified. The "object" argument will contain the previous field value (instead of the new value). New mod API optional patch : PersistentIConfigNode [KSP 1.8.0 - 1.12.3] (thanks to @NathanKell) Disabled by default, you can enable it with a MM patch. Implement IConfigNode members marked as [Persistent] serialization support when using the CreateObjectFromConfig(), LoadObjectFromConfig() and CreateConfigFromObject() methods. PartStartStability : fixed the patch causing an ArgumentOutOfRangeException on scene/vessel load in FlightIntegrator.Update(). As a side effect, this patch now make the FI first "valid" execution deterministic (will always be on the fourth FixedUpdate() cycle). RoboticsDrift : fixed incorrect handling when a robotic part is the vessel root part Prevent some patches failing with a ReflectionTypeLoadException when another plugin assembly fail to load (ex : the Sandcastle/EL integration assembly)

In case someone stumble on that thread, a fix for that issue is available in :

It's not. It's a (slightly stripped down) BSD license, as mentioned on the spacedock page and in full in the readme. Under the BSD license terms, anyone can redistribute a modified version, as long as the original license is kept.

I'm not entirely excluding it, but it's very likely a stock issue. I've seen this exception happening while testing other stuff a while ago, and I remember being able to reproduce it without KSPCF (but I might remember wrong) I'm not able to reproduce it right now, giving me a reproducible test case would help (also, which KSP version ?).

Thanks for the detailed report. So, two things happening here : - There is a missing check in KSPCF causing the "[RoboticsDrift] Servo info not found..." log entries when the "locked" state of a robotic part is toggled in the editor. This is harmless, but I will correct it to avoid the log spam. - The "NullReferenceException" log spam is unrelated to KSPCF, this is a stock bug. This happen because you have the "control from here" command module action assigned in the KAL controller, and that action is failing to signal that it shouldn't be executed while in the editor. V1.9.1 is out. Available from GitHub and CKAN. Changes in that release : RoboticsDrift : fixed (harmless) [RoboticsDrift] Servo info not found... log spam when toggling the locked state of a robotic part in the editor

From memory, yes, the solution and effect should be pretty similar. There are more or less only two ways to implement translation/rotation actuation interactions with the part coordinates, a drift inducing one and an okay one. Stock robotics were just using the wrong one If there are issues with the KSPCF fix, it's likely more implementation issues/oversights when interacting with the stock robotics code. The "drift fixing math" part should be pretty solid, I believe.

No, that won't change anything as far as AnimatedAttachment is concerned, this should be fixed from within this mod. And I'm not entirely sure about this, but I have some doubts this mod interacts correctly with stock robotics anyway, no matter if KSPCF is involved or not. Fixing this mod would involve a solution nearly identical to what I implemented to fix the robotic drift issue, but from a quick look at the source code, it probably would have to be rebuilt from scratch with a different approach for its intended purpose. What this mod is trying to do isn't easy and its implementation is taking too many shortcuts to be really viable IMO.

Krafs.Publicizer is a nuget package that interact with your IDE and compiler through MSBuild. It doesn't care about the platform you're using. Unless you're using an antiquated (non-Roslyn based) version of Mono to compile your project, it should work. This being said, if for some reason you're unable to use it, you can achieve the same effect manually : - Use an assembly publicizer tool on Assembly-CSharp (for example https://github.com/iRebbok/APublicizer or https://github.com/BepInEx/NStrip ) - Use the resulting Assembly-CSharp in your project reference when writing your code in whatever IDE you're using, and use that reference for your compiler. - Add "<AllowUnsafeBlocks>true</AllowUnsafeBlocks>" to your plugin *.csproj

I hope so. I did a fair bit of testing on my side, but there is always the possibility of some corner case I missed. Let me know if you encounter any issue.