Wyzard

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?

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.)

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.)

@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.

Speaking of settings XML files, here's an oddity. Using KER 1.1.6.0 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.

I notice that the 1.8 update of KER includes a subdirectory called "temp", containing some settings XML files. Is that intentional?

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.)

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).

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.

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 } }

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.)

Well, sort of a UI: in the astronaut center, for kerbals who are on R&R, it shows a timer that says when they'll become available for missions again.

BTW, following up on this: I tried changing the runningEffectName to powerEffectName in the LH2NTR patch (to match what RealPlume would do in the absence of the LH2NTR patch), but made the plume stop working — I'd get a little puff when the engine started, but no sustained effect. I still don't know the actual difference between runningEffectName and powerEffectName, or why RealPlume's patches replace the former with the latter, but nothing appears to be broken with runningEffectName in the LH2NTR patch, so I'll leave it as-is in that regard.

Starting KSP today, the AVC window counts up to "checked 92 of 93 add-ons", then sits there forever, never reaching 93. It worked yesterday and AVC hasn't changed, so presumably the problem is just a server that isn't responding, which isn't AVC's fault. However: The AVC window sits in front of everything and can't be moved, and ends up being right in front of my save in the load menu. The button for the save extends a little past the sides of the AVC window so I'm still able to click it, but it's a little awkward. The add-on list (opened by clicking the checkbox in the top-left corner) has a list of all my mods, but there's no indication of which one is still waiting for the response to its update check. The AVC window goes away when I load my save, so it doesn't actually hinder playing the game. But as a suggestion for future updates, it'd be good to have something in the UI to indicate which mods are waiting for their version checks to finish, and a way to move or close the AVC window before they're all finished. (Edit: I waited and that last mod's version check finished after a few minutes. So yeah, probably just a slow server.)

Even with 100% antenna signal strength, some experiments can only get a fraction of their science value from transmitting. For example: mystery goo on the launchpad in a new unmodded save, with a hefty antenna on the vessel. The science window says recovery +3.0 science, transmit +1.3 science. The transmit button says +40% bonus due to signal, but still only 42% return from transmitting. I think that 42% comes from the xmitDataScalar=0.3 in the part config, times 140% from the antenna boost. What I'm wishing for is a way to get the whole 3.0 science from transmitting, after analyzing in a lab — or in other words, for the blue "transmit" bar to be identical to the green "recover" bar. The ScienceData class in the API has a baseTransmitValue that influences how much science you get from transmitting. I did some experiments awhile back and found that it's possible to get what I want by changing that value on a ScienceData instance — I think just by setting it to 1.0, though it was like a year ago and I don't remember the details. (Based on that, I've thought about writing a mod for this myself, but I think the UI work would take more time than I have available right now.)

OK, good to know. I'll keep my pull request open, then.

Hey, sorry for not responding sooner. I see that you released a RealPlume update whose changelog says it has special handling for KerbalAtomics' stock and ReStock NERV patching. Does that affect the LH2NTR patch for the MissingHistory "Candle" and "Beacon" engines that we discussed here? Is my pull request (to update the patch's effect names) still applicable, or should it be changed to something else?

I've long wished for a mod that would remove the stock lab mechanics entirely, and replace it with simply: labs increase an experiment's "transmit" science value to be the same as the "recover on Kerbin" value. The idea would be that the scientists in the lab do the same hands-on analysis that the scientists back on Kerbin would do, and transmit their findings back home along with the raw experiment data. That would be a lot more straightforward, and would work better with mods like [x]Science that look at what's been transmitted/recovered. I dont't think such a mod exists, though; I've never heard of one.

