YellowApple

When right-clicking one of the Kerbal Foundries wheels in the SPH, instead of a working PAW, I get the following exception (with preceding context between adding the part and right-clicking on it): KF-WheelMedium added to ship - part count: 19 (Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 35) [11/19/2021 5:33:37 PM [x] Science!]: <Info> (StatusWindow) - StatusWindow.RefreshFilte r (Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 35) [11/19/2021 5:33:37 PM [x] Science!]: <Info> (ScienceWindow) - ScienceWindow.RefreshFil ter (Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 35) NullReferenceException: Object reference not set to an instance of an object at KSPCommunityFixes.UIPartActionNumericFloatEdit.Setup (UIPartActionWindow window, P art part, PartModule partModule, UI_Scene scene, UI_Control control, BaseField field) [ 0x0001c] in <8f81c7b736764f37a0edca532f4ee0dc>:0 at UIPartActionWindow.AddFieldControl (BaseField field, Part part, PartModule module) [0x00073] in <4a4632fe4eb0471fa0f9f87bb7432bc2>:0 at UIPartActionWindow.CreatePartList (System.Boolean clearFirst) [0x002bc] in <4a4632fe4eb0471fa0f9f87bb7432bc2>:0 at UIPartActionWindow.Setup (Part part, UIPartActionWindow+DisplayType type, UI_Scene scene) [0x0006a] in <4a4632fe4eb0471fa0f9f87bb7432bc2>:0 at UIPartActionController.CreatePartUI (Part part, UIPartActionWindow+DisplayType type, UI_Scene scene) [0x000f7] in <4a4632fe4eb0471fa0f9f87bb7432bc2>:0 at UIPartActionController.SelectPart (Part part, System.Boolean allowMultiple, System.Boolean overrideSymmetry) [0x001a7] in <4a4632fe4eb0471fa0f9f87bb7432bc2>:0 at UIPartActionController.HandleMouseClick (UnityEngine.Camera cam, System.Boolean allowMultiple) [0x0003f] in <4a4632fe4eb0471fa0f9f87bb7432bc2>:0 at UIPartActionController+<MouseClickCoroutine>d__39.MoveNext () [0x00082] in <4a4632fe4eb0471fa0f9f87bb7432bc2>:0 at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00026] in <2425394cf09642369e2109953e31f62b>:0 The exception itself then repeats hundreds of times. After this exception gets thrown, all other parts stop responding to right-clicks (i.e. no PAW window appears, and no further exceptions thrown) until I exit and reenter the SPH. Not sure if this is an issue with the newly-introduced UIFloatEditNumericInput patch specifically or if there's some issue with Kerbal Foundries that's triggering it. Haven't encountered any other parts (vanilla or modded) that have this issue. Unsurprisingly, after downgrading KSPCommunityFixes to 1.3.0 I can right-click on Kerbal Foundries wheels just fine, so whatever the issue is seems isolated to some interaction between UIFloatEditNumericInput and Kerbal Foundries.

Nice! Thanks! Unfortunately all mine are CNC-initialized at this point already, so probably can't do much to test it. Unless there's a way to delete the CNC data for a given craft?

