Search the Community

In Low Kerbin Orbit, the green line indicating the comm link always goes vertically down from my craft into the ocean or land directly below it. This happens with both a rocket and a spaceplane, so I don't think it's a problem with the vehicle. I'm running Windows x64 version 1.2.2.1622 . I start a new game in sandbox mode. "Enable Comm Network" is checked (green), and I check "Require Signal for Control" and "Plasma Blackout". I uncheck "Enable Extra Ground Stations". In earlier games the lines went to the nearest ground stations, but I don't know what caused the change. I added and upgraded a bunch of modes when I decided to try Kerbalism. I'm hoping it's just an option I can change, rather than having to start with a fresh install and add mods one at a time. [ Update: A fresh install from my zip file with no mods works as expected. CommNet links to nearest ground station. If I turn off extra ground stations, then link breaks when vessel is out of range of KSC, as expected. Guess I'll start adding mods to see if/when it breaks. ]

This is a new game compared to my KSP 1.0.5 career thread. Some things have changed in KSP 1.2, some mods are no longer available, and other mods have come into existence. Plus, there's the new features that KSP 1.1 and 1.2 brought. The newest mod that I'll be using is one of my own creation called Stock Antenna Balance. It's basically a lite version of RT that works solely through modifying the antenna power / mass / cost / energy requirements of Squad's stock antennas. It puts a larger emphasis on relay satellites as the direct-connect antennas can no longer reach back from Eeloo to Kerbin. All the magic is done through ModuleManager patches so it reuses existing components that Squad (or others) have provided. I also use some welded parts created through UbioZur Welding Continued, which are then modified to have the storage capacity that I want, or add USI-LS storage, or tweak costs / dry mass or other things. The welded parts are maintained at my GitHub repository. Selective use of welded parts helps reduce wobble and part count. The third is a set of MM patches that creates modified versions of Squad, Modular Rocket Systems, SpaceY, or other parts to add things like battery capacity, USI-LS storage. This is mostly done to reduce part count and these new or modified parts have mass / costs increased to balance out the additional capabilities. Current list of addon DLLs (from KSP.log): kOS.Safe v1.0.3.0 kOS v1.0.3.0 CCK v1.2.1.0 CLSInterfaces v1.0.0.0 ContractConfigurator v1.0.0.0 / v1.22.2 ContractParser v1.0.5.0 / vv5.0 ContractsWindow.Unity v1.0.7.2 ContractsWindow v1.0.7.2 / vv7.2 DMagic v1.3.0.6 / vv1.3.6 DockingPortAlignmentIndicator v1.0.0.0 DPAI_RPM v1.0.0.0 Firespitter v7.3.6195.32439 HaystackContinued v0.5.2.1 ICSharpCode.SharpZipLib v0.86.0.518 / v0.86.0 KerbalAlarmClock v3.8.3.0 KerbalJointReinforcement v3.3.1.0 KolonyTools v1.0.0.0 Konstruction v0.0.0.0 kOS.Safe v1.0.3.0 kOS v1.0.3.0 KSPRescuePodFix v1.0.0.0 MechJeb2 v2.5.1.0 / vDev #675 Sarbian / v2.6.0.0 MiniAVC v1.0.3.2 ModuleDockingNodeNamed v1.0.0.0 ModuleManager.2.7.5 v2.7.5.0 ProgressParser v1.0.6.0 / vv6.0 SCANsat v1.6.0.11 / vv16.11 ShipManifest v5.1.3.1 SmartParts v1.7.0.0 USILifeSupport v1.0.0.0 USITools v1.0.0.0 [x] Science! v5.4.6185.40021

I have 6 relays at altitude of 7000km above Kerbin, all equidistant from each other. Because I'm still working my way up the tech tree in this career game, I only have HG-5 to use as relays, but each of my satellites have 16 of them. (They form a lovely flower when extended...) Anyway, I have a ship at Mun, and this is what the path through the network looks like the picture below. You can see that the ship has a weak link to the first satellite with a direct path to KSC, giving me only 13% signal strength. I thought that the path with the overall best signal would be the path I drew in orange. Did I misunderstand how multi-hop signal strength is calculated, or does CommNet pathfinding not take signal strength into account? Edit: Hmm. After a while it's using the path I expected it to take. Perhaps it takes a while to recalculate... Anyway, how does one delete a forum post?

Hi, I figure I can post my notes about KSP's CommNet, given the namespace of CommNet is sort of large to sift through and no one has posted on CommNet yet. Organisation of KSP CommNet The entire CommNet feature is mainly consisted of CommNetUI, CommNetwork and CommNetVessel, along with a bunch of support classes and data structures CommNetUI is the user interface where a player is seeing and interacting with. This class has the method of interest, UpdateDisplay(), which draws every connection and shows/hides some or all connections, depending on the mode (FirstHop, VesselLinks, Network etc) the player selected. CommNetwork is subclass of the abstract class, Net, which is data-oriented class itself with multiple lists of different types, such as Link, Data and Occluder. This CommNetwork class manages and operates a global network of all CommNode (vessels) and CommLink (connections) objects. For example, the potential connectivity of a pair of two vessels is tested by SetNodeConnection() according to the connection and range rules. Every vessel (Debris, Rover, Flag etc) has the variable 'connection' of CommNetVessel class. This class has a number of methods that are releated to the vessel itself. For example, the class's CalculatePlasmaMult() calculates the multipler of the radio blackout of the reentrying vessel. CommNetScenario is responsible for starting up the CommNetwork and CommNetUI and disabling/enabling CommNet according to Game's settings. Support CommNet class CommNetNetwork seems to be a service layer where vessel and body data are added to and removed from CommNetork. It regularly fires a chain of health-check events for the CommNet. Relevant data structures of the CommNet CommNetHome is a ground station, whose data includes the body, alt, lat and lon. CommNetBody is a celestial body, whose occluder is supplied for CommNetwork to check if the connection is occluded between two vessels. CommNetVessel is a data structure attached to every vessel, even a debris (of course it is null). It has an unused variable of signalDelay, presumed a little gift for a certain mod. It also has a number of network-processing methods you can override: OnNetworkInitialized(), OnNetworkPostUpdate(), OnNetworkPreUpdate() and UpdateComm(). CommNode is analogous to a node of a graph. It has some information about antennas, remote-control capability. It is stored in the CommNetwork. The class conveniently provides a comparer, IEqualityComparer<CommNode>. Likewise, CommLink is analogous to an edge of a graph. It contains some information about the vessel-pair connection, such as the signal strength, relay capability of each node. CommPath, implied by its name, is a order-sequence of CommLink. How to substitute KSP's CommNet for your own CommNet Subclass CommNetUI to write your interface Subclass CommNetwork to create your own connection rules Subclass CommNetScenario to replace the KSP's stock CommNetwork and CommNetUI instances with your own subclasses above. You can also override OnLoad and OnSave for your CommNet data. You will need the KSPScenario tag to let KSP know it should run your CommNetScenario subclass instead of the stock CommNetScenario. Subclass CommNetVessel to write your communication behaviour for each vessel. KSP will automatically substitute the stock CommNetVessel for yours. Bug (Squad is aware of this now): CommNetNetwork class has the hard-coded CommNetwork instance in ResetNetwork() so subclass this class to fix it and then replace it in your CommNetScenario subclass (via reflection, singleton or FindObjectOfType)

Hi, first I should mention that I am running a rather heavily modded install. Still my problem is with mechanics from the stock game. I am using the Galileo plent system. I sent a probe to the second moon (Ceti). This probe has some siency stuff on it and is also supposed to function as a relay. For this purpose it is fitted with an HG-5 High Gain antenna (this is the only "real" antenna on it). This probe is orbiting in a circular, polar orbit at abit 200km (it was supposed to go to a higher orbit but ran out of fuel). So now I launch a second probe. A lander this time. This one has a Communotron 16 on it. Unfortunatly I forgot to activate the antenna after my transfer burn (at the time the built in antenna in the probecore was enough). So after a while I lose the connection... but I think to myself not all is lost... I still have the probecore antenna and the relay... that shoudl fix things for me... right? But when the lander gets closer to the relay it does not establish a connection. So in short... a probecore antenna does not connect with the relay... How do I have to design a relay so that it will actually do its job? Do the probecore antennas not work with relays? Does a relay have to have multiple antennas?

Not sure if this is a bug or what, but the "HG-5 High Gain Antenna" seems to be no good for contracts Bug or not? I don´t really think its a bug, but i can´t see anything else thats wrong... Edit: Just checked the part´s description. It specifically says it does direct transmissions...

(pinging @DMagic for comments as he clearly has extensive knowledge on icons like this post) More particularly, I am trying to colorize a vessel's map icon in the tracking station or mapview scene. Here're the codes below that I got to work but... //You should be able to use MonoBehaviour to run the codes related to MapNode during Update() public class CNCCommNetUI : CommNetUI { MapObject m_MapObject; public CNCCommNetUI() { base.colorHigh = new Color(0f, 0f, 1f, 1f); // blue connections } protected override void Start() { base.Start(); GameEvents.onPlanetariumTargetChanged.Add(OnPlanetariumTargetChanged); } protected override void UpdateDisplay() { base.UpdateDisplay(); //attempt to access vessel's map sprite //m_MapObject is of MapObject class, obtained from 'private void OnPlanetariumTargetChanged(MapObject mapObject)' MapNode mn = m_MapObject.uiNode; MapNode new_mn = MapNode.Create(mn.mapObject, new Color(0f, 0f, 1f, 1f), 512, mn.Interactable, mn.Pinnable, mn.InputBlocking); // try to colorise the grey icon as blue m_MapObject.uiNode = new_mn; } private void OnPlanetariumTargetChanged(MapObject mapObject) { if (mapObject == null) { return; } switch (mapObject.type) { case MapObject.ObjectType.Vessel: CNCLog.Debug("OnPlanetariumTargetChanged: Vessel: " + mapObject.vessel.vesselName); m_MapObject = mapObject; break; } } } The relay icon somehow turns into the different icon of an unknown type (generic?), and remains un-colorised. The MapNode class (decompiled by VS's ILSpy addon) has a confusing maze of methods like NodeUpdate(), Terminate() etc. Does anyone know how to solve this puzzling question?

Internal antennas aren't combinable and can't be used for transmitting science (or relaying signals) - their only purpose is to provide short-range control to unmanned craft. It makes sense that probe cores would include an internal antenna, but why command pods? If you have a command pod with a kerbal inside, then the kerbal provides control and the pod's antenna provides no benefit. If you have a command pod without a kerbal inside, then you're not going to have control even though you have an internal antenna - unless you have a probe core as well, in which case you can just use the probe core's internal antenna. Either way, the pod's antenna still provides no benefit. So why include the antenna module in command pods at all? Is there any circumstance in which it would have any meaningful functionality?

Just loaded 1.2, started Career from scratch for the challenge, and after a few Mun/Minmus missions, I thought I would send a one-way probe with a parachute to Eve. Unlocked the OCTO with SAS, all set up, broke Kerbin SOI en route to Eve and.... poof, it's gone. So, I have the Tracking Station fully upgraded, and a station in orbit with the base repeater antennas. Everything has LOS, but the table on this page: http://wiki.kerbalspaceprogram.com/wiki/CommNet ... says basically I can't control a probe around Eve or Duna until I unlock the DTS-M1 (PrecEng). By the time I unlock those, it's easier to send a manned mission. Going further than Eve/Duna requires a higher level unlock, by then I'll be sending manned missions on those as well. It seems that CommNet does nothing but kill / make it more difficult to use interplanetary probes. Am I missing something?

Previously I had expressed some grievances regarding the way that KSP handles signal strength and data transmission. After some time with my nose buried in information theory books and 30 year old PDFs about the DSN, I propose an improved system that is a little more realistic, but not too technically challenging. First, the concept of bands. The DSN is capable of operating in several bands, and these are; L-band (1-2 GHz) S-band (2-4 GHz) X-band (7-11 GHz) and more recently Ka-band (26-40 GHz) Lower power bands are available earlier in career mode, and the Tracking Station is capable of operating on higher energy bands with upgrades. Also included with the L3 station would be the ability to use a 500 GHz infrared laser communicator (with a new part or 2), which would provide a wide-band long-range communication link with properly equipped vessels. Higher power bands provide more bandwidth and less distance attenuation, but have higher energy costs per mit. Early antennae would only be able to utilize the L-band, but with the as-yet unimplemented part upgrade system they would be available to use a higher power band with the proper tech (eg, the Communotron 16 family would be L-band only at unlock, but could be upgraded to use the S-band later on). The late-game antennae would be capable of utilizing all bands, but only one at a time. This would be selected during vessel construction via the context menu, and would be fixed at launch. Each antenna also has 2 qualities (for determining signal) for each band. The first is the transmitter power measured in decibel-milliwatts (dBm), and the second is the antenna gain (also in dBm). The antenna also has a noise power, but this is independent of the band used. The tracking station also has these qualities for each band as well as a 'nominal bandwidth' value (~1-10Hz, except for the laser communicator which would be in the high kHz range), and upgrades will adjust the values to optimize for increased communication bandwidth and longer-distance communication (ie, higher power, higher gain, less noise power). Working with real-world values is difficult in KSP because of the reduced system size, but I have here a worked example with some conceptualized values. Before we get started, here is a quick unit conversion: dBm = [10 * log(W)] + 30 (watts to decibel-milliwatts) W = 10 ^ ([dBm + 30] / 10) (decibel-milliwatts to watts) Tracking Station: Level 1 L-band transmit/receive Gain: +50 dBm gain is directly proportional to the square of the antenna diameter and inversely proportional to the square of the wavelength Power: 30 kW = +44.8 dBm power is simply the transmitter power, a 'chosen' value Noise Power: 4.00e-20 W or -173.9 dBm thermal interference on the receiving end. directly proportional to bandwidth and dependent on the boltzmann constant Bandwidth: 10 Hz Bandwidth choice is arbitrary (read: defined by the hardware), but is usually higher on manned missions in cis-munar to allow for direct voice transmission. Unfortunately, this isn't a modelable feature so the bandwidth should stay low to keep the noise power down. Communotron-16 in Mun orbit, L-band transmit/receive Gain: +3 dBm Power 0.1W = -10 dBm Noise Power: 1.38e-20 W or -176.8 dBm Munar orbit is ~11.5x10^6 m from kerbin (give or take), so distance attenuation is calculated by: l^2 / (4*pi*r)^2 Where l is the wavelength and r the distance (units of meters, result is in watts). L-band has a wavelength of ~20cm (0.2m), so this equation evaluates to ~2.7e-10 W or -95.6 dBm To calculate received power, simply add the transmit power, the gains of the transmitter and receiver, and the distance losses. Uplink Signal: 50 dBm (station) + 3 dBm (probe) + 44.8 dBm (station power) -95.6 dBm (distance loss) = 6.5 dBm or 4.6 Watts received at Mun Downlink Signal: 50 dBm (station) + 3 dBm (probe) -10 dBm (probe power) -95.6 dBm (distance loss) = -48 dBm or 0.000015 Watts received at KSC Now, we can calculate the signal-to-noise ratio (SNR) for the uplink and downlink, and this is done by dividing the signal by the noise power of the receiver. Note that this has to be done in Watts because of the logarithmic nature of the decibel system. Uplink SNR = 4.6 W / 1.38x10^-20 W = 3.33e20 Downlink SNR = 1.5x10^-5 W / 4x10^-20 W = 3.75e14 Using the Shannon-Hartley theorem, we the calculate the maximum bitrate at which information can be exchanged across the link. This bitrate is used for determining probe control on the uplink side, and for determining data TX rate on the downlink side. C = B * log(1+SNR)/log(2) where C is the bitrate, B the available bandwidth, and log the logarithm base 10. This equation can be simplified by taking the numerator and using a logarithm base 2 without the denominator, but I figured I'd put it in calculator-friendly mode for those of you who don't know how to do change of base. Using this, we calculate our max bitrate in each direction: Uplink bitrate = 10Hz * log(1+3.33e20) / log(2) = 681 bits/s Downlink bitrate = 10Hz * log(1+3.75e14) / log(2) = 484 bits/s As you can see, these numbers are pretty small compared to modern communication standards, but they are probably within an order of magnitude or two of the balanced values. According to wikipedia (nb: not-necessarily reputable source) the 20W transmitter on the Apollo LM could support a 56 kbit telemetry link or a 1.6kbit backup link, ergo the base values for power, noise, and gain require a bit of tweaking (especially for the higher power bands). As mentioned above, the downlink bitrate determines the rate at which science can be transmitted. This requires a re-scaling of the 'mit', as these rates could transmit any experiment in less than a tenth of a second, however the 'mit' system seems to be arbitrary right now so this isn't a huge deal. The uplink bitrate would determine whether a probe was controllable or not - too low of a bitrate (set arbitrary value here) and the probe can't effectively receive commands from ground. Alternatively, a minimum receive power could be used as the limiter rather than bitrate - this would allow the player to calculate probe controllability a little easier. The actual transmission system works like so: Antenna also have a 'power per mit' value, which depends on the band being utilized. Higher power bands require more EC/mit, but due to the difficult task of converting EC to Joules (EC/s to Watts) I haven't run any numbers here. The rough estimate I've seen is 1EC = 1kJ (1EC/s = 1kW) but I'm not sure how well this is balanced. The transmit bitrate for an antenna would be tweakable by a percentage slider; this allows the player to continuously transmit data at a slower rate than maximum which may be necessary do to electrical constraints. For use with relays, each link would have a bitrate calculated, and the lowest bitrate would be the bitrate for the channel. When a probe desires to transmit data to KSC, the downlink bitrate is calculated and a 'long action' similar to how the MPL works begins. The antenna begins transmitting data at the calculated downlink bitrate times the percentage slider (and consuming EC at a proper rate), and science will either 1) begin to accumulate at KSC until all the data goes through OR 2) build up in the antenna until it has all been 'transmitted', from which another action made on the antenna will 'commit' the science to KSC. The former would be ideal, but I'm not sure how KSP would take to incrementing the science over time, especially through warp. On the player end, they would require a signal distance attenuation table for each band, and the would simply sum the tracking station gain, probe gain, the loss in the table, and the transmitter power to get a received power. The bitrates would be calculated under the hood, and be displayed on the probe antenna's context menu. Send and receive power would be displayed in the current signal strength bar next to the chronometer. The purpose of this redesign is simple: to increase realism in the science process. Yes, the 'unlock points' system has its flaws, but that doesn't mean the transmission system has to be garbage as well. The New Horizons probe took over a year to broadcast all of the data it collected at Pluto, and the Voyager probes still have a non-zero downlink bitrate (~200 bits/s IIRC). Why can I send back all my data from Jool at lightning-speed? Separating the uplink and downlink signals also allows us to create one-way links, for what that's worth - another realistic scenario that the current system cannot simulate. tl;dr: The CommNet mechanics are trash and it wouldn't take much effort to make it better.

