Fwiffo

Sorry if this is a stupid question that's been addressed before. I see several of these in my logs: [ERR 06:32:38.344] Cannot find an InternalModule of typename 'InternalVesselView' [ERR 06:32:38.344] Cannot find an InternalModule of typename 'EngineIgnitorRPM' I notice they've been around for a while. Is there any way to make them go away? It's not a big deal, I'm just trying to reduce the amount of white noise I need to sift through when doing troubleshooting. Thanks!

Love this mod. Driving rovers around without it sucks. I noticed in Version 2.3 a bunch of the wheels have skidSoundVolume = 0 in ModuleManager_WheelSounds.cfg. I'm not sure if it's changed from previous versions, but it's different from what I had in my own GameData directory. Any reason the skid sounds for those wheels was disabled? roverWheel1 has skidSoundVolume = 0.3 but all of roverWheel2, roverWheel3 and wheelMed have it 0.

How do you use this in a CFG? I figured out the field name is uiToggle but couldn't figure out the precise values it's expecting to parse. EDIT: Nevermind. I was subtly misled by the values listed above and in the changelog, but when I used Editor (capital E) it worked as expected.

The wiki entry for ModuleCrewIndicator says: toggleName: Optional. A string that references a toggle module (e.g.ModuleCrewIndicatorToggle) to control whether the crew indicator is on or off. If omitted, the indicator is always on. Are you sure having a ModuleCrewIndicatorToggle is optional? I had a craft without one, and had trouble getting it to show the crew status. Then I tried a simpler test by commenting out the following lines on your mk1can.cfg patch: // MODULE { // name = ModuleCrewIndicatorToggle // toggleName = indicatorToggle // } MODULE { name = ModuleCrewIndicator emissiveName = indicator // toggleName = indicatorToggle } The game slowed down to a crawl in the Editor and I get a ton of these messages in the log (with verbose = 1): Maybe I did something wrong... Also any reason ModuleCrewIndicatorToggle has a toggleName property instead of referencing it by its controllerName? (Is it because controllerName's are optional and act as color sources, but toggleName should not?) Finally, you might consider making the ModuleCrewIndicatorToggle button only visible in the Editor (or giving us an attribute to do so), not Flight UI.

Let me know once you are distributing the extra sounds with out-of-the-box Chatterer, so I can remove my "expansion pack" from CKAN. It'll make life easier for users, as presently there's a manual step after installing, and I'm guessing at least half of them will overlook it even though this message is smack dab in the description when you click the mod in CKAN: Adds an additional chatterset to Chatterer. Created by Fwiffo, by manually editing / reversing sounds from the NASA chatterer pack put together by KingNeberkenezer (BeeMeister on Twitch). IMPORTANT: After installing this pack, put a MANNED ship on the launch pad, open Chatterer settings, ensure Advanced Settings are enabled, then go to the Chatter tab, and load the set by typing the folder name 'expansion' (no quotes) and clicking Load. Which reminds me, please ensure you include a credit to KingNeberkenezer (BeeMeister on Twitch) someplace after you add those sounds. I took a quick look today and it triggered some memory neurons. Originally I had a reference to System.Drawing.dll, but had to remove it as the version of Mono shipped with KSP was missing that DLL/namespace. The only thing I needed it for was the PointF structure, which I instead implemented in PointF.cs. So in Solution Explorer, remove any reference you may have to System.Drawing.dll and it should work. There's further explanation at the top of the original PointF.cs file, which includes the comment: Note if you try to simply add a reference in the project to .NET's typical System.Drawing assembly, then KSP will fail to load this mod, with an error that MononicSpline cannot be loaded. Does that sound like your issue? :-) If only I had some more time I would just love to help you with that too ;-)

Awe, gee, well, shucks. How cool would that be on a thermometer! If you sized these just right you could make the mercury (or hot/cold squares) actually look like it's rising with temperature.

