• Content count

  • Joined

  • Last visited

Community Reputation

250 Excellent


About Jacke

Recent Profile Visitors

2867 profile views
  1. @IgorZ, something I noted for KIS. Its configuration file is "GameData/KIS/settings.cfg". That matches the files Module Manager checks for MM scripts. If the player can change any of those values in that file, that means on the next startup of KSP, Module Manager will detect that a file it scans has changed, discard its cache file from the last KSP startup, and scan every config file again, making the startup slow. If the config file was inside a "PluginData" subdirectory or named something not matching "*.cfg", that wouldn't happen. Perhaps you might consider changing the file?
  2. [1.0.5] FASA 5.44

    I don't think that will work. All parts with MODULE ModuleCommand's have CrewCapacity. Unkerballed ones have that set to 0. Will do a quick check for the MM code to check that. EDIT: Try this. @PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[>0]] { .... }
  3. [1.0.5] FASA 5.44

    Yes they do make a difference. The Launch Clamp 1.25m and 2.5m as in the archive don't have MODULE ModuleGenerators nor MODULE ModuleTestSubject because the code for them are cut off by typo closing braces. I was wondering why those clamps didn't have generators to provide charge before launch and that's how I discovered the typos.
  4. What did you do in KSP today?

  5. [1.3] USI Life Support [0.5.0]

    The problem is when you see unqualified days, like for example "500 days", is that Kerbin-days or Earth-days? Others knew that if it was MKS, it's Kerbin-days, but I didn't before now. Statute miles and nautical miles differ less, but people died in World War 2 because aircraft ranges in statute miles were compared to mission distances in nautical miles. It's why aircraft always use nautical miles now no matter the service. If the time is hours, that's okay, because the hour is the same. But now days should always be qualified as Kerbin-days or Earth-days.
  6. I agree that he needs to start clean and reinstall again. But I think one of the reasons why his GameData folder ended up that way is he just didn't know enough to fix a common problem with many install archives. 1. Install archives for mods now often include a GameData directory in which they put their mod. Horray! 2. And inside that GameData directory ISN'T just one or a very few named directories to go in GameData, as it should be. But all sorts of files. Includes common names like "README.txt" that will overlap between many mod install archives. All these files shouldn't be in GameData directly but in the GameData/<modname>/ directory.
  7. [1.3] Tweakable Everything Continued (replacement)

    You're welcome, @theersink. I wonder if the problem with CKAN is it's somehow ending up with the ToadicusTools.dll from the VOID release when all 3 are installed. CKAN has a noble goal, to do something like Debian does with dpkg and apt for its software: allow parts to be put into packages and simply and cleanly be installed and removed. But it's trying to do so without the underpinnings Debian has for it: the Debian Policy Manual, detailing the standards, requirements, and best practices learned, built up, and revised over years of experience. And a community of pacakge devs that follow those policies. Packages are constrained in their names and file layouts. Config files are identified and handled specially. There's tools to carefully replace files from other mods and handle alternatives. And a vast number of other important details, which makes sure this all happens near seamlessly. Packages in development still get bugs, including packaging bugs, but with the standards, it's easier to figure them out and even work around them before they're fixed. So it's not surprising CKAN breaks. It's kind of surprising it works at times. I've seen how Debian packages interact and break and potentially the same can happen with mods installed by CKAN, but they can be worse because CKAN can't impose standards on modders to package their mods to reduce them. Only Squad is in a position to do so and it would be hard for them to do so with a long established modding community. I use the tool JSGME to enable and disable mods that I set up to use it. I tend to avoid a lot of errors that aren't inherent in KSP, a mod, or between mods. But I still screw up, as I did with using the ToadicusTools.dll from VOID instead of Tweakable Everything. But I usually find these and fix them.
  8. [1.3] Tweakable Everything Continued (replacement)

    You've got some issue in your install. Despite having a copy of ToadicusTools.dll version, there's a log entry saying it's not being found by KSP. Is the directory of ToadicusTools laid out as I mentioned above? If it's not, that's an indication something is incorrect in the install. Search under GameData the KSP install directory for ToadicusTools.dll and be sure you only have one and it's version As far as I know, it doesn't have code like ModuleManager.dll that disables earlier versions when a later version is present, so a copy of could cause problems. If that's not the case, then I advise deleting the subdirectories "ToadicusTools/" and "TweakableEverything/" under "GameData/", download the Tweakable Everything install archive, and reinstall from it. This is to fix potentially damaged files, especially ToadicusTools.dll.
  9. [1.3] Tweakable Everything Continued (replacement)

    Be sure you have the version of Toadicus Tools that came with Tweakable Everything; it's the one that's version It's also will have a ToadicusTools.version file and the plugin will be in a Plugins subdirectory. I was setting up VOID at the same time, identified the later version of TT with Tweakable Everything, and though I'd grabbed it and put it into use. But when I recently enabled Tweakable Everything, the lag was massive and the App Launcher didn't show up in the VAB. Look at my logs and I saw errors similar to yours. Turned out I'd put in Toadicus Tools that came with VOID. Look at "GameData/ToadicusTools/" and make sure you have these files. ToadicusTools.version Plugins/ ToadicusTools.dll Right-click on ToadicusTools.dll and click Properties, then on the Properties window click the Details tab. Version should be
  10. While I was doing my testing, I set up my flight windows for MechJeb for KSP 1.3.0 and I'm happy to see improvements. Old issues solved and many new features I'll have to check out. Thanks to @sarbian and all who brought these about. I time-warped several times and saw the inclination sign update by itself without any input from the player, which is good. But it flips sign for the upcoming Node between about 60 to 80 degrees before the true closest alignment with the Node. Seeing as it also launches between about 45 to 60 or 70 degrees before the true alignment and I'm not surprised it can sometimes launch with the wrong sign. I don't think any more comment is needed here about this part of Ascent Guidance. Until @sarbian or someone else can dig into the code and address this, there's a manual workaround. 1. First use Launch to the Plane to get the size of the launch inclination. 2. Use map view and Mun's orbit as a projection of the equator, see the proper sign for that inclination: positive for an Ascending Node, negative for a Descending Node. 3. Manually judge the launch site alignment with the Node. 4. Launch with the regular autopilot of Ascent Guidance.
  11. [1.0.5] FASA 5.44

    There's a typo, an extra "}", in the .cfg files for the Launch Clamp 1.25m and Launch Clamp 2.5m that removes their MODULEs ModuleGenerator and ModuleTestSubject. The extra "}" is between the text for MODULE LaunchClamp and MODULE ModuleGenerator for both. Note: the copies of those 2 files here still have the typo "}" in them. GameData/FASA/Misc/FASA_Launch_Clamp_125/FASA_Launch_Clamp_125.cfg (line 87) GameData/FASA/Misc/FASA_Launch_Clamp_125/FASA_Launch_Clamp_25.cfg (line 77) The typos have likely been around a while as they also exist in another copy I have of FASA Launch Clamps from 2016 December.
  12. I played around and Launch to Plane of Target finally always gave me a countdown. And pressing Engage Autopilot got it to launch automatically after its countdown. But it appears Ascent Guidance is miscalculating when best to launch to put the rocket into the plane of the orbit of the target, at least when aiming at Minmus. Appears to be often 45 to 60 degrees early. 4 runs of Launch to Plane autopilot gave me relative inclinations of final orbit with respect to Minmus's orbit (the target) of 4.56, 6.93, 7.75, and 2.55 degrees. Using map view and the equatorial orbit of Mun to manually judge when at the Descending Node to launch, with an inclination of -6deg, using the regular autopilot gave me a relative inclination of 0.34 degrees. Logs of the 2 games here and here.
  13. I'd say It's not complete as it doesn't trigger the launch. I was trying to use (Orbit) Longitude of the Ascending Node (LAN) for the rocket on the pad versus Target LAN to gauge when the pad passed through the relative Nodes with respect to the target, but from judging by eye when it passes through a Node versus the angular difference between LAN and Target LAN being 0 or 180deg, they aren't the same. As a work around, judging by eye and using the Launch-to-Plane inclination on a regular Ascent Guidance will probably be good enough. Launch to Rendezvous seems to be aimed at near co-planar multiple launches from the same pad, at least for a near-equator pad like KSC. It judges the phase angle to get that first close pass soon. And it does automatically launch. Log files from a couple of games with several attempts at using both LtR and LtP, here and here.
  14. When you say Ascent Guidance launches into a -6 inclination orbit, does the rocket aim south of due east and increase in South Latitude? That's what I see AG do. -inclinations incline to the south and +inclinations incline to the north. The orbit of the rocket will always be reported with a positive inclination from 0 to 180deg, as the difference between the orbit from AG having -inclination or +inclination is where the Ascending Node is. Did some testing of the target features of AG. Didn't bother with the phase angle (what I assume you meant as the leading angle, seen both used) as the test rocket was just an orbital one. Once I set Minmus as the target, I'm offered two new buttons in AG: Launch to Rendezvous and Launch to Plane of Target. LtR has a countdown clock that you can use autowarp to get to launch time and will launch the rocket. But as far as I can tell, LtR only worries about phase and doesn't bother with launching near one of the Nodes to get a co-planar rocket orbit. Alternately, LtP only worries about the plane and sets the orbit inclination appropriately (6deg for Minmus, which appears correct), assuming the sign -/+ is selected for the next node crossing. But LtP has no countdown clock and you have to determine manually when the launch site is just about at the next Node, which is hard.
  15. [1.3] PatchManager

    Confirming that fixed it! Thanks, @linuxgurugamer!