Yep, that development build seems to have done the trick; UI (mostly) works as expected. I say "mostly" because I'm getting NullReferenceExceptions when trying to use the UI to edit the antenna frequency assignments on previously-launched craft (specifically, by clicking on any of the "Management" buttons in a pre-CNC-launched craft's "Setup" window): NullReferenceException: Object reference not set to an instance of an object at CommNetConstellation.CommNetLayer.CNCCommNetVessel.readAntennaData () [0x000d8] in <c3d7796138f34e91b11081a96027aa82>:0 at CommNetConstellation.CommNetLayer.CNCCommNetVessel.getAllAntennaInfo (System.Boolean readAntennaData) [0x0000b] in <c3d7796138f34e91b11081a96027aa82>:0 at CommNetConstellation.UI.VesselMgtTools.AbstractMgtTool.precompute () [0x00000] in <c3d7796138f34e91b11081a96027aa82>:0 at CommNetConstellation.UI.VesselMgtTools.ToolContentManagement.selectTool (System.String toolCodename) [0x00060] in <c3d7796138f34e91b11081a96027aa82>:0 at CommNetConstellation.UI.VesselMgtTools.ToolContentManagement+<>c__DisplayClass9_0.<getLayoutContents>b__0 () [0x00000] in <c3d7796138f34e91b11081a96027aa82>:0 at DialogGUIButton.OptionSelected () [0x00000] in <8ed6226a17824027b61a78aa9c35f6f0>:0 at DialogGUIButton.<Create>b__23_1 () [0x00000] in <8ed6226a17824027b61a78aa9c35f6f0>:0 at UnityEngine.Events.InvokableCall.Invoke () [0x00011] in <7d9ec060e791409ab3eb85c61e312ed6>:0 at UnityEngine.Events.UnityEvent.Invoke () [0x00023] in <7d9ec060e791409ab3eb85c61e312ed6>:0 at UnityEngine.UI.Button.Press () [0x0001c] in <b8803ab285134f53a88a8b0a5eabde77>:0 at UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) [0x00009] in <b8803ab285134f53a88a8b0a5eabde77>:0 at UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) [0x00007] in <b8803ab285134f53a88a8b0a5eabde77>:0 at UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.ExecuteEvents+EventFunction`1[T1] functor) [0x00063] in <b8803ab285134f53a88a8b0a5eabde77>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) UnityEngine.EventSystems.ExecuteEvents:Execute(GameObject, BaseEventData, EventFunction`1) UnityEngine.EventSystems.StandaloneInputModule:ReleaseMouse(PointerEventData, GameObject) UnityEngine.EventSystems.StandaloneInputModule:ProcessMousePress(MouseButtonEventData) UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent(Int32) UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent() UnityEngine.EventSystems.StandaloneInputModule:Process() UnityEngine.EventSystems.EventSystem:Update() However, this goes away (for a given craft, at least) once I've switched to flying the affected craft at least once (all "Management" buttons seem to function as expected, and the "Active frequencies" list populates correctly), so I'm guessing there's some initialization step that needs to happen in the flight view for each craft before CNC can see it (which might've contributed to the root cause of the dictionary key exception, come to think of it). In any case, it's at least playable now (even if it was a bit annoying having to switch to each craft to get it to fix itself).