I wanted to make the on/off transition of the default blinking lights on my science equipment a little less harsh, so I added some slight easing. Also made them blue (for science!). He's a quick, ad-hoc tutorial on compositing color source functions if anyone's interested. Start out with a simple pulsate() color source. I picked a period of 400ms, equal to the cycle of the default blink() the mod applies to stock science parts: pulsate($HighScience, 400, 0) Feed that into a square wave blink() pattern, which will be used to gate the signal. For the moment, it gives us a periodically flashing light which comes on instantly then appears to "drain" more slowly (great for a "red-alert" type effect): blink(pulsate($HighScience, 400, 0), 200, $Off, 200) Shift the blink pattern to uncover the pulsate portions we're actually interested in. Here we center the orange "on" portions at the blue peaks. Note a positive phase moves the signal left, and negative moves it right. We want to shift by 100ms, which works out to 0.25 of the total cycle. Note we also push up the minimums of the pulsate() waveform to 0.5, which starts the flashes at a higher brightness and reduces the ramping effect (I want the dimming to be subtle): blink(pulsate($HighScience, 400, 0.5), 200, $Off, 200, 0.25) // p = (1/2) * on / (on + off) Finally, we add some emphasis by widening the "on" segments (by 25%, or an eighth on each side) and shifting the blink slightly to the right (reducing the phase shift by 25ms), so the lights illuminate more quickly than they go out. This was entirely to tweak things to personal taste: blink(pulsate($HighScience, 400, 0.5), 250, $Off, 150, 0.25) // p = (2/5) * on / (on + off) Here's what it looks like in the end. The top LED is mine, the lower one is the default (from version 1.2 of the mod). In my own game I also slowed mine down slightly more than seen here, which made the effect more prominent. It's completely a matter of taste - I just found the softer blink more appealing when there are lots of these things going off at once all over your ship :-). Some friendly suggestions to @Snark after going through this exercise: Next wiki update, add some documentation to pulsate() clarifying which end is which (i.e. in 3-parameter form it starts at 1, and ends at the value you give it). Consider adding a phase parameter to pulsate() to give modders a bit more flexibility. Clarify docs as to which direction positive and negative numbers shift the phase. EDIT: Open the spoiler to see a couple slower variants suitable for the mediumValueColor source (to indicate availability of lesser science).

That's a good point. So, you could narrow the focus a little from what I did and disable the deprived warning only when SAS is off and the user is not trying to turn the ship. I did a quick test and hitting a rotation key (causing a request for electricity to be made) also clears the aberrant flashing. Both equally (screenshots and gameplay). I follow what you mean about the "wiring diagram" approach and it's basically what I did within the part. But after implementing it (and even using the toggle() feature to somewhat reduce the amount of cfg clutter) I'm of the opinion this is a case where it might be better to introduce a feature specifically for this, rather than trying to accomplish it through the existing "nesting" methodology of the mod. i.e. I'm thinking bake master "On/Off switch" functionality into a new part [module] intended to occur only once on your ship. All the emissive controllers would be smart enough to check if that part [module] exists, and if so, turn off their output when the switch is turned off. From a programming perspective, the only thing this new module would really do is provide a ship-wide boolean state variable. It would be wired up to an existing toggle to provide the actual button (or maybe come in the form of a ModuleMasterSwitchController which would be a cut-down ModuleToggleLED or different flavour of ModuleBooleanIndicator). I put [module] in brackets because I'm not sure if there's an efficient way to check for a module across the entire ship, and/or whether that problem becomes simpler if the mod knows it would always occur on only a specific type of part (and reading your post a little further, I see you get into that question too). I guess there's no way to store / retrieve state information at the "ship" level? (I know some mods stuff things into savegame files, for better or worse...) An advantage of the approach is the user doesn't have to do a thing to their cfg's to make this work. All they have to do is stick the new "Master Switch" part somewhere onto their ship and it just works. I'd be curious if anyone else would appreciate having a master switch to toggle all the IndicatorLights functionality off at once. It would feel akin to using the main breaker switch on your fusebox. Could there be a way for a toggle button somewhere on your ship to feed that "global mod variable"? That would avoid breaking immersion from the need to drop into the debug console. Yes, a side-effect would be the button would be game-wide rather than just for the active ship - personally I'm ok with that compromise. Yes. In my implementation I copped out on the "logical-combining" part - it's just a SPDT switch. It was intended for simple one-liner cases where you want to avoid creating whole new ModuleBooleanIndicator. I figured for complex cases the user can just revert to that. I did do one small thing which turned out to be helpful when using it; that was to make the offSource optional (so it knows to just use $Off if not specified). Incidentally (and purely for academic interest) the resulting toggle() could have been combined internally with a theoretical generic new "timer()" parameter (essentially a squarewave generator) to implement existing patterns like blink(). e.g. blink() === toggle(squarewave(200ms), onSource). Where squarewave() is some class that inherits from a generic timer(). But I digress :-P. Hah, great analogy! Incidentally the only reason I went to the trouble of creating a pull request was because I thought it would be convenient for you. Personally I find GitHub a little less intuitive to use than I feel it ought to be. Anyway I respect your desire not to have other people dabbling in your code. I just wanted to move on with my CFG files, and needed some of the missing functionality to proceed. It looked (and was) very trivial to implement and I figured I was doing you a favor. I was careful to preserve the coding patterns you used (and had hoped to learn something if you took a look at it and said "no, that over there isn't quite right, here's how it should be done"). Sorry if it offended you. I removed the link as requested.

