toadicus

Hmm, sorry I haven't got to this yet! I'll take a look when I can. I have been absolutely buried at work, and am moving house, so I haven't had time to do any development or testing lately. But, here is a compile of TweakableRCS missing two lines of code that made the assignment logic only work in Flight. If it works, please let me know. If it doesn't work, also please let me know. http://ksp.hawkbats.com/TweakableEverything/TweakableRCS.dll

Glad you're enjoying it! If I can ever stop working, moving, and visiting family, I've got some pretty cool things in the works for future development, I think. All still optional, too!

Hmm, yeah. I don't actually apply the tweak in the editor; I let you set it, but nothing gets done until flight. Should be an easy change though. Sure! Make a file like TweakableEverything\RealChuteStaging.cfg, and add this patch: PART[*]:HAS[@MODULE[RealChuteModule]]:FOR[TweakableEverything]:AFTER[RealChute] { MODULE { name = ModuleStagingToggle defaultDisabled = false activeInFlight = false activeInEditor = true } } I haven't tested that, but it should work. Obviously, change the settings in the patch if you want different behavior.

The config looks fine; those coordinates are all well within your screen. Scratch #2. That leaves #4. The fact that your log is too big for pastebin suggests that Something Wrong is firing exceptions every update, which would be indicative of a problem. If you've got a Google account, zip up a log file with a strong compression (I use 7-zip in Windows), upload the .zip file to Google Drive, share it with "Anyone with the link", and give me the link, here or in a PM.

For good measure, I just tested it: it works just fine on both by lightly-modded and heavily-modded installs. There are a few possibilities: You don't have any parts active in the editor. VOID does not function in the editors unless there is a root part defined. Add a part (any part) and try again. Your main VOID window somehow got ejected from the screen. You can try resetting VOID to factory defaults using the toggle in the flight-mode configuration window, or by deleting config.xml from VOID/Plugins/PluginData. You have an old or otherwise incompatible version of Toolbar. You have another mod that is causing a conflict with VOID or Toolbar that I cannot duplicate. In order for me to provide further assistance, I need a copy of your debug log (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) after a run of the game in which you experienced the problem. No worries mate! I promise you won't offend me.

Can you get me any more information, or a debug log (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), so I can help track down your specific conflict? The toolbar button works fine inside and outside the VAB. I've said this before, but here it is for this page: VOID uses licensed KER code to do its engineering calcs. At this time, my way of respecting Cybutek's generosity is to not duplicate KER's functionality completely so as to avoid directly competing. I am planning to add a pane that shows TWR for different bodies, but the per-stage grid breakdown is currently off limits. Again, that's not a part of cybutek's license or anything: that's just my way of respecting his hard work. If you want KER, use KER. If you want VOID, use VOID. If you need both... use both!

Good catch, as usual. I've fixed both of those items and refreshed the download. No new version number; just redownload. Thanks!

AdaptiveDockingNode has been updated to version 1.4! This is mostly just an excuse to update the download links now that SpacePort has officially bit the dust, but also includes a minor behavior fix and reduces a bit of code bloat. Details over in The Official Thread. Also, I've done a careful examination of the endline characters in this version of UnivDockPorts.cfg in multiple hex editors and via python scripts, and can confidently say that it very definitely does not have \r\r\n endings in any lines, and in fact only has \r\n endings on every line. Also, \r\r\n wouldn't matter to the parser afaik; that's just an extra blank line as far as it's concerned, and it just ignores those.

AdaptiveDockingNode has been updated to version 1.4! This version should improve behavior in certain circumstances when driving fixed-size adaptive ports, docking to variable-size adaptive ports. It's also an excuse to update now that SpacePort's bit the dust. Changelog v 1.4 [2014-05-30] * Reverted change to cause FixedUpdate to run only for ports on the active vessel.

"Fault detection" means that if some other mod or ModuleManager patch pulls Squad's module or from under its TE helper module, the TE module shouldn't explode everything and fill your logs up with Exception spam. This happens mostly with RealismOverhaul stuff around gimbals and reaction wheels, but I'm working to make sure such changes won't make TE break everything anyway.