So: I'm adapting well to the new CommNet, but there's something I don't quite understand. The right-click context menu for antennae while in flight reveals two or three buttons depending on the antenna. "Extend Antenna" and "Transmit Data" buttons are pretty self-explanatory, but there's another that has me befuddled: "Require Complete". I've found no explanation in any of the documentation so far on what this button is or what it does. Can anyone satisfy my curiosity about this? What does the "Require Complete" button do?

Hi everyone, I am playing a modded career in the new 1.2 version and I've set the difficulty to hard with no groundstations and about 0.25 DSN power in order to encourage me to build a communication network. Now in my early career I only have the HG-5 antenna to use as a relay, however it doesn't seem to work: I've launched a set in keo-stationnary orbit at an angle from KSC so it always has signal, yet it doesn't seem to be able to transmit anything. When my other probes are behind Kerbin and do not receive signal from KSC anymore, my relay doesn't do anything even when there's a direct link between the two sats. Here's the way it's set up now : the sat and its orbit

Hello everybody, A few days ago I migrated from 1.1.3 to 1.2. I discovered that in my legacy saves (that is, saves I created in 1.1.3) every probe that has one of the new relay antennae attached doesn't show up in the tracking station (ones with direct antennae do), and therefore can't be switched back to once one has switched from the probe to the Space Center after launch. After I uninstalled all mods the problem in the old save persisted. However, in a new sandbox save, the probes with relay antennae did show up as expected. To test the issue I built three identical rovers (one with a direct antenna, one with a relay antenna, and one with both) in each save and launched them. I included the logfile (in the file the save in which it worked is above the one where the problem occurred). Does anybody know if there is a chance to fix this issue for my old savegames from 1.1.3? I'd hate to start all over...again. Logfile - Dropbox-Link

