Jump to content

allista

Members
 View Profile  See their activity

  • Posts

    2,208

  • Joined

  • Last visited

 Content Type 

Everything posted by allista

  1. allista
    Well, it's made as a building and is obviously meant not to be shipped in a rocket, but to be build on-site. If you're looking to assemble kits in space, there are orbital variants of everything: OrbitalAssemblyLine, OrbitalWorkshop and OrbitalAssemblySpace. *if you haven't seen it already, there's an explanatory video on orbital construction: https://www.youtube.com/watch?v=GpYY00kO2hg
  2. allista
    Version 2.4.0 for Kerbal Space Program 1.7.0 Released on 2019-05-28 Incremental Station Construction See the video for details Vessels constructed inside Orbital Kit Container can be docked to the main vessel instead of the container when launched. Orientation of deployment/spawning can be changed (in 90 degrees steps around Up axis) from the container's part menu and from the workshop UI. Added in-editor information window that shows assembly/construction requirements for the current ship, and shows bottom-most attach nodes available for docked construction. Deployment hint shows silhouette of the vessel that will be constructed in addition to the size of the deployed container. Deployment hint may be shown/hidden per container. Added part menu button to add a single part to the container in editor. Added warnings that prevent accidental deployment. Corrected Vessel/PartKit requirements calculations. Now resources that are not stripped away when a kit is created do not contribute to complexity and construction resource requirements. A PartKit costs at least dry-part-cost*0.1. Fixed kit resizing on kit creation/deployment in flight. Download
  3. allista
    Version 2.4.5.1 for Kerbal Space Program 1.7.0 Released on 2019-05-28 Using latest AT_Utils Download
  4. allista
    Version 3.3.6.1 for Kerbal Space Program 1.7.0 Released on 2019-05-28 Fixed some issues with Procedural Adapter and APR module. Using latest AT_Utils Download
  5. allista
    Version 3.5.6 for Kerbal Space Program 1.7.0 Released on 2019-05-28 In editor TCA UI is available whenever you have a command module. No engines/rcs are required to setup TCA configuration. Fixed exceptions caused by TCA grouping (thanks @123nick for reporting it) Other bugfixes. Download
  6. allista
    Oh, there's soooo much exceptions there (~54k), it's a wonder the game runs at all I'm not sure which of them are related to your problem, but at least some of them are from TCA, and that just may be it; the good news is that this particular bug was reported recently in TCA thread and the fix will be in the next joint release. Regardless, your mod list needs a spring cleaning: CommNetConstellation, BeaconCommNet (whatever that is), FlightPlan, IONRCS, ComfortableLanding -- all these couldn't even be loaded.
  7. allista
    Well, not exactly, but I've figured out how to fix it Something brakes the election logic that decides which TCA instance is the master of its group. Pretty hard to reproduce consistently to figure out the cause. But irrespective of it, the fix is just to check for the resulting state and repair it when it happens.
  8. allista
    Can't think of anything in GC that could have caused this, short of NRE; except that nothing in GC reacts to the docking. In any case, I'd look at the logs first.
  9. allista
    It's Teaser Time!
  10. allista
    Cool, didn't know you can do that with CKAN Not a user, me
  11. allista
    The actual dependency tree of GC from CKAN is like this: So yea, CRP blocks installation through CKAN via the chain GC -> GC-Core -> CRP. But CRP is just a bunch of config files, so despite what CKAN thinks, you can download and install it manually. CKAN should (I suppose) recognize manually installed mods and allow normal installation of GC. If not, just grab GC from the SpaceDock: https://spacedock.info/mod/1123/Ground Construction/download/2.3.2
  12. allista
    Which KSP version do you use?
  13. allista
    That'll be better, yes, but I'm not sure if he has the capacity
  14. allista
    @DStaal, @Terwin, @Paadwyn If you understand about USI logistics, I'll appreciate patches (or instructions) for workshops' configs to enable support for it. If patching configs is enough, of course.
  15. allista
    @123nick, thanks for the report, I'll check it.
  16. allista
    Look at the existing patches that CC provides. Here are the patches for the stock tanks, for example: https://github.com/allista/ConfigurableContainers/blob/master/GameData/ConfigurableContainers/Parts/Squad_Patch.cfg The "hardest" thing is to calculate the total volume. For that you need to look at the resources your tank holds by default and search for them here: https://github.com/allista/ConfigurableContainers/blob/master/GameData/ConfigurableContainers/TankTypes.cfg Then calculate as follows: Total volume = sum(resource_i/its_units_per_L/1000)
  17. allista
    CRP is actually a set of configs, so it's easy to use, as it's contents are available though the game database API. But with plugins (dlls with code) it's a different matter. There are several ways for one plugin to use another, and none of them is good. The easiest way is to link against a dll. This allows it's usage as if it's just your own read-only code; very powerful, very easy with modern IDEs. But makes such dll a hard dependency: your plugin won't even load if the one you're linking against is not present or of incorrect version. So your development itself depends on the work of the maintainer of the said dll, and on the correct installation by your users. That's why we mostly see this pattern simply as a way to organize the code by owned by a single developer/team. E.g. USI and my own utility libraries. There were precedents like KSP API Extensions, but I don't see them now. The other option is to use the so called reflection: a way to examine and manipulate foreign code objects at runtime without any previous knowledge about them. Which is to say that your compiler may have no knowledge, but you, of course, should have it to use reflection as a substitute for an API. So, this was is complex, messy and very prone to silent regression in case the foreign code changes due to an update. The cleanest way is to use an event/message system. Unity has one, and KSP provides a way to send custom part events. But as you can send only generic objects, it's hard to expose and to use a comprehensive API through it. Both sender and receiver should agree on the protocol, and the receiver (i.e. the API user) should each time painfully typecast everything back; which also means that only built-in types may be used. And that's why APIs based on event systems are usually restricted to necessary minimum of functionality which can be made stable and robust. To be fair, there was an attempt at the task. But unfortunately it didn't live:
  18. allista
    Unfortunately yes. I could have measured the net power flux at the time of switching away from a workshop and include it in calculations, but I could not simulate periods of being in planetary shade (if some of that flux is produced by the solar panels), eclipses and so on; what even worse, if some other mod does the same, we would use the same virtual power twice, this upsetting the balance. The same goes for other resources that are produced in parallel with their consumption, like ore mining. So unless there's a system-wide API for background resource production+consumption, the only thing we can reliably use is the storage. BTW, the workshop window provides the values of resource requirements for kit assembly/construction, including EC.
  19. allista
    Do you have enough resources stored, especially EC? The workshops do "background construction", but as there's no actual background execution in KSP (at least there wasn't at the time I made this), it is implemented as a "catch up": the moment you switch back to the workshops, it calculates what it would have had done in that time, and does it in a single big step. But if there's not enough resources for that, the step is made proportionally to what you have, and the construction is paused. While away from the workshop, you can see the simulated status of the construction in the main GC window (opens with toolbar button).
  20. allista
    CKAN reindexes packages independently, so in the first day or two such discrepancies are, unfortunately, common. It would be great to specify the exact versions of the dependencies, but that, if at all possible, would require updating netkan metadata with each release; which is also subject to reindexing. It would be also great if KSP itself informed the user when some of the dlls couldn't be loaded, instead of just logging an error. But it is how it is.
  21. allista
    Thanks for letting me know, I'll check if ckan gets the updates. Though the big is fixed in a version for KSP-1.7, so if you're using 1.6 ckan won't let you get it.
  22. allista
    With the correction for GC toolbar button, of course.
  23. allista
    With the correction for Hangar toolbar button, of course
  24. allista
    I want to stress this here, in TCA's thread, because most requests for this feature came from TCA users. Not surprisingly, considering how heavily I use color-coded UI elements in TCA. So, next time you want to change the way TCA buttons and labels look... Just right-click on TCA's toolbar button and enjoy!
  25. allista
    Version 3.3.6 for Kerbal Space Program 1.7.0 Released on 2019-05-14 Added ability to change UI color scheme at runtime To access the Color Scheme dialog, right-click the GC toolbar button Download
×
×
  • Create New...