Fwiffo

I made a program once that would download really bright iridium flare predictions into my calendar and sync them to my phone, so it would buzz me a minute or two before one. I'm sure by now there must be some iOS/Android apps out there to do something like that.

Feature suggestion (once you're done with getting the wiki up to date): It would be nice if one could define more complex, global, constant color sources in the settings file. e.g. $HighScience = blink(pulsate(blahblahblah)). Even better if we could define our own, new names. That would allow you to get rid of all the duplicated parameters across the various parts files, give users a single place to make updates to shared patterns, and (if implemented cleverly) reduce the number of object instances required (and garbage collection impact) when running your mod (many parts could all share a reference to a single squarewave/pulsate/etc. generator). I know it's easier said than done, but figured I'd suggest it.

Update seems to have resolved my issue; thanks.

Thanks! Will try that out.

Is there any way in a CFG I can include a RetractableLadder module in the default "Gear" action group? (So my ladders extend when my landing gear do, without having to set that up for each craft - similar to the way lights have a defaultActionGroup property)

Any idea what's causing this log noise when I launch a craft?

If this has already been reported feel free to ignore. I am getting several "ArgumentOutOfRangeException: Cannot be negative. Parameter name: length" exceptions when KSP 1.2.1 tries to instantiate this mod: [LOG 06:39:41.325] [AddonLoader]: Instantiating addon 'QStockToolbar' from assembly 'QuickGoTo' [EXC 06:39:41.327] ArgumentOutOfRangeException: Cannot be negative. Parameter name: length System.String.Substring (Int32 startIndex, Int32 length) QuickGoTo.QuickGoTo.get_relativePath () QuickGoTo.QStockToolbar..cctor () Rethrow as TypeInitializationException: An exception was thrown by the type initializer for QuickGoTo.QStockToolbar UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) AddonLoader:OnLevelLoaded(Int32) AddonLoader:OnSceneLoaded(Scene, LoadSceneMode) UnityEngine.SceneManagement.SceneManager:Internal_SceneLoaded(Scene, LoadSceneMode) Here's the full log if you need it. Here is my Config.txt: I also tried BlizzyToolbar = false, with same results. The exceptions are logged and the button does not come up in any toolbar (blizzy or stock) under either scenario (BlizzyToolbar true/false). It does work if I remove the blizzy DLL from the Gamedata. My installed blizzy toolbar is v 1.7.13 (installed from CKAN) and here is its toolbar-settings.dat file if you need it (although I also tried without any toolbar-settings.dat and it didn't make a difference): Honestly the only thing I use blizzy for these days is this mod, to get a couple of single-click-away QuickGoto buttons (e.g. to quickly revert to VAB after launch, useful when trying out many interations of a ship on the pad) ps. I also tried removing blizzy by renaming "Toolbar.dll" to "Toolbar.dll.removed" and still get the errors! Judging from log entries I think some other mods might also be having issues with blizzy.

Sorry if I asked this before. Is there an easy way to MOVE a part from a stock subcategory to my new custom one? I'm using this CFG with this mod, but it's only "copying" parts to the new subcategory. Wondering if there's easy way to suppress parts manufactured by "Fwiffo Industries" from showing up under the stock categories. // Gets merged with content in StockCategories.cfg @CATEGORY[Filter?by?Function] { @SUBCATEGORIES { list = 120,Fwiffo } } // Would be in SubCategories_Fwiffo.cfg SUBCATEGORY { name = Fwiffo icon = SPD FILTER { CHECK { type = manufacturer value = Fwiffo Industries } } }

Hey @DuoDex I noticed CKAN still says this isn't compatible with 1.2. I asked them to address that; hope that's ok.

Could someone tell me what drycom_MJPropellant in the settings file means / meant?

Could you elaborate on that please? e.g. Do I need to switch the order of my parameters to that function in my parts to maintain old behavior? If I used the 3-parameter format should I change it to pulsate(blah, blah, 1, old_third_parameter)? Thanks!

I noticed this mod was updated a while ago to work with KSP 1.2 (yay!) and that 1.2.1 fixes the flickering issue (yay again!). Does anyone know if the configurations included with this mod (particularly, the "Filter Extensions - Default Configuration" listed on CKAN) have been updated to reflect the new stock categories and stock icons in KSP 1.2? (e.g. coupling, payload, ground, thermal, communication, etc). I only use this mod to add a "Fwiffo" category to keep my custom parts separate. Aside from that, I sort of like the new way KSP 1.2 organizes the parts and I want to have as minimal an impact as possible. EDIT: Nevermind, answered my own question. For anyone else wondering:

@MOARdV Love your builds; thank you! But hate your zip naming. After I placed the newest version on my HDD beside the old one, I almost got tricked into thinking build 29319 was later than 13911 (which one would think just looking at the filenames). Maybe you could consider including a marker like "beta4" in any future beta releases? :-)

