toadicus

xebx, that sounds like pretty normal behavior. Remember that "additive" ranges mean that the nominal and maximum ranges of a link vary depending on the endpoints. A Comm16->Comm16 link will be very short, a Comm16->Comm88 link will be much longer, and a Comm88->L3TrackingStation link will be very long indeed. From there, the system picks the "best" link based on (more or less) the percentage of that overall distance that lies between the transmitter and the receiver. So in your situation where the Eeloo probe relays through the Jool probe when additive ranges are off, but does not when they are on, the reason is because it is actually "closer", from a radio gain perspective, to Kerbin than it is to the Jool probe. Kerbin is quite a bit better at listening than other probes. To your first edit question: In general, probes will more often connect directly to Kerbin when you're using additive ranges than they do when you're not, for the reasons I outlined above. When additive ranges is turned off, the receiving antenna is completely ignored and your transmitting antenna will literally pick whatever's closest, no matter what. The pretty lines system cannot actually be inaccurate; it uses a cache of pre-determined links to decide where to draw the lines. Claw's BandwidthFix will not operate at all when using AntennaRange; it specifically looks for Squad's transmitter module, which I inherit from but do not keep the name. No adverse interactions should happen at all. linuxgurugamer, I'm happy to entertain such a prospect. Let me know when you've got something to show me, and what I can do to help out. I like your concept for showing how antenna pairs perform in game. I'm not sure I'm going to have time to get to that before Squad stockifies the mod, but since that seems to be getting father away every day, I might after all. Gkirmthal, thanks for the feedback! I'll try to take another pass at the README this weekend. Skalou, I've added a link to the OP. Thanks for reminding me that I hadn't already.

I should rewrite the controlsurfaces patch to disable that module when FAR is installed, because FAR has its own stuff. Might disable when Claw's mod is around, too. Thanks for the report.

