toadicus

New dev build with a number of optimizations. In general this has sped up the average loop time by 10-20% in my test network. [zip] [tar.gz] [tar.xz]

If you can try to duplicate one of those specific problem scenarios and get me a log for it, that'd be great.

vardicd, I did a bunch of benchmarking yesterday, and in non-GC frames the network resolution is taking about 20µs per relay for a network of 4 relays. Going up to 50 relays it seems reasonable that it'd take 250µs per relay... 50 times, which is 12.5ms; enough that whatever else is going on in your heavily-modded install is probably going to push you under the 60 fps mark. I'd be surprised if it pushes you below 30 fps, though. How severe is the hit you're seeing? I'd still like to get this threaded... but it's Really Rather Complicated, so that particular endeavor is going to need to wait. In the meantime, there are a few things I can do -- I can spread the network out so it only resolves a few relays per frame, perhaps -- and there are a few things you can do -- try pushing your update delay up to about 66 ms and see if that a) helps and is something you can live with. Thanks for testing! smunisto, I've been playing my career save a bit lately and have actually been rather happy with the way the relays are working. I have a bunch of little sats in Minmus orbit, all with Comm. 16s, and a single comsat with a Comms DTS. I'm upgraded to KSC2. So the little sats have a (max) range of 10.6 Mm with the comsat or 60 Mm back to Kerbin; the big sat has a range of 35.5 Gm back to Kerbin. Relays prefer lower cost connections; that is, connections where range²/maxRange²[1] is the smallest. The little sats and the comsat are going to be at most, say 2 Mm apart, whereas they're all about 47 Mm from Kerbin. (47/60)² is a lot bigger than (2/10.6)², so the little sats will all use the big relay rather than phoning home to Kerbin. They'll even use marginally-yellow connections to the big sat, because (47/60)² is really right at the edge of their range, so it's rarely going to be useful. Mun is next on my hit list; it'll be interesting to see what things look like there, since 10/60 is a lot more like 2/10.6. I suspect they'll actually wind up flipping around a lot, but generally preferring Kerbin. So that said, there's a reason I like the idea that some of the higher-end antenna pairings should be useful in a "Jool's Moons" sort of environment. If you put a couple of Farseers in high, inclined Jool orbits to phone home to Kerbin, IMO they should play nicely as relays for medium-sized antennas throughout the Jool system. You don't need to look at Pol->Bop; Jool->Bop would probably be fine. But, that's just my opinion and my gut feeling as I type this. The numbers you've got on paper there are making sense and looking nice. Play test it; see if you can get a few others here to play test it, and see how it shakes out! One final thought on this balance pass: once you're happy with the ranges, you should tinker with the power use, part mass, and scales. The 90-09 should be a bit bigger and heavier than the 88-88, and the Farseer should be a bit bigger and heavier than the 90-09, etc. Hopefully the Origami part maker already sorted that out, but if not, you've got ModuleManager and can do it yourself. You should be able to modify KSC ranges with a ModuleManager patch, like so: @TRACKING_STATION_RANGES[*]:FOR[SmunistoARPatches]:NEEDS[AntennaRange] { // Indexes are 0-based, so this is KSC2 @range,1 = 123456789 } I haven't tested this or anything, so it's possible it won't work, but everything I know about ModuleManager says it should. It's possible I might need to add a "name" field to TRACKING_STATION_RANGES for it to work right. Footnotes: [1] Technically perhaps this should be range²/nominalRange², but that wouldn't change very much.

I doubt that adding AntennaRange compatibility to a couple of antennas requires dealing with APIs. A Module Manager config file will do, which as far as i know has no licensing issues. For the record: distributing patches facilitating AntennaRange functionality to mod parts does not violate my intent as regards any of my rights, properties, or the expressions thereof. I've intentionally used a very permissive license that only requires written consent for using my name in regard to a derivative work. That said, I fully encourage the basic politeness of seeking consent or advice for other uses anyway, especially in the interests of "playing nicely with others". We're all here to have fun, I want to do whatever I can to help others have fun, and I'm always glad when others do, too. Sigma88, thanks for your interest and for asking. I'm aware some users want more antennas, and in general I think it's a good idea. That said, I also think that avoiding save-breaking is a better idea, so within the base mod that I distribute, I have no plans to include additional parts. I also can't model or animate, so I'm incapable of producing more antennas without a collaborator. All that said, if you're interested in collaborating and offering an "expansion pack" of antennas that I could co-distribute, I'd be very interested in helping to design and balance patches around such parts, and such co-distribution. If that's something you're interested in, shoot me a PM. Hmmm, can you check to see if it's vomiting all over your log? The Windows version really doesn't like it when things are writing the logs a lot; if I left some verbose logging on that could explain the slowdown. If I didn't... I'm not sure what's up. Let me know; I'll be looking in to it. Very awesome of you, sir. Nope; any holes left are an artifact of having three parts to use and a diverse set of available uses to cover. Let me know how I can be of service.