I opened a bug report. @Diazo if you were talking to someone at Squad about it feel free to let them know.

Yes that should be the one I meant. I wonder if that requirement you mentioned for it to be first still exists. I did some weldments and the mod was not placing it first. I haven't noticed any trouble with the science container yet but have not completed field testing missions. Do you recall exactly what the symptoms were?

Updated. Let me know if you have questions. By the way out of curiosity: Are you talking about ModuleScienceContainer or something else?

I will update the GitHub issue I have in place for this. I've learned a lot more since I first opened it and I think there's a better approach that will hopefully fit in more cleanly with the mod's approach to things.

I fix the animations in post-weld. It's actually not hard, your mod could handle this fairly trivially (at least in some cases) and users would have a much better time with such components. Thanks for clarifying. I'm not intimately familiar with how the mod works internally and am still learning. I completely understand your reluctance to maintaining a lot of specialized code. I need to play a little more with the existing capabilities provided, although I do wish they were a little less constrained. I've found a lot of cases where the welder gets things wrong and manual fix-up is required post-weld. Granted I'm doing more advanced welds than most people venture into. I'm just reporting issues as found, you can take or leave them as you see fit. I recognize you volunteer your time (which I'm enormously grateful for) I certainly won't feel insulted if you don't want to work them. :-)

Search the text contents .craft file you're trying to import. My guess is that "ValueError: could not convert string to float '.0.0'" (can't tell if those are commas or periods) means there is a field somewhere which the importer is expecting to be numeric but has an extra decimal or whatever. Can KSP open the craft OK?

