Jump to content

allista

Members
  • Posts

    2,208
  • Joined

  • Last visited

Everything posted by allista

  1. @LatiMacciato, or vice versa: install ConfigurableContainers-Core if it is needed as a dependency, and use IFS-full. So: CC-Core + IFS-full is OK CC-full + IFS-Core is OK CC-full + IFS-full awake krakens!
  2. Also, could you give me the .sfs file that is affected, I'll see why the Grapple module can't read the DockedVesselInfo from there. Oh, I understood you perfectly But such mistakes that seep through checking and rechecking before release are indicative of heavy concentration loss, which genuinely worries me
  3. Yes, that would remove Hangar capabilities from the stock cargo bays. I just don't see why do it? You can still use them as cargo bays if you like, Hangar does not interfere with it. As for ConfigurableContainers, this mod is about patching other parts. If you remove the patches (GameData/ConfigurableContainers/Parts/...) CC would simply sit there and won't do anything, like any other utility library. You will see its functionality only on parts that were made to explicitly use it, but nowhere else. Oh, this does worry me a lot. Brain malfunctioning...
  4. Heck! This should have been fixed! I've checked it with the old saves and it worked... Wait, I'll come up with a workaround and post an updated .dll
  5. OK, the next thing on the list is to deal with the cost problem. Could someone please make a github issue about it, summarizing the facts? Generally it is much better to report bugs on github, because it instantly catches my attention, allows specialized discussion and progress tracking. I've totally missed the forum for the past week due to work
  6. Ground Construction v1.1.2 for KSP 1.2.2 (2017.02.22) ChangeLog:
  7. Configurable Containers v2.4.0.5 for KSP 1.2.2 (2017.02.22) ChangeLog:
  8. Hangar v3.3.1 for KSP 1.2.2 (2017.02.22) ChangeLog:
  9. TCA v3.4.1 for KSP 1.2.2 (2017.02.22) ChangeLog:
  10. Level is mutually exclusive with the other modes that control horizontal component of the thrust, that's why Cruise, Go To, Stop, Anchor and Follow Path will disable Level. All of them use the same core module to control thrust with different purposes. If you want a copter-style control over your craft you should use the VTOL Control mode in Advanced Tab instead of Level. What resets the Level after takeoff is the VTOL Assist module (also in Advanced Tab); you can safely disable it. During manual landing, though, nothing should interrupt Level mode. Currently these are not supported. Only stock ModuleEngines and its derivatives (like ModuleEnginesFX and such) are supported. To add support for FSEngine I need to compile against the Firespitter.dll, thus making it a hard dependency, which is unacceptable. So I will be forced to move the FS dedicated code into a separate optional .dll, which in its turn entails many technical difficulties. What it boils down to: this is on my TODO list, but not a priority.
  11. AutoBreak/Gear/Chute and so on are not per se functions, just flags that are allow or forbid the use of corresponding actions by autopilots. They don't do anything by themselves. Also, I cannot reproduce this one: just now Level stayed active throughout more than two minutes of piloting around KSC at 10m above ground.
  12. It will "work" but you wouldn't see it until you have parts specifically configured to utilize it. The Parts folder contains MM patches to add CC to stock and other mods' tanks. So unless you got CC as a dependency of MKS, why delete it?
  13. Noted. Working on it. Edit: fixed. No when you choose the key, you have three options: ESC cancels the process; BACKSPACE sets key to None; anything else (or, on some systems only alpha-numerics) are set as the new hotkey. Edit2: releasing new version today. The fix will be included.
  14. @LatiMacciato, thanks again for the report! Found and fixed it. Saves are safe and everything will be working as expected after the update.
  15. @eLDude, @Jebs_SY and everyone concerned; I've found and fixed the "Coroutine couldn't be started" bug. And today's the release day
  16. Thanks. This has already been reported and I'm working on the fix. Meanwhile it is safe to ignore as it doesn't seem to impact the game. Thanks! I'll check this and see if I can reproduce it. GH issue to track: https://github.com/allista/hangar/issues/187
  17. Sorry for the delay. Too much work at work I see I have confused you with the Smart Engines by failing, yet again, to describe it properly in the docs. First, I didn't mean this mode to be used for anything but orbital maneuvering. I even recorded a video about it, but never got the time to edit and publish it Second, your guess is correct: SE works by dividing engines into a mutually exclusive groups by their thrust direction; dividing line being, obviously, +/- 45 deg, or 90 deg cones, to be precise. It then keeps enabled only one group at a time, trying to minimize rotation, or maneuver time, or fuel usage. It would "work" with VTOLs that have their (non-maneuver) engines pointed in the same direction (this having only one group); but in other cases just don't engage it unless in orbit.
  18. Sure thing, that's exactly what GC is for. And it doesn't matter what parts do you use: stock, ELP's or from any other mod.
  19. Well, this is intentionally not so obvious; the feature was added specifically for color-blind users, while general public is mostly happy with the defaults. So I left it without UI and provide the answer I gave you per request. This is just like with other .glob files where tons of options and settings are "hidden"; and any of them could be overridden via corresponding .user file.
  20. It is possible to customize colors, yes. For that you need to add the GameData/000_AT_Utils/000_AT_Utils.user file with the following content: StylesConfig { //available colors: normal (meaning white), grey, red, dark_red, green, dark_green, yellow, dark_yellow, cyan, magenta EnabledButtonColor = green ActiveButtonColor = yellow InactiveButtonColor = grey ConfirmButtonColor = green AddButtonColor = green CloseButtonColor = red DangerButtonColor = red } And change the colors as you please. You can omit the any of the options for them to follow default style defined in corresponding .glob file.
  21. OK, I see. As with the KV problem, KSPIE uses the stock ModuleEnginesFX (which is fine) and an ElectricEngineControllerFX to change engine parameters. I'll look into the code of the latter and see if I can do anything...
  22. I'm sorry, but the core components -- the .dll and basic configuration -- are indeed required. I just forgot to update the OP. If you don't want the game content of ConfigurableContainers you just have to remove the GameData/ConfigurableContainrs/Parts subfolder. Then GC will be happy with its dependency, and you will have none of CC's patches.
  23. If these engines are a modified version of ModuleEngines I could try to work them out. Could you name a specific part so that I could look at its config?
  24. Why, of course! The AnimationGroup, not AnimatiorGeneric! Indeed, it controls the emitters. But it is private: private void ToggleEmmitters(bool state) { KSPParticleEmitter[] componentsInChildren = base.part.GetComponentsInChildren<KSPParticleEmitter>(); int i = 0; int num = componentsInChildren.Length; while (i < num) { componentsInChildren[i].emit = state; componentsInChildren[i].enabled = state; i++; } } So the only thing I can do is to remove the effect from the model completely
  25. Are you sure it's the dust causing the lag? It seems very unlikely. Anyways... there's no way to control it. Even more, I'm not currently sure which module controls the emitter O_o
×
×
  • Create New...