I'd like to place some relay satellites in-line with points L4* and L5* in front of and behind the Mun. Assuming the usual 60 degree difference, how should I calculate the angle required from my parking orbit around Kerbin (usually 150km) to burn for an apoapse and reach either point at the correct angle? Thanks! *Emulated. Yes, I know; don't remind me. Single body physics.

I'm designing a return probe for Laythe and doing trials on Kerbin. My problem is, shortly after launch, at roughly 50-60k altitude, it loses contact with KSC, going instantly from maximum signal to zero. I have a surface-mounted Mk 16 antenna on it, which has not been destroyed by aero forces. I have a direct line of sight to KSC (level 2 tracking station). Contact isn't re-established once it's out of the atmosphere so it can't be plasma-induced comms blackout either (and I'm not going that fast anyway). So... what gives? Why am I losing contact?

I've been using a simple spreadsheet that calculates orbital heights and resonate orbits with same for dropping off equally spaces satellites to use as a commnet. Decided to convert the spreadsheet to google docs and make it available to the public here. https://docs.google.com/spreadsheets/d/1SJcB8x4P4t25jtWR-0TS-06R8Dq5OSslS5R964H32UM/edit?usp=sharing The sheet is only lightly protected in that you'll get a warning if you attempt to modify a field that I didn't intend on having modified. The cells that are intended on being modified have yellow backgrounds. Additionally, the sheet displays the synchronous orbital altitudes for each planet and moon (background goes red if the orbit is beyond the SOI of the planet or moon) and additionally, gives a "holding altitude" if you wish to precisely position a synchronous satellite over a specific location on the planet. For instance, let's assume you wish to have a synchronous satellite directly over the launch pad at KSC. The longitude for that launchpad is at 74°33'27" W. Using the spreadsheet, you can see the "Target Underneath" row and get your satellite into a circular orbit with an altitude of 10,343,473 meters. Then wait until you're directly over KSC. Once that happens, perform a retrograde burn to drop your periapsis to 2,862,940.708 meters and when you reach periapsis, circularize your orbit and you should be positioned directly over KSC. If 10,343 kilometers is inconveniently high (after all, it's high enough to be captured by the Mun), you can put a non-zero integer value into the extra orbits cell and instead of circularizing the first time you reach periapsis after your retrograde burn, you add in the number of extra orbits you specified. For instance changing extra orbits from 0 to 1 changes the holding orbit altitude from 10,343 kilometers to 5,673 kilometers. The bottom of the sheet has the calculations for the resonate orbit required to deposit satellites at a desired altitude. It performs the calculations for performing an insertion at the apoapsis of the resonate orbit or the periapsis of the resonate orbit. Just get your bus into the proper orbit and then release and circularize each satellite when the bus reaches the desired apoapsis or periapsis. In any case, suggestions and improvements are welcome.

I encountered an issue with a probe last night, wondering if anyone else has experienced it. I haven't played around yet to understand how repeatable the issue is. I had a probe on a fly-by of Mun, where it lost comms on the back side of the Mun. I time warped past this, and when comms came back, I stll had no control over the probe. (Comm's showed full signal, etc). Returning to tracking station, and reloading the craft fixed the problem. I encountered this again when trying to land the probe, time warping through the entering Atmo I passed through a ground station comm blackout spot, once in the atmo I had no control again, and the game wouldn't let me return to tracking station (without reverting to last save), and the probe crashed. Anyone else experienced this? Is this a known bug with the new comm system? My install is mostly stock (KER, Automated Science Sampler, Better Burn Time, MM (no scripts))

I'm having problem with communication, I have a HG-5 antenna on all of my satelite with only KSC as a ground station enabled. However my one satelite which is blocked by Kerbin and cannot talk to KSC is unable to talk to other satelites, why does this happen? http://imgur.com/j05BjlZ(screenshot)

So far I'm very happy with the commnet mechanic. There is one thing I'd ask of it, tho: the ability to remove completed (or missed, for that matter) maneuver nodes in partial control. That way, I can set multiple nodes in succession, hit the Maneuver Node pilot mode, do the maneuvers at full throttle and hit the green checkmark (or the red x if my maneuver wasn't goot enough - eh, you preprogrammed the probe and it didn't perform 100% as expected, life's harsh), and the ship will point to the next one.