Sigma88, that's absolutely possible! There are no licensing issues at all around enabling antennas to work with AntennaRange; maybe I should make that a bit more explicit on the front page. Here's a quick primer: The Fields AntennaRange extends and augments the functionality of the stock ModuleDataTransmitter through the new ModuleLimitedDataTransmitter class. This class uses five additional configurable fields to define the part's behavior. nominalRange is the range, in meters, at which the part should function identically to the stock module, i.e. without any modification to the power cost or packet size. This is used along with maxPowerFactor to calculate the maximum range of the part. simpleRange is the same as nominalRange, but is used when the mod is in "simple" mode. In general it will probably need to be a much larger number than nominalRange. maxPowerFactor effectively sets the maximum range of the antenna by essentially capping how much the power may be "turned up" to get better range. I originally used 8 for this number, because it felt right. I've since used 4 (for my DTS) and 16 (for my Comm. 88-88). You don't want this number to be too high, or small probes will go uncontrollable a lot when transmitting. maxDataFactor defines the maximum "speed up" bonus that comes from using antennas at less their nominal range. I originally used 4 for this number for all parts; the DTS has a higher bonus now. Note that all of the fields needed for Squad's ModuleDataTransmitter still need to be filled out. Depending on how you're defining your parts, they might need to go in your AntennaRange patch, or they might already be defined on the base part. The Mechanic In general, the scaling functions assume the following relation: D² α P/R, where D is the total transmission distance, P is the transmission power, and R is the data rate. Data rate increases as range decreases below nominalRange: R α nominalRange² / D² By default, power use increases as range increases above nominalRange: P α D² / nominalRange² Optionally, power use may remain fixed, and data rate instead decreases as range increases above nominalRange: R α nominalRange² / D² Patch Conventions To maximize cross-compatibility, please consider the following conventions for ModuleManager patches regarding AntennaRange: When providing new definitions for your own parts, always specify a :FOR[YourModHere] pass name. Whenever changing default AntennaRange definitions (e.g. if you were going to rebalance my antennas to suit your mod), please do so in the :AFTER[AntennaRange] pass. I recommend providing all optional functionality (e.g. enabling RemoteTech vs. AntennaRange modules) in separate patches using :NEEDS[] blocks. A sample AntennaRange configuration for an all-new mod part might look like this: @PART[modPartName]:FOR[YourModName]:NEEDS[AntennaRange,!RemoteTech] { MODULE { // ### Module Definition ### name = ModuleLimitedDataTransmitter // ### Squad Definitions ### // Delay between transmission packets, in seconds packetInterval = 0.10 // Data capacity of nominal transmission packets, in MiT packetSize = 2 // Resource cost of nominal transmission packets, in units packetResourceCost = 20.0 // Resource name to be consumed by transmission requiredResource = ElectricCharge // Animation module index, 0-based, of the antenna extend/retract animation DeployFxModules = 0 // ### AntennaRange Defintions ### // Range, in meters, at which the antenna behaves per the "nominal" characteristics above // Used with "additive" ranges. nominalRange = 10000000000 // Range, in meters, at which the antenna behaves per the "nominal" characteristics above // Used with "simple" ranges. simpleRange = 56250000000 // The maxmimum multiplier on packetResourceCost, essentially defining the maximum power output of the // transmitter. Maximum range is defined as: maxTransmitDistance = nominalRange * sqrt(maxPowerFactor) maxPowerFactor = 16 // The maximum multiplier on packetSize, essentially defining the maximum data throughput of the // transmitter. maxDataFactor = 2 } // We add this ModuleScienceContainer so that when transmission fails the antennas can try to stash the data instead of dumping it to the void. MODULE { name = ModuleScienceContainer dataIsCollectable = true dataIsStorable = false storageRange = 2 } } This example assumes that the base part definition does not include a ModuleDataTransmitter module, or any RT modules. If the base part definition includes a ModuleDataTransmitter module, a sample AntennaRange patch could look like this: @PART[modPartName]:FOR[YourModName]:NEEDS[AntennaRange,!RemoteTech] { @MODULE[ModuleDataTransmitter] { @name = ModuleLimitedDataTransmitter nominalRange = 10000000000 simpleRange = 56250000000 maxPowerFactor = 16 maxDataFactor = 2 } // We add this ModuleScienceContainer so that when transmission fails the antennas can try to stash the data instead of dumping it to the void. MODULE { name = ModuleScienceContainer dataIsCollectable = true dataIsStorable = false storageRange = 2 } } IIRC, RemoteTech parts should not have ModuleDataTransmitter definitions. In that case, to facilitate RT, AR, and Stock compatibility, a suite of patches like this might be appropriate: // If we don't have RemoteTech, add a stock ModuleDataTransmitter first. @PART[modPartName]:NEEDS[!RemoteTech]:BEFORE[YourModName] { MODULE { // ### Module Definition ### name = ModuleDataTransmitter // ### Squad Definitions ### // Delay between transmission packets, in seconds packetInterval = 0.10 // Data capacity of nominal transmission packets, in MiT packetSize = 2 // Resource cost of nominal transmission packets, in units packetResourceCost = 20.0 // Resource name to be consumed by transmission requiredResource = ElectricCharge // Animation module index, 0-based, of the antenna extend/retract animation DeployFxModules = 0 } } // If AntennaRange is installed, convert that to a ModuleLimitedDataTransmitter @PART[modPartName]:NEEDS[AntennaRange,!RemoteTech]:FOR[YourModName] { @MODULE[ModuleDataTransmitter] { // ### Module Redefinition ### @name = ModuleLimitedDataTransmitter // ### AntennaRange Defintions ### // Range, in meters, at which the antenna behaves per the "nominal" characteristics above // Used with "additive" ranges. nominalRange = 10000000000 // Range, in meters, at which the antenna behaves per the "nominal" characteristics above // Used with "simple" ranges. simpleRange = 56250000000 // The maxmimum multiplier on packetResourceCost, essentially defining the maximum power output of the // transmitter. Maximum range is defined as: maxTransmitDistance = nominalRange * sqrt(maxPowerFactor) maxPowerFactor = 16 // The maximum multiplier on packetSize, essentially defining the maximum data throughput of the // transmitter. maxDataFactor = 2 } // We add this ModuleScienceContainer so that when transmission fails the antennas can try to stash the data instead of dumping it to the void. MODULE { name = ModuleScienceContainer dataIsCollectable = true dataIsStorable = false storageRange = 2 } } // If RemoteTech is installed, do their module(s) instead @PART[modPartName]:NEEDS[RemoteTech]:FOR[YourModName] { // RemoteTech module(s) here } As Kerbas_ad_astra noted, the next version of AntennaRange will implement "additive" ranges, which means that links will be defined by the pair of antennas in use, and not just the one antenna on the transmitting side (this will be optional; hence the need for simpleRange as seen in the examples above). Under this "additive" system, the following formulæ may be useful when designing parts: [B]PER ANTENNA[/B] nominalRange is a given, and is never calculated maxPowerFactor is a given, and is never calculated maxTransmitDistance = nominalRange * sqrt(maxPowerFactor) [B]PER LINK[/B] (connected pair of antennas) NominalLinkDistance = sqrt(nominalRange1 * nominalRange2) MaxLinkDistance = sqrt(maxTransmitDistance1 * maxTransmitDistance2) Therefore, to find the MaxLinkDistance from two sets of nominalRange and maxPowerFactor: MaxLinkDistance = sqrt(nominalRange1 * sqrt(maxPowerFactor1) * nominalRange2 * sqrt(maxPowerFactor2)) To find a single antenna's nominalRange from a desired maxTransmitDistance given its maxPowerFactor: nominalRange = maxTransmitDistance / sqrt(maxPowerFactor) To find a single antenna's desired maximum range given the desired maximum link distance and another set maxTransmitDistance: maxTransmitDistance1 = MaxLinkDistance * MaxLinkDistance / maxTransmitDistance2 Remember that maxPowerFactor may differ between antennas (and does, in my lastest configs: longAntenna is 8, mediumDish is 4, commDish is 16). Currently Kerbin's maxPowerFactor is hard-coded as 8. Feel free to use this spreadsheet for balancing antennas if it's useful to you: https://goo.gl/ChsbfL On Balance In my configs I've balanced the three stock antennas to cover all of the stock solar system. Since you're introducing five more antennas and working with OPM, you will probably want to change the behavior of the stock parts and diversify the range to gradually cover the whole OPM system. Since you have some parts specifically designed for use in planetary subsystems, their balance when transmitting to other parts is probably more important than their balance when transmitting to Kerbin. For longer range parts designed to make the whole interplanetary leap, the inverse is probably true. Feel free to ask questions! If anything's unclear or you just want to bounce balance ideas off of me, don't be shy. I'm always happy to help.

EngineStagingToggle.cfg will add a "Toggle Staging" switch to all parts with the stock engine modules (so, all stock engines and many mod engines), allowing them to be removed from the staging list. FairingStagingToggle.cfg does the same, but for parts with the stock procedural fairing module (so, all stock payload fairings, and many mod payload fairings).

OneRaven, I've never used that mod, but I'm clobbering a lot of the stock functionality, so if they're using some feature that Squad's parts don't, I'm not too surprised. I'll take a look soon. curtquarquesso, I'm using it in my career save fwiw. I'm pretty confident that I've sorted all the issues to do with 1.0 update items that were hard to see, and the only issue I'm aware of is the one report by OneRaven.

Sorry for being absent over here folks. I'll look in to the stage info window as soon as I can. luizopiloto, what kind of interface would you envision? Because there's already a mod called Telemachus that provides a lot of info as a web page: http://forum.kerbalspaceprogram.com/threads/24594 Not sure it provides everything VOID does, but I know it does a lot. Gaiiden is probably the expert there. At least, I think Gaiiden uses it. VOID can also provide a lot of info as a CSV file. If you can read that in real time, you can do a lot of cool things with it. I'm relatively certain that Gaiiden is the expert there. Anyway, doing something external isn't really on my radar right now, but if there was a compelling way to provide external information in a way that wasn't too far out of scope, I could consider it.

TweakableEverything has been updated to version 1.11.6! This version brings various fixes and a couple new "Extras" cfg patches. CHANGELOG: v.1.11.6 [2015-06-06] * EXTRAS: Now bundling two extra .cfg files, which may be copied in to GameData for people who want them. * TweakableStaging: No longer trying to reposition decouplers based on their part's offset, because it was causing unexpected behavior. * TweakableDecouplers: Fixed an issue where parts with staging disabled would spontaneously decouple when loaded. * TweakableEngineFairings: Fixed to more accurately track whether or not fairings/shrouds should be present, especially when loading jettisoned parts. * TweakableDockingNode: Fixed to avoid upsetting the universe when starting up a docking node that had previously been used as a decoupler.

Another dev build, which restores support for what we'll call "simple" ranges, i.e. not additive/geometric ranges. This necessitates a new field, "simpleRange", for all module definitions. My values for simpleRange at this point are the same as the nominalRange values in 1.9 and 1.9.1. This is at least a "beta" grade build. [zip] [tar.gz] [tar.xz]

One more dev build; this one hopes to solve some premature decopulation issues, based entirely on guesswork. [zip] [tar.gz] [tar.xz] If you have issues with spontaneous decoupling, please a) try this build, 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), and c) provide detailed reproduction steps.

