Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by wreckreation

  1. I used the grapple and the magnet all the time, for collecting large debris in orbit. I used the magnet for a lot of other things, as well. When they disappeared I b*tched and moaned to myself - "Why?? How cruel! How unfair! Waaaaaah!" - but I didn't say anything on the forum because 'mod authors are volunteers and busy with their own lives and they probably dropped them for... reasons.' But if, indeed, you could see your way to bringing them back, I would sing your praises to the heavens.
  2. Looks awesome! But... not to rain on your parade, but those towers are lightning rods, meant to protect the launch vehicle from a storm. Not going to have much of that on the Mun. But otherwise, thumbs up! Looks really cool.
  3. FYI, in my testing, I did notice something that had escaped my attention until now. In vtol mode, the Hover widget ignores how you have the altimeter set (ASL or AGL). Prior to take off, and throughout your first flight, the Hover widget uses height above sea level (ASL). As soon as you land, it switches to height above ground (AGL), and remains that way for all subsequent flights with the same vessel (even after switching to another vessel and back, or VAB and back). Not a showstopper, just a (very) minor annoyance.
  4. So, instead of a video, I decided to bite the bullet and do what I should have done from the beginning: identify possible mod conflicts. It's tedious and boring and I was admittedly being lazy, hoping someone here would already know the answer - "oh, yeah, I had that happen, too, and it's this that's causing it." Mea culpa. The culprit is Persistent Thrust v1.7.5. Remove that and TCA works as expected, i.e. rather brilliantly. Sorry for the fuss.
  5. No, no warnings from TCA. Nothing in the ksp debug console. it just gets up to about 30 meters or so (it's slightly different every time) and then just drops back down to the ground. I'll post a video of it as soon as I get a chance, today or tomorrow. EDIT: no video, see below.
  6. I have a vtol plane that is unflyable without this mod. I've used it in the past and it worked brilliantly. However, I've come back to ksp after some time away, and now .. well, something has changed(?).. maybe? Or maybe I'm an idiot and have misconfigured it. I set the plane to Hover and set the altitude to a couple of hundred meters above the ground. VTOL Assist is on, Smart engines is off. I activate the vtol engines, they rev up and the plane begins to rise. It gets to about 30m above ground, then inexplicably loses thrust and lands hard. Any clues greatly appreciated!
  7. Works in 1.12.2. No bugs so far! If that changes, I'll edit this post.
  8. You rock, @damonvv. Thanks for updating this!
  9. You're probably tired of hearing about this. I have the "loading part upgrades" problem. KSP 1.12.2. (Referencing the above conversation, removing CraftManager does not cure the problem). I've narrowed it down to KerbalX API and Ship Manifest. Removing both of those cures the problem; so does reverting ZeroMiniAVC from the latest v1.1.1.1 down to v1.1.0.2. Neither KXAPI or Ship Manifest have MiniAVC.dll. All the MiniAVC.dll files in other mods have been pruned (i.e. MiniAVC.dll.pruned). Running ZeroMiniAVC, KerbalX API and Ship Manifest in a pristine install of KSP 1.12.2 with no other mods works just fine. KSP.log Player.log Any way I can narrow it down further? Any other thing you need from me to help diagnose it? Any and all clues and/or help *greatly* appreciated. Thanks!
  10. Indeed it has! Ever so grateful for your swift response @linuxgurugamer. You da man!
  11. You're likely already aware, but just in case: In KSP v1.12.2, the "ignore if Hangar Extender installed" bit of the "Enforce Bounds" option isn't working. I have both this mod (v0.7.3.2) and Hanger Extender (v3.6.0.1) installed, and if that box is checked it enforces the bounds regardless. Thought you'd like to know, and hope I haven't added too much to the already very large list of mod to-do items you must have. Thanks, and keep up the good work!
  12. Ok, I feel really... I swear I looked for the option and didn't find it. I swear. I can only plead sleep deprivation. Sorry to have wasted your time! Like I said, this mod has saved me from embarrassment more than once. Too bad I couldn't save myself. Thanks, and keep up the good work!
  13. Really like this mod, saved me from forgetting things more than once! I do have one (hopefully) small request: can we get an option to start minimized? It starts maximized every time I go into an editor. Every. Time. As helpful as this is, I want it out of the way most of the time, and having to close its window. every. time. I go into the editor... well, you get the picture. I know you're busy, but is there any chance?
  14. Dude, you rock. Thanks so much for getting this out so quickly.
  15. Wonderful mod, love the Buffalo, used it for years. Unfortunately, I'm having the same or a similar issue. When on the ladder for the Buffalo Crew Cab, pressing [F] to Climb Out does nothing. But it *does* work on a stock ladder attached to the same vehicle. And option to Board does not show up when on the Cab's ladder, so no way to get back in. KSP 1.12.1 and 1.12.2 Buffalo 2.10.2 Wild Blue Tools 1.82.1 Pic of GameData folder KSP.log Any other info you need to diagnose this, let me know. Keep up the good work!
  16. If this is the wrong place to post this, I apologize and feel free to move it. I need some advice. I have parts with the following titles: Large Modular Service Tower Medium Modular Service Tower Small Modular Service Tower Delta II Modular Service Tower General Strongback Tower 1 - Large General Strongback Tower 2 - Small Other things, like required tech or folder name, are not useful for distinguishing between them. I want to put the first 3 in subcategory A and the last 3 in subcategory B. So I need to do something like the following [&&=AND, ||=OR, !=NOT]: SUBCATEGORY A title(modular) && title(small || medium || large) SUBCATEGORY B title(tower) && !(title(modular) && title(small || medium || large)) A is easy enough, but there doesn't seem to be a way to do B. Filters OR together, checks AND together and lists OR together. So title(modular) && title(small || medium || large) is easy to do: CHECK { type = title value = modular } CHECK { type = title value = small, medium, large } but the only way to NOT that whole thing is to put it in a filter and invert it: FILTER { invert = true CHECK { type = title value = modular } CHECK { type = title value = small, medium, large } } But now I need to AND all that with the check for title(tower), and I can't because it would OR with another filter. Am I missing something? Is there another way? Any advice at all would be greatly appreciated.
  17. Indeed! There are ships IRL that can sink their decks below the water's surface, move under another ship and then refloat to lift that other ship clear of the water and transport it. Such ships have gunwhales near the middle of the ship even with the deck (but normal height fore and aft). I imagine in KSP something like that could come in very handy for retrieving larger craft.
  18. Oh I am sooo looking forward to using this to build spacecraft and crew retrieval ships. Awesome work! Keep it up!
  19. Awesome mod! Thought you'd like to know, Decouple With Control v1.11.0 generates warnings from Module Manager: [WRN 13:01:23.550] more than one :HAS tag detected, ignoring all but the first: DecoupleWithControl/DecoupleWithControl/@PART[*]:HAS[@MODULE[ModuleDecouple,ModuleToggleCrossfeed]]:HAS[!MODULE[ModuleStateFundingDisposable]]:NEEDS[StateFunding] [LOG 13:01:23.550] Deleting root node in file DecoupleWithControl/DecoupleWithControl node: @PART[*]:HAS[@MODULE[ModuleDecouple,ModuleToggleCrossfeed]]:HAS[!MODULE[ModuleStateFundingDisposable]]:NEEDS[StateFunding] as it can't satisfy its NEEDS [LOG 13:01:23.550] Deleting root node in file DecoupleWithControl/DecoupleWithControl node: @PART[*]:HAS[@MODULE[ModuleDecouple],@MODULE[ModuleToggleCrossfeed]]:NEEDS[RemoteTech] as it can't satisfy its NEEDS [WRN 13:01:23.550] more than one :HAS tag detected, ignoring all but the first: DecoupleWithControl/DecoupleWithControl/@PART[*]:HAS[@MODULE[ModuleDecouple,ModuleToggleCrossfeed]]:NEEDS[RemoteTech]:HAS[!MODULE[ModuleStateFundingDisposable]]:NEEDS[StateFunding] [WRN 13:01:23.550] more than one :NEEDS tag detected, ignoring all but the first: DecoupleWithControl/DecoupleWithControl/@PART[*]:HAS[@MODULE[ModuleDecouple,ModuleToggleCrossfeed]]:NEEDS[RemoteTech]:HAS[!MODULE[ModuleStateFundingDisposable]]:NEEDS[StateFunding] The lines in the config in question appear to be these: @PART[*]:HAS[@MODULE[ModuleDecouple,ModuleToggleCrossfeed]]:HAS[!MODULE[ModuleStateFundingDisposable]]:NEEDS[StateFunding] { MODULE { name = ModuleStateFundingDisposable disposable = true alwaysDisposable = true } } ... @PART[*]:HAS[@MODULE[ModuleDecouple,ModuleToggleCrossfeed]]:NEEDS[RemoteTech]:HAS[!MODULE[ModuleStateFundingDisposable]]:NEEDS[StateFunding] { MODULE { name = ModuleStateFundingDisposable disposable = true alwaysDisposable = true } } I'm no MM wizard, but given that MM ignores all but the first HAS and first NEEDS, the top config statement would appear to add a ModuleStateFundingDisposable module to some parts regardless of whether they already have that module or not (if you have State Funding installed). The bottom statement would appear to add the module to some RemoteTech parts, regardless of whether they already have that module and whether you have State Funding installed or not. I don't use State Funding, so the impact on my game is negligible. At worst, some RT parts have a module added for a mod I don't use. But I thought you'd like to know anyway. Cheers, and keep up the good work!
  20. Thanks for maintaining this mod! You likely already know this, but on the off chance, FYI, the link in the first post: Docs are in the Filter Extensions Wiki leads to https://github.com/linuxgurugamer/FilterExtension/wiki which is empty. Perhaps you meant to link to https://github.com/Crzyrndm/FilterExtension/wiki, which has the wiki in question? Or copy the wiki from Crzyrndm to your github? Thought you'd like to know. Keep up the good work!
  21. Thanks for the response. I agree it's a minor issue. But I assume most mod authors want to know about even annoying little things like this so, if they do have the time, they can address it if they choose, or have the opportunity to explain why they can't or aren't going to. I know I'd prefer to know something isn't going to get fixed and I have to live with it than wonder about it. But LGG has already solved it in the latest version by using option 4: moving the .version file to where madlad expects to find it.
  22. Thanks for writing this mod! It gives me a little more peace of mind running the many mods that I do. Just FYI, the mod ASET PRC has its .version file in the folder Gamedata/ASET. MADLAD apparently expects to find it in the folder Gamedata/ASET/PRC, and complains with the following stark warning when it's not there: KSP Installation Validation Monitor INSTALLATION ISSUES ASET_PRC has been installed incorrectly and will not function properly. All files should be located in: <KSP install directory>/GameData/ASET/PRC. Do not move any files from inside that folder. Related entries in KSP.log: [LOG 21:27:51.942] [MADLAD]: Found 0 exceptions [LOG 21:27:51.943] [MADLAD]: Parsed Log in 53 ms [ERR 21:27:52.088] InstallValidator: Missing file: ASET_PRC.version [LOG 21:27:52.108] [MADLAD]: Parsed .version files in 164ms ASET PRC in fact functions just fine. Copying the .version file from Gamedata/ASET to Gamedata/ASET/PRC silences the warning. Thought you'd like to know.
  • Create New...