toadicus

AntennaRange has been updated to version 1.2! This version introduces a new optional feature that will interrupt control of unmanned probes when no relay connection exists, and improves the presentation of relay data in the right-click context menus. Once again, both of the new "hard mode" features are still experimental. Please let me know how they're working! CHANGELOG: v.1.2 [2014-05-07] * New and improved right-click GUI presentation for relays. * Improved accuracy of line of sight checks. * Added optional feature to prevent control of unmanned vessels without radio contact.

I used to think I used a lot of mods, until I saw all the mods listed in your logs. Kerbal Construction Time is among those mods you use that I do not.

Version 1.3 is out! Now available exclusively via the new release thread over in the development forum. I gave this release as much testing as I could squeeze in time for yesterday, and docked a bunch of variously-sized ports to each other, on small vessels and large vessels, in orbit and on the ground. Changelog v 1.3 [2014-05-07] * ModuleManager 2.X config update. * Changed FixedUpdate to only run for ports on the active vessel, to improve performance. * Changed the vessel filter distance to a flat, plugin-wide configurable value and increased the default number substantially. v 1.2 [2014-05-05] * No longer calling part.activate unnecessarily. * Made support for the module database optional. v 1.1 [2014-04-26] * Fixed distance check to check distance rather than position. * Integrated support for a caching module database. v 1.0 [2014-04-10] * Initial Release

