StarkRG

It seems like in 1.12 the accelerometer sensor is giving an acceleration not including the gravity vector, so sitting still on a launch pad it returns approximately 0, but when falling on kerbin it will show approximately 9.8-ish, this is contrary to what's in the documentation, assuming I'm reading it correctly. Similarly the Grav sensor provides its reading in m/s (shows 9.8-ish on kerbin), not in terms of g as the documetnation states. Is anyone else getting this or is it just some weird mod interference on my install?

I discovered a workaround to use any percentage, and, while still a PITA, is a lot less of one than using the 1/2 button like that (which I had been doing before). What you do is enter a percentage, then switch it to m3 select one digit and enter it manually (such as, if it says 0.1234567, select the 7 and type 7), the red numbers will turn white and you'll be able to add it.

Something in the update between 1.8.3.4 and 1.8.3.5 has caused the Linux version of AFBW to no longer be compatible with the version of SDL in ubuntu's 21.04 "hirsute" repositories. The version that's installed is "2.0.14+dfsg2-3" (as reported by apt, I don't know if there's a better way to get the version of a library) and I'm getting the "DllNotFoundException: libSDL2-2.14" error mentioned earlier. I've tried reinstalling AFBW, but to no avail but rolling back to 1.8.3.4 does work. (yes, the problem also exists in 1.8.3.6, I actually had to install 1.8.3.5 to determine if the problem was there too)

I want it for the more intuitive communication structure. How CommNet works just makes no sense to me. But, surely, a colony should classify as their new home?

I can't seem to enter a percentage value when adding tanks. When entering a value it shows up as red and the add button is disabled. If I click on the "max" or "1/2" buttons it doesn't have a problem with them, but if I enter "100" or "50" it suddenly does.

Is there a way for the "Connected" health factor to consider the Remote Tech connection to KSC? Ideally, this should scale with signal delay (if enabled) since feeling connected to home is a lot easier when you don't have to wait minutes or hours for a reply. Additionally, and I'm not sure exactly how you might go about implementing it, but a connection to a base or orbital station with a crew compliment above a certain threshold (maybe 10 or 20) should count as some fraction of a connection to KSC. This would make it so that you could send a massive ship to Jool orbit where the signal delay might otherwise make the "connected" factor too small, but having so many kerbals in one place would give a boost to anyone exploring the Joolian moons. Similarly, being aboard a vessel with that many kerbals might be considered "Home" or potentially be worth some fraction of the "At KSC" factor.

So nobody has any idea about the "rendering procedural drag" issue?

I'm getting a strange conflict between StageRecovery and Configurable Containers (or, rather, the AT Utils library) when RealChute is involved, but it doesn't happen when they're the only mods so there might be other conflicts I haven't nailed down. After having this issue pop up a couple of times I created an all-stock craft that would display the issue every time I load it into the VAB. The issue is simply that the game hangs and player.log shows that it's in a loop of "DragCubeSystem: Rendering procedural drag for mk2LanderCabin.v2". If I leave it running in this state for several hours it runs out of stack space and throws an error showing where the loop is occurring. By working my way down, eliminating other mods eventually I discovered that the craft would load most of the time, but if I did it repeatedly it would eventually get stuck in the loop. I was able to get it to happen, at a guess, about a fifth of the time with 13 mods installed. I've asked over in the StageRecovery thread, but haven't had any response over there so perhaps nobody knows. Here's the error that eventually pops up: These are the 13 mods I was able to get it to work some of the time: And here are the mods that I normally run:

I'm getting some kind of weird mod conflict between StageRecovery and Configurable Containers (or, rather, the AT Utils library), but it doesn't happen when they're the only mods (which suggests possibly other conflicts, or potentially a memory issue?). It also seems to involve RealChute, but, again, it doesn't happen when they are the only ones. What happens is I try to load a craft into the VAB and it hangs. The player.log shows that it's in a loop of "DragCubeSystem: Rendering procedural drag for mk2LanderCabin.v2". By keeping the game open for several hours in this state I got it to finally throw an error (though it's not a fatal error and the game remains open). I was able to intermittently replicate the loop, though not the error, with a minimal install of 13 mods. I've been trying to track down this conflict for about a week now (well, over a week, but I've been focusing on it much more this week). This is on Linux with KSP 1.9.1 (yes, I know it's not officially supported, but most mods seem to work, I just gotta figure out which ones are only partly working). I'd rather not have to stop using StageRecovery, Configurable Containers, or RealChute if possible. Any help would be appreciated. The error that eventually happens (It looks to me like Stage Recovery updates something when the craft changes which triggers AT Utils to update something which triggers Stage Recovery, ad infinitum): The mods in my main instance: The 13 mods I was able to occasionally get the loop in:

I have all installed through CKAN, so whatever versions are currently listed there.

I'm having a bit of an issue that I've tracked down to this mod and possibly (probably? prossibly?) is the result of running it in 1.9.1 when you've clearly stated that it's for 1.8.1 (that said, this is the only mod built for 1.8.1 that seems to be having problems, presumably there are others, they're just minor). B9 Part Switch throws an error when attempting to load parts from this mod, in particular it says "No tank type named 'KGExSupport' exists". I tracked down the offending ModuleManager config to the B9FuelSwitch configs for this mod which do have a "tankType = KGExSupport" line, however it's in a "SUBTYPE:NEEDS[KGEx]". This confused me because I didn't think I had any mods which might be labelled "KGEx" and should therefore not be loaded, however I did find a directory called that which contained "DockingPortDescriptions" and "ShieldedPicoPort" which I did just install, so I assume that's what it's picking up on, however neither of those have a plugin which could create such a tankType and, therefore, there's no "KGExSupport" for it to find. Since such a plugin doesn't exist, I've gone ahead and removed those sections from the config (as well as the others looking for KGEx for good measure, even though they weren't causing an issue) and it seems to now be working. I assume changing the name of that directory, or just moving them to be directly under GameData would also have solved it, but that would have been problematic for CKAN. Complete exception follows (in case that's helpful, though I kinda doubt it):

The loop ends up looking like this (after loading a saved vessel which had worked fine on a previous launch of the game): DragCubeSystem: Rendering procedural drag for mk2LanderCabin.v2 (Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 35) -INFO- Tac.LifeSupportModule[FF5B753A][568.57]: OnAwake (Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 35) DragCubeSystem: Rendering procedural drag for mk2LanderCabin.v2 (Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 35) -INFO- Tac.LifeSupportModule[FF5B18A2][568.57]: OnAwake (Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 35) This isn't the first time I've gotten stuck in this loop, but all the other times have been while using Bluedog Design Bureau parts so I figured that was the problem (and I've mostly avoided using them). This is the first time this loop has happened with a stock part. The only mod mentioned here is TAC Life Support, but it doesn't seem like that should be what's causing the problem (what would that mod have to do with "rendering procedural drag"? If I could narrow down which mod is causing the issue I might be able to either fix it or decide not to use that mod. Unfortunately I don't see any hint of what it might be. Here's a complete Player.log. Edit: This is on KSP 1.9.0 with quite a glut of mods (263, according to CKAN, though there are a couple that aren't handled by CKAN)

Seems to me that the attribution and license both already exist by the link being in this thread and firegun saying the only change was to recompile it with the version changes. If there's not going to be an official release any time soon then it seems rather inconsiderate to delete links to unofficial versions.

Since 1.9.0 I am getting the following error which results in the game not starting. The "RR_MetalOre" is what pointed me to this mod and the game starts without it. [ModuleManager] Exception while calling B9PartSwitch.B9TankSettings.ModuleManagerPostLoad(): System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Exception: Fatal exception while loading tank type RR_MetalOre ---> System.Exception: Exception while loading field resources on type B9PartSwitch.TankType ---> System.Exception: Exception while loading field resourceDefinition on type B9PartSwitch.TankResource ---> B9PartSwitch.Fishbones.Parsers.PartResourceDefinitionValueParser+PartResourceNotFoundException: No resource definition named 'MetalOre' could be found at B9PartSwitch.Fishbones.Parsers.PartResourceDefinitionValueParser.FindResourceDefinition (System.String name) [0x00024] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.Fishbones.Parsers.ValueParser`1[T].Parse (System.String value) [0x0000b] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.Fishbones.NodeDataMappers.ValueScalarMapper.Load (System.Object& fieldValue, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00022] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.Fishbones.NodeDataField.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00043] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00025] in <9d3fe92d8f32452f86b4a1298323bc91>:0 --- End of inner exception stack trace --- at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00058] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00033] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.TankResource.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.Fishbones.Parsers.NodeObjectWrapperIContextualNode.Load (System.Object& obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00038] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.Fishbones.NodeDataMappers.NodeListMapper.Load (System.Object& fieldValue, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x0009e] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.Fishbones.NodeDataField.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00043] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00025] in <9d3fe92d8f32452f86b4a1298323bc91>:0 --- End of inner exception stack trace --- at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00058] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00033] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.TankType.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.B9TankSettings.ReloadTankDefs () [0x0004c] in <9d3fe92d8f32452f86b4a1298323bc91>:0 --- End of inner exception stack trace --- at B9PartSwitch.B9TankSettings.ReloadTankDefs () [0x0007f] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at B9PartSwitch.B9TankSettings.ModuleManagerPostLoad () [0x00000] in <9d3fe92d8f32452f86b4a1298323bc91>:0 at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&) at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 --- End of inner exception stack trace --- at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00048] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at ModuleManager.PostPatchLoader+<Run>d__16.MoveNext () [0x0060b] in <6cc6df54448a4c2b97e086234872a67b>:0

Oh, it doesn't disable the plugin if it detects that?