Stone Blue, that's not specifically related to the conversation at hand, but you still don't need to be sorry for asking. That said, similar to the data logger conversation, precision for those fields is specified in significant figures (more or less), so you don't tell it "give the number in kilometers", you tell it "give me the 2/5/8/11 most significant digits using the prefix needs the fewest filler zeroes" (or something like that; the description isn't perfect). So if you've asked for 8 sigfigs and your apoapsis altitude is 1,234,567,890, it will calculate that it should divide the value by 1,000,000 and show you 1,234.5678 Gm (I think; . If you pull your apoapsis down to 987,654,321 m, the same setting will determine that it should divide the value by 1,000 and show you 987,654.32 km. This is intentional and is intended to reflect your preference for seeing a bunch of numbers before the decimal point, or just a few, as relevant. In general I try to put as few numbers after the decimal point as possible in each case. As to the twitchy numbers, there's not much I can do about that. If you're in a highly eccentric orbit looking at your periapsis of about 1,000,000 m, with a sigfig setting of 11, it will generally show you the raw value in meters. Because Squad's integrator doesn't handle the edge cases for eccentricity (meaning very circular or very elliptical orbits) very gracefully, the value will be very twitchy. Theoretically I could smooth that myself with a rolling average or something similar, but I'm not sure it's worth the overhead. Open to thoughts on that, though. Glad you're enjoying the mod! I enjoy making it and love that I get to share. Gaiiden, Lat/Lon were previously entirely unformatted; I made them F3 because the magnitude is known (always within 0-3 orders of magnitude), and the sort of instrument that measures it would not really be subject to loss of precision as the magnitude varies. But, since one arcsecond (around 30.87 meters on Earth's equator, so less on Kerbin) is 0.00027~ degrees, I should probably go down to at least F4. What's your preference?

Skalou, glad you're enjoying it! All, I noticed the cargo bay issue myself during play a couple of days ago; I've got it fixed internally and will release an update soon.

So, the options I have for communicating precision come in two main flavors: fixed and variable floating point. The former lets me say "always show this value to three places", for example "0.123" and "123456789.123". The latter is mostly like "show me this value to three significant figures", which would thus show numbers like "0.123", "1.23", "123" and "123000". Generally, for numbers that will vary significantly in magnitude, I prefer the latter. But, you're right that three sigfigs is not enough. How many would you like? Single-precision floats are theoretically good to about 9 digits in this sort of use. Double-precision are good to about 17 digits. I could give you the whole thing every time if you'd like, or anywhere in between. Update: here's a quick example mostly using "G9", or "9 sigfigs", with "F3" or "3 fixed decimal places" for a few items that can be reasonably expected to stay within a small range: http://hastebin.com/unofayijac.csv

Gaiiden, do you want the throttle as fractional (0..1) or percentage (0..100)? Most spreadsheets are handling that all pretty automatically these days, but I figured I'd ask. You were too slow. Here's a quick update for you: [zip] [tar.gz] [tar.xz] I used the percentage, because spreadsheets play really nicely with it these days. If you want fractional I'll change it.

linuxgurugamer, the "official" way to distribute user-contributed patches for AntennaRange is via the Compatibility Patches page on the github wiki. BigFatStupidHead's already got a patch up there that looks like it may be the one you're distributing; I dunno how they compare. At this point I'm keeping the base mod "stock only"; everything's subject to change once Stock gets AntennaRange-ified in 1.1 (or whenever that happens). I could add such a toggle. I've added an issue to help me remember. Gkirmathal, have a look over the README; it should help.

For me it seemed like RealHeat was the culprit. FAR+MFI doesn't have the problem, but FAR+RH+MFI and RF+MFI do.

TweakableEverything has been updated to version 1.13! This update adds the new TweakableControlSurfaces module, and fixes the names of fuel pump action group items. CHANGELOG: v.1.13 [2015-10-02] * New module! TweakableControlSurfaces lets you limit stock control surfaces. * TweakableFuelPumps: Pump actions should no longer be named "True Pump", but should correctly get their resource's name. * Updated for ToadicusTools refactor.

VOID has been updated to version 0.18.4! This version moves the settings file and data logger targets to the active save's folder and brings some minor feature improvements. CHANGELOG: v.0.18.4 [2015-10-02] * VOID_DataLogger: Now emits lat/long data in a more machine-readable format. * VOID_CBInfoBrowser & VOID_VesselRegister: Now using a list of CelestialBodies sorted by distance, depth-first. * Now correctly saving settings to the right scene when reverting. * Moved VOID settings file and CSV target directory to the active save directory. Existing settings will be copied to each "new" save. * Updated for the ToadicusTools refactor.

AntennaRange has been updated to version 1.10.2! This version finally, formally fixes some old bugs and exploits and adds support for the High Gain Antenna from the AsteroidDay mod. CHANGELOG: v.1.10.2 [2015-10-02] * Fixed an issue that could cause Exceptional behavior when the active vessel had no transmitters. * Fixed an issue that could result in Exceptional behavior when a target relay unexpectedly disappears. * Fixed an issue that would result in Exceptional behavior when viewing antenna part tooltips in the R&D scene before opening the Editor scene. * Corrected EVA Kerbals to start with 0 ElectricCharge. They will automatically fill to maximum when leaving the vessel, if the vessel has sufficient ElectricCharge. * Added patch support for the HighGainAntenna from the AsteroidDay mod. * Updated for the ToadicusTools refactor.

ObsessedWithKSP, I might get to that this weekend. First week in a couple of months that I'm not expecting to be working all 7 days. BobsYerUncle, docking ports should decouple when staged, and the staging list toggle should either add or remove them from the staging list. I just tested it on my end and everything worked fine. Have you tried duplicating the issue with no other mods installed? If so, please provide a 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). If not, please do, and let me know the minimum set of mods you need to cause the problem. Thanks!

Loving having this back in the repertoire, GregroxMun. Has anyone noticed mach / re-entry effects happening at low speeds? It's been happening with and without FAR installed.

New dev build up with per-save settings files and CSV save locations. "New" saves will automatically copy settings from the old global settings file if it exists; both the current save's file and the old global file will be deleted if you click Factory Reset. Also tweaks the Celestial Body Info Browser and the Vessel Register to use the sorted list of bodies, and puts range checking on their body indexes to avoid problems when removing mods that add lots of CelestialBody objects. Enjoy! [zip] [tar.gz] [tar.xz]

smjjames, TE disables Squad's gimbal limiter in favor of our own gimbal tweak, but it isn't designed to work with multiple modules on the same part. I'll have to look in to how that works on Squad's end and accommodate. jwest, I'm sorry to say I can't reproduce that in my test bed, so it's probably interference from another mod. The issue as reported in your log is a stack overflow; one of the tweakables on the Mk I pod (and probably many other parts) appears to be suffering from infinite recursion, but nothing I know about the code that controls it (in KSPAPIExtensions) says that should be very possible. You've got some other mods that are misbehaving; you should probably back up your save and try to isolate the minimum set of mods necessary to duplicate. Sorry I can't be more help! - - - Updated - - - Update: Let's think about gimbal tweaks for a bit. There's no "easy" way that is also necessarily right to accommodate gimbals (at least not that's as obvious as for engine fairings). I can't easily apply multiple sliders during execution, because adding tweakables after part compilation is a huge nuisance. This means I can't generate tweaks on the fly based on how many gimbal modules I see. To do that, I'd need to communicate the number of gimbals to the part somehow, which AFAIK ModuleManager does not support, so patches would need to be done by hand for parts with multiple gimbals. I could pretty easily just make one set of tweaks and apply them to all gimbals on the part. Since parts with multiple gimbals... probably... have balanced engines with balanced gimbals, that's... probably... safe. But it might not be, and since I don't have any mods with multi-gimballed parts, I don't really know. I could also do a hybrid sort of solution where I steal Squad's sliders and use them for our gimbal range tweak, then apply the "Reversed" toggle to all of the above. In general I'd hope the second option can work, because having multiple sliders with the same name is confusing and usually unhelpful. What do you guys think?

