[1.1.3] AntennaRange 1.11.4 - Enforce and Encourage Antenna Diversity

[BudgetHedgehog]

AntennaRange...

• does not have any time delay or any facility for programming future actions.
  
• does not have additive ranges; everything is transmitter-side (so if you have a whip antenna out at Jool, it can't phone home even if there is a big dish around Kerbin).
  
• does not require antennae to target other antennae and does not have any limit to the number of relays that can be "connected" at any time.
  
• does not have those cool lines that show you which relays are connected to each other.
  
• does not maintain a persistent model of the relay network; everything is calculated dynamically as contact is required (constantly, when probe connectivity is enabled and you're flying a probe).
  
• allows line-of-sight and connectivity requirements to be disabled.

Also, AntennaeRange doesn't contain as many save-breaking bugs

To be honest with you, I can quite happily live without the above. Apart from the cool lines, I really want them, but otherwise, most of what you listed is more of an annoyance or a non-issue for me.

[JeffreyCor]

I agree with ObsessedWithKSP, I like the lines

RT also will only connect based on the range of the shortest antenna, so if you have a small antenna and a big dish, your connection is the range of the small antenna. In that way the second item on the list really seems to be the same. (whip antenna connects to satellite with dish, which connects to the KCP / orbital disk around Kerbin.) The lack of conflicts is a huge plus for this one

[toadicus]

Apart from the cool lines, I really want them...

I agree with ObsessedWithKSP, I like the lines

I don't have any idea how to make the pretty lines. But, if I get a chance I'll take a look at learning.

@toadicus getting a error https://www.dropbox.com/s/7smzwy1toq3b0xy/LOG.txt

Did you unpack the latest ToadicusTools library from the AntennaRange archive? The versions currently included in TweakableEverything and VOID are missing that method. I'm working on a new deployment strategy that will prevent such confusion in the future.

[toadicus]

OK re-done my cfg's put them all in 1 feel free to do what ever use it or not, mod's cover whole or part

// RemoteTech2

// Squad

// Hyomoto Aerospace

// Dmagic

// DongFangHong

// FASA By Frizzank & APOLLO By DennyTX

// NovaPunch

// Telemachus

// Lionhead

// AIES

// LLL-Lite

https://www.dropbox.com/s/xv2153q8ybfl1s6/AntennaRange2.cfg

I'm not 100% sure on this (maybe you know something about MM that I don't), but I think your :HAS[~ModuleDataTransmitter[]] clause on each part is entirely superfluous. According to the documentation the ~ operator applies to properties, not modules, so ~ModuleDataTransmitter would be checking for parts that do not have a "ModuleDataTransmitter = fooBar" value defintion, rather than those that do not have a ModuleDataTransmitter module. To check for the latter, you could use :HAS[!MODULE[ModuleDataTransmitter]], but since you are wanting to change the definition if it exists, or add it if it does not, you don't actually want to check for that. The %MODULE {} syntax later on is sufficient for the effect you're looking for.

[Mecripp]

Fixed,

Edit - @toadicus I'm having a brain fart, I made 2 cfg file's 1 with @ and 1 with % your file the Antenna's are locked to me or don't deploy when transmitting if you add

DeployFxModules = 0

To the bottom of your file they should, Don't know if it's a bug with MM or OS guessing your Mac or Linux but if you would

try both and see the different menu you get in game.

% https://www.dropbox.com/s/xv2153q8ybfl1s6/AntennaRange2.cfg <---- updated 5/12/14 added packetResourceCost = ** and TechRequired = ******* to RT2 parts.

Edited May 12, 2014 by Mecripp2

[Mecripp]

Don't see why ModuleAnimateGeneric is changing with either 1, The only thing that should be changing is with either 1 is ModuleDataTransmitter but with @ the Stock Antenna's are locked and with % there not.

[toadicus]

I need to know a little more about what you're trying to do. Are you using your AntennaRange cfg file in place of or in addition to mine? Are you trying to change the stock animation behavior? If not, is the stock animation behavior broken with my cfg?

The Squad part cfgs already assign DeployFxModules = 0 for longAntenna and CommDish, and additionally ProgressFxModules = 1 for mediumDishAntenna. Your cfg is assigning them again without an operator, so you are adding an additional value which the Squad code is unlikely to ever look at. If you're trying to change those values you should be using @ or %, since the definition already exists, e.g.

@PART[longAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 1500000
		maxPowerFactor = 8
		maxDataFactor = 4

                [B]@DeployFxModules = 0[/B]
	}
}