John Nowak, I'm pretty sure I have tools available to figure elevation angles like that. Whenever I get to ground stations (which I almost certainly will at some point), that's a feature I'd like to include.

I haven't really ever made anything gratuitously large, but I my Tylo Explorer ship back in 0.18 was pretty good sized: I didn't launch the whole thing at once, but I recall the launcher that did the outgoing fuel tanks (the four '32s in and around the middle section) being rather good sized.

rkman, I meant that it would technically actuallly be affecting received power (not transmit power), but in my code it will be abstracted as a multiplier on both nominal and max link ranges, as you said. smunisto, the nominal ranges on the Comm. 16 and Comms DTS look way too low to me. You could walk out of range of a 16 in about 2 minutes; my kids' walkie-talkies are better than that. In general I think the balance of my Comm. 16 in the last dev build is basically the shortest viable range for an actual part. Maybe try the new KSC ranges, work from the Comm. 16 as a baseline and try to balance a nice progression from there? FireFaced, I changed the name in the license on the OP. The source files carry the actual license would I care to ever enforce anything; the one on the forum is here because Squad says it must be, and not because of my careful attention to my IP. In the future, though, I'd rather such admonishments take the form of a PM. Thanks!

Gristle, I have a theory about what might be going on there. I have been getting an inkling that, since 1.0, Squad (or some other mod, perhaps) is forcibly activating parts in "already used" stages when vessels load. Since I'm not actually telling the decouplers that they are unable to fire, and someone is circumventing my logic by calling force_activate, staging-disabled decouplers in "already activated" stages get fired during load. Again, that's a theory. I haven't been able to test it at all yet. If it is the problem, you might be able to work around it by putting all of your decouplers in the very top stage before you disable them. cipherpunks, if you're not using using the dev build from post 700, please see if that solves your issue. If not, please provide logs and reproduction steps. SaintWacko, see if this does what you're looking for: @PART[*]:HAS[@MODULE[ModuleEngines]|@MODULE[ModuleEnginesFX]] { MODULE { name = ModuleStagingToggle defaultDisabled = false activeInFlight = true activeInEditor = true } } I've actually been wanting that myself recently; I'll probably pack it in by default in the next release. curtquarquesso, thanks for the assist.

rkman, I'm glad you're still here, and noticed. Sadly (perhaps?), I don't think we're going to get a whole lot closer to the original AntennaRange 2.0 concept than this, for a number of reasons. Chief among these reasons is that I'd have to use such laughably unbelievable numbers to achieve a similar effect (since the whole point of the mod is that it's important to pick the right antenna for the job), I'm not sure I could sleep at night. For example: Voyager is around 19.5 terameters from Earth, sending 12 W through a 48 dBi antenna. It goes all that way, down through the atmosphere, and is received by a 74 dBi antenna. We get on the order of 10^-20 W out the tail end of that antenna, and we can still hear it. These numbers generally even account for a bunch of the noise. Numbers from here: http://descanso.jpl.nasa.gov/DPSummary/Descanso4--Voyager_new.pdf#page40, PDF page 40 if the bookmark doesn't work. The most distant conceivable probes in KSP are about 700 gigameters from Kerbin. Common consensus amongst the modding crowd suggests that 1 EC/sec = 1 kW. The stock 88-88 uses 20 EC every 0.1 seconds, making it a 200 kW transmitter. That's four times higher than broadcast AM radio stations are allowed to run in the United States, and more than 16,000 times more powerful than Voyager's radio. These two facts together mean, all else being equal, the received power back at Kerbin would be on the order of 12 million times higher than Voyager's signal getting back to Earth. Even if we break with consensus and treat 1 EC/sec = 1 W, it's still 12000 times more power received. This means that, in order to make things work as expected, I'd need to handwave the baseline noise levels up by at least 30 dB (and perhaps 60 dB!), or completely trivialize the power usage (which would be more realistic, but clearly out of line with Squad's vision for the system). Also, this wouldn't have any direct impact on the way the mod plays: in the end, it'd still basically be about comparing antennas and their ranges. So, I've decided to leave the baseline ambiguous, and make it more about comparative gains and powers instead. It puts a little more burden on the antenna designer -- you have to bake gain and power into "range" yourself -- but since that's mostly me anyway, I feel like that's OK. What I do still want to do is add circumstantial noise, which would have a direct multiplicative impact on "power" (and therefore a sqrt impact on range). I'm thinking I might add optional "atmospheric noise" that could make it harder to transmit off and around bodies with atmospheres, and optional "radiation field noise" based on localities around big planets and such. Again, it'd be defined a bit arbitrarily, but it would act in service to realism without modeling a bunch of lies into the baseline (and also making me rewrite a bunch of code). MoarDV, you're correct that players do not start with "talk anywhere" capabilities at the beginning of career mode. In general, theoretical future ground stations (on Kerbin) would have the same ranges as KSC's tracking station, and be upgradeable in the same way. John Nowak, I can foresee a possible tie in with mods like Kerbinside to make ground stations cheaper to buy near other facilities when they exist. Changing how StageRecovery works would certainly be up to StageRecovery. vardicd, thanks for the explanation. Let's call that sort of mechanic a "control station" rather than a "ground station", because really its location on or above the ground is pretty unimportant to its actual function, which is to make probes controllable. The primary problem from my end is that such a mechanic would have to only affect probe control -- science transmissions would still need to go back to Kerbin. Currently I don't differentiate between those two reasons in the slightest, and that would need to change first. After that, it's basically a matter of adding a vessel module to see if you have X unemployed Kerbals on the ship (i.e. not being used in a science lab or cockpit). Just being honest: at this point, that sort of feature is pretty far down the list of things I might do, but it is a cool idea.