Gaiiden, as usual that's probably a VesselSimulator issue. Is it wrong in all simple cases, or is this a specific case with odd staging or nonstandard parts of some kind? The horizontal velocity issue is a KSP bug. Horizontal velocity has technically always been wrong as reported by KSP, but an attempt to fix it in 1.0 made it much worse. I wrote a detailed bug report to Squad a few months ago, and wrote a workaround here but it hasn't been released yet. The dev build I put up recently includes the workaround.

I agree with Obsessed that tweaking Isp when stock telegraphs such changes and their impact so poorly is outside the scope of this mod. If KerboKatz' Afterburner already does what is being requested, maybe the right answer is for the requestor to write a patch to apply Afterburner to his rocket parts as desired. SpaceTiger already provides instructions for such in his thread.

Thanks for fielding that one, Kerbas_ad_astra. Not sure how I missed it! Gkirmathal, I've tried to consolidate all of the answers to questions like that into the README file, most easily read on github where the markdown gets interpreted: https://github.com/toadicus/AntennaRange/blob/master/README.md

Got it in two, Skalou; I dropped the ball over the summer holidays. I put it on the tracker to help me remember this time. Brainpop14, you're wanting me to specifically let you increase the thrust to engines? By how much would you need, and do you think is reasonable? In general I have intentionally not added that feature in the past, because it tends to feel a bit "cheaty", where most of my tweaks are purely convenience and tuning items, not literal power increases. I am very hesitant to do something like this. Thoughts: Thrust increase would need to be very limited. Maybe up to 10%? There would probably need to be some penalty for "overdriving" the motors. Maybe increase heat generation? I feel like this might need a cost impact as well. Comments welcomed.

Thanks for the update Aaron Also. Feel free to loop me back in should your future investigations point to an incompatibility between TweakableEverything and another mod.

I haven't seen that myself, djnattyd, but I'll take another look to make sure something odd hasn't crept in and get back to you. Thanks for the report! ObsessedWithKSP, EVAManager handles "filling" of EVA resources as the EVA part "leaves" the pod. It will automatically fill up to maxAmount (still 100) from the vessel (assuming you have enough there). EVA parts then "empty" their resources back into the ship. This was the previous exploit: remove a Kerbal from the ship. Since their part "magically" has 100 ElectricCharge, the pod doesn't contribute anything. Use some ElectricCharge on the ship. Put the Kerbal back in the ship. It empties its ElectricCharge into the ship, allowing you asource of magical ElectricCharge.

Aaron Also, I haven't used either of those parts. Are they parts of the Chaka Monkey and NovaPunch packs, respectively? In general I don't think this mod should be auto-activating any decouplers. But, it's possible. If the issue is actually around autofairings, there's more room for error on my part. Can you troubleshoot by removing the CFGs and DLLs for TweakableDecouplers, TweakableStaging, and TweakableEngineFairings, one at a time only, to see if removing any of those individually gets rid of your problem? Once you've isolated it, please get me a log along with a description of how you caused the problem and the combination of mods present. As always, please test with as few mods as possible to rule out other factors. Thanks!

Give this a go: [zip] [tar.gz] [tar.xz]

Warezcrawler, looks like it's working:

Thanks TMPhoenix! I'll give that a quick test and include it. Warezcrawler, I'll have to take a look. I usually use FAR, so I haven't even noticed that such a tweak doesn't already exist in the base game. I'll keep you posted. Beano et al, I think I've finally figured out what you're talking about, and I think I've also figured out a fix. Stay tuned.