TweakableEverything has been updated to version 1.3! This update is mostly minor compatibility fixes, but includes necessary fixes for use with ZodiusInfuser's new InfernalRobotics struts. It also fixes the download links since SpacePort is going away. CHANGELOG: v.1.2 [2014-05-30] * TweakableSolarPanels: Improved fault detection. * TweakableAnimateGeneric: Improved fault detection. * TweakableStaging: Improved behavior when attaching parts in certain conditions. Fixed a bug that cropped up when TweakableStaging was used without any classes subscribing to it. * TweakableLadders: Disabled Squad's ladder tweakables, because ours is just so much cooler. Improved fault detection. * TweakableReactionWheels: Improved fault detection.

AntennaRange has been updated to version 1.3! This version adds the much-requested colorful toolbar button, and an option to fix power consumption at long range, degrading data instead. I'm also working with rkman to come to a better understanding of antennas, and am considering developing a slightly more realistic antenna degradation model for that option in future releases. Thanks for your patience, rkman! CHANGELOG: v.1.3 [2014-05-30] * Added otherwise-nonfunctional Toolbar button in flight that will change colors to indicate current connection status (hint: red is bad) * New option allows power costs to be fixed even at long range, reducing data rate instead.

VOID has been updated to version 0.12.0! This version include the new "Advanced" HUD module, which is not actually advanced at all but just gives you more data on the screen than you had before, if you want it there. I have a window in development to share T:W ratios the various bodies, but it's giving me fits trying to make it work in the editor. Enjoy, and as always please let me know how things are working out! CHANGELOG: v.0.12.0 [2014-05-30] * NEW MODULE! VOID_HUDAdvanced is a second pair of HUD windows which display craft and maneuver node information, respectively. * VOID_VesselInfo: Resource mass fixed to actually display resource mass. * VOID_Rendezvous: Now displays local sidereal longitude for targets by default; re-enabled extended orbital info for targets. * Updated shared KER code. * Minor potentially-performance-enhancing improvements (not reviewed by the FDA) * Time intervals are now displayed in Kerbin days & years when so selected in the game settings.

Hmm. I could probably put together a pane for that. I've explained before that, since cybutek has graciously allowed me the use of his simulation code, I am intentionally trying not to duplicate all of Engineer's functionality in the VAB. But, I don't think a TWR pane would be crossing that line. Ermm... oops. Thanks for the bug report; that's fixed.

Glad you got it sorted.

New goodies coming soon:

That functionality already exists, but it isn't added to all parts to keep bloat down and because I haven't decided yet which parts should get it by default. Have a read of the spoiler in this post for documentation on how to had staging toggles to any part.

I've got that code checked out in my dev builds now. Thanks! I'll try to get an update out soon.

Do you also have a ModuleManager dll installed? You should also have "Kerbal Space Program\GameData\ModuleManager.2.0.8.dll" (or a version newer than 2.1.1). Also, make sure you only have one ModuleManager dll installed; last I checked its handling for multiple copies was disabled. If you've unpacked my archive into GameData and have a ModuleManager dll installed and things still aren't working, a copy of your debug log (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) will help me know more.

Do you know how the 100s baud bandwidth from the Voyager probes compares to their original throughput? I know 100 baud sounds really slow today, but in 1977 that might not have been so bad. That said, I am aware that their output is really, really low and that the DSN is leveraging much newer tech than 1977 to boost and process the signals from the Voyager probes on its way in. AntennaRange does respect the square root law as distance changes (using D² α P/R as the nominal relationship), but does not model antenna gain directly. Currently the only available behavior increases bandwidth along the square-root law as antennas come "inside" their nominal range, and increases the power use as they go "outside" their nominal range. The next update will allow the power draw to be fixed, reducing bandwidth instead, as in Real Life. I looked in to modeling gain early in development and concluded that I didn't know enough about radio to do that. Now that the plugin actually works, maybe I could revisit it. That could help me make diversity in antennas more meaningful, too.

I have considered adding a few antennae. I'm not a modeler or an animator and have no time to become one, but I've considered asking carmics (the AIES developer) if he'd let me distribute a few parts with MM patches to make them AR relays. But, I have a little trouble deciding what to do with it, and I'd need to do some research into different space-based communicators. In real life we can still talk to the Voyager probes using nothing but their radio and a ground station... and those have tech from what would probably be the "middle" of Earth's progression. Since then we've primarily been increasing bandwidth (and with bandwidth, security and quality) as far as I know... which is not very far, because radio is not actually my thing. All that to say, such a notion is on my radar, but I don't have a good bearing on how to proceed with it, so for right now it's not at the top of the stack. I very much encourage you to share MM patches for any antennas that you do repurpose. I know MeCripp's already got some; you might all work together to find a compelling solution. To make that work I'd need to implement additive ranges. And even then that would only matter until you got the big dish, which would add up to a very large number with whatever I set Kerbin's default to. I do know what you're saying, I'm just not sure if there's a "right way" to implement it, and I don't think it feels very realistic. See above about Earth's comms to the Voyager probes. Thanks! You guys are nice, too.