Here's a new dev build that should resolve the decoupling docking ports issue, and the problems with tweakable engine fairings. [zip] [tar.gz] [tar.xz]

Update: dev build using those ranges, with some other fixes: [zip] [tar.gz] [tar.xz]

MoarDV Something like "KSC1 for all of Kerbin" isn't a bad idea. But, I don't think "KSC3 for all of Kerbin" is a bad idea, either, so I might not be a good judge. Anyone else have a thought on that? mega_newblar, no I'm not. If you're looking for an easier way to manage your mod versions than "manually", my current preference is CKAN. I like it especially because it can't break my mods, even if it tries. Fraz86, I've had very similar thoughts about the Kerbin->Duna ("window only") range. if I could reduce DTS+KSC2 by like 75% by doing that, it'd be more attractive. But for 30%, it's a bit meh. Also: thanks for the "plain english" idea on the spreadsheet; it even helped me to think about it. Here's my new thoughts on ranges for an all-stock game: [TABLE][TR][TD][TABLE][TR][TD][/TD][TD]From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]To↓[/TD][TD][m][/TD][TD]1.80E+04[/TD][TD]7.00E+09[/TD][TD]4.00E+10[/TD][/TR][TR][TD]Comm. 16[/TD][TD]1.80E+04[/TD][TD]1.80E+04[/TD][TD]1.12E+07[/TD][TD]2.68E+07[/TD][/TR][TR][TD]Comms DTS[/TD][TD]7.00E+09[/TD][TD]1.12E+07[/TD][TD]7.00E+09[/TD][TD]1.67E+10[/TD][/TR][TR][TD]Comm. 88-88[/TD][TD]4.00E+10[/TD][TD]2.68E+07[/TD][TD]1.67E+10[/TD][TD]4.00E+10[/TD][/TR][TR][TD]KSC1[/TD][TD]8.00E+05[/TD][TD]1.20E+05[/TD][TD]7.48E+07[/TD][TD]1.79E+08[/TD][/TR][TR][TD]KSC2[/TD][TD]2.00E+11[/TD][TD]6.00E+07[/TD][TD]3.74E+10[/TD][TD]8.94E+10[/TD][/TR][TR][TD]KSC3[/TD][TD]2.25E+12[/TD][TD]2.01E+08[/TD][TD]1.25E+11[/TD][TD]3.00E+11[/TD][/TR][/TABLE][/TD][TD][TABLE][TR][TD]|[/TD][TD][/TD][TD][/TD][TD][/TD][TD][/TD][/TR][TR][TD]|[/TD][TD]To↓ From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]|[/TD][TD]Comm. 16[/TD][TD]<Kerbin Orbit[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Kerbin->Mun[/TD][/TR][TR][TD]|[/TD][TD]Comms DTS[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Jool's Moons[/TD][TD]Jool's Moons[/TD][/TR][TR][TD]|[/TD][TD]Comm. 88-88[/TD][TD]Kerbin->Mun[/TD][TD]Jool's Moons[/TD][TD]Kerbin->Duna[/TD][/TR][TR][TD]|[/TD][TD]KSC1[/TD][TD]Low Kerbin Orbit[/TD][TD]Kerbin->Minmus[/TD][TD]Kerbin SOI[/TD][/TR][TR][TD]|[/TD][TD]KSC2[/TD][TD]Kerbin->Minmus[/TD][TD]Kerbin->Duna[/TD][TD]Kerbin->Jool[/TD][/TR][TR][TD]|[/TD][TD]KSC3[/TD][TD]Kerbin SOI[/TD][TD]Kerbin->Jool[/TD][TD]Kerbin->Eeloo[/TD][/TR][/TABLE][/TD][/TR][/TABLE] The most significant differences from your recommendation below is the LKO range on whip->KSC1 is almost doubled, so players who don't skate the ragged edge of the atmosphere can still get a link (remember 7.07e+4 is only 70,700 m; that's not a lot of leeway!), and 88-88->88-88 can now stretch all the way to Duna, allowing for some interesting possibilities with interplanetary relay systems. I often think it would be interesting to set up a relay network around Duna's orbit to expedite transmissions from a theoretical Laythe base. It also brings whip->whip up to 18 km, which makes it way more useful for rovers and such. Or really seat-of-the-pants lander/mothership connections.