However, that is not necessary; Squad's code already has DeployFXModules = 0 defined so such a line is literally just clobbering the value with the same number.

I just tested my cfg on a relatively mod-light install with both of these cfgs:

@PART[longAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
@MODULE[ModuleDataTransmitter]
{
@name = ModuleLimitedDataTransmitter
nominalRange = 1500000
maxPowerFactor = 8
maxDataFactor = 4
}
}

@PART[mediumDishAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
@MODULE[ModuleDataTransmitter]
{
@name = ModuleLimitedDataTransmitter
nominalRange = 30000000
maxPowerFactor = 8
maxDataFactor = 4
}
}

@PART[commDish]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
@MODULE[ModuleDataTransmitter]
{
@name = ModuleLimitedDataTransmitter
nominalRange = 80000000000
maxPowerFactor = 8
maxDataFactor = 4
}
}

@PART[longAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
%MODULE[ModuleDataTransmitter]
{
%name = ModuleLimitedDataTransmitter
nominalRange = 1500000
maxPowerFactor = 8
maxDataFactor = 4
}
}

@PART[mediumDishAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
%MODULE[ModuleDataTransmitter]
{
%name = ModuleLimitedDataTransmitter
nominalRange = 30000000
maxPowerFactor = 8
maxDataFactor = 4
}
}

@PART[commDish]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
%MODULE[ModuleDataTransmitter]
{
%name = ModuleLimitedDataTransmitter
nominalRange = 80000000000
maxPowerFactor = 8
maxDataFactor = 4
}
}

In both cases, the antennae deployed when transmitting, then retracted. Manual operation of the antenna also worked.

[Zeroignite]

Oh, here's a thought... how difficult would it be to have an antenna to return to its prior state after transmitting? For example, on probes I want my 88-88 to stay deployed rather than folding back up after transmitting

[toadicus]

Oh, here's a thought... how difficult would it be to have an antenna to return to its prior state after transmitting? For example, on probes I want my 88-88 to stay deployed rather than folding back up after transmitting

So that's something that I've looked into here, and also for TweakableEverything, and the basic answer is "really really". Squad's ModuleDataTransmitter actually checks the animation state to be sure it is where it should be. If I prevent the antenna from retracting after a transmission, the antenna never works again.

To do it right, I'd need to complete re-implement the transmitter. That's something I've considered doing for a few reasons... but at this point I'm not going that route.

[Mecripp]

I need to know a little more about what you're trying to do. Are you using your AntennaRange cfg file in place of or in addition to mine? Are you trying to change the stock animation behavior? If not, is the stock animation behavior broken with my cfg?

The Squad part cfgs already assign DeployFxModules = 0 for longAntenna and CommDish, and additionally ProgressFxModules = 1 for mediumDishAntenna. Your cfg is assigning them again without an operator, so you are adding an additional value which the Squad code is unlikely to ever look at. If you're trying to change those values you should be using @ or %, since the definition already exists, e.g.

@PART[longAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 1500000
		maxPowerFactor = 8
		maxDataFactor = 4

                [B]@DeployFxModules = 0[/B]
	}
}

However, that is not necessary; Squad's code already has DeployFXModules = 0 defined so such a line is literally just clobbering the value with the same number.

I just tested my cfg on a relatively mod-light install with both of these cfgs:

@PART[longAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
@MODULE[ModuleDataTransmitter]
{
@name = ModuleLimitedDataTransmitter
nominalRange = 1500000
maxPowerFactor = 8
maxDataFactor = 4
}
}

