Jump to content

allista

Members
  • Posts

    2,208
  • Joined

  • Last visited

Everything posted by allista

  1. Oh, my! That's a bug. What's more, I've just checked, and it's literally a single litera bug There's MaxApR() in the code where there should've been MinApR() Thanks!
  2. The tooltip on this setting says: Maximum allowed days until launch. If no suitable launch window is found within that period, launch when in plane with the target. Also, the Max. Days option respects the Kerbin Time setting (whether use 24h days or 6h). Launch from the Mun: using Rendezvous autopilot? There's no ApA setting there, no? Didn't quite get this part
  3. TCA does not require Configurable Containers, merely suggests, and you can choose to not install it. So what you did does not affect TCA. Configurable Containers do conflict with IFS in that both mods modify the same parts (stock and from mods) using MM patches; and as both dynamically handle in-part resources, they cannot work side by side. Both libraries (i.e. dlls) could be installed simultaneously, though, as they don't do anything without part patches; this corresponds to CC-Core and IFS-Core packages that some other mods require. No debug logging in release builds, as it has considerable performance impact. Anyway, if there's an exception of some sort, it should be present in output_log.txt (Player.log mac/linux). If there's nothing of the sort, it may be an incompatibly with another mod, or an error in logic. In both cases I need to see with my own eyes what's happening, either via vodeo/screenshots or by using your .craft or save files.
  4. The "incompatibility" with ART is just that the "space" that is "freed" during the mining is used in completely different ways, by different PartModules (or rather frameworks of PartModules) that know nothing about each other; nor can they without linking against one another. To make things compatible, I need to: design and implement (in ART's codebase) the asteroid-shared-space API through part events and/or other means that do not require linking the Hangar against ART reimplement corresponding part of the Hangar to use the new ART's API to interact with asteroid's space, if and only if the ART is present, while using internal space storage otherwise (imagine now what would happen if a user installs Hangar, then ART, then removes ART or Hangar?) solve (even remotely I do not know how) the backward compatibility problems, so as not to break savegames At my current workload level I would estimate the work to take about 4-6 months, and only if I don't spend my KSP time for other mods. *colors in the wishlist are just approximate priorities. The greener, the more I'm inclined to take it to development.
  5. To mine resources, the asteroid factory uses a module that inherits from the stock ModuleAsteroidDrill, so the mechanics is the same. There is a difference in configuration, though, in that the stock Radial Drill has Efficiency=5, while the Asteroid Factory has Efficiency=10. This affects the steepness of the exponential asymptotic curve that determines how much resources you get each cycle of the harvesting process. So the Asteroid Factory will harvest an asteroid faster. But the final amount harvested is defined in asteroid itself.
  6. This mod haven't been updated in a while and is marked as "for KSP 1.3.1". So it seems like their problem, not GC.
  7. Looks like installation issue. Probably missing AT_Utils, or it's version is incompatible with your version of TCA. Try downloading from SpaceDock and reinstalling, so that the GameData has both the 000_AT_Utils and the ThrottleControlledAvionics folders from the archive.
  8. Surprisingly, it works like a charm! Yea, I know it says "Rename Kit". I've already fixed that
  9. Thanks for the report. Please, share the output_log.txt (Player.log on mac/linux) after the crash; there have to be some exceptions that cause this. I will try it myself when there's time, but you'll probably make it faster then me. I concur, it would be great to have the possibility to name docking ports. But since they're Sqad's modules which are, truth be told, not intended to be used multiple times in a single part, I unfortunately cannot do nothing about it (and believe me, I already tried), There's a pretty useful mod: that claims to add the capability to name docking ports. But I'm not sure they do consider multiple-module parts. Hm... I've just had a thought about how it could be done, though. Let me try it out...
  10. You can add MM patch for TweakScale, but why do it, if you simply can make an empty container, then assemble a kit in it without any size restrictions?
  11. The 3.5.2 is probably compatible with KSP-1.4.2, so what you see is most likely an installation error. Have you also replaced the AT_Utils with the one that comes with 3.5.2? More importantly, share the ~/.config/unity3d/Squad/Kerbal Space Program/Player.log, so we could look at the errors.
  12. Never removed it, actually. If your KSP/Unity distribution correctly assigns KeyCodes to key events, you can assign anything except Esc and Backspace. If not (like on some win platforms), only alphanumerics do work. That's Unity's limitation, not TCA's.
  13. I may be compatible with 1.4.3, but I'm not so sure about the older versions. Tell is what you'll find. If you're using USI there's containers for all the needed resources to accumulate. If not, I recommend Configurable Containers for the task. There full version with the patches for most of the container parts. As for the the reduced construction speed: this mechanisms is actually implemented from the beginning, but there's a threshold to it. Kerbals won't do a 0.1% percent of work they able of; nobody would And the conversion is very slow compared to most construction requirements (which vary per part). So the intended operation is: first accumulate, then build.
  14. No mismatch: 1. It's the ThrottleControlledAvionics.user, the user_ is a rogue file that went into the archive by accident. 2. The location is GameData/ThrottleControlledAvionics/ThrottleControlledAvionics.user as you see from the logs (".." meaning "one dir up") 3. Indeed, why not?
  15. With the current architecture this could be done in principle, but I need to make another special container module that will not be resizable and be destroyed when the resulting vessel is spawned inside. I consider this a feature request. Thanks for the idea. https://github.com/allista/GroundConstruction/issues/41
  16. Oh... It seems I wasn't paying enough attention here. Reckon I also need to fix this now Thanks)
  17. The code in AnisotropicResizable.cs#L145 does just this: recalculates drag cubes in OnStart. Animations, however they're implemented, should use something like this: MultiGeometryAnimator.cs
  18. The part with PR did happen, i.e. the proper version of GC was included in MKS repo. As for the MKS release, I don't really know, but was under the impression that it also did. Currently there's another PR with GC 2.1 that adds the long requested orbital construction to completely supersede ELP; but as far as I know, RoverDude is occupied with his job and family for the last months , so again, we all have to be patient. Life comes first. In any case, you can always install the standalone version of GC, which will work just fine with MKS. The difference with the bundled version is that some parts and features are excluded so as not to interfere with the ways USI runs things.
  19. Thanks for the report. I'll recheck tech requirements; they haven't been changed in a while, so you're probably right.
  20. That's an intended limitation. Honestly, I don't think I should've allowed to carry gunpowder grain inside DIY Kits at all; but as it is now, you can pack SF from Kerbin where it's produced. On the other hand, if you assemble a new kit off-world, you don't have the luxury of including resources into the kit because as a rule you don't have any. Indeed, does your base produce SF to add it to the kit from which the separatrons will be build? Even if it did, there's no way to transfer it, because, well, it's solid. This is not a trivial problem, actually. There're a number of resources that are required for some parts to work (consider reactors that use Uranium), but which you cannot produce, transport or transfer; they only come with the parts on Kerbin. It stands to reason that you can take a complete part, disassemble it and add to the kit; but you cannot create such a kit from scratch, because even if you make all the pieces on 3D-printer, they're not enough for the part to work; and 3D printers can produce enriched radioisotopes no more than gunpowder.
  21. I don't think it would, as a part in KSP cannot hold two volumes of the same resource. So there's actually nothing to merge. As for the empty costs -- that's weird! From the configs: GAL 300k + 100u Machinery OAL 450k + 100u Machinery OW 50k IW 3.5k I've just looked in-game, figures almost match (for some reason the parts cost a little less in Editor; also strange). Even full they cost less than you say...
  22. Let me tell you what I'm planning on doing next for GC; after I tend to the long standing matters in Hangar and maybe (fingers crossed) start to implement the translational control via active gimbaling in TCA that I've been long dreaming about. I'm going to work on the docked spawning from kit containers. So that you could actually grow a space station incrementally, next module docked to the previous right away. That's my priority.
  23. Knowing how part joints actually work in KSP, I totally agree. Still, this is a game and one encounters such limitations all the time. That's just what I wanted to ask, provided, if course, that @AlonzoTG have some skill in 3D modeling. There are two problems here: first is texting. I can reshape the nodes to #3, but that would mean to re-texture everything from scratch; which is always triple harder than modeling the objects. But second is: suppose I do it; what will become of the ships that people here are building right now with the current parts? Anyways, judging by the looks of the real space station is pretty standard to make segments considerably thicker than the passages/ports between then; recon this has something to do with pressure inside. And aesthetics
  24. Why does attaching #2 node to #4 node of the fairing bother you so much? It would stick alright and will be held in place with auto-struts. It's enough to lift the thing into orbit, is it not? Other options include: pack them into a kit and build it in orbit; use Hangar's alternative fairings. I like the idea of making several attach nodes using the shroud module, so I'll see what it costs in terms of labor. But unfortunately I don't have that much free time for KSP, and I always prefer adding new functionality in code to adding new pretty models. So to be honest, as much as I like 3D-modeling, all the parts I make are only for MVP, and I try to spend on them as little time as possible.
  25. Yea, sorry, this is documented somewhere (probably in TCA docs, because UI elements are in the shared library), but is not obvious. 1. To apply the change of any numerical field in any of my mods you just have to press Enter (or numpad's enter). There once was the Set button, but it was replaced by this behavior to conserve UI space. 2. Once you've applied the change, the line will change back to F/E/X, and you will have the free volume to add another tank of any type, including your saved config. 3. The "strange" volume increment is just 5% if the total volume. And the small decimal part (.000009) is not rounding, but the floating point error; when a commuter works with the floats, it cannot, due to the nature of internal representation, perform exact operations. 1.0+1.0 is always equals something like 2.000002 or 1.999997. This is what you see here. I could choose to round the numbers to, say, 1L. But that would mean you'll always have some small unusable leftover volume. So instead the volume field uses the round robin format to show and read current value exactly.
×
×
  • Create New...