Jump to content

Johould

Members
  • Posts

    125
  • Joined

  • Last visited

Posts posted by Johould

  1. On 7/11/2018 at 10:23 AM, revan1611 said:

    Hi everyone, i want to ask a quick question. Is it safe to install MKS on current KSP version (1.4.4.2215)? Because AVC shows that AT Utils and Ground Construction Core dependencies are incompatible, and i'm a bit paranoid to test it.

    Everything except DIY kits. The DIY kit part could be selected in the VAB, but trying to pick a ship to put in it did nothing. I didn't have any DIY kits in flight so I don't know if they break.

    Manually upgrading Ground Construction to the new version 2 didn't seem to break anything in MKS and lets selecting a design in a DIY kit work, but I haven't tested it farther than that. It should be updated in the next MKS release, RoverDude already accepted a patch from allista.

  2. On 11/1/2017 at 12:49 PM, Esendis said:

    One choice? There's another? Quicker preferably? :D

    Considering that uranium is also blocked from stock fuel transfer, I think the only alternative to leaving a vessel docked while it fills is designing the refinery so uranium tanks can be detached and physically transferred to your rover. :(

  3. 9 hours ago, billybob579 said:

    I'm running up against an issue that was mentioned back in August, but never resolved so far as I could find, so hopefully there's new info now. I've had a rover parked next to my base for quite some time now, automatically sharing habitation with the base. Now, however, when I drive that rover out of habitation-sharing range, the hab timers for the kerbals inside the rover immediately drops to zero and they go homesick. Is this just an unfortunate side-effect to balance an awesome feature, or am I overlooking some way to update their habitation to be dependent on the rover, rather than the base?

    Have you tried sending them EVA, or transferring them to the base for a bit before going back out in the rover? I think habitation is based off the absolute time you entered the current vessel, or the time since you were in another vessel, rather than actually counting down a remaining time. Decreasing the available hab time doesn't change when you entered the vessel, so you could suddenly go under. The problem is that their hab time already was dependent on the rover, and it didn't reset the entry time when you lost all the habitation bonus from the base.

  4. On 10/8/2017 at 8:20 PM, Johould said:

    Based on peeking around near the changed code, it looks like the added categories are filters based off the USI manufacturer names. Maybe I will try making custom CCK categories instead.

    Yep, everything except the order of the category buttons in the VAB seems to end up woking just the same if I delete PartCatalog.cs from USITools and then set up some CCK categories along these lines:

    @CCKExtraFilterConfig
    {
         Item
         {
                 name = Manufacturing
                 tag = cck-manufacturing
                 normalIcon = 000_USITools/Manufacturing_N
                 selectedIcon = 000_USITools/Manufacturing_S
                 usedByMod = UmbraSpaceIndustries
         }
    }
    @PART[*]:HAS[#manufacturer[USI?-?Manufacturing?Division],~tags[*cck-manufacturing*]]
    {
      @tags ^= :$: cck-manufacturing:
      &tags = cck-manufacturing
    }

     

  5. On 4/24/2016 at 7:49 AM, NecroBones said:

    Adding tags should be pretty easy. Strings can be added onto by doing something like this:

    
    @PART[MassiveBooster]
    {
    	%tags = #$tags$ sounding
    }

    The variable can reference itself and add something at the end.

    Unfortunately this doesn't work any more when the part has no tags, it produces errors and leaves the tags unchanged.

    [LOG 20:54:45.931] [ModuleManager] Applying node MyModuleManangerPatches/categories/@PART[*]:HAS[#manufacturer[USI?-?Logistics?Division],~tags[*cck-logistics*]] to UmbraSpaceIndustries/Kontainers/Kontainer_KIS_03/C3_Kontainer_KIS_03
    [LOG 20:54:45.931] [ModuleManager] Cannot find key tags in PART
    [LOG 20:54:45.931] [ModuleManager] Error - Cannot parse variable search when replacing (%) key tags = #$tags$ cck-logistics

    Using a separate &tags entry seems to work:

    @PART[MassiveBooster]
    {
    	@tags = #$tags$ sounding
    	&tags = sounding
    }

     

  6. Hello. It looks like this may have some incompatibility with either KIS 1.7 or KSP 1.3.1 - the game is crashing just before displaying the main menu, with only Workshop 1.2.1c, KIS 1.7 and dependencies installed. Here are logs https://ufile.io/bjrz7. I didn't get an error.log, but I never have (maybe that doesn't work on Linux 64 bit?). KSP loads fine if the Workshop directory is moved away.

    That's OSE Workshop 1.2.1c (1.2.1 according to Workshop.version) with the included dependencies CommunityResourcePack 0.7.2, ModuleManager 2.8.1, and Firespitter 7.6.0,

    and KIS 1.7 (1.7.6468 build 41490 in KIS.version) with its included dependencies CommunityCategoryKit 2.0.1 and ModuleManager 2.8.1 (identical to your DLL).

     

  7. Is there any way to move parts into MKS categories, or remove MKS parts from stock categories? In particular, I was hoping to unclutter Utility a bit by moving all the drills and converters into Manufacturing. That doesn't look like a CCK category, so I tried this MM patch, with no effect:

    @Part[MKS_Drill_*]:FINAL
    {
      @category = Manufacturing
    }

    How could I move these parts?

    22 hours ago, goldenpsp said:

    Hmm. The OP hasn't been updated to say 1.3.1. There has not been a post announcing a new version. So I'm pretty sure that would be no.

    There is now a new release. There is a little more discussion in the USI Life Support thread. It seems the existing release was expected to be compatible (maybe it only crashes on Linux?). Fast turnaround after it was reported.

  8. 8 hours ago, DStaal said:

    The giving the storage in the part itself doesn't make sense - as the whole point is that they are *collapsed* and not taking up the whole volume they enclose, so saying they should still hold the materials that would be in that enclosed volume is a bit non-sensical: It doesn't have that volume yet.

    I'm not sold on the overall idea, but onboard storage could work like the inflatable LFO tanks, expanding as the storage is filled.

    I don't think it's so bad to occasionally have to ship around resources. Planetary logistics can abstract the details of a planetary shipping network, but building and using local cargo ships sometimes is interesting too. Of course that motivation doesn't need to be inflatables. It would be nice if routine mission manager worked away from Kerbin.

  9. 8 hours ago, KriLL3 said:

    Sure, but I need a tank for those material kits larger than the volume of the thing I'm inflating, it's a bit excessive imo.

    Nothing should need a larger container than the inflated volume. If any part doesn't have decent volume savings when shipped deflated along with a container I think it's a bug. If you prefer you can always inflate the part in the VAB and not worry about material kits.

    Besides just launching more compact payloads a big point of inflatables is that material kits are relatively easy to produce in the field, so ideally you don't need to ship the material kits at all, or just on a reusable local freighter rather than from KSC.

    I'm not sure how the balance works out now that ground construction is integrated - shipping a DIY kit along with just specialized parts can also be finished with local material kits.

    Incidentally, do the extra modules USI uses for life support and logistics and stuff mess with the "complexity" calculation in GC?

  10. On 5/13/2017 at 0:01 PM, MaxwellsDemon said:

    My save file is over 6 meg... you sure I should post the whole thing?   :/

    They do compress very well. If you post it as a "gist" it ends up in stored in git, which basically gzips everything, and gzip is good for like 10x compression on a save. I don't know what attaching to an issue does.

  11. For hab/home time, it seems to be cheaper to send colony supplies or missing ingredients until you need several thousand kerbal-years of hab time. Past that point, the quadratic growth that comes from increasing both the base time and multiplier together might win out, if you want several thousand total kerbal-years of hab time (especially if you can make specialized parts for inflating hab rings and building DIY kits).

  12. 20 hours ago, bloodgusher said:

    I've scanned all the biomes and as far as I can tell, Leto has zero RareMetals and zero Uraninite.

    It may be worth setting up some manufacturing and shipping the missing resources. If you have all the other ingredients, 1t of RefinedExotics is enough to manufacture about 18t of Machinery or 7.5t of ColonySupplies. By units it's exactly 1/25th of the result. (Most MKS converters have the same total number of units in and out, but the various densities mean the mass balances are all over the place. The strangest is that Machinery masses over twice the sum of the specialized parts and material kits that go into making it).

  13. 6 hours ago, DStaal said:

    Catch-up runs the vessels in the current physics frame with all models and physics in a reduced mode, from what I understand.  Background processing would run *every* vessel, all the time.

    If your game slows down when you enter the range of one of your bases, think about what it would do if you were in range of *all* of them.

    I was hoping maybe the reduced mode was light enough to allow running it for several vessels at once, but only whenever the game was already going to run it for one vessel. Ideally run everything around the new planet with the days interleaved so even mutual dependencies would work out (like if the mining base needs supplies from the manufacturing base it is supplying for the crew to keep working the whole time). If that's too much to hope for, maybe at least some way of configuring bases so that whenever the game would catch-up it, makes sure that some other vessels are up to date first. I'd rather have a long pause when returning to a base after a few years than finding no production and the crew all on strike.

  14. Well, I don't mind just using EPL to build DIY kits for now, and I'm not far enough in my new save to really need to build kits away from Kerbin anyway.

     

    KIS will definitely let you attach kits to ships, or docking ports to kits - the DIY kit itself might be too heavy to lift conveniently.

  15. 2 hours ago, RoverDude said:

    Background processing (i.e. running processes on unloaded vessels) is generally a really really bad idea, especially given the number of bases, converters, etc. you typically see in late game with colonization.

    But there *is* a new logistics system in the works :wink:

    How is that different from the usual catch-up processing? Does the usual catch-up run with all the models and physics loaded? I just assumed it was sort of just checking converters.

    Remembering to visit bases in the right order sounds like a pain, I wouldn't want to waste a few years' production by loading a main base before touring the mining outposts. Do you know of any fixes that might be feasible?

  16. 30 minutes ago, N3N said:

    And maybe you have to actual start every launch by yourself at a base and it consumes a procedural part of LF+Ox+Mono+Machinery/MK/SP and take some time to arrive at the space station.

    I haven't tried it with MKS, but that sort of sounds like what Routine Mission Manager is supposed to do - fly a mission once yourself, and then you can just order up a repeat mission delivering the same payload for the same costs.

    Maybe only missions from KSC? I don't think it's very flexible about letting you switch to a different payload of similar mass, or automatically combining several recorded flights to deliver along a new route.

  17. Starting construction on a DIY kit loaded with a vessel design that includes DIY kits will destroy the solar system. Do you have plans for how that might work?

    Besides just generally wondering what would happen, I was thinking of building a spindly exoatmospheric freighter on minimus, already loaded for a colonization mission, including DIY kits. I think it would make sense to just dump parts from  the child kits into one big box for easier launch, so it makes sense that at least the full mass and price of kits from the design would add to the new kit, with it's assembly time representing just sorting out and repacking the contents for the smaller kits 

     

    For another experiment, I could build a DIY kit from an OSE workshop but it came out as an empty kit. There is a bit of thematic overlap between Ground Construction and OSE Workshops with the construction window showing a sequence of parts being built. It's a bit odd to use both, when OSE workshops builds parts completely from off-planet resources - DIY kits definitely save on assembly but it's a bit odd that then assembling the parts automatically is the only step requiring the specially shipped DIY kit - although that kind of fits with your plan to support orbital construction by having hangers previously-built parts according to ship designs.

    If you think of it like that, maybe the expanded DIY kit is acting like a temporary construction enclosure, and invisible dedicated KIS storage for the vessel parts, perhaps along with something special that makes building the individual parts cheaper.

    Then the low tech option for building a sort of kit offworld would be building actual parts and shipping over a KIS container, or just parts that require advanced ingredients. Perhaps the process to build an actual DIY kit could require starting with the parts in an inventory, and then take more time/work trimming off excess mass (perhaps returning it as (some fraction of) the same resources needed to build the kit). Requiring enough KIS storage to have all parts on hand rather than allowing them to be manufactured and packed incrementally might be a decent way to require bigger bases to pack kits of bigger vessels.

  18. On 4/29/2017 at 9:57 AM, DStaal said:

    In those - if I remember correctly - they are the number of crew who would get the full hab time.  If you put in less crew, you get more hab time than that, if you put in more crew then you get more hab time.

    It's a bit less meaningful there. :wink:

    With the Hitchhiker a single Kerbal gets the 21 Kebal-months (plus 1 for 4 seats), and with more crew it is divided evenly, like getting 330d each with two Kerbals.

  19. 1 hour ago, Brigadier said:

    If I'm not mistaken, it's the maximum number of Kerbals the part will support with its given bonus.  Additional Kerbals present in the craft beyond that number will not be able to take advantage of the multipliers.

    Sure, that's how multipliers work (well, multipliers apply fully up to the limit and then divide evenly, took me a while to figure out too), but the Hitchhiker container doesn't have any multiplier. It just has a straight +21 months hab time, which seems to apply to a single kerbal crew, or divide evenly between crew members. That's why I'm so confused that it has a "Crew Affected" number in the habitation information.

×
×
  • Create New...