A few formulas for your reference: PER ANTENNA: nominalRange is a given, and is never calculated maxPowerFactor is a given, and is never calculated maxTransmitDistance = nominalRange * sqrt(maxPowerFactor) PER LINK (connected pair of antennas): NominalLinkDistance = sqrt(nominalRange1 * nominalRange2) MaxLinkDistance = sqrt(maxTransmitDistance1 * maxTransmitDistance2) Therefore, to find the MaxLinkDistance from two sets of nominalRange and maxPowerFactor: MaxLinkDistance = sqrt(nominalRange1 * sqrt(maxPowerFactor1) * nominalRange2 * sqrt(maxPowerFactor2)) To find a single antenna's nominalRange from a desired maxTransmitDistance given its maxPowerFactor: nominalRange = maxTransmitDistance / sqrt(maxPowerFactor) To find a single antenna's desired maximum range given the desired maximum link distance and another set maxTransmitDistance: maxTransmitDistance1 = MaxLinkDistance * MaxLinkDistance / maxTransmitDistance2 Remember that maxPowerFactor may differ between antennas (and does, in my lastest configs: longAntenna is 8, mediumDish is 4, commDish is 16). Currently Kerbin's maxPowerFactor is hard-coded as 8. As you observed, links to Kerbin are always dissimilar. Feel free to use this spreadsheet if it's useful to you: https://goo.gl/ChsbfL I'm still exploring ideas about link ranges and asymmetric pairings myself, so I'm glad you're pushing through all this to experiment with things yourself and share what seems best to you. Per my release comment: The 1.9.1 release is a technically older code base than any of the dev builds, without any experimental or untested features. If you want to keep playing with geometric ranges, play with the dev build. It has all the fixes, plus the new features. As always, you can find the dev build here: [zip] [tar.gz] [tar.xz] In general I think that would be the cooler way to do things, but it involves me learning a lot of tech that I'm not already familiar with. I'll take a glance over Extraplanetary Launchpads (and maybe Kerbinside) about how to "launch" craft from other locations and see how feasible I think it is for this mod. In general I'm with RKMan on this one. Transporting a 70 meter dish to another planet would be a huge and largely-wasteful operation. The ones we have here do the whole job just fine. Nothing's stopping you from designing a huge, heavy part, giving it a giant range in the cfg, and shipping it out yourself right now, though. I'm glad you're enjoying it! I enjoy making it, and am happy to share. - - - Updated - - - Update: I actually played the game last night (<gasp!>), and I felt like whip->KSC2 was too long. Do we think we could support a 480 km range (down from 4.8 Mm) for whip->KSC1 to keep whip->KSC2 from reaching past Minmus? Downside: it puts whip->whip down to 4.8 km, which is not very far. [TABLE][TR][TD][/TD][TD]From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]To↓[/TD][TD][m][/TD][TD]4.80E+03[/TD][TD]2.26E+09[/TD][TD]2.05E+10[/TD][/TR][TR][TD]Comm. 16[/TD][TD]4.80E+03[/TD][TD]4.80E+03[/TD][TD]3.29E+06[/TD][TD]9.92E+06[/TD][/TR][TR][TD]Comms DTS[/TD][TD]2.26E+09[/TD][TD]3.29E+06[/TD][TD]2.26E+09[/TD][TD]6.81E+09[/TD][/TR][TR][TD]Comm. 88-88[/TD][TD]2.05E+10[/TD][TD]9.92E+06[/TD][TD]6.81E+09[/TD][TD]2.05E+10[/TD][/TR][TR][TD]KSC1[/TD][TD]4.80E+07[/TD][TD]4.80E+05[/TD][TD]3.29E+08[/TD][TD]9.92E+08[/TD][/TR][TR][TD]KSC2[/TD][TD]2.26E+11[/TD][TD]3.29E+07[/TD][TD]2.26E+10[/TD][TD]6.81E+10[/TD][/TR][TR][TD]KSC3[/TD][TD]7.12E+12[/TD][TD]1.85E+08[/TD][TD]1.27E+11[/TD][TD]3.82E+11[/TD][/TR][/TABLE]