I've never tried PAD but I don't use the EER Fine Adjust. I commented in a thread a while back the reasons I don't like it in its current form :-). It would be nice if EER converted the rotation quaternions to euler angles or whatever and showed those in the "Position Debug" window as well.

https://www.reddit.com/r/KerbalSpaceProgram/comments/2phybb/kurvy_kurvy/

Speaking of the 1.2.1 drop. Anyone know if they did anything about input locks?

If it doesn't, I'm pretty sure KSP's stock "Reload database" button would (at least I assume the one in the stock menus is not put there by MM). While we're talking debugging tools, AssemblyReloader by @xEvilReeperx is also pretty sweet (even though it doesn't get a lot of attention). It doesn't reload assets, but does let you swap in a new version of your mod's DLL without restarting the game (I think it can even detect when the DLL is overwritten with a new one and load it automatically). Technical details are in a PDF he used to distribute with the mod. A long time ago I was doing a bunch of mod debugging, and between it and the mono debugger for VS2015, I had a pretty tight "Edit-Compile-Continue" cycle going.

Did you change your manual from PDF to ODT? I'm having trouble opening the latter.

Personally I like having a hotkey which will always get me to no-snap mode, without having to bother to look at what mode I'm in beforehand. Not saying your idea doesn't have merit (it does), just pointing out some of us who are used to the way it works now may not want to lose that. :-) LGG if you're considering this, maybe find a way to keep both around? If you don't want to clutter up additional hotkeys you could do something like Alt+C to toggle between no-snap and last-snap setting, and Alt+C+C (Alt not released in between) to go to no-snap... (may sound silly but you get what I mean)

Interesting, though starting to get over my head :-). I think the welding process does seem to know about them at some level, since they make their way into the weldment? In any case I was able to reproduce without any MM patching (but still using MODEL syntax, I'm not sure if that still counts as "virtualized"): I'm starting to wonder if this happens for any MODEL mesh which is not at the origin in the original cfg and is rotated in the preweld. Also wonder if this is the same reason weldments of weldments come out fuzzled.

Only if they are all facing the same direction, and even then, I have doubts. Hi @cy-one, I *think* (if I remember correctly) including a fixed solar panel in a weldment causes the entire part to become sensitive to light (i.e. as long a sunray hits any part of the weldment, it will charge). You could try using the welder to make a part that includes all those solar panel meshes, then manually edit the part modules to specify values that would be equivalent to all those panels. (Obviously this is unsupported and kind of venturing out on a limb. I do a lot of that with this mod :-) ).

LOL sorry I should not have said "simple". The trig itself is straightforward, but everything you need to actually get to the point of being able to apply the trig is a bit mind-bender :-). At least for simple folk like me. Since the sensors themselves come out correct, I'm kind of hoping you already have the code to fix this but something in the mod just overlooks applying it to these meshes. The "plates" (little light emissives) are meshes that are added into the stock sensor parts (by an MM patch). They just happen to be the parts that were triggering it for me; I'm fairly confident the issue is not specific to anything about that mod. If it's easier to set up, you can just install IndicatorLights (also available on CKAN) and it will patch in the meshes for you. Let me know if you need me to provide anything else to make this easier to repro / troubleshoot.

Any idea what would cause the offsets I'm seeing to these meshes? Preweld on the left, postweld on the right. The displaced items are meshes that were originally patched into the science parts via MM. The postweld meshes are the correct size and in the correct orientation, just not in the correct location. It's almost as if they're being adjusted in X and Z without taking into account the rotation they had in the original part. EDIT: I've done some drawings on a piece of paper to check calculations, and confirmed. The mod has a bug in that it is just blindly adding the x, y, z offsets of the mesh without taking into account the orientation of the part it came from. Once you get your head around the coordinate system, it's correctable with some simple trigonometry. More info in the spoiler:

Yes, it's basically guaranteed to happen whenever you attach a part radially then move it. The attach_node's are not aligned to snap locations. It's useful when you want to align various parts, or align a part to the VAB "origin" (y=15m). It might be more useful if you could change the grid density (i.e. make it finer). If you attach the same parts to a parent, they should align consistently when using snap mode. Another useful shortcut key is "F" (I might have customized it so might be different for you) to change between local / absolute mode. Try and see if that gives you improved consistency. Yes that's SUPER annoying. It's a hopefully-temporary bug that was introduced when the final KSP 1.2 came out. LGG actually had developed a workaround which a bunch of mods including this one were using to prevent that issue, but it broke. It's a problem around input locks for which Squad really needs to push out a better solution. (So the short story is, unless someone comes up with another clever workaround this is something Squad needs to fix on their end). If you know of any mods which successfully avoid responding to keyboard shortcuts while your cursor is in a textbox, let us know!

Hey @Tallinu, try Alt+C. That immediately sets you to no-snap mode. One point I agree with, it would be nice to have the ability to snap only along one axis. That would be helpful when moving radially mounted parts up or down along fuselages. That said, the recent introduction of "master snap" helps and alleviated the need somewhat.