In my experience, sharing an effect between two engine modules doesn't work — the game only applies the effect to one of them, and the other gets no effect at all. That's the reason why the LH2NTR patch needs to duplicate the effect node in the first place; see this earlier KerbalAtomics change and this forum post by @JadeOfMaar. I tested and confirmed that back in KSP 1.3.1. when I added the initial fix to the LH2NTR patch, and again in 1.7.3 when I updated the fix to be compatible with RealPlume. However, I only only tested with runningEffectName, because that's what the MissingHistory part configs use for the two engines at issue. I see that RealPlume's patch removes the runningEffectName attribute and adds powerEffectName instead. I don't actually know the difference between those attributes, or when to use one vs. the other. Jade's post back in 1.3.1 said the problem applies to both, but I haven't actually tested with the latter. Do you think switching to powerEffectName would allow both engine modes to use the same effect, so the LH2NTR patch wouldn't have to copy the effect node? (Actually, I should probably make the patch use powerEffectName for those engines when RealPlume is present anyway, just to stay consistent with how RealPlume configures the engine modules.)

Yep, the RealPlume update changed the effect names so the LH2NTR patch was once again trying to copy from effect nodes that didn't exist. I've submitted pull request #79 to update the patch with the new names. Ideally the LH2NTR patch should run first and change the engines to multi-mode, and then RealPlume should see that the engine is multi-mode and apply a different version of its plume patch. That'd be the most elegant way for it to work, and it'd also make it possible for the two engine modes to get different plumes (one for LF, one for LH2). Currently, though, the LH2NTR patch runs after RealPlume (it's at :BEFORE[zzLH2NTR] in the patch order), which makes it awkward: RealPlume has already patched the single-mode engine with a different effect name, so LH2NTR has to be aware of that and use the new name when copying the effect for the alternate mode. It might help to have LH2NTR run between RealPlume's early and late phases, instead of after both — e.g. change "zzLH2NTR" to "zLH2NTR", or "zRealPlume" to "zzRealPlume". That way the new effect name would have already been patched into the engine module by RealPlume's early phase, and LH2NTR could just copy that and the PLUME node to set up the engine's alternate mode. But I don't know whether RealPlume can correctly handle multiple PLUME nodes on a part, and changing the patches to run earlier or later could change how they interact with other mods, which might introduce other bugs.

I was referring to the https://www.tancredi.nl/downloads/logs.zip link that seems to be the same everywhere. But it's good that you also posted the ReStock-specific messages here, and relevant portions of other logs in other threads. What I was reacting to was mainly noticing that a majority of the threads on the first page said their last post was by N3N, and they mostly had the same copied/pasted text saying that there are errors because of missing files. Usually when someone has a bunch of mods logging errors about missing files, it's because they installed wrong, so that's the impression it gives to me and probably many others — particularly since I use ReStock and I've never seen the errors you reported. (I don't use most of the other mods you posted about, though, so I haven't looked closely at the problems with those.) If you actually have done a bunch of investigation on all the messages in your logs, that's good, and I don't want to discourage you from doing that. I'm not trying to accuse you of being lazy. It could very well be that a bunch of mods have harmless errors, and it looks like some people have said so in a few other mod threads. But the way you reported them all at once gives the impression that it's an installation problem, even if you claimed otherwise. However, I think this might be part of it. Your "don't denounce me to the moderators" statement might have come across more strongly than you intended, so "arrogant" might have been too strong a word for me to use in response. Sorry about that.

There are about 20 threads on pages 1 and 2 of this forum right now where you've posted the same log and said that various mods are broken because of missing files. Other people in those threads don't seem to be having problems. That by itself should be a sign that maybe there is something wrong with your installation, and your sentence above comes across as a little arrogant because of that. Some mods may have bugs, but if you're going to mass-report problems, you should do some more troubleshooting of the individual mods, preferably in isolation. Don't just post one big log with lots of unrelated errors across lots of mod threads.

CommunityResourcePack is included with several of Nertea's Near Future mods (Propulsion, Electrical, and Aeronautics). I'm guessing you're using those, since you posted in that thread saying B9PartSwitch broke your game.

This thread is about a graphics glitch in KSP 1.3 that was fixed in 1.4. It sounds like your problem is something entirely different, so it's probably more appropriate to post it as a separate support thread.

Yeah, that's what I did for my already-accepted Mun contract too. For the record, if anyone else is in a similar situation: find the CONTRACT block that corresponds to the PbC contract — they have "subtype" names like "ProbeMun" or "ProbeEve" — and delete the PARAM block whose ID is "vpg".