@PART[mediumDishAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
@MODULE[ModuleDataTransmitter]
{
@name = ModuleLimitedDataTransmitter
nominalRange = 30000000
maxPowerFactor = 8
maxDataFactor = 4
}
}

@PART[commDish]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
@MODULE[ModuleDataTransmitter]
{
@name = ModuleLimitedDataTransmitter
nominalRange = 80000000000
maxPowerFactor = 8
maxDataFactor = 4
}
}

@PART[longAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
%MODULE[ModuleDataTransmitter]
{
%name = ModuleLimitedDataTransmitter
nominalRange = 1500000
maxPowerFactor = 8
maxDataFactor = 4
}
}

@PART[mediumDishAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
%MODULE[ModuleDataTransmitter]
{
%name = ModuleLimitedDataTransmitter
nominalRange = 30000000
maxPowerFactor = 8
maxDataFactor = 4
}
}

@PART[commDish]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
%MODULE[ModuleDataTransmitter]
{
%name = ModuleLimitedDataTransmitter
nominalRange = 80000000000
maxPowerFactor = 8
maxDataFactor = 4
}
}

In both cases, the antennae deployed when transmitting, then retracted. Manual operation of the antenna also worked.

Just using your file and thats it the stock antennae are locked in there state, I can transmit data but they don't deploy and making the 2 cfg, I post they both do different thing with the menu.

Will change MM to what you have in the folder and see how they turn out maybe a bug with MM 2.1

Edit- Samething with MM 2.08 https://www.dropbox.com/s/9qk6df6ju0c64jr/screenshot2.png ------- https://www.dropbox.com/s/24n1no4duyuydr2/screenshot3.png ----- thats just running with what you have in folder.

Edited May 8, 2014 by Mecripp2

[toadicus]

My modules aren't even on the parts in those screenshots; that "locked" indicator is just the normal status of the ModuleAnimateGeneric. Do you have two copies of ModuleManager lying around by chance? Its election process was disabled recently. If not, something else is up. I'd need a log to know more.

[Zeroignite]

So that's something that I've looked into here, and also for TweakableEverything, and the basic answer is "really really". Squad's ModuleDataTransmitter actually checks the animation state to be sure it is where it should be. If I prevent the antenna from retracting after a transmission, the antenna never works again.

To do it right, I'd need to complete re-implement the transmitter. That's something I've considered doing for a few reasons... but at this point I'm not going that route.

Fair! I'm... actually a little impressed it's that hardcoded, rather than just checking state.

[KerbMav]

I do not care for automatic deployment, I would be really happy if an antenna I wanted deployed would remain deployed, I will gladly rightclick/actiongroup every antenna in my game if I could just get rid of automatically retracting antennas.

[rkman]

...Above that range, packet size stays floored at Squad's value, and packet power costs increase. When power cost gets too high, the antenna no longer functions.

Any chance of an option to have power cost remain the same but have data rate decrease with distance? (As it does in reality, where output power is limited not by available power supply but by the rated maximum output power of the transmitter.) Beyond some range the data rate would become unusably slow, though for gameplay purpose there probably should also be a hard limit on range, as there currently is

I suppose it can be simulated by manually throttling down packet size with increasing distance, but it would be nice if it could do that automatically.

[toadicus]

I do not care for automatic deployment, I would be really happy if an antenna I wanted deployed would remain deployed, I will gladly rightclick/actiongroup every antenna in my game if I could just get rid of automatically retracting antennas.

Alas; were it so easy, I would have done it already. The problem isn't that I can't get it done for a reasonable amount of effort without making the UX terrible... the problem is that I can't get it done for a reasonable amount of effort at all. It's a request I'm well aware of, and when the time comes, I'll let everybody know.

Any chance of an option to have power cost remain the same but have data rate decrease with distance? (As it does in reality, where output power is limited not by available power supply but by the rated maximum output power of the transmitter.) Beyond some range the data rate would become unusably slow, though for gameplay purpose there probably should also be a hard limit on range, as there currently is

