Jump to content

HebaruSan

Members
  • Content Count

    3,678
  • Joined

  • Last visited

Community Reputation

4,442 Excellent

About HebaruSan

  • Rank
    External Tank

Profile Information

  • Interests
    http://kerbalx.com/HebaruSan
    http://steamcommunity.com/profiles/76561197970804764/screenshots/

Recent Profile Visitors

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

  1. KIS's compatibility metadata comes from its author-maintained version files. The one included in the download says: "KSP_VERSION": { "MAJOR": 1, "MINOR": 8, "PATCH": 0 }, "KSP_VERSION_MAX": { "MAJOR": 1, "MINOR": 99, "PATCH": 99 }, "KSP_VERSION_MIN": { "MAJOR": 1, "MINOR": 8, "PATCH": 0 }, That's where the current 1.8.0 minimum version compatibility is coming from. The remote version file at https://raw.githubusercontent.com/ihsoft/KIS/master/KIS.version was later fixed to say 1
  2. Yup, that's known and expected if you use UI scaling, because UI scaling makes it impossible to predict where the window will appear in a sane way:
  3. Yup. And it's migrating to GitHub to increase uptime; remove it and re-add.
  4. Guessing you tried playing around with the auto-installed column. Uncheck the mods that you consider "anchor" mods that you definitely want to keep, leave checked the ones that you would not mind having auto-removed if all mods depending on them were uninstalled. When did this happen, what was CKAN doing at the time?
  5. It's probably easier to opt in to just that one incompatible mod by selecting it on the Versions tab:
  6. [snip] How extremely powerful engines are used a question of fleet practices, interstellar agreements, etc., not physics. Thus "Somebody Else's Problem" in the context of speculating about a link between "artificial gravity" and said extremely powerful engines.
  7. Settings like that can almost always be manipulated programmatically, if desired.
  8. Hmm, I don't think the Kzinti Lesson is a problem for this idea, at all; in fact, it helps. Yes, "Starships' engines are extremely powerful and efficient," as already stipulated. The have to be, to be able to perform the suggested maneuvers routinely. Why they don't use them as weapons can be delegated to be handled by a SEP Field.
  9. An idea to reconcile a perplexing fact-cluster from the Star Trek franchise in what I think is a new, hard-sci-fi-ish approach: Crews on board starships experience "gravity" (exactly equal to that of southern California), which is rarely explained, discussed, or explored in an interesting way Line of sight with away teams on the surface is never interrupted by the horizon, for comms, sensors, transporters, weapons, or anything else Starships' engines are extremely powerful and efficient, for both FTL and sub light speed travel, able to accelerate extremely quickly and rarely
  10. Again for those to come after us: I had to set driver.orbit in the coroutine, after the other objects initialize themselves. Quite surprising; usually you want to properly initialize an object before passing it to other objects to use, but apparently in this case you're supposed to wait till after the end. I guess these objects only get data by reacting to events rather than grabbing it from each other proactively, and presumably they set that up in their Start methods.
  11. Next bizarre quirk... none of the below lines do one single solitary thing. The orbit is gold colored despite setting every available property to red and passing red to every available color setting method. driver.orbitColor = Color.red; orbitRenderer.SetColor(Color.red); orbitRenderer.nodeColor = Color.red; orbitRenderer.orbitColor = Color.red; patchRenderer.patchColor = Color.red; patchRenderer.nodeColor = Color.red; patchRenderer.SetColor(Color.red);
  12. Interesting updates. First, this fixed those exceptions and eliminated the extreme stuttering they were presumably causing, so patched mode now works and is butter smooth: orbitRenderer.driver = driver; The orbit still starts out corrupted, but if I re-run the whole process verbatim, it suddenly amends itself to the copy of Kerbin's orbit that I asked for. So there's some kind of mystery state that's set properly the second time but not the first; time to randomly rearrange assignments till it works...
  13. Any luck yet? I can get an orbit to display, but only in "simple" mode (i.e., single orbit, not multiple patches). And that orbit isn't at all what I expect, the periapsis looks like it's dropped down to 0 despite the whole Orbit object being a direct clone of Kerbin's. Screenshot of the corrupted orbit in simple mode: Relevant portion of log (patched mode), with some statements added to annotate the coroutine: [LOG 17:47:11.971] Waiting for end of frame [EXC 17:47:12.213] NullReferenceException: Object reference not set to an instance of an object OrbitRendererBase.Creat
  14. Vessel.patchedConicSolver is a PatchedConicSolver, the patches property of which is a list of 150 Orbit objects reflecting the vessel's current orbit, as well as any future SOI transitions it will make on its current trajectory. The "real" orbits are at the start of the list, and most of the subsequent objects just have all their internal pointers set to null (presumably this was done for performance, to avoid re-allocating the list). Vessel.patchedConicRenderer is a PatchedConicRenderer, the patchRenders property of which is a list containing one PatchRendering object for each orbit in P
×
×
  • Create New...