This mod has been discontinued after complete integration into stock KSP. Thanks devs! AdaptiveDockingNode is a creator-targeted plugin that facilitates multi-sized docking ports via the addition of a helper module alongside Squad's ModuleDockingNode. AdaptiveDockingNode was originally developed for use with Cpt. Kipard's Universal Docking Port Set. Sarcastically Annotated Features Video Sarcastically Annotated Features Video Documentation ModuleAdaptiveDockingNode currently has one configurable field: [KSPField(isPersistant = false)] public string ValidSizes; ValidSizes should be a comma-delineated list of nodeType definitions ala ModuleDockingNode, describing all nodeTypes for which the adaptive docking port should be valid. @PART[*]:HAS[!MODULE[ModuleAdaptiveDockingNode],@MODULE[ModuleDockingNode]:HAS[#nodeType[size2]]]:FOR[AdaptiveDockingNode] { MODULE { name = ModuleAdaptiveDockingNode ValidSizes = size2, size1, size0 } } The patch above will add a ModuleAdaptiveDockingNode to all parts with a ModuleDockingNode module and a nodeType of size2, provided they do not already have a ModuleAdaptiveDockingNode defined, and allow them to be used with all size2, size1, and size0 docking ports. For proper functionality, all docking ports -- even single-size docking ports -- should be made adaptive. Without this step, docking ports without a ModuleAdaptiveDockingNode module will be unable to dock with adaptive ports when the vanilla port is being controlled and the adaptive port is on another vessel. As packaged, AdaptiveDockingNode comes with ModuleManager patches that will add single-size adaptive nodes to all stock and stock-alike docking ports, plus a 2.5m & 3.75m adaptive node to the KW Rocketry 3.75m docking ring. Monetization If you like what you see here, please consider donating via the PayPal button below. Thanks! Downloads KerbalStuff: Coming Someday! Not KerbalStuff: [zip] [tar.gz] [tar.xz] Changelog v 1.7 [2015-05-25] * Updated for KSP 1.0.x! * Corrected a scenario where vessels with multiple parts would cause Exceptional conditions during FixedUpdates happening before Start has concluded. * Various code optimizations behind the scenes. v 1.6 [2014-12-15] * Updated for KSP 0.90. * Now supports gendered docking ports, according to laboratory tests. v 1.5.1 [2014-10-07] * Updated for KSP 0.25. v 1.5 [2014-07-17] * Updated for KSP 0.24. v 1.4 [2014-05-30] * Reverted change to cause FixedUpdate to run only for ports on the active vessel. v 1.3 [2014-05-07] * ModuleManager 2.X config update. * Changed FixedUpdate to only run for ports on the active vessel, to improve performance. * Changed the vessel filter distance to a flat, plugin-wide configurable value and increased the default number substantially. v 1.2 [2014-05-05] * No longer calling part.activate unnecessarily. * Made support for the module database optional. v 1.1 [2014-04-26] * Fixed distance check to check distance rather than position. * Integrated support for a caching module database. v 1.0 [2014-04-10] * Initial Release License AdaptiveDockingNode is copyright © 2014 toadicus, released under a Simplified BSD license. This software uses the ModuleManager library, © 2013-2014 Ialdabaoth (who is awesome), sarbian, et al Used under a Creative Commons Attribution-ShareAlike 3.0 Unported License. AdaptiveDockingNode 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: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. 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. 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 HOLDER 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 ModuleManager library, © 2013-2014 Ialdabaoth (who is awesome), sarbian, et al Used under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Yes, several modules in the newest version absolutely depend on the ToadicusTools.dll library. ModuleDB.dll is technically optional. The various modules have always shared utility code, but now that some of them are depending upon each other, I need them to link to it dynamically rather than compiling it in statically. I'm very curious about your report that your performance is impacted negatively. In general, I've seen the opposite. Can you post an output_log.txt run with a) ToadicusTools.dll and ModuleDB.dll present, and just ToadicusTools.dll present, and comment on the relative performance? If I need more information, would you be willing to run some debug builds to help me troubleshoot? EDIT: Just FYI, you should be able to take a screenshot even from within the full-screen game by pressing "F1" in-game. The screenshot should be saved in /path/to/KSP_arch/Screenshots.

Glad you're enjoying it! So, I'm not 100% sure what you're saying here. From the sounds of it, I think you're saying this: In a stock + TE install, you made sure GameData/TweakableEverything/Plugins/PluginData/TweakableEverything/config.xml was deleted, and the ports all worked correctly. Did you run the program a couple of times to make sure a bad config file didn't reappear? [*]When you install the rest of your mods, the TE config.xml file gets corrupted (filled with gibberish, not valid XML) again, and certain functionality (like undocking animated docking ports) doesn't work. [*]You relocated "bits of" TweakableDockingNode.cfg (I'm guessing the lines within the dockingPort1 patch?) into GameData/Squad/Utility/dockingPort1/part.cfg. This caused the port to run correctly. So, based on #1 above, it sounds like all's well with TweakableEverything. If I'm understanding you correctly and then guessing a few other details correctly myself, it sounds like the issue you're having is tied to another mod throwing exceptions in the space center scene, preventing TweakableDockingNode from correcting invalid protoVessel definitions in your persistence file, which is circumvented when node_stack_tdn exists in the actual part.cfg file, rather than being added by ModuleManager. Alternatively, it could be just about anything else. The conclusion of the story is that you have another mod somewhere causing an incompatibility. If you show me KSP's debug log file (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux (& Mac?): ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log) after a run of the game that exhibits the problem, I can try to tell you which one, and might even be able to do something to work around it on my end (depending on the issue). Yes; that's why it's been done as separate dll's. The only caveat is that TweakableDecouplers and TweakableDockingNode both depend on TweakableStaging; if you remove TweakableStaging, those two modules won't work.

I read through the log file in as much detail as I could manage. 370,000 lines of per-frame debug code is a lot to sift through. That said, I'm pretty confident that my plugin was working as expected. I clearly see it adjusting the node sizes as anticipated, and followed your approaches in a couple of times. The ports did acquire, so if the magnets weren't doing the job that's not an issue with my plugin. I had a bit of debug functionality slightly wrong so I can't tell you specifically why the docking failed, but from the looks of it I think you probably weren't aligned correctly. It's entirely possible, IMO, that this is indicative of a part balance issue on the bigger ports. In my tests, I used one of Kip's 2.5m ports and the KW 3.75m port, and I had to be pretty spot-on even to get the magnets to work (my code engaged at twice the magnet distance). I'd say for the big ports, balance would be aided by boosting the magnet force -- and probably the acquire and reacquire distances -- of the 3.75m ports, at least. That's another discussion, though.

Thanks for that! Those logs pointed me right where I needed to look. So the problem was this: in order to avoid looping through all the vessels every physics frame looking for potential docking nodes, I filter out all of the vessels that are "too far away" to be useful. Only I was being too aggressive (way too aggressive actually; I had failed to square a multiplication factor), so it was filtering out even very nearby vessels if the vessel was significantly large such that its center of mass was too far from the port you were trying to use. I've changed that to a flat number now; instead of basing it on the port's acquireRange, it's now just "1000 meters". So if you've got a vessel more than 1km long... you might have trouble docking to it. But, that value is now pulled from a config.xml file in AdaptiveDockingNode/Plugins/PluginData/AdaptiveDockingNode (created after you load a port for the first time), so if you need to make it bigger, make it bigger. If you feel like performance is not as good as it should be, make it smaller (100 meters is probably still reasonable). Here's a new copy of the debug dll. It should also be way friendlier to use while testing. If you could give it another go I'd really appreciate it, and I'll get another release out tonight.

So, I haven't tried to load up the craft yet, but that log is chock full of exception spam. At least the following mods are causing exceptions during program startup: 'ExsurgentEngineering' 'MechJebRPM' 'SCANsatRPM' The same three also throw an exception during the part compile phase when MechJeb tries to register them in its moduleRegistry. Since you included KSP.log and not output_log.txt, I can't tell specifically what some of the other exceptions come from. Later, there are literally dozens of NullReferenceException tosses during what could be Awake, Start, or early Update passes (i.e. during or immediately after loading a vessel), then hundreds more from MechJebModuleDockingAutoPilot probably right after a docking event. KSP doesn't do a great job of making sure that various mod code runs unimpeded when another mod fails to handle an exception. While some of the exceptions in your log are "normal" and I've seen them not make a big deal (mostly to do with clouds, a couple that KSP throws), the exceptions during flight and vessel startup are almost certainly preventing ModuleAdaptiveDockingNode from starting itself properly. When it can't do that, it refuses to do anything and the docking ports are literally no different than stock ports. I would start by removing those three plugins and see if your problem persists. If it does, this is an issue for the author of those mods. If it doesn't, grab this debug dll, overwrite GameData/AdaptiveDockingNode/AdaptiveDockingNode.dll, run the test again, and report back here. Yes; I will start maintaining a release thread in Addon Development, since my plugin isn't useful without a parts mod like yours to give it life. In the meantime, you can follow the git changelog here. I am very interested to hear more stability reports. Since the 1.1 release I've only heard from Eleven, whose helpful log inclusion suggests (to me) that the problems he's having are nothing to do with MADN. It's possible that I could beef up its fault tolerance and try to "restart" the module if it doesn't get started properly, but there's nothing I'm ever going to be able to do about a bunch of Exception spam during FixedUpdate from other mods. Do the adaptive docking nodes work for you? Do they not? When don't they? Thanks, all.

Can you get me a copy of your debug log? In Windows, look for output_log.txt in the KSP_Data subfolder of your KSP install. I use DRE and a bunch of other mods as well and don't have those problems, so I'm going to need more information to track down your issue.

This doesn't actually fix the problem, but the new version of TweakableEverything I posted this weekend runs all of the patches during FOR[TweakableEverything] (for everything that adds a module) or AFTER[TweakableEverything] (for a few things that tweak modules added during FOR for specific parts). If you need to be sure you're running after me, it shouldn't be hard anymore.

Double posting because releases are worth making sure you all see it. I've updated AdaptiveDockingNode to 1.2; available at SpacePort and not at SpacePort ([.zip] [tar.gz] [tar.xz]). Should fix the SDHI incompatibility!

I haven't tried it at all with MM 2.1.0, but it works fine with 2.0.8. Can you make sure you are running the latest version of the plugin? That fixes a major issue with the adaptive ports working properly. If you continue to have problems, please provide your debug log, a craft or persistence file that exhibits the problem, and a list of mods required to use it. Thanks! You're misreading the cfg slightly, but that doesn't help much in explaining the problem. In fact, MADN does not remove or replace the ModuleDockingNode; it is a helper module that operates alongside it. The incompatibility you're seeing is surely because MADN activates the part during its startup... I don't remember why, but it does. Calling activate on the part is basically the same thing as pressing "space" to activate the stage containing it, so the RealChuteModule is arming, or deploying, or whatever it is those modules do when you activate them. The good news is that's probably something I can fix pretty easily. The bad news is there's nothing you can do to fix it. If you wanted to hack in a modulemanager patch to prevent MADN from being added to parts that contain a RealChute module, you could add this patch to the end of AdaptiveDockingNode.cfg: PART[*]:HAS[MODULE[ModuleAdaptiveDockingNode],MODULE[RealChuteModule]] { !MODULE[ModuleAdaptiveDockingNode] {} } That will prevent any of the paradock parts from becoming adaptive ports, which in turn means that you will be unable to dock them to adaptive ports of a different size when you are "driving" with the vessel containing the paradock part. I'll see about working up a proper fix Soon.

Yes, that is exactly what it means.

Done: https://gist.github.com/toadicus/6444fdf9050fc451a00e Done before the wipe: loaded game, entered tracking station, clicked on craft. Included in the posted log: clicked "fly", craft loaded, craft waggled itself to bits, terminated game with a click to the "X" on the game window. By my quick review, I don't see anything exceptional coming from your code, either. I'd be happy to give your dev version a try. I keep backups of my career save as a matter of course.

This mod doesn't touch the cost numbers, and they currently have no use in game. If you're using a mod that makes the cost numbers meaningful, I recommend you consult the author of that mod with your recommendations. If by that you mean something like: "if I put a short range satellite in an orbit near a long range satellite, can the short range satellite make use of the long range satellite's longer range to transmit data home?" then the answer is yes. For example, the max range on the short range whip antenna is about 4 Mm, but the max range on the large dish antenna extends well beyond Eeloo. If you take a large ship out to Jool, say, with a large dish on the "mothership" and whip antennæ on your moon landers, your landers will be able to relay their experiment data back to Kerbin through the larger ship.

Thanks for the request! Thoughts from users are literally the only way I have to know how to make my mods better. Without your feedback I'm just guessing. Hope you enjoy it!

Good catch! I've fixed that internally. I definitely do still take suggestions. I'm just really busy, so sometimes it takes me a while to get to them.

AntennaRange has been updated to version 1.1! This update brings optional occlusion modeling, adds a tweakable "throttle" to packet size, and some more behavioral improvements. Check out the new AntennaRange toolbar button in the Space Center to activate occlusion modeling! The occlusion modeling works in vitro, but hasn't seen a lot of playtesting. Please consider it experimental for now, and let me know if you run into any trouble! Note that the Toolbar mod is ʀᴇǫᴜɪʀᴇᴅ in order to access the config menu! You can get it straight from the source. CHANGELOG: v.1.1 [2014-05-03] * Added tweakable "throttle" for packet size, to let you trim your transmission rate to stay within your power limits. * Config patches updated to MM 2.0 format. * Added occulsion modeling as an optional feature. See the toolbar button in the space center to enable! * Major refactor of underlying library code to use ToadicusTools. * Relicensed to Modified BSD. * Improved behavior when transmitting directly from an experiment dialog.

VOID has been updated to 0.11.0! This update should improve the performance of the engineering calculations, and provides a toggle to disable them if that's not enough. Be warned: turning them off will remove a lot of information. CHANGELOG: v.0.11.0 [2014-05-03] * Fixed a bug that would sometimes cause exceptional conditions when a vessel took a very long time to load. * Added a core toggle to disable engineering calcuations. Values gleaned from engineering calculations will display NaN or 0 when disabled. * Improved compatibility with the new Engineering code to avoid engineering values sometimes flickering to NaN or 0 when they should not. * Fixed a bug that occured sometimes when not using the Toolbar. * License changed to modified BSD. * Major refactoring of the underlying library code.

TweakableEverything has been updated to version 1.1! The new version adds TweakableStaging, a new module used by ModuleDockingNode and ModuleDecouplers, improves cross-mod compatibility, and updates to ModuleManager 2.0.8. I've been crazy busy at work lately so there's not much new functionality, but I felt like it'd been too long since the last update. CHANGELOG: v.1.1 [2014-05-03] * TweakableDockingNode & TweakableDecouplers refit to use new TweakableStaging. * TweakableStaging: New module! Now you can add staging toggles to any part you like, with your own MM patches. * Updated to ModuleManager 2.0 patch format. * Improved failure detection in some modules to improve compatibility with other mods, notable RealismOverhaul. By default, TweakableStaging does not apply itself to parts not already covered in the TweakableEverything umbrella. However, adding it to additional parts according to your preference is easily done through a simple ModuleManager patch (or two). The two examples below demonstrate the basics, and include documentation. // EXAMPLE ONE: Add staging togggle to launch clamps and defaults them to enabled. @PART[*]:HAS[@MODULE[ModuleEngines]]:FOR[TweakableEverything] { MODULE { // The 'name' entry is not optional and should not be changed. name = ModuleStagingToggle // Defines if the tweakable should be available in the editor. // Defaults to false. activeInEditor = true // Defines if the tweakable should be available in flight. // Defaults to false. // activeInFlight = true // Defines if staging should be disabled by default. // Defaults to false (mimicing stock behavior on most parts). // defaultDisabled = true // Uncomment this line to define a custom staging icon for the parts. // Defaults to the part's original icon if it exists, or DECOUPLER_VERT if not. // Options are: // MYSTERY_PART, LIQUID_ENGINE, SOLID_BOOSTER, COMMAND_POD, DECOUPLER_VERT, DECOUPLER_HOR, // FUEL_TANK, PARACHUTES, WINGLETS, SAS, STRUT, STRUT_CONNECTOR, ADV_SAS, RCS_TANK, RCS_MODULE, // FUEL_LINE, LANDING_LEG, REACTION_WHEEL, WHEEL, LANDING_GEAR, PROBE, SCIENCE_GENERIC // stagingIcon = LIQUID_ENGINE } } // EXAMPLE TWO: Add staging togggle to launch clamps and defaults them to disabled. @PART[*]:HAS[@MODULE[LaunchClamp]]:FOR[TweakableEverything] { MODULE { // The 'name' entry is not optional and should not be changed. name = ModuleStagingToggle // Defines if the tweakable should be available in the editor. // Defaults to false. activeInEditor = true // Defines if the tweakable should be available in flight. // Defaults to false. // activeInFlight = true // Defines if staging should be disabled by default. // Defaults to false (mimicing stock behavior on most parts). defaultDisabled = true // Uncomment this line to define a custom staging icon for the parts. // Defaults to the part's original icon if it exists, or DECOUPLER_VERT if not. // Options are: // MYSTERY_PART, LIQUID_ENGINE, SOLID_BOOSTER, COMMAND_POD, DECOUPLER_VERT, DECOUPLER_HOR, // FUEL_TANK, PARACHUTES, WINGLETS, SAS, STRUT, STRUT_CONNECTOR, ADV_SAS, RCS_TANK, RCS_MODULE, // FUEL_LINE, LANDING_LEG, REACTION_WHEEL, WHEEL, LANDING_GEAR, PROBE, SCIENCE_GENERIC stagingIcon = STRUT } }

sirkut, I built myself a big, articulated solar power station for use with KSPI beamed power. It worked great on launch, but any future attempts to load the vessel end in... ...well, .Here's the output_log, case it helps: https://gist.github.com/anonymous/f88978866b84148ee82c I've tried with and without KJR, turning my quantum struts on and off before and after loading, all to no avail.

Yes. FAR doesn't change anything to do with those numbers, so the information VOID presents is valid with or without FAR installed.

If you want to send over craft files (and a list of mods I'd need) I'd be happy to take a look and see if I can reproduce it. I could alternatively give you a debug build with a bunch of logging output to see if that shows anything useful. Even if it is a KSP issue, I like to try to work around those whenever I can.

The change I made to actually fix it doesn't have anything to do with persistence, but the cfg change I made may; I really don't know how the ordering gets done on that sort of thing. But, you might try making sure that any existing ModuleDockingNode definitions occur before any ModuleAdaptiveDockingNode definitions within the docking port PART{} entries in your persistence. If that makes it work, it's possible I could write something to automatically update bad persistence files.