[1.1.3] AntennaRange 1.11.4 - Enforce and Encourage Antenna Diversity

[Comm Cody]

How would I adjust another mod antennas so that they display the same behavior as stock antennas in this game?

I download Tantares, and the antennas in there do not have this behavior at all.

[Mecripp]

How would I adjust another mod antennas so that they display the same behavior as stock antennas in this game?

I download Tantares, and the antennas in there do not have this behavior at all.

Found the parts cfg open it with notepad or any text editor

@PART[[COLOR="#FF0000"]YOUR_NAME_HERE[/COLOR]]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		[COLOR="#FF0000"]nominalRange = 1500000             // <---------------------------- Change to what you want or leave them
		maxPowerFactor = 8                                             
		maxDataFactor = 4[/COLOR]
	}

	MODULE
	{
		name = ModuleScienceContainer

		dataIsCollectable = true
		dataIsStorable = false

		storageRange = 2
	}
}

EDIT- Some one has posted setting for that mod before and thought there was even a post in that thread, I had some but there very old and know, There are some new ones.

Edited May 25, 2015 by Mecripp2

[vardicd]

The new version seems to be working for me, although in a whole-y unrelated note, I've just managed to lose my entire save.

{Thou shalt never attempt to edit thy persistence file whilst game is running, under pain of Kraken-ing.}