Great Scott! AntennaRange has been updated to 1.9.1, which fixes the crash-to-desktop that was reported and fixed in dev builds a week ago, but I forgot to release officially. Z-Key Aerospace, this fixes the issue you're reporting. My bad! A few other features we've been talking about are in here, too. Note that geometric ranges and the associated rebalance are NOT being released in this build. That needs more playtesting first. If you want it released, playtest! CHANGELOG: v.1.9.1 [2015-06-02] * Improved "circular relay" detection to avoid infinite loops. This fixes the crash to desktop / hangs forever issue. * No longer incorrectly checking for line of sight to Kerbin when the line of sight option is disabled. * Pretty lines can now be toggled on and off using the toolbar/applauncher icons in map mode. This is not a persistent change. * Made the network resolution update delay configurable, from 8 ms to 2.5 s.

So if my little orbital modeling script is correct, the maximum distance between Kerbin and Duna at ideal transfer arrival and departure points is about 20.6 Gm. That's not a whole lot shorter than 3.52 Gm, especially after padding it by 10% for people who aren't right on the money. Here's a (stock) pass using a synodic requirement for DTS+KSC2, and giving the 88-88 a little extra range, and allowing it to do Jool missions with a KSC2: [TABLE][TR][TD][/TD][TD]From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]To↓[/TD][TD][m][/TD][TD]4.80E+05[/TD][TD]2.26E+09[/TD][TD]2.05E+10[/TD][/TR][TR][TD]Comm. 16[/TD][TD]4.80E+05[/TD][TD]4.80E+05[/TD][TD]3.29E+07[/TD][TD]9.92E+07[/TD][/TR][TR][TD]Comms DTS[/TD][TD]2.26E+09[/TD][TD]3.29E+07[/TD][TD]2.26E+09[/TD][TD]6.81E+09[/TD][/TR][TR][TD]Comm. 88-88[/TD][TD]2.05E+10[/TD][TD]9.92E+07[/TD][TD]6.81E+09[/TD][TD]2.05E+10[/TD][/TR][TR][TD]KSC1[/TD][TD]4.80E+07[/TD][TD]4.80E+06[/TD][TD]3.29E+08[/TD][TD]9.92E+08[/TD][/TR][TR][TD]KSC2[/TD][TD]2.26E+11[/TD][TD]3.29E+08[/TD][TD]2.26E+10[/TD][TD]6.81E+10[/TD][/TR][TR][TD]KSC3[/TD][TD]7.12E+12[/TD][TD]1.85E+09[/TD][TD]1.27E+11[/TD][TD]3.82E+11[/TD][/TR][/TABLE] Edit: If you want to try it, here are the relevant parts of the cfg: http://hastebin.com/etoyabufez.c Edit2: It's worth saying that you'll be very disappointed with that config if you don't have the dev build from page 60.

