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?

The mod is reporting that it's incompatible with 1.9.

Again, the engine throttle works fine, it's the wheel throttle that doesn't work, in other words, I can't control a rover using my flight stick without resorting to using the keyboard to make it go forward and then, because it's keyboard input, it's either full torque or zero. Another thing that would be really, really useful would be to have an "Absolute" setting for trim axes (and, while you're at it, all the others as well, though I don't know what use they might be). What I mean by that is the same kind of input as the throttle, if the input is 10% in the positive then trim is at 10% instead of increasing at a rate of 10% or whatever, if it's increased to 20% then trim gets set to 20% instead of increasing twice as fast.

Wait, you mean they've officially dropped a major feature of the game? That seems rather inconsiderate of them. They should really remove the controller UI elements from the settings screen and should mention that they are no longer properly supporting Linux.

From what I've been able to gather, there is no in-game controller support on linux without Advanced Fly-by-wire. At least as of over six months ago, I haven't been able to find any new information.

I've got this running in 1.7 and it mostly seems to work (at least the basic rotation and throttle stuff works). However, I can't seem to get wheel throttle to work. Additionally, it would be cool to be able to use an axis setting as a button, this would allow the use of flight pedals to activate brakes (above 50% activate brakes). While it would be nice if brakes could be an analog input, I don't see an easy way to do this and would likely have to be an entirely separate mod.

I'll +1 this, and also add the suggestion that, if something is on the grounds of the KSC and landed, repairs should be able to be done "remotely" since it's not really remote. Additionally, once a vessel has been recovered and stored in KCT there should be an option to repair or replace all faulty parts in a vessel without having to bring it into the editor first (repair would be the default and replace only if the part was flagged for trashing). Finally it'd be nice to have an in-game config for the failure chances. Parts on my vessels seem to fail inordinately frequently, even when they've been used once (bypassing the beginning of the bathtub curve) and have safety ratings of 3, 4, or 5 (having six or seven safety 5 parts with one or two uses under their belts is very annoying, not to mention that new safety rating 5 parts shouldn't be failing as much as new safety rating 2 parts, even accounting for the bathtub curve). I just thought of another nice feature: burn in. Once you've used a type of part enough that all new parts of that type are given safety rating 5, you should be able to spend a bit more (10-15%) to bypass the beginning of the bathtub curve. This is what server-grade hard drives are, they're no different than consumer-grade hard drives, it's just that they've been tested beyond the point that most of the early failures have already taken place. Second afterthought: If an engineer is on board, make "remote" repairs more likely to succeed.

Guess I'll be trying out the new directx fix, then. Anyone know if there's a way around this that doesn't have the mentioned "slightly more overhead"? I'm not sure yet if it'll be a problem, so maybe I don't need a solution.

My main gripe with this beautiful mod is that it's incredibly difficult to see land masses on Kerbin from orbit as the atmosphere seems overly blue. Everything just looks like ocean with clouds. Is there a way to reduce this effect?

Regarding the Linux/OSX crashes, I'm on Linux and have done a bit of research. I installed RPM, ASET, and MK1-2 IVA in a clean install of KSP. I turned on the RPM debug, loaded the game and launched only the capsule. I did this twice and both times the game crashed after loading "swPush_THRTL_CUT". I went into MK1-2_ASETinternal.cfg and removed that section and tried again. This time it crashed right before where that switch was. I went back, put it back, and removed the section following it, "swPush_THRTL_FULL". This time the game progressed further before it crashed. [LOG 14:21:40.337] [JSICallbackAnimator]: Configuration complete in prop 90 (PanelDivider), supporting 1 callback animators. [LOG 14:21:40.342] [JSIActionGroupSwitch]: Configuration complete in prop 91 (swPush_THRTL_CUT). [LOG 14:21:40.343] [JSICallbackAnimator]: Configuration complete in prop 91 (swPush_THRTL_CUT), supporting 1 callback animators. [LOG 14:21:40.343] [JSICallbackAnimator]: Configuration complete in prop 91 (swPush_THRTL_CUT), supporting 1 callback animators. [LOG 14:21:40.346] [JSIVariableAnimator]: Configuration complete in prop 92 (ALCORThrottleCtrl), supporting 1 variable indicators. [LOG 14:21:40.347] [JSICallbackAnimator]: Configuration complete in prop 92 (ALCORThrottleCtrl), supporting 2 callback animators. [LOG 14:21:40.347] [JSICallbackAnimator]: Configuration complete in prop 93 (DigitalIndicator_Throttle), supporting 1 callback animators. I tried the same procedure but, instead of getting further, it went back to crashing right after that final PanelDivider. Don't know if this'll be of any help. But let me know if there's anything more I can try.

For the record, it appears the problem is the result of RasterPropMonitor. Edit: it's ASET causing the issue, and it's a known bug.