:( :(

[toadicus]

vardicd, that's why I keep routine backups of my saves folder. Bummer!

[vardicd]

vardicd, that's why I keep routine backups of my saves folder. Bummer!

I usually do too, just cleared them out today by accident.

[dwerntz]

It seems that even when "Require Line of Sight" is not selected it's still enforcing line of sight for my space craft. I noticed this in 1.8 as well. On a semi related note, the settings window says it's 1.8 even though I deleted the old folder completely from gamedata and installed 1.9.

[Mecripp]

You might try deleting your MM caches files and see if it helps.

[dwerntz]

Even with a fresh install (KSP folder nuked from orbit) and only antenna range installed (along with hyperedit) it's still acting the same way.

[Hyomoto]

@Toadicus - I don't know exactly how complicated or interesting you'd like to make this, but let me ramble a bit in case it turns out useful! I assume you are using something like Dijkstra's algorithm or a brute-force search to find connections between satellites, but have you considered spreading this search out over a wide time frame? I'm sure you have to do this to some extent, but as the most recent test showed, a high density constellation can wreak havok. So, I suggest a sort of 'searching for signal' state for a ship/satellite indicated by a flashing Antenna Range icon. During this time it is pinging all satellites within range who report whether or not they have a path back to Kerbin, and caches the results. Depending on network traffic this might be quick, or if a lot of satellites are in this state, it might take much longer. Once it finds one that reports a path back to Kerbin, it applies a timestamp and a reliability rating. The rating is basically an 'uptime', how often, when asked, it has been a successful path. When it comes time to recalculate, it can priority search reliable and known good connections first and dump any low reliability, missing or just ignored options. This should avoid, to some degree, complex constellations going 'bananas' and in it's own way rewards building said constellations since high reliability connections back to Kerbin are prioritized over jumping across random craft.

I suggest suspending operations during high time warp, as a drawback a lot of ships might have to drop into searching for signal once you've exited, but any high traffic zones: ie: constellations, should come back online quickly enough that it would be a minor nuisance if at all.

Edited May 26, 2015 by Hyomoto

[toadicus]

dwerntz, and anyone else noticing that LOS is required whether you ask for it or not, give this build a shot: [zip] [tar.gz] [tar.xz]

Hyomoto, individual resolution searches don't traverse the entire network at all; I use a "lazy" resolution that naturally takes up to "D" frames to resolve, where "D" is the number of relays in the longest chain that must all depend on the next one in line. The basic method goes like this:

1. Once per "frame" (runs in Update, but rate-limited to about 60 searches per second), the network manager loops through all of the vessels and tells their "best" relay to find its connection status. "Best" relays are determined for each vessel the first time they're visited and cached; this cache is dump in response to a variety of events.
   
2. All relays start the game assuming they cannot transmit.
   
3. Per relay, status resolution runs more-or-less thus:
   
   1. Loop through all vessels
      
      1. If the current vessel is of an invalid type (asteroid, debris, etc), throw it out and restart with the next vessel.
         
      2. If the current vessel is the vessel we're currently resolving, throw it out and restart with the next vessel.
         
      3. If the current vessel is not in line of sight, check it if is the closer than the last occluded vessel (or infinity). If so, stash it and the body that's blocking it, and restart with the next vessel.
         
      4. If the current vessel is closer than the next closest vessel in line of sight (or infinity), otherwise throw it out and restart with the next vessel.
         
      5. If the current can transmit (this is not a recursive check), check if using it would result in a circular relay. This walks up the chain to see if the current relay's target, or it's target's target, or it's target's target's target, etc. are on the same vessel as the relay we're resolving. if it is, throw it out and restart with the next vessel. If we've taken a number of steps in our circular relay check greater than the total number of vessels, we're clearly looping back around because of some undetected problem, so throw it out and restart with the next vessel.
         
      6. If we've made it all the way here, this is the most eligible target. Stash it and restart with the next vessel.
         
      7. When we've gone through all the vessels, we should have one or both, or neither of a stashed blocked relay and a stashed eligible relay.
         
      8. Check any stashed eligible relay to see if it's in range for transmitting and closer to Kerbin. If so, target it. If it's out of range but Kerbin's not, target Kerbin.
         
      9. If there is no stashed eligible relay and Kerbin is out of range, pick between Kerbin, the stashed blocked relay, and the stashed eligible relay, to decide which one is the "next best" option for displaying a target even when disconnected.
         
      10. When this is done, the relay has cached: whether or not it can transmit, whether or not it is transmitting to Kerbin, what relay it is targeting (if any), what relay is the best relay without line of sight (if any), and what body is blocking that relay (if any).
          
          
      11. Move on to the next vessel.
          
          So let's think about a quick example with five vessels.
          Vessel 1 has a long range Antenna and is in solar orbit with an unobstructed view of Kerbin and Vessels 2, 3, 4, and 5. All other relays are out of range of Vessel 1, but it is in range of all of them (this sort of inconsistent behavior will change when we allow additive ranges).
          Vessel 2 has a medium range Antenna and is in a low, equatorial Munar orbit on the "far side" of the Mun. Kerbin is blocked from view, but Vessel 5 is not.
          Vessel 3 has a short range Antenna and is on the surface of the "near side" of the Mun. Kerbin and Vessel 5 are in view, but out of range. Vessel 2 is in range, but not in view.
          Vessel 4 has a short range Antenna and is on the surface of the "far side" of the Mun. Vessel 2 is in range and in view. Kerbin and Vessel 5 are out of range and out of view.
          Vessel 5 has a medium range Antenna and is in a high, inclined Kerbin orbit.
          
          • Before frame 1, all vessels report no connection.
            
          • In Frame 1, we check all vessels starting with vessel 1.
            
            • Vessel 1 finds no blocked relays, no eligible relays, but is in range of Kerbin, so it now reports it can transmit.
              
            • Vessel 2 finds a blocked connection to Kerbin and an eligible relay on Vessel 1. Vessel 1 is out of range and Kerbin is closer, so it targets Kerbin and reports no connection.
              
            • Vessel 3 finds eligible connections to Kerbin and Vessel 1 and no blocked eligible connections. Kerbin is closer than Vessel 1, so it targets Kerbin and reports no connection.
              
            • Vessel 4 finds a blocked connection to Kerbin and an eligible relay on Vessel 1. Vessel 1 is out of range and Kerbin is closer, so it targets Kerbin and reports no connection.
              
            • Vessel 5 finds eligible connections to Kerbin and Vessel 1 and no blocked eligible connections. Kerbin is closer than Vessel 1, so it targets Kerbin and reports it can transmit.

          [*]After Frame 1, we have green lines from Vessel 1 to Kerbin and Vessel 5 to Kerbin. We have red lines from Vessel 2 to Kerbin, Vessel 3 to Kerbin, and Vessel 4 to Kerbin.

          [*]Frame 2

          • Vessel 1 has no change.
            
          • Vessel 2 finds a blocked connection to Kerbin and an eligible relay on Vessels 1 and 5. Vessel 5 is closer and in range, so it targets Vessel 5 and reports it can transmit.
            
          • Vessel 3 finds eligible connections to Kerbin and Vessel 1 and a blocked eligible to Vessel 2. It can't transmit to any of them and Vessel 2 is the closest, so it targets Vessel 2 and reports no connection.
            
          • Vessel 4 finds a blocked connections to Kerbin and Vessel 5 and an eligible relay on Vessels 1 and 2. Vessel 2 is closer and in range, so it targets Vessel 2 and reports it can transmit.
            
          • Vessel 5 finds eligible connections to Kerbin and Vessel 2 and a blocked eligible connection to Vessel 4, but Vessels 2 and would cause a circular relay. Kerbin is still in range and view, so it targets Kerbin and reports it can transmit.

          [*]After Frame 2, we have green lines from Vessel 1 to Kerbin, from Vessel 5 to Kerbin, from Vessel 2 to Vessel 5, and from Vessel 4 to Vessel 2. We have a red line from Vessel 3 to Vessel 2.

If you imagine an EVA Kerbal on the ground next to Vessel 4, the Kerbal wouldn't resolve a connection until after Vessel 4 resolves in Frame 2 (which might be later in Frame 2, or early in Frame 3, depending on where the Kerbal is in the list of "vessels").

In practice, those two frames happen before the ship you loaded even starts drawing on your screen. You can notice the "lazy" in action when a relay that was a "destination" relay e.g. was making a link from a more distant relay to Kerbin becomes occluded; for 1 frame it will target Kerbin and report no connection and the previous "source" vessel will target Kerbin and report a connection, in the next frame it will target the previous "source" vessel and report a connection, resulting in a sort of "flicker" appearance.

This whole thing runs at O(n²), and not all checks are performed for every stop in the loop because I discard potential targets as aggressively as possible. Were I to do a path all the way back to Kerbin for each relay using something like Dijkstra's, I'm pretty sure it would be O(n³). But, by being lazy, I don't need to bother traversing the whole network for any given relay because momentary incorrectness on the order of 8-33 milliseconds is an acceptable delay for this kind of mechanic in this kind of game.

TL;DR: to answer "have you considered spreading this search out over a wide time frame?": yes.

The search will naturally resolve over the course of 1 or more frames as necessary based on the depth of the network. I have also considered spreading it over an even wider time frame, e.g. only running the check on one vessel per frame, effectively making the responsiveness of the network on the order of t * N * D, where "t" is the Update time in Unity (usually 8 to 33 milliseconds), "N" is the number of relays, and "D" is the depth of the longest chain in the network. For a game with 20 relays and a deepest chain of 4, that would put the worst-case resolution delay at around 2.5 seconds, whereas currently the delay is t * D. Relay chain depth is realistically limited to 3 or 4; it's very uncommon to see a chain longer than that for any reason (at least in my experience). I like a responsiveness on the order of 132 ms much better than 2.5 seconds.

It would be pretty easy for me to have relays go straight back to Kerbin if they can do so; basically just put the "can I talk to Kerbin?" check before the per-relay vessel loop instead of after, and skip the loop entirely if so. I could then resolve most networks in only slightly worse than O(n), because at any given time odds are good that most relays can talk straight back to Kerbin. But, I think people like seeing relays going through chains to talk to other relays on their way back to Kerbin -- even if it's not the most realistic representation, I think it feels more "fun". Since charge use isn't modeled on the other relays, the cost of a chain isn't really relevant.

In some respects, it would be cool to model charge use along the chain, and there are a few mod tools out there to do so, but it's a high-cost operation on my end for what feels like very little reward. Since transmission happens outside the simulation anyway (it's tied to real-time seconds, not simulation seconds), all it would really do is penalize the player by making them spin more at time warp waiting for the transmission to finish. That's already tedious, and I'd rather not make it more so just for the sake of "realism".

Questions for you: are you recommending such consideration because there is a change in behavior or performance you'd specifically like to see? Do complex networks cause your game to stutter or slow down? Are expensive-looking relay chains something you don't want to see? If so, why?

I'm absolutely happy to consider recommendations and requests, and hopefully this explanation helps interested parties to make such from a thoroughly-informed position. Remember that realism is not the end-all in this mod; playability is a higher concern. I'm trying to strike a balance between "easy but mindless" (like the stock implementation) and "realistic but tedious" (like RT, in my opinion). In general, I feel like that realism serves fun better than mindlessness until it turns into tedium.

Edited May 26, 2015 by toadicus

[garwel]

Hi, I have a strange issue with my ships disappearing after a couple seconds. AntennaRange seems to think they are uncontrollable even though they certainly should be fine (e.g., they are at low Kerbin orbit, with antennas).

[toadicus]

Hey garwel, can you get me 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) so I can take a look and see if I can tell what's going on? I've never experienced that sort of symptom before.

