toadicus

If it makes things any simpler for anyone, here's a download link for the patch. No changes from the pasted version above, it's just already named correctly and doesn't make anyone use notepad. http://ksp.hawkbats.com/dev/MMKWFix.cfg Right-click and save as, click then right-click and save as, click then use some old-timey menu or something to save as, or however you like to download things. EDIT: Look at me, sitting on a post for an hour and a half and missing that ejwith9953 has beat me to the punch! Don't I feel silly.

Mostly I'm just thinking about how super-wrong a line measurement on a cylindrical projection would be if you were anywhere not-near the equator. Doesn't matter a whole lot for launches from KSC, but if you're using a mod that gives bases at non-equatorial latitudes, a line on a cylindrical projection map would mean something very different.

I can't be 100% certain, because I haven't tried every part... but I think this MM patch will fix the scaling issues while K & W deal with real life. @PART[*]:HAS[#author[KW*Rocketry]]:FOR[KWRocketry] { @MODEL:HAS[#scale[0.8*0.8*0.8]] { @scale = 1, 1, 1 } @MODEL:HAS[#scale[0.9*0.9*0.9]] { @scale = 1.125, 1.125, 1.125 } @MODEL:HAS[#scale[1.0666*1.0666*1.0666]] { @scale = 1.33325, 1.33325, 1.33325 } @MODEL:HAS[#scale[1.12*1.12*1.12]] { @scale = 1.4, 1.4, 1.4 } @MODEL:HAS[#scale[1.2*1.2*1.2]] { @scale = 1.5, 1.5, 1.5 } @MODEL:HAS[#scale[1.6*1.6*1.6]] { @scale = 2, 2, 2 } @MODEL:HAS[#scale[2.4*2.4*2.4]] { @scale = 3, 3, 3 } @MODEL:HAS[~scale] { scale = 1.25, 1.25, 1.25 } } HTH!

Just to clarify, "downrange distance" is the distance from point A to point B along an idealized sphere (ignoring topography, etc.), where point A is the reference location (e.g. the space center) and point B is the surface point radially beneath the subject (e.g. the spacecraft), right? If so, I can give you that. I could put it on the HUD in situations where it makes sense, even, if that's something you're interested in.

No worries. It's literally impossible for you to offend me; my only encouragement to you is that the more informative your posts are, the more helpful I can be. I totally get the frustration of trying to get mods working in a new install; I mean, how am I supposed to start a career without TACLS?

Fixed! Apparently my magical deployment script is slightly less magical than I thought. Thanks for letting me know.

AdaptiveDockingNode has been updated to version 1.5.1! This update is nothing but a recompile against the KSP 0.25 assemblies. Cpt. Kipard, I know I owe you an answer. Trying to finish my follow-up first. Changelog v 1.5.1 [2014-10-07] * Updated for KSP 0.25.

TweakableEverything has been updated to version 1.4.1! This update brings KSP 0.25 compatibility and a fix for LV-N fairings. CHANGELOG: v.1.4.1 [2014-10-07] * Updated for KSP 0.25.0. * TweakableEngineFairings: Probably fixed an issue that caused the LV-N fairings not to do as they're told.

AntennaRange has been updated to version 1.4.2! This update brings 0.25.0 compatibility and miscellaneous fixes. CHANGELOG: v.1.4.2 [2014-10-07] * Updated for KSP 0.25.0. * Fixed an issue that caused the in-flight AppLauncher button to duplicate when reverting flights.

VOID has been updated to version 0.14.2! This version brings KSP 0.25 and miscellaneous fixes. CHANGELOG: v.0.14.2 [2014-10-07] * KSP 0.25.0 Compatibility * VOID_DataLogger: Added latitude and longitude. General cleanup. * VOID_CareerStatus: Quick fix for KSP 0.25.0 compatibility. * VOID_Core: Rebuilt the module-loading system to help protect against broken modules. * VOID_EditorCore: Hopefully actually stopping the editor button from ever duplicating itself even sometimes. * VesselSimulator: Updated to latest KER code.

Yup, that's almost certainly part of the API change. I've tweaked a couple of things and internally it's working well. 0.25 update coming Soonâ„¢.

Done! I will happily accept pull requests to help keep up to date. I don't think the live KerbalStuff site is using your update yet, so I can't release a change that supports it yet, but thanks for the interest!

I would love to get some new screenshots together, and it's on my "to do" list for uploading to KerbalStuff, as well. But, I have the aesthetic sense of something that's really bad at making things look good. I've got a few requests out to friends, but I'll make it official here: If you have an awesome-looking screenshot that showcases VOID (or any of my mods), please get it up on the webz and shoot me a PM with the link (or share it here, if that's your thing). If these are all things you don't know how to do, and you wish you could just e-mail it to me, send me a PM or post here and I'll see how I can help you. Thanks!

I will absolutely be updating everything for 0.25. I don't get the new versions any sooner than you all, so I don't know what's going to break until it's broken. There was an API change that breaks compatibility with one of the modules; from my desk at work that's all I can say for sure. I'm hoping to have working updates out tonight sometime (tz: America/Los_Angeles).

So, what I meant in option 1 is to arrange the transforms in such a way that getting them to be close enough to trigger docking is physically impossible with nongendered ports. It might take some tricky geometry, but since the default acquire distance is 1 meter, if you positioned the transforms such that a nongendered or incorrectly gendered port couldn't physically get closer than 1.5 meters from the transform, undesired ports would never be able to dock with it. Again, I don't know if that's really a thing that will work with the geometry you have in mind, or if it's possible to build parts that way, etc, but I feel like it should be. If the male geometry is long and narrow, you can put the transform 1.5 meters (or whatever) behind the tip. If the female geometry is correspondingly deep and narrow, you can again put the transform 1.5 meters behind the opening. Any nongendered port (which it blunt and has its transform right on the surface) will not be able to get closer than 1.5 meters, so it will never be able to dock. Then we could use a node type like "size2_gendered", which would work just fine in the existing logic but would make sure that no amount of shennanigans with non-gendered ports could make a dock happen. We could then also play with all these numbers so you could have differently-sized ports, etc. I'll touch base with sirkut about what he thinks in terms of the more advanced plugin. In the meantime, I don't know anything about how the parts need to be designed to get all of that motion involved; you might want to talk to ZodiusInfuser if you haven't already.

So, thinking about this... there are a few of ways I can think of to consider approaching it. First, the "do nothing" option. If you can construct the colliders and place the node transform in such a way that the two modules won't acquire until you get the "ATV" extension into the socket, you can make ports that will provide a nominally-gendered behavior without any plugin support. The parts won't move or turn you into alignment, but it'll be easier to maintain and to use. Second, the "gendered plugin" option. If building the parts like that just doesn't work or is way too hard (I have no idea), I can add some simple functionality to ADN to enforce gendered docking when relevant. Finally, the "fully articulated parts" option. If you actually want the parts to push and pull and grip and twist as indicated in that diagram, I'll get in touch with sirkut and see if I can find a way to do an Inferal Robotics-powered plugin that will do all those awesome things before actually docking the vessels. If I recall correctly, IR has some limitations related to pistons and docking, so some parts of the movement may be Very Challenging. But, it'd be awesome.

As far as I know, if you add the QuantumStrut module to a part with a named transform and name that transform in the TransformName field, you should have a working strut originating from that transform. But, I didn't design or build the parts; those are all still BoJaN's, and in fact have never designed or built a part, so I'm not very qualified. If you have an example that you'd like to me to fiddle around with and see what I can make happen, I'm happy to do so. The code base hasn't had any meaningful changes since May 7th, 2014. There have been a few minor updates under the hood since then, but if your version is still working you're not missing out on any awesome new functionality. The only possible exception is K3|Chris and I added KASifyQSC a bit later in the game, so if you use Kerbal Attachment System and don't have the KASifyQSC.cfg patch, you're missing the KAS functionality.

Updated to Beta_3! Implements new 'browse' API methods and improves null checking during Mod construction to avoid exceptional behavior for certain mods.

It's no trouble, I just can't help you without more info. You've taken a step in the right direction! But, like I said, it works just fine for me, so I'm going to need more information on what makes your experience different than my experience. One of the best ways to get me that information is by giving me your debug log after a run of the game that exhibits the problem. You can find your debug log here: Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log. Put it up on pastebin or gist or dropbox or however you like to share big files, and put a link to it here. With a log, I may be able to find the problem directly, and work around it or notify the author of the incompatible mod if the problem is on his/her end. You could also list all of the mods you have, and from there I could try telling you the mods that I don't use, and therefore that you should try removing to see if the problem goes away. Once you find it, I can take a look and find the right solution, as I above.

KerbalStuffWrapper is a suite of .NET-compatible utilities that provides access to the KerbalStuff API. The suite is broken into three parts: KerbalStuffReadOnly.dll - A library implementing access to the documented, read-only KerbalStuff API members. This should be suitable for use in KSP mods for version checking and other purposes. Released under the BSD 2-Clause license. KerbalStuff.dll - A library implementing access to the document, read-write KerbalStuff API members. Depends on and inherits from KerbalStuffReadOnly.dll. This should be suitable for use in external applications performing mod management for KerbalStuff users. Released under the BSD 2-Clause license. KerbalStuffWrapper.exe - A proof-of-concept console application providing command-line access to all documented KerbalStuff API members. Released under the BSD 3-Clause license. Note: this software is currently in BETA. While all of the currently-planned features are implemented, testing has been limited and bugs may occur. I strongly encourage developers and users using or linking this software to report bugs early and often. Thanks! DOWNLOADS KerbalStuff: [zip] SOURCE: [git] Currently hosted only on my private git. If interest in collaboration develops, I will move it to github. CHARITY: Do you like what you see here so much that you can't imagine downloading it without first parting with your hard-earned money? If so, this specially-crafted PayPal donation button will help you to take the currency of your choice and make it my money instead of your money. More seriously though: donations are 100% optional and entirely at your own discretion. If you do choose to donate, I'll appreciate it! TODO: Implement additional API members as SirCmpwn releases them. Maybe abandon the console app and collaborate on SirCmpwn's instead. Maybe make the console app less ugly. LICENSE: Author: toadicus Copyright © 2014, toadicus All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the author nor the names of other contributors may be used to endorse or promote products derived from this software without specific prior written permission. * Neither the name of the author nor the names of other contributors may be used to endorse or promote products derived from this software without specific prior written permission.¹ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software uses the CLAP .NET Command-Line Parser, Copyright © 2011 Adrian Aisemberg, SharpRegion. Used under license. This software uses the MiniJSON .NET JSON Parser, Copyright © 2013 Calvin Rien. Used under license. This software uses the FormUpload multipart/form-data library, http:www.briangrinstead.com/blog/multipart-form-post-in-c. KerbalStuff is copyright © 2014 Drew DeVault. Used under license. ¹3rd clause applies only to KerbalStuffWrapper.exe; see README and full source at http://git.toad.homelinux.net/projects/KerbalStuffWrapper.git for more information.KerbalStuffWrapper

I don't have an easy boolean property like "IsUseful" or something that he can scan for. In general, when I duplicate a parameter (like gimbalRange), I name it exactly the same. If the user hasn't tweaked the parameter, my gimbalRange and Squad's gimbalRange will be the same value. If they have, mine will be different. That said -- and I'm not 100% sure about this -- I think that most craft should work just fine without TweakableEverything, except the ones built with inline and shielded docking ports used in the preattached configuration. Whatever my tweak was doing will no longer be the case, so the craft might not work as intended, but it should load and not break everything forever. That's one of the benefits of my "helper module" approach, as opposed to extending and replacing existing modules. EDIT: The NF radiators may look and act like solar panels that point the wrong way, but they use a completely different module under the hood and handle all of their animating internally without using any of Squad's modules. So, to support them I'd need to write a whole new module myself and then be prepared to support it. In general, explicitly supporting foreign mod products lies down the path of madness; if I support one mod explicitly then I'll be asked to do another, and another, and there's just too many for me to try to handle them all. Furthermore, the awesome thing about the mod community is that you can take requests straight to the developers themselves instead of relying on hack-around bandaids like TweakableEverything to get the functionality you want. I strongly encourage you to ask Nertea to add an open/close tweakable for his radiators -- that would be a much more graceful solution to your request. On the other hand, I'd like to see it happen, too, so maybe when I'm a bit less busy I'll shoot him a pull request. I took a closer look at the NFE radiators and it looks like they do actually extend the Squad solar panel so at the barest level of theory I feel like my tweaks should apply to it. But, it's been a long time since I wrote the module and I'm not really a C# expert, so I'll need to do some inspection. I do still think that implementing the tweakables in NFE is the right way forward, but now you've got me curious. EDIT2: Oh! I know why. The MM patch just isn't applying because it's based on name, not type. If you duplicate the TweakableSolarPanels ModuleManager patch to and make it something like this: @PART[*]:HAS[@MODULE[FissionRadiator]]:FOR[TweakableEverything] { MODULE { name = ModuleTweakableSolarPanel } } My tweaks should apply, and I'd guess they'll work. Do note, nertea already implements the sun tracking tweak, so you'll have two of those.

All of the PartModules that TweakableEverything adds are added by ModuleManager patches, except the EVA tweaks, which are added dynamically. The full list is: ModuleTweakableRCS ModuleTweakableEVA ModuleTweakableDockingNode ModuleTweakableGimbal ModuleTweakableResourceIntake ModuleTweakableDecouple ModuleTweakableJettison ModuleStagingToggle ModuleTweakableAnimateGeneric ModuleTweakableLadder ModuleTweakableCrossFeed ModuleTweakableReactionWheel ModuleTweakableSolarPanel

The standard range for all of my tweakables is [0X..2X], where X is the default value assigned in the part.cfg file. For some of the modules (Decouplers, DockingNode, Gimbals, ReactionWheels), these multipliers can be constrained within those bounds by changing the "x" (lower) and "y" (upper) values in the PluginData config files that the mods will generate after their first run. In general, I agree with OOZ that fairness is not a huge issue here. I've tried to avoid allowing things to be taken well outside the order of magnitude of what Squad has in mind, and in general I think doubling the values indicated maintains Squad's general vision, allows for more flexibility (e.g. none of the stock radial decouplers are really strong enough to push off a big radial booster, so doubling the decoupler force might help streamline a design). As long as people in your subcommunity are all on the same page ("I built this with TweakableEverything"), comparison remains valid. The NF radiators may look and act like solar panels that point the wrong way, but they use a completely different module under the hood and handle all of their animating internally without using any of Squad's modules. So, to support them I'd need to write a whole new module myself and then be prepared to support it. In general, explicitly supporting foreign mod products lies down the path of madness; if I support one mod explicitly then I'll be asked to do another, and another, and there's just too many for me to try to handle them all. Furthermore, the awesome thing about the mod community is that you can take requests straight to the developers themselves instead of relying on hack-around bandaids like TweakableEverything to get the functionality you want. I strongly encourage you to ask Nertea to add an open/close tweakable for his radiators -- that would be a much more graceful solution to your request. On the other hand, I'd like to see it happen, too, so maybe when I'm a bit less busy I'll shoot him a pull request. I am unaware of any compatibility issues with the base game or any other mods, except HoneyFox's TweakableGimbal, which is much more advanced than mine and should be used in place of mine (not in addition to mine), for users seeking that added functionality. My shielded docking port works just fine, so if you're having an issue you'd need to clarify your problem and get me some troubleshooting information like a debug log or another mod that triggers the issue or something like that. Now, if you're talking about the in-line docking port, it does work weird, because of a Squad limitation. Squad only allows two attach nodes to be used for child->parent attachment in the editor (i.e. when first placing the docking port in the game, only two attach nodes will be valid). This preference is determined by the order in which they appear in the part file (first and last, as I recall), so there's nothing I can do to work around it. This means that you can't use an inline port as a "T" where the vertical leg of the T is the existing stack you're building in the editor, which is a bummer. Sorry.

Give me until after October 4th and I'm game. I've got a Big Professional Licensure exam on the 4th and what with family, work, and studying I've got no time right now. Things will let up after the 4th and at that point I'll absolutely be up for it.

inigma: I have used all of my mods with many of the mods on your list with no ill effect. I have personal experience that TeakableEverything is compatible with: Kerbal Engineer Redux HyperEdit Toolbar by blizzy78 Kerbal Alarm Clock TAC Fuel Balancer Mk2 Cockpit Internals Chatterer Kerbal Attachment System Karbonite I have no reason to believe that any of the other mods on your list would cause compatibility issues. I don't have availability to promise testing time at this point, but I will accept consolidated bug reports from you for your pack (you do the basic troubleshooting steps, send complete reports to me via PM or in the TE thread).