HebaruSan

Members
  • Content Count

    3,494
  • Joined

  • Last visited

Community Reputation

4,221 Excellent

About HebaruSan

  • Rank
    External Tank

Profile Information

  • Interests Array

Recent Profile Visitors

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

  1. Well you're using an ancient version of the game for no reason that you cared to share, and you didn't say which versions you're using of any of those mods. There's plenty of room for all sorts of things to go wrong there.
  2. The second node is the plane change. Astrogator generates one maneuver to adjust your solar apoapsis, then another to align your orbit with your target's orbit.
  3. You're welcome, glad you like it. Yes. No special database, the planet data is loaded from the game on the fly, using whatever planet packs you have installed.
  4. Hi, I'm sorry I was so bluntly critical, you don't need to worry about being professional. I was specifically looking at the "short description" on SpaceDock. If you're interested in tips, try to sum up the mod in one sentence. A reader who sees "realistic spacesuits" may be interested in that, but adding another four and a half sentences makes it look like there's a lot more to it, and things like dependencies and future plans can easily be kept to the "long description" section.
  5. The abstract is really, really long. Normally this would be one sentence, for this mod it's 5.
  6. Submitted to fix the version file: https://github.com/allista/ThrottleControlledAvionics/pull/102
  7. So it would no longer be possible to switch to radial symmetry?
  8. How would symmetry work for parts attached below?
  9. OK, there are indeed some differences between the "available" and "installed" versions of JNSQ 0.9.0 in your registry. What steps did you take, exactly? If your CKAN is in a state where no JNSQ is installed, and then you install it, it should simply copy the "available" module to the "installed". Somehow the old data is persisting.
  10. Your mod is for KSP 1.10, but some of its dependencies are for KSP 1.9, so the user has to manipulate compatibilty to install it. https://github.com/KSP-CKAN/CKAN/wiki/User-guide#choosing-compatible-game-versions (Don't worry about the $vref absent message, that's a false positive.)
  11. A minor clarification on this as my thoughts finish collecting themselves. Including this group in the every-30-minutes passes is not done to handle new releases (though in a few cases it does do that as a side effect, as with SCANsat). Rather it is done because version files have a "remote version file" feature that gives the author the opportunity to change a mod's compatibility post-release, which must be reflected in the CKAN metadata, and there is no on-demand notification available for this. So in addition to the webhook, we need to check such mods regularly in case the remote version file has been updated.
  12. This has changed over time. A summary of the current state of the art: Scenario Time till update SpaceDock with CKAN checkbox checked Immediately(ish) SpaceDock with an active version file Within 30 minutes GitHub or other hosts Within 30 minutes SpaceDock otherwise Up to 24 hours SCANsat is in the second category, hence the difference between v20.4's release date timestamp (17:27 UTC) and when it was indexed (17:44 UTC) is approximately 17 minutes: https://github.com/KSP-CKAN/CKAN-meta/blob/master/SCANsat/SCANsat-v20.4.ckan The first group in the table is handled via a webhook notification mechanism by which SpaceDock instructs the CKAN infrastructure to check the mod for new releases right after an upload finishes, which only happens if the "Add to CKAN" checkbox is checked on SpaceDock for that mod. If the background jobs mentioned below are not active, this happens immediately, otherwise it waits for the background job to finish (up to 10 or so minutes). The second and third groups are handled by a background job that checks those mods for updates every 30 minutes. The exact timing will vary based on the scheduling of the background job when the release is created and the position of the mod in the overall queue (currently alphabetical). The fourth group is handled by a similar daily background job. The idea is that simple SpaceDock mods don't need to be checked every 30 minutes because we should receive instant notifications for them, but in case the webhook breaks down on either the SpaceDock or CKAN side, there's a fallback mechanism to catch up. (There is a fifth group consisting of only my two mods, which are hosted on GitHub but are enabled for instantaneous updates via some special magic to which non-CKAN team members do not have access, but it's safe to ignore that for purposes of an overall summary.)