[dwerntz]

dwerntz, and anyone else noticing that LOS is required whether you ask for it or not, give this build a shot: [zip] [tar.gz] [tar.xz]

That did the trick! But the console still says 1.8. Thanks for the fix!

[garwel]

I found that it doesn't really disappear: in fact, it moves out of sight very very fast. Perhaps, the camera stops following the ship and instead focuses on the empty space where it was.

Log file

UPD: After this happens, something goes wrong with the Tracking Station view. All vessels disappear from it and buttons for filtering vessels move leftwards. And even the quit button (in the top right corner) stops working, so you have to shut down the app from Windows Task Manager.

Edited May 26, 2015 by garwel

[toadicus]

garwel, it looks like you've got an old version of ToadicusTools. Please update it from KerbalStuff or use the version bundled with AntennaRange.

[Mecripp]

HEHE bad garwel bad got update it all hehe on in fun

EDIT- I have done that many times lol

[garwel]

You're right, sorry. Thanks for the mod, by the way!

PS: Besides, I think it would be neater and more clear if the pretty lines were only drawn for the active vessel (at least in map mode, i.e. not in Tracking Station).

Edited May 26, 2015 by garwel

[KerbMav]

Aint the small dish a bit short in range for the big one to be relatively deep in the tech tree - even behind a R&D upgrade I think?

