Jump to content

allista

Members
 View Profile  See their activity

  • Posts

    2,208

  • Joined

  • Last visited

 Content Type 

Everything posted by allista

  1. allista
    No, there's currently no CTT support in GC. I, unfortunately, never got to that part; never even played with CTT. So a PR will be great!
  2. allista
    Thanks again! I think I've fixed both issues. The latter being merely the information on part menu not updating properly.
  3. allista
    This is definitely a bug I'll check it right away, thanks! I'm going to release a new version tonight, so if I fix it fast, I'll include the fix. OK, so is there some interface EL expects to find to gather the needed information?
  4. allista
    The costs of stored vessels are added to hangar's cost via IPartCostModifier interface. So the problem here should be somewhere on EPL side. @taniwha, would you care to look at this?
  5. allista
    Nor does it intend to
  6. allista
    Thanks again. Found and fixed both issues. Sorry to bother, but I'm interested: have you checked anything yet? I'm planning to make a release of all the mods later today, so your results will be very valuable
  7. allista
    @RoverDude, @DStaal, so, in the end of the day night: which path seems to be the best? GC uses USITools as is, providing only UI to instantly demolish any vessel in range, converting mass to MaterialKits like the demolition charge does. GC demolished vessels part-by-part over time with higher yield (dealing with catching-up, drifting and other staff): Using any qualified workshop with engineers inside. Using new dedicated part (that @RoverDude will create? Or teach me his modelling style ).
  8. allista
    Except that it would still cause the creation of the GroundWorkshop module, and will require some code tuning to honor this flag in GetInfo, OnStart and other relevant places, which is error-prone. And it's best to use "isEnabled = False" as it is already present in any PartModule. I mean, there's no need to actually make the "NotGroundWorkshop" module. It may be just a line in part.cfg without any class backing it up. It's enough that MM will see it and won't patch a part marked that way. Edit: I've done both. The patch with NotGroundWorkshop works perfectly as is, without any coding from my part. But the isEnabled flag is now also honored by GroundWorkshop module. So you can use either.
  9. allista
    Heck! What a shame *I see it too; the Mk1 pod does not have "Construction Window", nor can it construct anything, but it is still listed in the scenario window. Thanks!
  10. allista
    Let's say: @PART[*]:HAS[#CrewCapacity[*],~CrewCapacity[0],!MODULE[NotGroundWorkshop],!MODULE[GroundWorkshop]]:FINAL { MODULE { name = GroundWorkshop AutoEfficiency = True } }
  11. allista
    Whitelist is too restrictive with respect to mods that provide parts that I don't know of Would you prefer a dummy module then? Irrationally it seems to be more robust.
  12. allista
    Understood. I wonder, could it be done with MM alone? E.g. you add some magic value (like "NotWorkshop = true") directly to the PART node, and my MM patch checks for that value in the HAS block. MM should see such a value even if it's not used by the Part.Load. FYI, workshop efficiency calculation: I was thinking that a workshop itself should be the required part; especially if we tune the above efficiency calculation to eliminate most of the would-be workshops. But it could also be a specialized part. However, @DStaal almost convinced me that the prolonged disassembly in space (as I imagined it) is a bad idea; and that it should be left to the Hangar+KIS project.
  13. allista
    @mcortez, what you've described is what I'm currently trying to accomplish with Hangar+KIS, not with GC per se. @DStaal, @RoverDude, I deliberately left the proposition alone, because see above The question here is: should GC have standalone simplified demolition, or should I just point users to MKS for that? Or to use USI's demolition/logistics as is, but through GC interface?
  14. allista
    They're not all command parts, but all crewable parts with enough m3/kerbal of free space. Mk1 pod will not be listed, but the science lab will. The restriction is configurable, so we can exclude almost all cockpits by tweaking it.
  15. allista
    They're all separate workshops with separate queues, yes. But each will require at least one engineer inside to work. So if you have only one engineer who's in the PUD, the PUD will work, but Logistics and Refinery won't. And vice versa.
  16. allista
    This is strange. If you can reproduce it, could you capture a video for me? No, one workshop can construct only one kit at a time (hence construction queue). But two or more workshops can; they can also build the same kit, accelerating the process.
  17. allista
    GC panel should provide the info about any workshop and its status. If it misses one, it's a bug. But construction is done the workshop itself, so if you can switch to it from tracking station, you can summon the Construction Window from its part menu and see the status of or control the construction. Also, demolition module provides more flexibility. GC would only handle whole vessels, without ability to select parts.
  18. allista
    Hm... I always thought that trading amount for time is fair. On one hand you have a bomb and the ability to catch some of the pieces flying away. On the other you have a lone astronaut with the wrench huddled inside a can. And in my experience time does have an impact on the gameplay. Not everyone are willing to just skip a week or two in the time-warp to get +15% of a resource. And when you're trying to fill such time with action, it quickly becomes pretty hard. So I don't really see a conflict here. But I'm not holding that hard onto my idea, just discussing; with the exact purpose of preventing conflicts.
  19. allista
    I agree: controlled slow demolition should have higher yield. Timescale should be much shorter than for construction, but again, the complexity factor should play its role here (one thing is to scrap a fuel tank, the other -- to disassemble a rocket engine). I think something like 1:5-1:10; what takes 5-10 hours to construct will require 1 hour to demolish. Docking is not required: as far as the demolished ship stays loaded I can process parts remotely. So if the two ships are close enough with ~0 relative velocity, they'll stay that way throughout the full orbit. So I can safely switch to somewhere else, then return back after a time. The drift of some 100-1000m is not an issue. The most that could happen is that ships will drift beyond loading range. In that case demolition will just pause. USITools provide wireless logistics, which is more complicated that demolition, so I don't want to reimplement it. But I still can have soft dependency and, if without USITools, distribute resulting resources through current ship only.
  20. allista
    You mean USI_ModuleDemolition? Well, given the simplicity of the module, I think it would be easier to reimplement the demolition part inside GC, while reusing the logistics. The major difference is not part complexity, which is just another multiplier; but the time. I want to make demolition a process, like construction, not an instantaneous event. So that at the cost of some time and energy any kerbal engineer in any workshop-qualified part can recycle any debris out there part by part (using the same catch-up technique for unloaded operation). Or would it be too hindersome for enjoyable gameplay? @DStaal, what's your opinion?
  21. allista
    Thanks! Ok, so the basic idea is to automate the use of the ScrapPart method. This will require additional layer of abstraction in GroundWorkshop to have a single queue for construction/salvage tasks. And as always, I would like to make USITools a soft dependency... so either I need additional PartModule in a separate dll for that, or a reflection-based wrapper. On the USI side: I'll make my modifications to include complexity in a separate brunch for you to review.
  22. allista
    That's great! I had a feeling that USI might have something for that. Could you point me to that particular code? I'm a little lost in there I was thinking of something resembling the look-and-feel of GC: decouple single part from the vessel (and destroy it immediately), "process" it over some time to salvage resources (mass->kits, modified by part's complexity as computed by GC), then go to the next. In contrast to construction, this could be done in orbit.
  23. allista
    Question: do you, folks, need some kind of debris salvager that would process existing vessels and produce small amount of MaterialKits? I imagine this to be a capability of a properly manned Workshop, meaning that kerbals themselves would disassemble vessels and salvage materials from the parts. This could also lead us to using whole parts salvaged from another vessel, if a Kit's blueprint contains such a part; though as much as this is tempting, it will be very hard to implement, considering tweakscaled and procedural parts. @RoverDude, join the discussion?
  24. allista
    Patch for GPOSpeedFuelPump: https://www.dropbox.com/s/dbf26ob605pdha4/ConfigurableContainers.cfg?dl=0 Place it into GameData/GPOSpeedFuelPump/Patches/ I hope it will soon be included into GPO.
  25. allista
    @gamerscircle, here's the patch that works: https://www.dropbox.com/s/dbf26ob605pdha4/ConfigurableContainers.cfg?dl=0 @hab136, you're welcome to include it into GPO. I apologise, I currently don't have the time to fork-pull-request.
×
×
  • Create New...