Edit: Ninja'd by dudecon Currently, all of Kerbin's surface is a "ground station". Any antenna with a positive range at least as long as the vessel's height will have a connection. What Kerbas_ad_astra means is that, in a potential optional future feature wherein transmissions must optionally be made to specific locations on Kerbin's surface, we could allow ground stations to be built by calling vessel that is "landed" (or maybe "splashed down?") on Kerbin a "ground station" and therefore viable target for transmissions. You do not need an orbital network to communicate to things at various points on Kerbin. That's an interesting concept, and it could give a bit of extra meaning to getting the T3 tracking station upgrade: you could wake up all your probes on Duna at "odd" times of the cycle.

So something like the middle ground I mentioned would be generally to your liking, John Nowak? And it's acceptable in general that the stations would be entirely ethereal and have no actual, physical presence in the world?

So, even considering OPM, it's hard to separate the DTS and 88-88 enough. [TABLE][TR][TD][/TD][TD]From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]To↓[/TD][TD][m][/TD][TD]4.80E+05[/TD][TD]3.27E+09[/TD][TD]3.82E+10[/TD][/TR][TR][TD]Comm. 16[/TD][TD]4.80E+05[/TD][TD]4.80E+05[/TD][TD]3.96E+07[/TD][TD]1.35E+08[/TD][/TR][TR][TD]Comms DTS[/TD][TD]3.27E+09[/TD][TD]3.96E+07[/TD][TD]3.27E+09[/TD][TD]1.12E+10[/TD][/TR][TR][TD]Comm. 88-88[/TD][TD]3.82E+10[/TD][TD]1.35E+08[/TD][TD]1.12E+10[/TD][TD]3.82E+10[/TD][/TR][TR][TD]KSC1[/TD][TD]4.80E+07[/TD][TD]4.80E+06[/TD][TD]3.96E+08[/TD][TD]1.35E+09[/TD][/TR][TR][TD]KSC2[/TD][TD]3.78E+11[/TD][TD]4.26E+08[/TD][TD]3.52E+10[/TD][TD]1.20E+11[/TD][/TR][TR][TD]KSC3[/TD][TD]1.94E+13[/TD][TD]3.05E+09[/TD][TD]2.52E+11[/TD][TD]8.61E+11[/TD][/TR][/TABLE] Here's a pass that basically says "let's make 88-88 + KSC3 a complete win, and talk to Plock with 88-88 + KSC2": [TABLE][TR][TD][/TD][TD]From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]To↓[/TD][TD][m][/TD][TD]4.80E+05[/TD][TD]3.27E+09[/TD][TD]1.95E+12[/TD][/TR][TR][TD]Comm. 16[/TD][TD]4.80E+05[/TD][TD]4.80E+05[/TD][TD]3.96E+07[/TD][TD]9.67E+08[/TD][/TR][TR][TD]Comms DTS[/TD][TD]3.27E+09[/TD][TD]3.96E+07[/TD][TD]3.27E+09[/TD][TD]7.99E+10[/TD][/TR][TR][TD]Comm. 88-88[/TD][TD]1.95E+12[/TD][TD]9.67E+08[/TD][TD]7.99E+10[/TD][TD]1.95E+12[/TD][/TR][TR][TD]KSC1[/TD][TD]4.80E+07[/TD][TD]4.80E+06[/TD][TD]3.96E+08[/TD][TD]9.67E+09[/TD][/TR][TR][TD]KSC2[/TD][TD]3.78E+11[/TD][TD]4.26E+08[/TD][TD]3.52E+10[/TD][TD]8.59E+11[/TD][/TR][TR][TD]KSC3[/TD][TD]3.63E+13[/TD][TD]4.17E+09[/TD][TD]3.44E+11[/TD][TD]8.41E+12[/TD][/TR][/TABLE] In both of these models, DTS + KSC3 is longer range than 88-88 + KSC3 in the current dev build. In general I think both of these concepts are too much for stock KSP. Can we do something about DTS+KSC2?