Being able to reach Duna - and farther inwards at the same time logically - with the second antenna available in stock seems to make sense?

Just a suggestion/question to understand your design decision.

[toadicus]

It might look cleaner, garwel, but I don't think it would be better. The whole purpose of the pretty lines system is to convey the state of your network at a glance. Users should be able to diagnose why their active vessel does not have a connection and make a judgement as to how best to correct the deficiency with the information presented. If you can't tell what other relays do or do not have connections, the latter isn't possible. Feel free to convince me otherwise, if you'd like.

KerbMav, I agree.

This is a whole different topic, but what would people think about using additive ranges for antennas, and cutting the big dish antenna range considerably? This would have one primary effect, and I'm considering it for a specific reason.

Basically, this would let you extend the range of a smaller but more distant antenna using a closer antenna. For example, you could send an orbital probe with a whip antenna to Mun as long as you had reasonably coverage over Kerbin with probes using medium dishes.

This would also let you send a mission to a distant planet, knowing that you won't be able to talk to it when it gets there... unless you get your science in gear and launch some Big Dish antennas before it finishes the trip.

I'm considering this particularly for the latter reason, in view of the point at which Squad starts offering contracts to Duna. I basically always get contracts to Duna long before I actually have the Electronics tech you need for the big dish. This means I can't even start the mission -- at least not if I want to get science for it, or if the mission requires science from Duna, or if I'm using "no probe control without connection".

In general, because of the huge differences between the antennas (since there's only three), I don't think this would change gameplay very much. The primary play change I'm thinking about is making the jump from medium dish to big dish less extreme, e.g.:

Communotron 16 -- Increase range to half of Kerbin's SOI, so it can be used for Minmus probes if you put a comsat with at least another Communotron 16 in orbit first.

Comms DTS -- Increase range to half of Duna's SMA + half of Kerbin's SMA. This would let the DTS be used for all "inner system" missions -- again, if you put at least another DTS in orbit first.

Communotron 88-88 -- Change range to something like 3/4 of Eeloo's SMA. This will reduce the overall range (currently about 2× Eeloo's SMA) when used in conjunction with another, and will require you to use another 88-88 nearer Kerbin to relay the signal. We could extend the range with ModuleManager magic when we detect the Outer Planets mod.

[KerbMav]

.

Seems a bit overcomplicated for something that was supposed to be a lighter version of RemoteTech?

I think we need more dishes.

[dudecon]

It might look cleaner, garwel, but I don't think it would be better. The whole purpose of the pretty lines system is to convey the state of your network at a glance... Feel free to convince me otherwise, if you'd like.

Could we get a checkbox in the config window for this? Then everyone wins!

I mean, except for you. 'Cause then you have to write more code, and seperate functionality, and check to see if the network connects to the active probe, and then retroactively disable drawing for the non-displayed lines, but still need to burn processor cycles for all of them in case they become active at some point. That sounds, to me at least, like loosing.

[toadicus]

KerbMav, I'm not sure what would be more complicated about it. As long as Kerbin's transmission range leveled up (either along with the tracking station, or as you unlocked new antennas), the actual functionality would be almost entirely identical. The benefit is that you can get extra use out of smaller antennas, i.e. by sending a whip to Duna and then receiving it with a dish (or your super-long range Kerbin station). In fact, it's so much similar that I question whether the code to make it work is worth writing.

