Tahvohck

@king of nowhere @Basilicofresco Here's a Module Manager patch that makes the RDU and TV configurable modules instead of permanent upgrades. Thanks for helping me track down what was going on by posting years ago

The X and Z axis for rotation seem to be flipped in the UI. This can be seen most readily in absolute position mode with a large angle. Pressing +/- on one actually rotates the other. You can also see the effect by leaving the window open but using the stock rotation tool. As you can see here, the rail is rotated around the red axis (X) but the 10 degree rotation is listed in the blue (Z) field. Rotating it further back causes additional rotation in the Z box.

How long are inflatable parts supposed to take to inflate? For me they inflate to about 50% and then slow down drastically. I have kerbalism installed, which I know isn't explicitly supported, but it's not like nitrogen or oxygen or ANY resource are being consumed during the inflation that might be starving it of the ability to inflate. What's weird is that transferring crew back and forth temporarily boosts the speed back up. Edit: nevermind, it wasn't immediately clear, but it is because of kerbalism. On the ground it was harder to see, but in space it's clear to see it's consuming Atmosphere to inflate the part. It powers through some of the excess Atmosphere and then it's limited by the combined power of my pressure control modules.

Sensible Screenshot is breaking when I try to use dates or the save name in the screenshot. NullRef on both of them. Let me know if providing a modlist or more of the log file would help, but it seems to me that it's going to be isolated code if it's failing the DateTime of all things. [LOG 03:29:06.042] SCREENSHOT!! [EXC 03:29:06.366] NullReferenceException: Object reference not set to an instance of an object MagiCore.StringTranslation.ReplaceStandardTokens (System.String sourceString) (at <4ba817917bf941048de4cb8d3f2b666f>:0) MagiCore.StringTranslation.AddFormatInfo (System.String original, System.String caller, System.String DateString, System.Collections.Generic.Dictionary`2[TKey,TValue] extraVariables) (at <4ba817917bf941048de4cb8d3f2b666f>:0) SensibleScreenshot.SensibleScreenshot.GetFileName () (at <bdd87ade0549468dbcdd2abb58e04d28>:0) SensibleScreenshot.SensibleScreenshot.DoWork () (at <bdd87ade0549468dbcdd2abb58e04d28>:0) SensibleScreenshot.SensibleScreenshot.Update () (at <bdd87ade0549468dbcdd2abb58e04d28>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Config code just in case: DateString = yyyyMMdd-HH.mm.ss FileNameTemplate = [body]_[version]_[date] ConvertToJPG = False JPGQuality = 75 KeepOrigPNG = False FillSpaces = True ReplaceChar = _ And just to be sure, I did check that that format is compatible with the DateTime.ToString() method: C:\ > [DateTime]::Now.ToString("yyyyMMdd-HH.mm.ss") 20230702-20.56.11

I think that will work perfectly, thanks. EDIT: Okay, that was a pain, I'm apparently really rusty with module manager patches; had to debug with the dump command... Here's a patch for Modular Fuel Tanks that gets rid of an issue they have where one of their files has duplicate entries for... everything, as far as I can tell. This is most obvious when you're using CryoTanks, since it would give it two switcher dialogues. @PART[*]:HAS[@MODULE[ModuleFuelTanks]]:AFTER[modularFuelTanks] { @MODULE[ModuleFuelTanks],* { %FlagForDeletion = yes } } @PART[*]:HAS[@MODULE[ModuleFuelTanks]]:AFTER[modularFuelTanks] { @MODULE[ModuleFuelTanks],0 { %FlagForDeletion = no } } @PART[*]:HAS[@MODULE[ModuleFuelTanks]]:AFTER[modularFuelTanks] { -MODULE[ModuleFuelTanks]:HAS[#FlagForDeletion[yes]],* {} } @PART[*]:HAS[@MODULE[ModuleFuelTanks]]:AFTER[modularFuelTanks] { @MODULE[ModuleFuelTanks] { -FlagForDeletion = delete } }

Can someone PLEASE collate the information in this thread and update the wiki? It's so out of date it's not even funny. Is there any syntax that can match "has this node this many times"? I'm trying to write a patch that deletes nodes that have been double-applied and being able to say @Part:HAS[Node:count>2] { -Node,1 } instead of having to list every part with a duplicate node would be really helpful.

@cakepie hasn't posted on the forum in four years (almost to the date, actually), though they did interact about a year ago. HOPEFULLY this ping gets their attention. The license for this mod is, unfortunately, a pain in the ass for modification. Even if I was willing to maintain it that would put me off. With that said, you can get this to compile pretty easily against 1.12/ModuleManager 4.2.2 with the following setup: .NET version: 4.8 References: Assembly-CSharp.dll UnityEngine.CoreModule.dll UnityEngine.InputLegacyModule.dll UnityEngine.PhysicsModule.dll UnityEngine.Te3xtRenderingModule.dll UnityEngine.UI.dll 0Harmony.dll ModuleManager.4.2.2.dll CLSInterfaces.dll ConnectedLivingSpace.dll You'll need to make the following change to the source files to use the MM-distributed Harmony: diff --git a/Source/HarmonyPatches.cs b/Source/HarmonyPatches.cs index 163ecb3..d54befc 100644 --- a/Source/HarmonyPatches.cs +++ b/Source/HarmonyPatches.cs @@ -4,7 +4,7 @@ using System.Reflection; using UnityEngine; using KSP.UI.Screens.Flight.Dialogs; -using Harmony; +using HarmonyLib; namespace AirlockPlus.Harmony { @@ -18,9 +18,9 @@ public sealed class Patcher : MonoBehaviour // If Harmony dependency is missing, AddonLoader will barf in logs when instantiating addon // ADDON BINDER: Cannot resolve assembly ... // and none of this will execute - Assembly harmonyAssy = typeof(HarmonyInstance).Assembly; + Assembly harmonyAssy = typeof(HarmonyLib.Harmony).Assembly; Debug.Log($"[AirlockPlus|Patcher] Using Harmony {harmonyAssy.GetName().Version.ToString()} located at {harmonyAssy.Location}"); - HarmonyInstance harmony = HarmonyInstance.Create("com.github.cake-pie.AirlockPlus"); + HarmonyLib.Harmony harmony = new HarmonyLib.Harmony("com.github.cake-pie.AirlockPlus"); harmony.PatchAll(Assembly.GetExecutingAssembly()); harmonyAvailable = true; Destroy(gameObject); I've only tested it briefly since recompiling it, but at first glance it works fine. Given that the harmony code is all I changed I'd be surprised if there's any actual "new" bugs that didn't exist already.

Heads-up, there's a bug in the the altimeter configuration. The 1000 meter arrow doesn't have an attached transform. // arrow rotation MODULE { name = JSIVariableAnimator refreshRate = 1 // x100 VARIABLESET { scale = 0,100000 variableName = ALTITUDE controlledTransform = ALT10_arrow localRotationStart = 0,0,0 localRotationEnd = 0,360,0 modulo = 1000 longPath = yes maxRateChange = 1 } // x1000 VARIABLESET { scale = 0,100000 variableName = ALTITUDE localRotationStart = 0,0,0 localRotationEnd = 0,360,0 modulo = 10000 longPath = yes maxRateChange = 1 } // x10000 VARIABLESET { scale = 0,100000 variableName = ALTITUDE controlledTransform = ALT1000_arrow localRotationStart = 0,0,0 localRotationEnd = 0,360,0 longPath = yes maxRateChange = 1 } }

Thanks for the link, that's exactly what I'm looking for. It's doing more or less what I expected too, but I noticed - it looks like it's updating the cache every physics frame. Isn't that a little too aggressive? The fact that each antenna has a method of transmitting data is pretty neat too, but with how Kerbalism overhauls science results and transmission (some experiments taking ingame weeks to run) it probably doesn't help as much as it could. And I hadn't actually heard that it was going to implement its own CommNet! From what I'd seen it was actually just supporting RealAntennas more explicitly instead, with some form of updated RT support possible in 4.0. If it does roll its own CommNet, I hope it's at least as good as RT/RA.

Did you ever write NFE configs?

Right, but it knows about the other paths, right? How does it translate the list into the shortest path? (A link to the spot in the code that does this would be enough). I assume it's sorting some sort of List/Array structure by total distance and then taking whatever is at index 0, vs finding the index of the shortest path. And yeah, it wouldn't know anything about link power without some sort of (hard?) bind into Kerbalism which would be a significant amount of work; with Kerbalism 4.0 in the works it probably would be a bad idea to add that feature at this time anyway. I was mentioning that as more of an ideal solution, with the fallback of putting the user-selected link first in the list of links as a more practical one.

I know that it's a known fact that Kerbalism and RemoteTech don't play nice together (to the point where Kerbalism throws a warning when both are installed), but RT's path algorithm is causing me some heartache when transmitting science over long distances. RT's dish-coverage code is making it pick the weaker Dish-to-DSN-Omni link past a certain distance, rather than the stronger Dish-to-local-Dish-to-DSN-Omni connection. Is this because it's trying to pick the fastest path? And if so, shouldn't pointing a dish at a spacecraft ALWAYS prefer that spacecraft if possible? Normally I'd blame this on Kerbalism since it's the mod with an interaction, but I know that RT supports multiple control paths and it's clearly displaying the active path as a direct connection to the DSN. If RT simply has an array of connections and Kerbalism is picking the first on in that array, is it possible to have the array in a different order while still preserving the fastest-path for control? It'd be nice if it ordered it by signal strength when Kerbalism was installed, but just having the active target at the front of the list if possible should "solve" the issue.

Thanks for the confirmation. I've kept it removed for now, personally, since I wasn't even using it... not sure why I had it installed in the first place.

Dunno what I did, but I've eliminated the issue for now in my modded save. I've removed the following, but I don't think they're to blame. AmpYearPowerManager 1:V1.5.8.0 DeployableEngines 1.2.3 FilterExtensions 3.2.6 MoarFEConfigs 1.0.5.2 ModularFlightIntegrator 1.2.8.0 NearFutureLaunchVehicles 2.1.2 REPOSoftTech-Agencies V1.5.8.0 SixCrewScienceLab 1.2 SixSeatMk3cockpit 1.2

Some good news, out of 128 mods I've identified 96 that don't seem to be interfering, and I've confirmed it's not a local configuration issue (fresh install with 128 still had the issue, I believe). Bad news: The 32 mods I'd removed were ones I was sure weren't causing issues. So... that's a good time. That leaves the following to test: Personally I have my eye on ModularFlightIntegrator, maybe the wind tunnel mod. If it's any of the contract mods I'm gonna have stern words for them. Test 2 - failure Test 3 - clean Edit: No video this time. I can't actually get the interaction to happen again on the minimized list. Also, it turns out I already eliminated Modular Flight Integrator... so I have no idea. I'm gonna see if I can get my full modded install to work with this knowledge.

Here's some testing done with the panels open, in case Boris sees anything in particular that might be setting the AA off. Modlists are in the video descriptions, I'll be doing further tests as I have patience for them. It should be noted that Remote Tech is installed in both cases, but there are no antennas on the plane, and there's also no kOS KPU modules on the plane. Edit: Also, sorry about double-posting, I'm not thinking very well right now.

This could be related to my issues as well, though I'm seeing it at low altitudes and pretty much any speed. The nosedive is exactly what's happening though. Are AA and FAR your only mods?

I'm also finding that the AA will occasionally wig out after several minutes of flight on KSP 1.11. I thought this was an issue with kOS at first but the plane thinking it's on the ground seems pretty likely from what I'm seeing in the previous posts. I'm testing on a clean + isolated install anyway, but with no error messages it's hard to say why the AA is suddenly deciding that it needs to apply hard authority. Edit: It's a mod interaction. I can't reproduce it when clean + isolated. I'll see if I can figure out what it is - kOS shouldn't have control of my vessel and neither should remote tech under these situations (manned flight)

I've recompiled the code against KSP version 1.10.1 as well as added a NullRef check that should prevent crashing on switching game modes. As far as I can tell, @Serdidn't publish the beta code to github, so that performance change code isn't included. https://github.com/Tahvohck/KSP-Audio-Muffler-Redux/releases/tag/v2.6.3

Hm. I'll look into that.

I'm able to hook it into RemoteTech, but for some reason that completely destroys the feedback loop that AA uses. I'm not sure where I'd even start to look for troubleshooting that. You might still get a pull request from me at some point, but it won't be any time soon, since programatically dealing with FlightCtrlStates isn't something I know how to do. In the meantime, the oscillations aren't so bad that they aren't manageable.

You know the codebase a lot better than me, but I'll dig through and see if I can find the correct place to hook in.

You're correct. This is an interaction with RemoteTech. The only mods in this save are Remote Tech, Atmospheric Autopilot, and Module Manager. Without Remote Tech, this plane flies stable. With Remote Tech, the plane flies with rapid oscillations. A 10 microsecond delay probably shouldn't cause these oscillations by itself, which means this is an issue with how AA sends commands to the vessel. Remote Tech has an API that allows bypass of the signal delay, which this mod appears not to be hooking into (and should be, given its purpose). I couldn't find RemoteTech.API referenced in your github, so "fixing" this oscillation should just mean hooking into the Remote Tech API and registering a sanctioned pilot.

What's going on with the difference in flight performance for drones vs pilots? I thought this was just because my drone planes were small, but even small piloted planes are stable, while small drone planes wobble all over the place. I've even tested this by putting a command seat on a drone plane and suddenly it's stable.

My solution personally is to add a very short-range omni to the control station, but that's out of the scope of TETRIX. I think the best solution for TETRIX would be to put the dish and the ground station in the same node, and to make all the experiments successors to that node so that you can't unlock things without some way to use them.