• Content count

  • Joined

  • Last visited

Community Reputation

121 Excellent

1 Follower

About Wyzard

  • Rank
    Spacecraft Engineer

Profile Information

  • Location Maryland, USA
  1. In particular, DeployableEngines comes with Cryogenic Engines, which has been updated for 1.3. And it does contain a DLL. (Or did you mean some other "engines folder"?)
  2. FWIW: I just installed this mod in 1.3 and it seems to be working fine. I built a test plane using MkIV fuselage parts and tried out several of the engines (Scimitar, Broadsword, Valkyrie, Arcadia), and they're all working correctly (including mode switching on the dual-mode engines, and the Arcadia's thrust reverser). I omitted the MarkIVSystem/Plugins folder since Nertea said those plugins aren't actually used anymore. I also omitted all the other top-level folders besides MarkIVSystem (e.g. NearFutureProps, DeployableEngines, etc.), and instead used the newer versions of those things that are bundled with Nertea's other mods. It looks like MkIV itself works fine in 1.3, and the problems people've had are just from the outdated bundled dependencies.
  3. Does your mining lander have a part that's able to push to PL? If not, it won't work. You need one of the "Material Processing Unit" parts (which are meant specifically for uncrewed mining vessels), or a logistics module (which is intended for crewed bases). You don't strictly need to have 6 hours of storage on your vessel. You want to, for efficiency — without enough storage, your drills will basically be idle for part of each day, because storage is full and the daily PL push hasn't happened yet to free up some storage space. But PL will still work with less storage, as long as the vessel includes a part that provides PL capability. Note that a PL push will only happen when the storage tank is more than 75% full. If you've just landed your miner, even if it has PL capability, you'll need to wait awhile for it to mine enough resources to do its first push.
  4. I think this makes a lot of sense. Supplies isn't just food, it's water and oxygen too, and you can't survive 15 days without those. That implies that there's a small reserve within the cabin itself, even after the supply containers are empty.
  5. Hmm, that SEV cabin looks suspiciously like a Karibou. NASA engineers must be playing with MKS!
  6. It also has some similarities to Feline Utility Rovers — wheel placement, and the sloped bottom of the front cabin. (I suspect FUR might be inspired by the same movie.)
  7. FWIW, if you install Indicator Lights, the experiments themselves will flash.
  8. This sounds like it may be referring to the bug where some parts allocate much more radiator capacity than they need, leaving other parts starved for cooling. That's not specific to USI reactors, though; I think it's just a bug in the stock heat mechanics, possibly related to the part having a large "max cooling" value. The workaround is to use "nearby-only" radiators placed such that the offending part(s) can't draw from them, but other parts can. "Having to use stock radiators" is just because HC doesn't provide any nearby-only radiators. There's an MKS drill that's known to cause the problem, which sparked some discussion in the MKS thread and a bug in the MKS tracker. My example craft file attached to the bug has a USI reactor and stock TCS radiators, but I originally encountered the problem while using NFE's MX-0 reactor and HC's YF-75 radiators (together with those MKS drills). (Note that this was in 1.2.2, though; I haven't tried it again in 1.3.)
  9. I tried out v0.0.4 and I'm able to install patches now, so it looks like the path issue I had earlier is fixed. Thanks for the quick response! A few observations: The OP shows a screenshot of the settings in the Game Difficulty window, but they're actually in a separate window that's accessed via a button in the main PatchManager window. I think it's better that way, though; PatchManager's settings aren't related to difficulty, and changing them shouldn't force the game's difficulty level to "custom". The description above the "store active patches in the PatchManager folder" checkbox says that changing it won't move patches that are already installed, but the patches actually do move to the new location when I click OK to close the Settings window. If I change a mod's original version of a patch (as can happen when upgrading a mod), the installed copy in ActiveMMPatches doesn't change, even if I open the PatchManager window and click the "Apply All" button. Looks like the only way to activate the updated version of the patch is to disable the patch, apply all, then re-enable and apply all again. It may be a good idea to make the "Apply All" button reinstall patches that are already active, to pick up any changes that may have been made to the original version. (It'd also be helpful if PatchManager could notice the discrepancy and warn the user.) Other than those issues, things are working well. I'm hoping that PatchManager gains traction and becomes widely-used, because optional patches are something that aren't really well-handled in KSP right now. (I can only think of a few mods that provide them, each in its own ad-hoc way. I'd love to see that change.)
  10. Yeah, I thought about that. I figured it'd be appropriate to suggest it here since PatchManager would be the main user of the feature, and linuxgurugamer might therefore might want to make the MM changes. I may suggest it over in the MM thread as well, but actually I kinda like the :NEEDS/:FOR approach better — it's simpler to implement and provides more flexibility. I'd expect that patch definitions can be garbage-collected after MM has applied its changes to the game's real configuration, so memory usage of disabled patches shouldn't be an issue. They do still need to be parsed, but people probably aren't going to have large numbers of optional patches in their installation so I doubt that's a significant issue either.
  11. Well, in principle it'd just be a small adjustment after MM has finished scanning for patch files, before it starts actually processing them. Just add some more files to the set that's about to be processed, and remove some others. I'm pretty sure filesystem scanning and patch application are already decoupled, since MM has to filter the patches based on :NEEDS conditions, and rearrange the list to satisfy :AFTER constraints. This would just be an added step before that one. (But I don't know how the MM code is structured, so I don't know whether it'd be easy to add or if it'd require a lot of refactoring.) Actually, the existing MM preprocessing brings another idea to mind: optional patches can be controlled by a :NEEDS condition for a patch-specific name (e.g. :NEEDS[ExampleModRealismModeEnabled]), and to enable the patch, PM could just create a dummy .cfg with a corresponding :FOR clause which defines that name. Default-enabled patches would use :NEEDS[!ExampleModRealismModeDisabled] instead. This would avoid the need to hide patches in a PluginData folder and copy them out to activate them, and it doesn't require any changes to MM. It also has the advantage that :NEEDS conditions can be applied to arbitrary things within a patch file, rather than being limited to enabling or disabling the entire file. (And actually, the above can be accomplished already if the mod author ships the dummy :FOR patch to be enabled by PatchManager using the current copying mechanism. But it'd be useful if PM could directly create the :FOR patch using a name defined in the PatchManager metadata file.) Anyway, that's enough brainstorming from me for now. I'll try out v0.0.4 later tonight.
  12. I like the new fainter aurora. But the terminator has noticeable color banding, and a sharp transition from white to greenish. (I've seen this in my game too, so @blorgon, it's not just you.) That said, I personally don't think the terminator banding is really a big deal — it's only noticeable around the south pole, which isn't something I spend a lot of time looking at.
  13. I was thinking about the issue of where to copy the patches to, as well as the challenge of enabled-by-default patches that was discussed earlier, and it occurred to me that it might be useful to add patch enable/disable functionality into ModuleManager itself. If ModuleManager could read a config file that tells it to ignore certain patches, or to process certain patches that'd otherwise be ignored (due to being in a PluginData folder), PatchManager could act as a front-end for editing that config file, and there'd be no need to copy patch files at all. I know that'd be a big change in direction for this mod, and a bunch of work on a different mod to support it, so it's understandable if you'd rather not go in that direction. But there are benefits in being able to enable/disable MM patches without having to copy them to different paths, so I'm suggesting it as a possible future enhancement. In particular, if an upgraded version of a mod brings an upgraded version of a patch, a copy previously made by PatchManager will still be the old version, and some extra steps are needed to replace it with a copy of the new version. If the patch is instead enabled in-place via MM config, the new version takes effect immediately. Hypothetically, imagine PatchManager creating or editing a file like this: ModuleManagerConfig { // From ExampleMod/PatchManager/PM_DisabledByDefaultPatch.cfg use = ExampleMod/Patches/PluginData/DisabledByDefaultPatch.cfg // From ExampleMod/PatchManager/PM_EnabledByDefaultPatch.cfg ignore = ExampleMod/Patches/EnabledByDefaultPatch.cfg }
  14. Are you sure there's no visual change? It's pretty subtle and easy to overlook even when it's working. While in orbit and over the daylight side of a planet, open the PlanetShine settings window, click on the Advanced tab, and toggle the "global ON/OFF" checkbox while looking at the planet-facing side of your spacecraft. You should see a (subtle) difference.
  15. Yes, it's ModuleWeightDistributableCargo. Several MKS and Kontainers parts have it (such as most or all of the Ranger modules), and MKS includes an MM patch that adds it to the KIS storage box too.