I don't mind the idea of extra dishes, but I am not a modeler / animator. I'm also hesitant to add parts, because that means if you uninstall AntennaRange, your saves are all broken. As it stands, AntennaRange can be added and removed without consequence.

dudecon, the whole thing could be done in the line-drawing subsystem; instead of looping through the vessels and drawing for each one as applicable, start from the active vessel and walk down its chain to Kerbin. I'll think about it.

Edited May 26, 2015 by toadicus

[jpkerman]

If a player wants extra antennas there are ample extras in other mods and MM configs for most of them. I have five antennas from AIES and three from FASA added with ranges tweaked to give an overlapping progression up to the stock Comm 88-88 which covers the current stock system.

posted by toadicus: "... because that means if you uninstall AntennaRange, your saves are all broken. As it stands, AntennaRange can be added and removed without consequence."

Sorry, words appear to be English but they make no sense. 'Uninstall AntennaRange'????? Sorry, can not understand that concept. This mod is too vital to my Space Empire!

Edited May 26, 2015 by jpkerman

[Fraz86]

In general, because of the huge differences between the antennas (since there's only three), I don't think this would change gameplay very much. The primary play change I'm thinking about is making the jump from medium dish to big dish less extreme, e.g.:

Communotron 16 -- Increase range to half of Kerbin's SOI, so it can be used for Minmus probes if you put a comsat with at least another Communotron 16 in orbit first.

Comms DTS -- Increase range to half of Duna's SMA + half of Kerbin's SMA. This would let the DTS be used for all "inner system" missions -- again, if you put at least another DTS in orbit first.

Communotron 88-88 -- Change range to something like 3/4 of Eeloo's SMA. This will reduce the overall range (currently about 2× Eeloo's SMA) when used in conjunction with another, and will require you to use another 88-88 nearer Kerbin to relay the signal. We could extend the range with ModuleManager magic when we detect the Outer Planets mod.

Couldn't you accomplish the same progression of antenna ranges without additive behavior? You could just double the above ranges, as below:

Communotron 16: Increase range to Kerbin's SOI

Comms DTS: Increase range to Duna's SMA + Kerbin's SMA, allowing it to be used for all "inner system" missions

Communotron 88-88: Change range to ~1.5x Eeloo's SMA

Wouldn't this be functionally almost the same as the additive option, except that the non-additive approach wouldn't require a matching antenna in Kerbin orbit (which seems like a rather trivial difference)? The end result, in both cases, is a progression from Kerbin SOI -> inner planets -> outer planets, which feels intuitive and well balanced. And, as you said, the jump from medium dish to big dish would be less extreme.

I can see the pros and cons of additive vs non-additive, and I don't have a strong opinion either way. However, the discussion of progression of antenna ranges seems like a mostly separate issue, is it not?

Edited May 27, 2015 by Fraz86

[Mecripp]

Couldn't you accomplish the same progression of antenna ranges without additive behavior? You could just the above ranges, as below:

Communotron 16: Increase range to Kerbin's SOI

Comms DTS: Increase range to Duna's SMA + Kerbin's SMA, allowing it to be used for all "inner system" missions

Communotron 88-88: Change range to ~1.5x Eeloo's SMA

Wouldn't this be functionally almost the same as the additive option, except that the non-additive approach wouldn't require a matching antenna in Kerbin orbit (which seems like a rather trivial difference)? The end result, in both cases, is a progression from Kerbin SOI -> inner planets -> outer planets, which feels intuitive and well balanced. And, as you said, the jump from medium dish to big dish would be less extreme.

I can see the pros and cons of additive vs non-additive, and I don't have a strong opinion either way. However, the discussion of progression of antenna ranges seems like a mostly separate issue, is it not?

I could maybe see that with just stock dishes but there are mods that have a good handful of dishes where it's hard to fit them in so you have to start changing AntennaRange settings and really IMO his ranges are to far, After all alot of us use this mods to make a networks not just throw one dish up and reach anywhere what fun is that thats whys we use this mods to cut the range of stock and, I have even cut alittle of the range of AntennaRange and thats even if, I'm using just stock dishs, I use this mod to build a network thats it now, I get pretty lines, I'm all happy kerbal for me the Communotron 88-88 would only reach duna and at times a very low com to jool.

Edited May 27, 2015 by Mecripp2