StarkRG

Members
  • Content Count

    71
  • Joined

  • Last visited

Community Reputation

14 Good

About StarkRG

  • Rank
    Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. 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.
  9. 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.
  10. The recompile doesn't seem to have fixed the issue, at least not for me. I don't know if there's any debugging options we could try, I'm willing to assist in that regard if you want. In the meantime I've installed the last pre-actuators version of Buffalo, 1.2.3. Update: Ok, no, so that's not working either... I'm guessing it must be one of the other mods interfering to cause this problem... this is going to be one hell of a pain in the ass to troubleshoot...
  11. Almost every other mod works cross platform (there's only been three that I know of that had separate Linux and Mac versions and they were pretty low level stuff like memory management), and I used to be able to use Buffalo just fine, so I don't know what's changed. It's only KerbalActuators that's apparently failing to load, are you using some windows-specific code? Would you suggest I just go back to one of the previous versions that worked?
  12. It's definitely there. Proof. Is it possible it's somehow compiled for windows only? As I'm using Linux that would explain a lot...
  13. The problem also occurs with the bison pods, but not the crewless probe.
  14. I'm using KSP 1.2.2, I didn't even know there was a 1.2.9 And, yes, that's the version of Buffalo I'm using.
  15. Whenever I try to launch a vessel using the Buffalo command pod KSP crashes to desktop. The only thing I can see in the logs that might be causing this is a note at the top of the Player.log: The following assembly referenced from /home/starkrg/Kerbal Space Program/GameData/WildBlueIndustries/Buffalo/Plugins/Buffalo.dll could not be loaded: Assembly: KerbalActuators (assemblyref_index=1) Version: 1.0.0.0 Public Key: (none) The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/starkrg/Kerbal Space Program/GameData/WildBlueIndustries/Buffalo/Plugins/). Could not load file or assembly 'KerbalActuators, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. I've completely removed both KerbalActuators and Buffalo, and replaced them with clean copies from the zip and the problem still occurs. Here are the raw logs: KSP.log Player.log