I suppose it can be simulated by manually throttling down packet size with increasing distance, but it would be nice if it could do that automatically.

Hmm, should be simple enough. I had been using the Squad values as "minimums", but I could probably add an option.

[toadicus]

I don't have any idea how to make the pretty lines. But, if I get a chance I'll take a look at learning.

So, I've taught myself, generally, how to draw pretty lines. The next hurdle in this particular area comes from this:

AntennaRange...

• does not maintain a persistent model of the relay network; everything is calculated dynamically as contact is required (constantly, when probe connectivity is enabled and you're flying a probe).

Right now, if a relay isn't used in helping the active vessel phone home, I maintain the bare minimum amount of data on it. If a relay is on a vessel that's too far away for any of the antennae being used in our path back to Kerbin to talk to it, I don't maintain any information on it at all. Also, relays don't store any information at all about what relays they could have used, but aren't because they're not the best choice or can't because those relays can't make a path home. So, in terms of pretty lines, I'm left with two basic concepts:

1. Draw pretty lines only for the path back to Kerbin.
   In my view this is not very useful. Pretty lines that show you how you're getting home don't really tell you anything you don't already know: a path exists back to Kerbin. In all likelihood, you can intuit this path: "well my lander has a whip antenna and it's going back to the medium dish antenna on the drop ship which is going back to the long range dish on the mothership, which is either going straight back to Kerbin, or happening to hit that satellite I left at Duna that one time." The important information -- that a path exists -- is a given and the "how" doesn't seem very useful to me. "Why not?" is a much better question, but as I mentioned above I don't store any information that would help generate that graph.
   
2. Run an independent behavior just to model the whole network and draw it on the map.
   This has two possible drawbacks. The first and most obvious is that I haven't already done any of this work and I would need to invest time in it. Second, it might come with a performance hit. I've tried to optimize and cache as many of the queries as I can, but part of that optimization is intentionally ignoring things I can afford to ignore.
   

So, what is it that you guys are looking for? What makes a useful pretty-lines system?

[BudgetHedgehog]

How about something like drawing the lines during transmission. Even if they're pretty useless, they'll still be pretty to look at and if there's any break in the chain, maybe show where that break is so we can do something about it? I mean, if you can get permanent lines drawn without a noticeable performance drop, I'd totally be down for that, but if it's too big of a hurdle, that's cool.. I guess I don't really know what I want specifically, I just want lines

Yeah, very helpful, I know

[phoenix_ca]

Very simple config to prevent the toolbar texture from getting squished by ATM:

AntennaRange.cfg

ACTIVE_TEXTURE_MANAGER_CONFIG
{
	folder = AntennaRange
	enabled = true

	OVERRIDES
	{
		AntennaRange/Textures/toolbarIcon
		{
			compress = true
			mipmaps = false
			scale = 1
			max_size = 0
			make_not_readable = true
		}
	}
}

Would be nice to see that packaged with the mod, until such a config gets packaged with ATM itself. Go poke them about it.

[rkman]

Hmm, should be simple enough. I had been using the Squad values as "minimums", but I could probably add an option.

That would be great.

So, what is it that you guys are looking for? What makes a useful pretty-lines system?

I have no need or pretty lines. It might be useful if the current connection chain of the active vessel can be shown in the form of a list of names of vessels in the chain.

[toadicus]

Very simple config to prevent the toolbar texture from getting squished by ATM:

AntennaRange.cfg

ACTIVE_TEXTURE_MANAGER_CONFIG
{
	folder = AntennaRange
	enabled = true

	OVERRIDES
	{
		AntennaRange/Textures/toolbarIcon
		{
			compress = true
			mipmaps = false
			scale = 1
			max_size = 0
			make_not_readable = true
		}
	}
}

Would be nice to see that packaged with the mod, until such a config gets packaged with ATM itself. Go poke them about it.

Poke made: http://forum.kerbalspaceprogram.com/threads/59005?p=1149408#post1149408

Thanks!

[gmbigg]

So, what is it that you guys are looking for? What makes a useful pretty-lines system?

I'm not sure how to code this, but maybe using the toolbar icon to track connections would be a good 'pretty lines' solution?

For example, let's add two new icons; a yellow variant and a red variant of the current green one.

The current green icon symbolizes that your craft is at or below the nominal range; transmissions are as efficient, or better than, Squad's defaults.

The yellow icon symbolizes that your craft isabove the nominal range; transmissions cost more power than normal, but are still possible.

The red icon symbolizes that your craft is out of range entirely; transmissions are not possible at the present time.

If the toolbar icon becomes visible in flight, all you'd have to do is look at the icon to determine your current connection.

tl;dr

Use the Toolbar icons to track how efficient your connection is.

[NJC2]

It hasn't been quite a month since I asked if this mod required LOS for transmission and craft control, and I checked back today to see LOS has now been implemented. Nice!

I like Remote Tech, but I would like to maintain control of my unmanned craft because the way I see it, I am the ships computer and I'm carrying out pre-programmed commands that don't need constant communication with the KSC to carry out. I do like that it gave antennas limited range and requires LOS to transmit data back to KSC since it gives a real reason to set up satellite relay networks.

I have a few questions before I switch over from Remote Tech. I disabled Remote Tech by moving it out of the GameData directory, then created a test sandbox game and sent an unmanned probe around the Mun with just a communitron 16 on it. It seems like the craft only needs LOS or a connection back to the planet Kerbin. Would it be possible to require it to have a connection to the KSC rather than the planet itself? This way we still need to put up satellites to relay the signal around the planet to the KSC.

Since I already have a career mode in progress with Remote Tech and don't want to start over, will this mod work with Remote Tech or its antennas? Since I already have satellites and probes out there with Remote Tech dishes, would disabling the Remote Tech .dll be enough or do I need to edit configs for the antennas?

So, I've taught myself, generally, how to draw pretty lines. The next hurdle in this particular area comes from this:

Right now, if a relay isn't used in helping the active vessel phone home, I maintain the bare minimum amount of data on it. If a relay is on a vessel that's too far away for any of the antennae being used in our path back to Kerbin to talk to it, I don't maintain any information on it at all. Also, relays don't store any information at all about what relays they could have used, but aren't because they're not the best choice or can't because those relays can't make a path home. So, in terms of pretty lines, I'm left with two basic concepts:

1. Draw pretty lines only for the path back to Kerbin.
   In my view this is not very useful. Pretty lines that show you how you're getting home don't really tell you anything you don't already know: a path exists back to Kerbin. In all likelihood, you can intuit this path: "well my lander has a whip antenna and it's going back to the medium dish antenna on the drop ship which is going back to the long range dish on the mothership, which is either going straight back to Kerbin, or happening to hit that satellite I left at Duna that one time." The important information -- that a path exists -- is a given and the "how" doesn't seem very useful to me. "Why not?" is a much better question, but as I mentioned above I don't store any information that would help generate that graph.
   
2. Run an independent behavior just to model the whole network and draw it on the map.
   This has two possible drawbacks. The first and most obvious is that I haven't already done any of this work and I would need to invest time in it. Second, it might come with a performance hit. I've tried to optimize and cache as many of the queries as I can, but part of that optimization is intentionally ignoring things I can afford to ignore.
   

So, what is it that you guys are looking for? What makes a useful pretty-lines system?

How about adding a button on the right click menu for an antenna (or a button in the map screen/toolbar) to display connection information? When turned on it can calculate and draw lines to any antennas in range and in line of sight. You could use two colors like Remote Tech does, one to indicate which satellites it can talk to, and another color to indicate the current relay path back to the KSC.

Edited May 11, 2014 by NJC2

[toadicus]

It hasn't been quite a month since I asked if this mod required LOS for transmission and craft control, and I checked back today to see LOS has now been implemented. Nice!

I like Remote Tech, but I would like to maintain control of my unmanned craft because the way I see it, I am the ships computer and I'm carrying out pre-programmed commands that don't need constant communication with the KSC to carry out. I do like that it gave antennas limited range and requires LOS to transmit data back to KSC since it gives a real reason to set up satellite relay networks.

The AntennaRange restrictions on line of sight and probe control are independently optional. I have the same feelings as you do regarding probe control, and don't use that limitation in my own career save. The Toolbar button in the space center will pop up a configuration window and let you set those options.

I have a few questions before I switch over from Remote Tech. I disabled Remote Tech by moving it out of the GameData directory, then created a test sandbox game and sent an unmanned probe around the Mun with just a communitron 16 on it. It seems like the craft only needs LOS or a connection back to the planet Kerbin. Would it be possible to require it to have a connection to the KSC rather than the planet itself? This way we still need to put up satellites to relay the signal around the planet to the KSC.

I have intentionally not required a relay back to KSC specifically because, in my view, it's a rather baseless restriction. Back in the days of the first manned spaceflights, NASA was not dependent upon space-based infrastructure to talk to their pilots, but also had more than a 10 minute window to do so while they whizzed over Texas every hour or two. They used surface-based infrastructure to effect these early communications. The Apollo missions going all the way to the Moon also used surface-based infrastructure. IMO it's unreasonable to assume that the Kerbals do not have similar capacities even at the very start of a career save.

Were I to add such a limitation, I probably would actually not allow any artificial point on Kerbin to act as a relay. Instead, I'd require that an antenna be installed suitably close to KSC as "the KSC relay", and thus require the player to develop every single point of communications infrastructure -- even the "home base" antenna. But, IMO, that is not a fun or interesting requirement. Sending suborbital missions comprising an antenna on a parachute isn't challenging enough to be a fun task, and doesn't really contribute to the development of a meaningful skillset in terms of gameplay. If it's not well-founded in the "reality" of the game world, isn't fun, and isn't educational, it's just busywork for its own sake.

I welcome discussion on this topic. Maybe there is a right way to make building a short range communications network in the early game a good addition! I encourage you (and anyone else) to recommend and defend an implementation that meets at least two of the three criteria above: grounded in reality, fun, or educational.

Since I already have a career mode in progress with Remote Tech and don't want to start over, will this mod work with Remote Tech or its antennas? Since I already have satellites and probes out there with Remote Tech dishes, would disabling the Remote Tech .dll be enough or do I need to edit configs for the antennas?

I don't know all the ins and outs or disabling RemoteTech2 (having never used it myself), but my supposition would be that in order to convert a career save from RT2 to AR, one would need to:

1. Make a backup of your entire persistence folder (/path/to/KSP_platform/saves/<yourSaveNameHere>
   
2. Remove the RT2 dll and other plugin files. The Textures subfolder and MM patches (root-level *.cfg files) can probably be removed as well.
   
3. The RT2 Parts subfolder needs to stay or you will lose active flights.
   
4. MeCripp has published a set of MM patches for converting RT2 parts (and many others) to AntennaRange relays. You might ask him if this is the latest, but the last link I saw was back here.

How about adding a button on the right click menu for an antenna (or a button in the map screen/toolbar) to display connection information? When turned on it can calculate and draw lines to any antennas in range and in line of sight. You could use two colors like Remote Tech does, one to indicate which satellites it can talk to, and another color to indicate the current relay path back to the KSC.

To this and the recent presentation conversation: I've got a few thoughts on adding some network-level presentation. Nothing firm enough to implement yet, but I'm mulling it all over. If anyone has further thoughts on the topic I would welcome them.

[phoenix_ca]

If you add RC2 level LOS restrictions without it being optional, I'll kick a hamster at you.

Just saying. >.>

[toadicus]

If you add RC2 level LOS restrictions without it being optional, I'll kick a hamster at you.

Just saying. >.>

No worries: all these new features are abd will always be optional.