Thanks for confirming. I fixed this in my personal version and sent a copy of the source code to @Snark in a pull request. Here's a copy of my bootleged DLL if you want to test (link removed at the very understandable and kindly-made request of Snark), and here's its unofficial changelog. It did entail removing the flashing "starvation" indicator when SAS is disabled. But I argue the warning should be disabled in any case when SAS is disabled. My reasoning is, if SAS is disabled, then presumably the reaction wheels are dormant (correct me if I'm wrong) so they aren't really "staved". (And in most cases where this is likely to occur you have other indicators that will be going off anyway, e.g. batteries). When SAS is enabled the starvation warning works just like it does today. Snark might feel differently and rework / exclude that fix.

Is there a simple way to wire all my emissives or controllers (which have different color sources) to be toggled by a single master ModuleToggleLED button? I want an "off" switch to let me turn off all the IndicatorLights under some circumstances. Also would like a field that can disable the ModuleCustomBlink GUI button during Flight (one less button on my list). Edit: My approach to this is going to be defining several ModuleBooleanIndicators (one for each emissive) and gating them all by the master toggle. I suggest you add a "ternary" ColorSource function that takes a toggle and two color sources as its inputs; it would make it possible to do this sort of thing with a lot less verbosity and less modules. Edit: I went ahead and implemented a toggle() parameterized ColorSource, which I think might be convenient in some cases. Tried to add it to my open PR or make a new one, but GitHub is foobared at the moment ("Oops something went wrong" responses). Might try again later, in the meantime the changes are in ColorSource.cs in my Fwiffo2 branch. In retrospect, it doesn't quite completely solve what I wanted to achieve. I think what I'm really after is a master "lightswitch" part that turns off all the indicator lights on your whole ship (not just in the one part). I love Indicator Lights, but it would be handy for those times you want to take a screenshot without the "Christmas Tree" effect (did I mention I appreciate the restraint you've exercised in that regard?).

Sorry I might have just assumed it didn't. Will have to test it out. I know if you used KSPUtil.dll it won't ;-).

Minor bug, multiple ModuleDataTransmitter's in a weldment are not consolidated correctly. e.g. The packetInterval fields are added, which makes the resultant antenna worse (longer delay between sending packets of data). It also adds packetResourceCost, which shouldn't be done (AFAIK transmission cost per data is normalized at 12 throughout the game). I believe a more reasonable formula should be: packetInterval = (minimum interval) packetSize = sum(each antenna's [packetSize / packetInterval] * minimumInterval) antennaPower = sum(each antenna's antennaPower) I'm not as sure about optimumRange, packetFloor and packetCeiling. Alternatively you could just pick the best antenna (e.g. one with highest antennaPower) and go with that, discarding the others.

The ModuleDataTransmitter from the built-in INTERNAL antennas of at least some command modules and probe cores have optimumRange, packetFloor and packetCeiling fields. Are they still used / relevant (do they affect the data rate based on distance from KSC / relay)? I noticed the DIRECT antennas (e.g. DTS-M1) don't have these fields. I'm trying to consolidate ModuleDataTransmitter modules from 4 parts (in a manner representing their combined effect): 2x Mk1 Lander Can Small Probe Core DTS-M1. Is this correct: // Left / right Probe DTS-M1: Combined: // lander cans: Small: // packetInterval 1.0 1.0 0.35 0.35 // packetSize 2 2 2 3.4 // packetResourceCost 12 12 12 12 // antennaPower 5000 5000 2000000000 2000010000 // optimumRange 2500 2500 removed // packetFloor 0.1 0.1 removed // packetCeiling 5 5 removed

Do you have a mistyped value ".0.0" or ",0.0" in the file you're trying to import?

That's a great summary. In my first career game, I tended to "hoard" results, i.e. save them for a mobile processing lab rather than transmitting them. I was under the impression that gets you data faster in the MPL's than if you were to put a bunch of already-transmitted results in them. Is that correct? At the end of the day does it make a difference in total science you'll get from the MPL?

Picking my workaround as "best answer", but I wish I could mark all of the helpful posts here as great answers :-).

Ok, learned something new today: Mods can inject tips into the loading screen. How cool. My name likely came from IndicatorLights. Thanks @Snark ;-)

Possible bug: Reaction wheels blink when your craft is first launched from the VAB, even when they aren't deprived. Toggling SAS on/off fixes it. Edit: More details in spoiler Suggestion: ModuleScienceAvailabilityIndicator needs an "unavailableColor" and/or "lowValueColor" field so you can chain other controllers onto it. e.g. I want to make my lander cans blink when crewReport science is available, and the rest of the time show the profession color of the kerbal inside. Don't think I can do that with the existing building blocks. Edit: I didn't want to wait, so went ahead and implemented those, along with the ability requested further up to constrain ModuleScienceAvailabilityIndicator to a particular experimentID. I'm going to send you a pull request with my fixes / enhancements. I'm still pretty new to GitHub so go easy on me.

Good catch; thanks! Renamed experimentId to experimentID across the board and it's working now.