Well, in general that's already the case. Early tech levels limit you to near-Kerbin missions; the whip antennas can barely make it to KSO. The medium dish gets you out to Minmus, again barely. You don't get the "go anywhere, do anything" antenna until Electronics, which is pretty far down the chain. OK folks, status update. Since gmbigg's recommendation has been so well-received, I've gone ahead and implemented it. I have it working and will release it soon. I've also been working on pretty lines. They... work? That is, it does draw pretty lines, and about 90% of the time they start and stop in the right places, they're always the right color and they only sometimes crash the whole process. Anyway, I might push out an experimental build in the not-to-distant future. Thanks for all the input, folks! Keep it up!

@ObsessedWithKSP: Those two issues are the primary reasons I sometimes think about completely rewriting the data transmitter. To the first, Antennas get activated several different ways. For some of the ways, I have good control over the process and can inject messages. Other ways it's a lot tougher. If you can tell me when it didn't add the "directly back to Kerbin" to the message, I'll see if I can't hunt that down. To the second, Squad's interface for IModuleDataTransmitters requires a CanTransmit() method, and will correctly not transmit if CanTransmit() returns false (the default Squad ModuleDataTransmitter will never return false). But, since they don't have any cases where that happens it seems like the rest of the experiment system doesn't do a great job of handling things when CanTransmit() returns false. Sometimes experiments are lost forever. Sometimes they appear to get stuck in the transmitter's queue, and will actually transmit if you manually start a transmission later. All of the actual transmitting is done in private methods that I can't change or call and shouldn't look at, so finding meaningful workarounds is tough. For now, these are known limitations and my best advice is to be careful. Working around Squad's default behavior is tricky and rewriting the whole module would be very time consuming, and if I got something wrong I might really ruin your day.

I'm using SciTE, but it looks like the download site for their Windows installer is down. I'll PM you a link to a download from a personal server, but Notepad2 will show you the problem as well. Notepad doesn't render \n linebreaks as a new line; it will ONLY draw a full \r\n sequence as a new line. Looking at a binary read of those lines in python: [ b'MODULE\n', b'\r\n', b'{\n', b'\r\n', b'\tname = ModuleAdaptiveDockingNode\n', b'\r\n', b'\tValidSizes = size0,size1\n', b',size2,size3\r\n', b'}\r\n', b'}\r\n' ] I use Linux, so 95% of my text files will come with \n newlines (all but those that I got from others using Windows). You probably copy-pasted some of those lines from something I sent you (probably from the 1.25m port) and then added the other sizes yourself in notepad, which didn't know and couldn't tell you that you were actually adding them after a newline.

All I had time for before work this morning was a quick launchpad test (I did use my super-modded install, just in case there was an incompatibility flying around out there). Everything with the Clamp Sr's and the X-Large Universal worked as expected; I did have some issues getting a Clamp Sr to dock to the KW ring, but it was only one way; if I changed vehicles they hooked right up. I think I've got a notion what's going on with that, and it's not really related here, so moving right along. I am going to guess / hope that the problem is this: I noticed this morning that in the latest SpacePort download of the Universal Docking Port Set, the X-Large port has a formatting error. Starting at line 59: MODULE { name = ModuleAdaptiveDockingNode ValidSizes = size0,size1 [b],size2,size3[/b] } That extra linebreak on the ValidSizes line is probably your problem -- I must have fixed it in my own install during development and forgotten about it. Head over to GameData/KipEnd/parts/UnivDockPorts, open up UnivDockPorts.cfg and see if that linebreak is there. That module definition (starting at line 59) should look like this: MODULE { name = ModuleAdaptiveDockingNode ValidSizes = size0,size1,size2,size3 } ",size2,size3" needs to be up in the same line as "ValidSizes =". Hope that helps!