• Content Count

  • Joined

  • Last visited

Community Reputation

333 Excellent


About Wyzard

  • Rank
    Junior Rocket Scientist

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. NFE patches the MKS reactors so they work like the NFE ones. Assuming you mean the USI "Kontainer" tanks that come with MKS: yes, they have boiloff when CryoTanks is installed. CryoTanks itself doesn't directly patch the USI kontainers since they already have a fuel switcher, but USI includes a patch of its own that does the same thing for the kontainer tanks specifically. If you're interested in the specifics, the files to look at are NearFutureElectrical/Patches/NFElectricalUSIReactors.cfg and UmbraSpaceIndustries/Kontainers/CryoTanks.cfg.
  2. Glad to see that there's a new release! I'll be trying it out later today. (I'm still on 1.7, though.) And I see that the xmitDataScalar fixes are included — thanks for that. However, I want to repost two small compatibility patches that I posted earlier and that I think might have been overlooked:
  3. It's good that there's documentation for this. However, having to edit the patch file means the customization will be lost when upgrading to a newer version of ReStock. As a variant of @Eridan's suggestion, it'd be handy to have a condition on each of the patches, that can be used to disable it — e.g. @PART[liquidEngine3_v2]:NEEDS[!ReStockDisableTerrier], so that someone who wants to use the stock model can make a little patch with :FOR[ReStockDisableTerrier], and ReStock's patch will turn off without having to edit the file. That'd make it upgrade-friendly.
  4. I'd always wondered about the actual distinctions between these categories. This is helpful to know.
  5. I'm confused as to why this mod calls MusicLogic.SetVolume at all — how is that related to science? Is it some sort of weird bug workaround?
  6. So, the news reporting about NASA's recent all-female spacewalk includes a photo of them holding a type of tool that should be familiar to KIS users. (That's from this NBC report. And this article has an image of Jessica using the tool on Earth.)
  7. MKS just uses Firespitter for resource switching in kontainer tanks, doesn't it? It may be worth looking at B9PartSwitch as an alternative — that's what most mods use (when the stock switcher isn't enough), and its UI is nicer than FSFuelSwitch. (Switching to B9 would have a backward-compatibility impact for spacecraft that've already been launched, though. But a major update like 1.8 seems like a reasonable time for that to happen.)
  8. @SQUAD, you may want to un-sticky and/or lock this thread. It's about a graphics bug in KSP 1.3 that was fixed in 1.4, and people are reading advice for that bug from two years ago and thinking it's relevant to launch issues in KSP 1.7/1.8 today.
  9. Speaking of settings XML files, here's an oddity. Using KER in KSP 1.7.3, I tried to open the KER settings in the VAB, but when I clicked the settings button, the KER window disappeared except for a tiny gray square near the top-left of where the settings window should've been. I figured it might be something wrong with the settings files, so I moved my whole Settings directory aside to make KER regenerate the defaults, which fixed the problem. Then I tested moving individual files back to see which one made the problem reappear. It turns out that the problem was caused by having this in my GeneralSettings.xml file: <?xml version="1.0" encoding="utf-8"?> <ArrayOfSettingItem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SettingItem> <Name>FlightAppLauncher_IsHoverActivated</Name> <Value xsi:type="ArrayOfXmlNode"> <XmlNode xsi:type="ArrayOfXmlNode" /> <XmlNode> <XmlNode xsi:type="ArrayOfXmlNode" /> </XmlNode> <XmlNode> <XmlNode> <XmlNode xsi:type="ArrayOfXmlNode" /> </XmlNode> </XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode xsi:type="ArrayOfXmlNode" /> </XmlNode> </XmlNode> </XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode xsi:type="ArrayOfXmlNode" /> </XmlNode> </XmlNode> </XmlNode> </XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode xsi:type="ArrayOfXmlNode" /> </XmlNode> </XmlNode> </XmlNode> </XmlNode> </XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode xsi:type="ArrayOfXmlNode" /> </XmlNode> </XmlNode> </XmlNode> </XmlNode> </XmlNode> </XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode> <XmlNode xsi:type="ArrayOfXmlNode" /> </XmlNode> </XmlNode> </XmlNode> </XmlNode> </XmlNode> </XmlNode> </XmlNode> </Value> </SettingItem> </ArrayOfSettingItem> So, a weird bogus value for the FlightAppLauncher_IsHoverActivated setting. Notably, the reason why I wanted to open the KER settings in the first place was to check on that option, because it had stopped doing the "hover activated" thing a few days ago when I accidentally clicked the Revert button in KSP's own settings (the screen you get to from the game's main menu). I thought maybe the "hover activated" option value was somehow stored in KSP's settings data instead of KER's, and that my revert had changed it back to its default. Instead, it appears that reverting the KSP settings may have somehow corrupted this KER setting. Edit: Actually, it might not be the KSP settings revert that did it. When 1.8 came out, Steam updated my installation, and I launched it just to see how much would work (since most previous game updates haven't broken lots of stuff). It turned out that I couldn't even click on stuff at the game's main menu, so I quit with Alt-F4 and told Steam to revert back to 1.7.3. I didn't load my save or enter the VAB or even the space center in 1.8, but if KER does any writing to its settings files as part of just booting the game, that could be what did it.
  10. I notice that the 1.8 update of KER includes a subdirectory called "temp", containing some settings XML files. Is that intentional?
  11. I've had that happen several times in 1.7.3 as well, so I don't think 1.8 is to blame. I haven't figured out which mod is removing those bindings, though. (EER is a plausible culprit, but it could also be something else.)
  12. Agreed, but that's less "bugfix patch" and more "refactoring the mod", so I stuck to the way it's done currently. BTW, Zs_Science.cfg has a separate section for each experiment, updating the EXPERIMENT_DEFINITION (for baseValue and scienceCap) as well as the stock part which runs that experiment (for xmitDataScalar). From a refactoring standpoint, I'd lean toward updating each of those sections to replace the single-part xmitDataScalar patch with one that patches all parts matching the specific experimentID. (That way there's a clear, visible association between each experimentID and the xmitDataScalar it should have, since they're not all 1.0).
  13. FWIW, I checked all the DDS files in my install — which includes ReStock and all Nertea's other mods, DMagic, Universal Storage, MKS, and various smaller part mods — and the only DXT3 textures I have are in WildBlueIndustries KerbalActuators, on two sample parts and a gear icon.
  14. Small bug report: PBC changes xmitDataScalar for some of the stock science experiment parts, but not for the equivalent Universal Storage parts. Here's a section that should be added to ZsUS2Patch.cfg: //// ***************** Science @PART[USAccelGravWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree] { @MODULE[USSimpleScience]:HAS[#experimentID[gravityScan]] { // Same as stock sensorGravimeter @xmitDataScalar = 1 } @MODULE[USSimpleScience]:HAS[#experimentID[seismicScan]] { // Same as stock sensorAccelerometer @xmitDataScalar = 1 } } @PART[USFluidSpectroWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree] { @MODULE[ModuleScienceExperiment] { // Same as stock sensorAtmosphere @xmitDataScalar = 1 } } @PART[USGooBayWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree] { @MODULE[USAdvancedScience] { // Same as stock GooExperiment @xmitDataScalar = 0.3 } } @PART[USMatBayWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree] { @MODULE[USAdvancedScience] { // Same as stock science_module @xmitDataScalar = 0.3 } } @PART[USThermoBaroWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree] { @MODULE[USSimpleScience]:HAS[#experimentID[temperatureScan]] { // Same as stock sensorThermometer @xmitDataScalar = 1 } @MODULE[USSimpleScience]:HAS[#experimentID[barometerScan]] { // Same as stock sensorBarometer @xmitDataScalar = 1 } }
  15. This is sort of a long shot, but would it be feasible for a future update to have the normal and expanded fairings as switchable variants on a single part, instead of separate parts? (Using the stock switcher ideally, or B9PartSwitch if the stock switcher isn't capable enough.) The fairing has an attachment node on the underside of the payload attachment ring, which is a nice place to put a probe core so that the launch vehicle's upper stage can be controlled (e.g. to deorbit it) after detaching the payload. There's also room under the payload ring for things like batteries and small monopropellant tanks. Because of that, I'd like to save my upper stages as subassemblies that include a KW fairing and some things under its payload ring. But since the normal and expanded fairings are separate parts, I'd need to have two versions of each upper-stage subassembly, identical except for a different fairing as the root part. Having a single fairing part with a normal/expanded variant switcher would alleviate that. (Without this, I tend to design upper stages that omit the fairing, and put the probe core and batteries and stuff in a cylindrical payload bay instead, which wastes that useful space under the fairing's payload ring.)