Getting similar issues as @Jiraiyah. Installed on KSP 1.11 on Linux via CKAN. In particular, getting the following exception whenever I click on the icon for it (in any context, be it map view, tracking station, or normal flight): KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2[TKey,TValue].get_Item (TKey key) [0x0001e] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at CommNetConstellation.UI.ConstellationControlDialog.AddVessels (CommNetConstellation.UI.TreeEntry tree, System.Collections.Generic.Dictionary`2[TKey,TValue] dict) [0x00052] in <79ca5fc98ea740e89d017261cb469175>:0 at CommNetConstellation.UI.ConstellationControlDialog.getVesselContentLayout () [0x0003b] in <79ca5fc98ea740e89d017261cb469175>:0 at CommNetConstellation.UI.ConstellationControlDialog.drawContentComponents () [0x000f4] in <79ca5fc98ea740e89d017261cb469175>:0 at CommNetConstellation.UI.AbstractDialog.spawnDialog () [0x00000] in <79ca5fc98ea740e89d017261cb469175>:0 at CommNetConstellation.UI.AbstractDialog.launch (System.Object[] args) [0x0000f] in <79ca5fc98ea740e89d017261cb469175>:0 at CommNetConstellation.UI.AbstractDialog.launch () [0x00000] in <79ca5fc98ea740e89d017261cb469175>:0 at CommNetConstellation.CommNetConstellation.Launch () [0x0001d] in <79ca5fc98ea740e89d017261cb469175>:0 at (wrapper delegate-invoke) <Module>.invoke_void() at KSP.UI.Screens.ApplicationLauncherButton.OnTrue (UnityEngine.EventSystems.PointerEventData data, KSP.UI.UIRadioButton+CallType callType) [0x00000] in <8ed6226a17824027b61a78aa9c35f6f0>:0 at UnityEngine.Events.InvokableCall`2[T1,T2].Invoke (T1 args0, T2 args1) [0x00011] in <7d9ec060e791409ab3eb85c61e312ed6>:0 at UnityEngine.Events.UnityEvent`2[T0,T1].Invoke (T0 arg0, T1 arg1) [0x00023] in <7d9ec060e791409ab3eb85c61e312ed6>:0 at KSP.UI.UIRadioButton.SetState (KSP.UI.UIRadioButton+State state, KSP.UI.UIRadioButton+CallType callType, UnityEngine.EventSystems.PointerEventData data, System.Boolean popButtonsInGroup) [0x00079] in <8ed6226a17824027b61a78aa9c35f6f0>:0 at KSP.UI.UIRadioButton.ToggleState (KSP.UI.UIRadioButton+CallType callType, UnityEngine.EventSystems.PointerEventData data) [0x00026] in <8ed6226a17824027b61a78aa9c35f6f0>:0 at KSP.UI.UIRadioButton.UnityEngine.EventSystems.IPointerClickHandler.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) [0x0011e] in <8ed6226a17824027b61a78aa9c35f6f0>:0 at UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) [0x00007] in <b8803ab285134f53a88a8b0a5eabde77>:0 at UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.ExecuteEvents+EventFunction`1[T1] functor) [0x00063] in <b8803ab285134f53a88a8b0a5eabde77>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) UnityEngine.EventSystems.ExecuteEvents:Execute(GameObject, BaseEventData, EventFunction`1) UnityEngine.EventSystems.StandaloneInputModule:ReleaseMouse(PointerEventData, GameObject) UnityEngine.EventSystems.StandaloneInputModule:ProcessMousePress(MouseButtonEventData) UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent(Int32) UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent() UnityEngine.EventSystems.StandaloneInputModule:Process() UnityEngine.EventSystems.EventSystem:Update() Further, getting a lot of "[CommNet Constellation] Vessel '(VESSEL NAME)' doesn't have any CommNet capability due to no probe core/command part or a kerbin on EVA", even for (in fact, especially for) vessels that I know for sure have probe cores. Full log: https://yellowapple-misc.s3-us-west-2.amazonaws.com/CommNet-Constellation-troubleshooting-2020-12-29/Player.log EDIT: Maybe something with one of these two methods not correctly building the expected "dict"? Looks like it's trying to pull an existing list of constellations, but this is a new(-ish) game that hasn't had constellations setup yet, so maybe that's the issue? Except it looks like the default constellation config is accounted for in the logs, so... ¯\_(ツ)_/¯

Would it be possible to make it clearer in the description that this mod makes the asteroids bigger? Installed this mod only to find that stuff already jaw'd to an asteroid I previously captured is now deep inside the asteroid (thankfully just some docking ports and a probe core, nothing too important, lol). I definitely appreciate the size tweaks, though; asteroids feel a lot more imposing, and it's gonna be a fun challenge to capture 'em when even Class As make stock Class Es look tiny.

Just a quick report that - as far as I can tell from some preliminary tests on my end - ScanSAT works fine as-is with KSP 1.5.1. Haven't tested with all parts and all scanning modes, but the basic (greyscale) altimetry scanner seems to do exactly what I'd expect.

I'd love to see this expanded eventually. For example: Fish could count toward science or funds when caught, depending on how big they are and how far away they are from the KSC (so, Administration Pond fish are less valuable than coastal fish are less valuable than polar fish are less valuable than Eve fish are less valuable than Laythe fish, and so on). Actual fish models. I'd love to see Jeb holding his latest catch proudly for the cameras... er, screenshot tools. Fishing boat parts (like mechanical fishing rods or dragnets or somesuch to catch bigger/deeper fish, for example). Ability to process "fish oil" into fuel or something. The list goes on... Until then, though, I've noticed a bug in the 1.1 version: after entering the fishing view, casting, reeling back in, and exiting the fishing view, kerbals can't climb onto things; something fails with the kerbal animation, and they kind of just float back down to the ground and can't move. Quicksaving and quickloading fixes this when it happens. Maybe some bug with the kerbal animation? There aren't any exceptions in Player.log when this happens (but there is a spamming of "set fishing state to NotFishing"). EDIT: this also affects ladders. The climbing animation will start, and then Jeb will just revert to a standing pose and freeze there. In the case of the ladder, though, the affected kerbal will still be able to move up/down (without any climbing animations), but upon reaching the top will fall down, start ragdolling erratically, then eventually "crash into terrain" and die. Screenshot for reference. Moar EDIT: fishing from on top of a craft (in this case, the same rover I was trying to climb onto) and actually managing to board in that state (i.e. by grabbing onto the crew hatch and hopping in), quicksaving, and quickloading causes the game to hang at the black "Loading" screen amid the sounds of one's craft exploding rather spectacularly. Exiting and reloading KSP temporarily fixes this particular issue.

As another Linux user, I got confused at first since most of the time (for the exact reason that seems to be underlying some other responses in this thread) KSP (and the mods thereof) use the right-hand Shift key on Linux where Windows (and Mac?) users would use Alt. I feel this, also, is worth mentioning. As for Alt + P not working, this is usually caused by one's window manager or desktop environment capturing the Alt key (or that specific keypress). I personally avoid that issue by rebinding my window manager's keyboard shortcuts to use Super ("Windows") instead of Alt. Suggestion: would it be feasible to put in a button (either in the KSP builtin "app" thingamajig or using Blizzy's toolbar) for those users who experience conflicts with other mods that use Alt + P (like Pathfinder and Smokescreen)? For Linux users this shouldn't be an issue (since they predictably use RShift + P instead of a literal Alt + P), but it'd still be a nice feature to have

There's a mod for this, but it appears there are some significant limitations (namely, when it comes to multiple RCS ports / solar panels / landing legs / crew hatches / etc. in the result).

When 0.90 came out, I submitted my "Hummingbird Mk.1" design to the "K Prize" thread here on the forums. I was going for the lightest, but I don't recall if I actually won the title. Once 1.0.x was out, I then reworked the design and barely managed to take the prize yet again. Readapting it for KSP 1.1 is on my bucket list.

As far as I can tell, this is a Unity bug; other Unity games (like Cities: Skylines) have the same problem when running under 64-bit Linux. I've tried asking about this in Unity-land, but I haven't gotten anywhere. Best one can do is limit how many mods are installed while hoping that the problem doesn't exist in Unity 5.

If anyone's still following this, the 16GB hard limit bug ("Using memoryadresses from more that 16GB of memory" [sic]) has been reported to Squad, and (based on my own experimentation) is a Unity 4 bug, rather than KSP-specific (also affects other Unity 4 games, like Cities: Skylines). I've also opened up an inquiry on Unity3D question/answer site for further details on that particular message specifically. Hopefully such artificial RAM limits will go away once we get Unity 5 (though given the multiple spelling errors, I suspect this might be some very dusty corner of Unity's codebase that might not have been adequately tested or identified...). EDIT: given that Cities: Skylines has since (or maybe it was all along) moved to Unity 5, and given that Cities: Skylines continues to have the same exact error (complete with the same exact poorly-spelled error message), it's doubtful that KSP 1.1 will solve this issue.

I've noticed a strange issue where base map icons (in my case for KerbinSide, but I'd imagine this would happen with other, non-KerbinSide KK bases as well) are appearing in non-map screens (KSC overview, VAB/SPH, etc.) after reverting from a flight to the SPH or VAB. I didn't notice this until I had selected Kerbin in the map view during a flight (in order to figure out where to land my spaceplane); since then, it's been happening pretty regularly, even after restarting KSP. Said icons are usually scattered near the top-right of the screen in the VAB/SPH immediately after the revert. Going to the KSC overview screen puts an icon over each of the KSC's launch sites. Going to the Tracking Center and back out seems to make the problem go away temporarily. Any ideas? This is a pretty-heavily-modded install; perhaps it's a mod conflict of some sort? It looks like, though, that whatever draws the icons doesn't properly destroy itself when reverting back to the VAB/SPH. I've yet to notice this happen when recovering a vessel.

I was only suggesting referring to CKAN's data for this sort of thing, since a lot of it (particularly when it comes to required/recommended/suggested mods for a given mod) is already tracked on their end and would therefore be less work. Regardless of one's opinions on the qualities of CKAN v. KSP-AVC, it would be a good starting point for such a proposed compatibility/support list. Sorry if I set off a nerve.

Some of this functionality is already provided by CKAN (I'm not sure about incompatibility detection, though); if not implementing incompatibility detection in CKAN itself, a standalone tool could skip a lot of the grunt work by using CKAN's metadata.

FAR still goes above and beyond what stock does. In my observation, stock's closer to NEAR than FAR: slightly more realistic without severely sacrificing gameplay "fun" (as opposed to FAR, which emphasizes realism as the number one priority). There are quite a few mods that (for whatever reason) still require Toolbar, and many of the rest still support it. While I personally prefer the stock toolbar in most circumstances, the fact that Toolbar continues to be supported (and even required) by various mods indicates that at least some folks feel differently. I still use it; rockets are still too wobbly for my tastes without it. Never used it, so I wouldn't know. Most of these mods (other than perhaps FAR) are pretty lightweight memory-wise compared to most other mods. Hopefully Squad gets around to working out the kinks with the 64-bit Windows version (thus bringing it up to par with the 64-bit Linux version, which is rock-solid in my experience), but I probably wouldn't be all that concerned about memory from things like Toolbar and KJR. Basically, KJR's pretty safe to go with. Toolbar's probably going to be mandatory depending on what other mods you use. FAR is still viable if you prefer near-absolute realism over the new stock system's balance of realism and accessibility.

I've found my most common uses of IR to be trailer hitches (for articulated trucks/lorries) and rotating platforms for radio/antenna dishes. I've built the occasional crane here and there, though I haven't done so with 1.0.x yet (since I generally use KAS - particularly the magnet and winch - for a lot of that, and I'm waiting on the KIS-functionality-deduplication update to be released).

After having made the list with the Hummingbird Mk.1 on 0.90, I figured I might as well try my hand at adapting it for 1.0.0. Surprisingly enough, it worked. Barely.

Just like with the old aerodynamic model, you can gauge whether or not you're hitting terminal velocity by the reentry effects appearing, so what I do is just use those as a gauge, gradually adjusting thrust while watching the flames to keep them as dim as possible (then, when they disappear, ramping up thrust ever so slightly until either maxed or the flames reappear). It isn't the most scientific approach, but I've found that it still *generally* works for my various SSTOs (though the sooner you punch through the lower atmosphere and hit a good cruising altitude - just on the cusp of losing intake air - the better; this is different from the old model, where terminal velocity seemed to be higher for whatever reason, thus allowing one to spend more time at lower altitudes building speed). For rockets, you're pretty much in the clear and able to hit the gravity turn with reasonable (maybe not *quite* optimal, but I haven't measured yet) efficiency once you get past 11km; start full-thrust until you start seeing white, then back off until you're at that 10-11km mark (at which point ramp up the thrust again). Most calculators probably haven't been adapted to the new physics model yet, so they're going to be off. Until then, "use the Force, Luke" and you'll be fine.

Also able to confirm similar symptoms; specifically, the following: Time would seemingly stop upon switching to a flight scene. One instance of a ship flying apart. During the above-mentioned bouts of suspended animation, some ships would have very strange thruster behavior without actually producing any thrust (even on ships that do not have any fuel whatsoever and are drifting aimlessly in space). Exhibit, for reference. Barrage of NullReferenceExceptions originating from TweakScale upon switching to a flight scene (I unfortunately did not save a copy of Player.log for further diagnosis, though I'd be happy to spin up a clean KSP 0.90 and try to test). Given the origin of the NullReferenceExceptions, I removed TweakScale (and subsequently removed and readded some other mod that complained about a lack of TweakScale despite not listing it as a dependency in CKAN metadata), and the problems resolved themselves. TweakScale is almost certainly the culprit (and is indeed the common denominator in every "me too" post in this particular thread. This has been reported by several others on TweakScale's thread (and at least one of those reports mentions this thread), so it's at least already been brought to someone's attention.

Cheers! Thanks.

First time I've actually submitted any of my SSTO spaceplanes to this particular thread. If I'm not mistaken, this particular flight would earn me the Advanced Pilot Precision Award (surprisingly enough) and Utilitarial Commendation. I'm not sure if this comes even close to the Minimalist Record, but small size / minimum parts with an entirely-stock design was one of my goals. I've been kicking around this particular design since 0.23.5, with incarnations for 0.24.2 and 0.25 prior to this one for 0.9. I've featured a prior incarnation of the Hummingbird (when I first devised it after toying around with speedboat designs) on /r/kerbalspaceprogram, but this is the first time that I've actually managed to document getting one to orbit and back safely, let alone without boosters, and even manage to deploy a payload. Enjoy!

Are you using the Asteroid Recycling mod by chance? I was having the same exact issue as you were (OutOfMemory exception on 64-bit Linux with KSP.x86_64, with latest ModuleManager) until I noticed a malformed config in ART (requesting ElectricCharge as a propellant rather than a resource) that caused crashes even after MM managing to successfully load after a couple tries; removing that stopped the MM choking on my end.

Can also confirm the Space Center screen strangeness; occurring on the 64-bit Linux build of version 0.25. Only mods installed are HyperEdit and Time Control. Noticed that - for me - it only happens when moving to a different SoI (so, for example, getting to Kerbin orbit is fine, but going on to Münar or Minmus orbit results in things locked up when I return to the KSC). Also, flying a craft that's already in a non-Kerbinar orbit doesn't cause problems; it's just the change in orbit. Input locks are all normal as far as I can tell when this happens, at least according to the debug window. Removing Time Control causes the issue to go away (though at the expense of the smexy slo-mo I downloaded it for ). Worth noting is that, for some bizarre reason, the Flagpole can be highlighted with the mouse, selected, interacted with, etc.; yet, literally everything else (other than the Time Control window and the various toolbar/exit buttons) cannot. Also, while usually this only results in abnormal control lockups, I've occasionally seen the KSC disappear entirely (like what's happening to StormWolf). Steps to reproduce: Launch any spacecraft Get spacecraft to Kerbinar orbit (I used HyperEdit for this to save time, but this also occurs via normal launches) Get spacecraft to any other SoI (tested Mün and Minmus; haven't tested Kerbin escape (Kerbol SoI) yet). Return to Space Center ??? Profit (not) Pastebin of Player.log while performing those exact steps exclusively: http://pastebin.com/ruuPJPr3 Would be happy to perform further testing, provide further info, etc. as necessary/desired. Edit: Oh, and if it matters/helps, I noticed similar symptoms with Time Control installed in 0.24.2, though I hadn't isolated it at the time.

Can also confirm that the patched version works on *nix (at least on GNU/Linux using KSP.x86_64 0.25). Probably safe to at least link to the patched version (if not publish it outright) if testing was your main concern.