Jump to content

allista

Members
 View Profile  See their activity

  • Posts

    2,208

  • Joined

  • Last visited

 Content Type 

Everything posted by allista

  1. allista
    I hate to write UIs That aside, I was thinking of adding some UI to configure rendezvous for a while. The problem is: if I provide the choice, I need to provide some guidance on how to make it in particular situation. And if I can't guarantee that the double-maneuver transfer is more efficient, why bother with it at all, except that it can be somewhat faster? I mean, configurable or not, the use of initial correction should be justified. BTW, surprisingly, plane-shift+Hohman transfer is not fuel-efficient; it is also resonance-sensitive and is definitely slower than direct transfer. How much slower: currently, full 2D optimisation takes approx. 1 to 5 seconds to converge, 5 iterations per frame. But as dimensionality goes up, the timing becomes less and less defined due to the increasing flatness of the landscape of the objective function. So in "good" case it still could be a second, but in a "bad" one could take tens. And on a flat hypersurface there's less chance that a semi-greedy algorithm will actually converge near the global minimum, not in a random local valley.
  2. allista
    Calling astromechanic to fix my brain gears! After @Jarin's report I'm trying (for several weeks now) to improve the rendezvous trajectory calculation. I've already implemented a semi-greedy conjugate direction 2D search for minimum dV transfer which works much better than the current two-step 1D search. But now I have a problem: if you use the rendezvous autopilot, you know that often it tries to correct current orbit to achieve faster resonance with the target; in most cases after this correction the total dV of the transfer+brake maneuvers drops. But half the time it drops less than the correction itself has costed, so the net dV is increasing instead of decreasing. Theoretically there are two solutions: either perform full 4D optimization for two consequent maneuvers (which is A. much slower, and B. it's harder to get to the global minimum in 4D than in 2D, so it will produce suboptimal total dVs). or try to predict from the vessel+target orbits if the correction will be successful. Currently I'm trying to do the latter; but so far in vain. I'm trying to separate the cases using PCA, but no matter what orbital parameters and in what combinations I plug into it, the best I get is ~30% separation between the "good" and "bad" classes. There're also a number of non-linear transformations I tried beside/along with PCA to reduce dimensionality of the problem. No luck. I will appreciate any advice/thoughts on this
  3. allista
    There certainly is, otherwise why would there be two versions? MKS's version is stripped down: it does not include any patches (so no workshops in stock parts, no ISRU) and parts, except for the DIY Kit itself. Instead, MKS adds its own dedicated workshops and MaterialKits production pathway.
  4. allista
    @RoverDude, what say you?
  5. allista
    I'm seeing it just fine:
  6. allista
    This is not an installation problem and this message is harmless: it just informs that AT_Utils tried to load a config file and failed because it does not exist. This is part of the normal operation. The cause of the crash is somewhere else. And as CTDs go, you'll probably find nothing related in the logs, because the logs are written by a living Unity instance, while at the moment of the "crash" it is terminated by the OS. So only native stack traces or core dumps could help to debug here.
  7. allista
    This is very interesting. I hope you still have a save with this problem, mabe a _before_launch autosave that GC makes? If so, I would like to look into it to see where the problem is.
  8. allista
    @RoverDude, considering the no-engineers problem, would you think it would be OK to let engineers of 0-lvl to be able to perform construction with, say, 0.5, or even 0.1 of SK (skilled kerbal) efficiency?
  9. allista
    No, this has nothing to do with resources. I already have several reports of this issue, but sofar was unable to reproduce it. For engineers to count, they have to be exactly in the workshop part, and have the experience level of 1 and above.
  10. allista
    Hm, the only reason for that error message I've found in my code I've already fixed in the latest version. So yes, logs would be appreciated. @Jebs_SY, @ErevanGaming, thanks for the logs! Will investigate the matter.
  11. allista
    Kerbonauts are not placed into the hangar in any special way: they're just transferred to vacant seats of available crewable parts of the receiving ship. So they continue to exist in a normal way, receiving experience as any other kerbals do.
  12. allista
    Like this:
  13. allista
    Just look at the trailer. Many moments are almost identical with the original GIST, like the battle in the water, or, for that matter, the scene where Major's body is made. Also in the SAC there's no mystery about Major's history, while in the trailer she says "I'll find out who I was"... So "noooo" indeed =\
  14. allista
    I'm afraid there won't be any, they're remaking the original GIST movie, not the SAC :(
  15. allista
    About autopilots and AI. Who knows tachikomas? Here's their grandparent!
  16. allista
    Good point. Will do.
  17. allista
    EDIT: Wait, there is for To Orbit. The steepness parameter. The higher it is, the higher and more pronounced will be the turn. Alas, currently it can't be configured for Rendezvous from surface. That I will fix.
  18. allista
    It seems they've found a workaround: Could anyone confirm this?
  19. allista
    Thanks a lot!
  20. allista
    Thanks! Fixed TankTypes.cfg may be obtained from github until the next release: https://raw.githubusercontent.com/allista/ConfigurableContainers/master/GameData/ConfigurableContainers/TankTypes.cfg
  21. allista
    Reinstall using the archive from SpaceDock.
  22. allista
    There is $kref entry which replaces the download one, because both mod version and download link are obtained from kref provider (SpaceDock in that case).
  23. allista
    You're right, I'll add this to the manual, thanks! Or maybe just make the configuration UI at last... Edit: github issue: https://github.com/qfeys/ThrottleControlledAvionics/issues/36
  24. allista
    ksp_version/vref are not required when you use SpaceDock as a package source: netkan simply uses the version provided by SD. If you add ksp-avc stanza though you're in trouble if the archive contains several .version files like mine do (AT_Utils.version and mod.version). Of course it didn't, that's why it is called GC-Core; to get Spacecrane and Mobile Workshop you need full GC Which is simpler to install directly from SpaceDock. You mean it wasn't able to download the archive from SpaceDock? Stranger and stranger...
  25. allista
    I've created an issue for that: https://github.com/KSP-CKAN/NetKAN/issues/5289
×
×
  • Create New...