[1.1.3] AntennaRange 1.11.4 - Enforce and Encourage Antenna Diversity

[Wolfox]

Hello, are there future plans for integrating Chatterer sync like in case of remotetech? (Beeps when connected). Would be really appreciated :-) (But maybe I should ask chatterer developer first)

EDIT: On the other note, I believe I got strange range bug, making first antenna (Communotron 16) unable to establish connection further than 120km (+-) above surface. Will post details as soon as I get home.

EDIT2: Do you plan to add Asteroid Day dish support? (Maybe like Communtron 88-88 up to Jool subsystem, and HG-55 dish covering whole system?)...Well maybe vice-versa, since 88-88 is stock and HG-55 not)

Edited July 3, 2015 by Wolfox

[rottielover]

I'd like to put a little more diversity in my ant collection, anyone have any suggestions?

[Wolfox]

I'd like to put a little more diversity in my ant collection, anyone have any suggestions?

You get one new in Asteroid Day official mod, and you can get alot of dishes from RemoteTech 2 (If you want just dishes for aesthetics, just copy only part files). Also there are nice antennas in BoxSat mod.

[Gristle]

What is the difference between additive ranges and not (simpleRange mode)?

[micha]

As of the last release or two, AntennaRange has required "EVA Manager" and "Toadicus Tools" as well as "Module Manager" when installing through CKAN.

ModuleManager I can understand since AntennaRange patches the stock antennas. But I don't know why it would require the other two. Is this on purpose or just an oversight?

PS. Loving the Mod; thanks very much for making it!

EDIT: Ok, the distribution ZIP of AntennaRange includes the other mods and I had a very quick look at the various projects so I can see why it needs the Tools as well. But as a suggestion, EVA Kerbal Antennas (and hence EVA Manager) should be optional / a separate mod since EVA Manager does a lot more than just affect antennas.

Edited July 3, 2015 by micha

[vardicd]

As of the last release or two, AntennaRange has required "EVA Manager" and "Toadicus Tools" as well as "Module Manager" when installing through CKAN.

ModuleManager I can understand since AntennaRange patches the stock antennas. But I don't know why it would require the other two. Is this on purpose or just an oversight?

PS. Loving the Mod; thanks very much for making it!

EVA manager and Toadicus tools are required files that make the stuff in the mod work, EVA manager covers the transmit abilities of your eva'd kerbals, and toadicus tools are important for, reasons I'm not familiar with, but trust me you need them.

[tg626]

Will you be adding support for the new flip dish from "Asteroid Day"?

[micha]

EDIT: Ok, the distribution ZIP of AntennaRange includes the other mods and I had a very quick look at the various projects so I can see why it needs the Tools as well. But as a suggestion, EVA Kerbal Antennas (and hence EVA Manager) should be optional / a separate mod since EVA Manager does a lot more than just affect antennas.

Having looked into it more, EVA Manager does not do anything more unless suitable config files are installed and activated.

So apart from a bug report (raised on GitHub) and an improvement suggestion (also raised on GitHub), don't mind my earlier post

[Geschosskopf]

Bandwidth could be a true limit, if toadicus desired.

.....

A bit complicated to implement, but it would add meaning to bandwidth stats beyond "how long do I have to sit here for?"

I suppose you could justify that if you wanted to go all RemoteTech with dumb probes requiring constant, hands-on control from KSC. Then bandwidth impacts the timeliness of control inputs.

But if you're using AR precisely because you think RT is obsolete in this day and age of autonomous vehicles, and thus are only interested in transmitting science, then all you're doing is uploading files. The instruments create files of fixed sizes so all that will change is transmission time based on bandwidth.

[toadicus]

What is the difference between additive ranges and not (simpleRange mode)?

"Additive" ranges (which I'm now calling "symmetric" ranges myself) use the geometric mean of both antenna ranges in the link to determine the nominal and maximum ranges. So if you had a hypothetical antenna with max range 8 and another with max range 2, the max range for the linked pair would be sqrt(2*8)=4. By doing this I can now improve link range as you upgrade the KSC tracking station, and put a little more variety in the gameplay behavior as you progress.

"Simple" ranges dictate the range of the link based only on the transmitting antenna. So if you have an antenna with range 8, your range to every other antenna is just 8. It winds up requiring much longer ranges on all three antennas.

PS. Loving the Mod; thanks very much for making it!

Glad you're enjoying it!

EVA manager and Toadicus tools are required files that make the stuff in the mod work, EVA manager covers the transmit abilities of your eva'd kerbals, and toadicus tools are important for, reasons I'm not familiar with, but trust me you need them.

ToadicusTools is a common library of utility functions that I use in all of my mods. My mods will almost always depend on it; except while a blue moon when I compile ToadicusTools code into a small mod directly.

Will you be adding support for the new flip dish from "Asteroid Day"?

Yes; probably based on my first concept from this post. Just need to stop working first, which looks like it probably won't happen until next weekend.

So apart from a bug report (raised on GitHub) and an improvement suggestion (also raised on GitHub), don't mind my earlier post

Addressed the config issue; thanks for the report!

[Gristle]

"Additive" ranges (which I'm now calling "symmetric" ranges myself) use the geometric mean of both antenna ranges in the link to determine the nominal and maximum ranges. So if you had a hypothetical antenna with max range 8 and another with max range 2, the max range for the linked pair would be sqrt(2*8)=4. By doing this I can now improve link range as you upgrade the KSC tracking station, and put a little more variety in the gameplay behavior as you progress.

"Simple" ranges dictate the range of the link based only on the transmitting antenna. So if you have an antenna with range 8, your range to every other antenna is just 8. It winds up requiring much longer ranges on all three antennas.

...

This is unintuitive and confusing. So my big dish antennas in orbit have their range more than halved because my planetary probes have shorter range antennas? Why would I ever want additive range? Additive range would also seemingly make any values shown to the player in the VAB meaningless as the actual range would depend on what the other components of the link were.

[toadicus]

This is unintuitive and confusing. So my big dish antennas in orbit have their range more than halved because my planetary probes have shorter range antennas? Why would I ever want additive range? Additive range would also seemingly make any values shown to the player in the VAB meaningless as the actual range would depend on what the other components of the link were.

That's not really a correct assessment. Ranges only get shorter relative to your antenna when your target has a shorter range than you do. When your target has a longer range, your range gets longer. Take a look at the table in the post I linked in #785, which shows both quantitative and qualitative descriptions of link ranges for various antennas. For example, a Comm 16 -> Comm 16 link has a very short range; only up to 18 km, but Comm 16 -> Tracking Station Level 1 gets to 120 km. Comm 16 -> Comms DTS is 10.7 Mm (almost to Mun) -- plenty for a small craft -> mothership sort of scenario, but Comms DTS -> Tracking Station Level 2 gets you past Duna a ways.

It's not the most intuitive, but it is realistic and it rarely results in unacceptably poor performance. If you find a case wherein it does, feel free to report it.

[Yemo]

"Additive" ranges (which I'm now calling "symmetric" ranges myself) use the geometric mean of both antenna ranges in the link to determine the nominal and maximum ranges. So if you had a hypothetical antenna with max range 8 and another with max range 2, the max range for the linked pair would be sqrt(2*8)=4. By doing this I can now improve link range as you upgrade the KSC tracking station, and put a little more variety in the gameplay behavior as you progress.

"Simple" ranges dictate the range of the link based only on the transmitting antenna. So if you have an antenna with range 8, your range to every other antenna is just 8. It winds up requiring much longer ranges on all three antennas.

That makes it pretty hard to add new antennas.

For example for my SETI mods I add a 160km omni antenna to every probe core.

I looked at the configs, especially the Communotron 16. It had an additive range set to about 6.5km.

The range between 2 Communotron is irrelevantly small (does it work this way)?

I have no idea how i could balance the integrated antennas with something like that.

I could set it to 1m range, then there is effectively no difference to the Comm-16 when talking to the KSC, making the latter completely irrelevant.

Also the range between two probe cores would be non-existant, when 2 Comm16 already have such a low range.

If I set the range higher, the Comm16 is irrelevant again.

tl,dr: I see no way to effectively balance a short range antenna with the additive settings.

[Gristle]

How are multi point (more than 2) links evaluated? How does Packet EC cost factor in?

[toadicus]

That makes it pretty hard to add new antennas.

For example for my SETI mods I add a 160km omni antenna to every probe core.

I looked at the configs, especially the Communotron 16. It had an additive range set to about 6.5km.

The range between 2 Communotron is irrelevantly small (does it work this way)?

I have no idea how i could balance the integrated antennas with something like that.

I could set it to 1m range, then there is effectively no difference to the Comm-16 when talking to the KSC, making the latter completely irrelevant.

Also the range between two probe cores would be non-existant, when 2 Comm16 already have such a low range.

If I set the range higher, the Comm16 is irrelevant again.

tl,dr: I see no way to effectively balance a short range antenna with the additive settings.

It's true that a Comm 16 -> Comm 16 link is very short. 6.5 km is the nominalRange; the maximum range is sqrt(8) times larger than that; 18 km. There's only useful in a handful of edge cases; maybe a rover off a lander, both of which have Comm 16s. The parent ship would surely have a higher gain antenna, though; probably a Comms DTS, and both of those can be heard by a Comms DTS for a very long ways. That Comms DTS can be heard by Kerbin for a very long ways, so all the parts remain useful.

The real question to ask when balancing your internal antennas is to ask "when do I envision these antennas being useful?" For example, I want the Comm 16 to primarily be useful in a "child craft" type role, that needs to relay through a bigger antenna before it can phone home. It's universally useful for landers from parent craft with DTS or 88-88 antennas, and can even do small probes throughout their Kerbin subsystem once you upgrade to Tracking Station level 2.

So, when are the integrated antennas on your SETI parts supposed to be useful? Are they supposed to be high enough gain to phone home to Kerbin on their own? If so, from how far away? Mun? Minmus? Eve? Duna? Eeloo? Balance the part around that number and the system will do all the rest for you.

For example, if you wanted one of your parts to be useful for medium-range (Kerbin->Duna) exploration in the Tracking Station level 3 phase, you'd want an effective link distance of about 3.54e10 m when talking to Tracking Station level 3. Tracking Station level 3 has a max range of 2e12, so your part needs a maximum range = 3.54e10 * 3.54e10 / 2e11 = 5.94e8 m. Do you want to pair with an 88-88 to have effective communications around the Joolian subsystem? That's a range of about 2.26e8 m, so you need a maximum range of 2.26e8 * 2.26e8 / 3.7e10 = 1.38e6 m.

Then you decide what makes your antenna a smarter choice than the Comms DTS, which at TS Level 3 can talk much further than Duna. Maybe you want your antenna to be really low power, and adjust its packet cost. Maybe you want your antenna never to suffer penalties for long range; set maxPowerFactor to 1.

I use this spreadsheet to help me with this, which you can freely copy; take a look in "Symmetric Link Worksheet". Most of the stuff is just noise for building forum tables; the important things are are in the top left. Inputs are the top row of ranges and the row of maxPowerFactor further down; everything else is automatic. The outputs you actually need for your .cfg file are the nominalRanges given in the row below that, shown bolded and underlined. Further down are a pair of tables to help you better conceptualize what your part can do in different circumstances.

This is new and a little more involved than the previous system. But the math isn't hard, and IMO it results in more rewarding gameplay. I talk about the math in more detail in the README.

The system is here to stay. I'm happy to help you work on your parts; feel free to shoot me a PM if you need it.

How are multi point (more than 2) links evaluated? How does Packet EC cost factor in?

What is a link with more than two antennas? If you're talking about distributed telescopic antennas such as in VLBI, that's not supported at all. If you're talking about one antenna that is "receiving" from probe X and "transmitting" to KSC, then those are two separate two-antenna links. There is no limit to the number of links in which an antenna may participate; if you have 20 probes with Comm 16s on the surface of Duna, they will all talk back to Kerbin through your orbital commsat with a Comms DTS (and it won't even know).

Charge use is not a factor in determining link range or performance except insofar as it does in the stock system wherein if you don't have enough power you will transmit more slowly. There are a few reasons for this, but they distill down to simplicity -- if I figured charge use into the ranges after config time it would be even harder for people to balance parts -- and stock-alike balance -- Squad's power use, given any of the available interpretations for EC/s -> Watts, is so laughably high that any real treatment of the transmission equation would result in trivially large ranges for literally every antenna in the game.

[Yemo]

My problem is, that except for edge cases, the range of an omni antenna only really depends on the dish.

So regardless whether I set the integrated range to 1m or 6500m, it makes the Comm-16 redundant (except for those very short ranges).

Which is a problem for any diversity regarding short range omnis.

The integrated could be close coms only, but long enough to allow omni communication for eg base ranges (10km or so) between 2 of them. But that is very close to the Comm16, which makes the latter one nearly redundant.

Also it should reach something like high Kerbin orbit for launches (so to KSC).

Edited July 5, 2015 by Yemo

[toadicus]

So if I'm reading you right, what you want is:

A single ship with a small antenna that is useful for very short range communications (short range to what? a nearby relay, a small probe? I understand in theory but I'm not getting what gameplay effect you're trying to achieve) and a large antenna that is useful for "phoning home." First -- AntennaRange does not really respect that kind of distinction. In terms of network resolution for drawing lines, inactive vessels always only use their longest-range antenna. The active vessel will resolve all of its antennas individually, and then decide when you click "transmit data" from an experiment which one of them is cheapest to use. But its "pretty line" will be defined based on the longest range antenna only.

Without knowing much more about the gameplay effect you want, I'm not sure where to go from here. I'm guessing you want something that will guarantee it will never talk back to Kerbin, and are frustrated because any meaningfully positive number when multiplied against the large tracking station ranges and then rooted will still generally give you a number equivalent to sqrt(tracking station range), which can be very large (1.4 Mm at least), so you can't guarantee that a short range antenna in low-Kerbin orbit will not just talk straight back to Kerbin.

Before I assume too much more -- what is the gameplay effect you're trying to achieve? What is the circumstance where you want your antenna to be useful and the Comm 16 not to be?

[Yemo]

So if I'm reading you right, what you want is:

A single ship with a small antenna that is useful for very short range communications (short range to what? a nearby relay, a small probe? I understand in theory but I'm not getting what gameplay effect you're trying to achieve) and a large antenna that is useful for "phoning home." First -- AntennaRange does not really respect that kind of distinction. In terms of network resolution for drawing lines, inactive vessels always only use their longest-range antenna. The active vessel will resolve all of its antennas individually, and then decide when you click "transmit data" from an experiment which one of them is cheapest to use. But its "pretty line" will be defined based on the longest range antenna only.

Without knowing much more about the gameplay effect you want, I'm not sure where to go from here. I'm guessing you want something that will guarantee it will never talk back to Kerbin, and are frustrated because any meaningfully positive number when multiplied against the large tracking station ranges and then rooted will still generally give you a number equivalent to sqrt(tracking station range), which can be very large (1.4 Mm at least), so you can't guarantee that a short range antenna in low-Kerbin orbit will not just talk straight back to Kerbin.

Before I assume too much more -- what is the gameplay effect you're trying to achieve? What is the circumstance where you want your antenna to be useful and the Comm 16 not to be?

Well, for SETI+RemoteTech, every probe core gets an integrated 160km omni range antenna for the following purposes:

1. Launch/Ascent/AtmosphereCommunication

2. Short range com without increasing part count, eg between a probe rover and a probe lander

3. Range well below the Com16

LKO-KSC would be fine, but Mun/Minmus (with KSC upgrade) would be far too much.

I do not know how to implement an omni antenna below the Com16 without making the Com16 essentially redundant.

[Handwich]

Hi toadicus. I have couple of small suggestions, but because it feels a bit weird doing so while having not contributed anything, I drew a cat. http://imgur.com/xYYwtzo

I hope you like cats.

First, in the R&D/construction info boxes, could you move the "nominal" and maximum ranges from the "Requires:" section to the one above, on the line below Bandwidth? I think they'd look better there.

Also, there's a stock bug where the bandwidth is displayed incorrectly. It's meant to be packetSize divided by packetInterval (values from the config file), but it's multiplying them instead, giving a tiny and completely wrong result. It works fine in action, it's just the info box which is wrong. Could you fix that in this mod?

Secondly, something which would make those suggestions sort of pointless. Considering how this mod works, I'm not sure the single bandwidth display is all that useful. I think it would be better to have sections which show the values at specific distances: optimum - where the packet size is at maximum, standard - where the packet size matches stock (currently "nominal", but I don't think that's the right word), and the maximum distance.

Something like this for the Communotron with a level 1 tracking station. The values here are probably wrong, but you get the idea.

Optimum Range
Range: 21.2 km
Packet size: 8.0 Mits
Bandwidth: 13.33 Mits/sec

Requires:
- ElectricCharge: 12.0/packet


Standard Range
Range: 42.4 km
Packet size: 2.0 Mits
Bandwidth: 3.33 Mits/sec

Requires:
- ElectricCharge: 12.0/packet


Maximum Range
Range: 120 km
Packet size: 2.0 Mit
Bandwidth: 3.33 Mits/sec

Requires:
- ElectricCharge: 96.0/packet

Would this be feasible? It would also have to take into account the option for fixedPowerCost, which I (and maybe others) have enabled.

As for the new Asteroid Day dish, I'd be happy with a range between the DTS and the 88-88. I don't know if you're planning to change the tech tree placement like you mentioned, but consider that its original placement doesn't make any less sense than the rest of the stock tree.

And to Yemo:

I do not know how to implement an omni antenna below the Com16 without making the Com16 essentially redundant.

Since AntennaRange seems to be balanced around only the 3 stock antennae, it makes sense that adding new ones will cause some overlap in terms of ranges covered. I don't use SETI or RemoteTech, but if you're adding more antennae, it may be reasonable to change the ranges AntennaRange gives to stock ones so yours fit where you want them in terms of balance.

[toadicus]

Yemo, is there a particular reason that obsoleting the Comm 16 is a bad thing? Something to consider here is that "very short range antennas" are only a realistically valid concept wherein both antennas are very low gain and the transmitter has very low power. As I've said before, NASA could hear my children's walkie-talkies from the Moon, but the walkie-talkies are certainly "very short range". The receiving end makes a big difference.

If you wanted to get your antenna to Keosynchronous orbit at KSC 3, you'd need a link range of 2.87e6 m, and an antenna range of 2.87e6 * 2.87e6 / 2e12 = 4.11845. That's going to be pretty useless for inter-relay communication, but in general it's going to meet your other criteria. If this is indeed a "very lower power" antenna that's to be expected: if you have a very low power antenna with low gain and I have an antenna with similarly low gain and we are very far apart, we won't be able to hear each other. If someone points a 70 m parabolic dish at you, they'll hear you even if you're using an antenna made from a paperclip unless you're halfway across the solar system.

I'd say that you should go ahead and make your part identical to the Comm 16, but make it higher power, on the rationale that it is a smaller (lower gain) antenna using more power to achieve the same bandwidth and the same range. This makes it a less efficient antenna and therefore it won't be the best choice if you can afford to put a Comm 16 on your craft (active craft will consider this when transmitting). This maintains some purpose for the Comm 16 (more efficient) while leaving a niche for yours (cheaper, no extra physics).

Handwich, thanks for the thoughts on that presentation. I like them, and have been meaning to revisit that box for a while. I'll see what I can do.

EDIT: What if I used EC/sec instead of EC/packet for the power requirement? That seems like a much more intuitive metric and should make comparing antennas easier.

Edited July 5, 2015 by toadicus

[Gristle]

I've developed a MM config to enable Antenna Range for the Tantares mod by Beale. I couldn't figure out how to edit the Wiki on GitHub so am posting it here. Would also appreciate some feedback on the values.

Here is theTantares AR worksheet I used compare / balance the ranges.

// title        = T-CD Communication Dish
// description  = A communication dish mounted on a folding arm.
@PART[Tantares_Antenna_A]:FOR[Tantares]:NEEDS[AntennaRange]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 5000000000
		simpleRange = 14142135623
		maxPowerFactor = 8
		maxDataFactor = 4
	    requiredResource = ElectricCharge
	}
}

// title        = A961A Hoop Antenna
// description  = A very low-power antenna. Suitable for nothing more than short-range communication.
@PART[Vostok_Antenna_A]:FOR[Tantares]:NEEDS[AntennaRange]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 50000
		simpleRange = 150000
		maxPowerFactor = 9
		maxDataFactor = 3

	}

	MODULE
	{
		name = ModuleScienceContainer

		dataIsCollectable = true
		dataIsStorable = false

		storageRange = 2
	}
}

// title        = V-ODA Backup Antenna
// description  = A crude, but reliable antenna.
@PART[Vega_Antenna_A]:FOR[Tantares]:NEEDS[AntennaRange]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 12000000
		simpleRange = 33941125
		maxPowerFactor = 8
		maxDataFactor = 4
	        requiredResource = ElectricCharge
	}
	MODULE
	{
		name = ModuleScienceContainer

		dataIsCollectable = true
		dataIsStorable = false

		storageRange = 2
	}
}

// title        = "Priority" Dish Mk5
// description  = A largely flat, high-gain, fixed dish. Popular in the second hand market to be re-used as a sled.	
@PART[Vega_Antenna_B]:FOR[Tantares]:NEEDS[AntennaRange]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 200000000000
		simpleRange = 848528137424
		maxPowerFactor = 18
		maxDataFactor = 6
	        requiredResource = ElectricCharge
	}
	MODULE
	{
		name = ModuleScienceContainer

		dataIsCollectable = true
		dataIsStorable = false

		storageRange = 2
	}
}

// title        = L-LG1 Low Gain Antenna
//description  = An extremely basic, but reliable, communication device.
@PART[Libra_Antenna_A]:FOR[Tantares]:NEEDS[AntennaRange]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 1500000
		simpleRange = 5196152
		maxPowerFactor = 12
		maxDataFactor = 2
	}
	MODULE
	{
		name = ModuleScienceContainer

		dataIsCollectable = true
		dataIsStorable = false

		storageRange = 2
	}
}

// title        = V-RE "Needle" Rendezvous Antenna
// description  = Though initially created in order to automate the meet-up and docking of spacecraft, the V-RE more often than not finds itself used as a basic communication device.
@PART[Vega_Antenna_C]:FOR[Tantares]:NEEDS[AntennaRange]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 2500
		simpleRange = 2500
		maxPowerFactor = 1
		maxDataFactor = 2
	}
	MODULE
	{
		name = ModuleScienceContainer

		dataIsCollectable = true
		dataIsStorable = false

		storageRange = 2
	}
}

// title        = L-HG1 High Gain Antenna
// description  = This folding communication dish will keep you in contact with ground control, theoretically outside the orbit of Minmus.
@PART[Libra_Antenna_B]:FOR[Tantares]:NEEDS[AntennaRange]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 50000000000
		simpleRange = 141421356237
		maxPowerFactor = 8
		maxDataFactor = 4
	}
	MODULE
	{
		name = ModuleScienceContainer

		dataIsCollectable = true
		dataIsStorable = false

		storageRange = 2
	}
}

//title = F020A "Nova" Communication Dish
//description  = Maintain a connection between Kerbin and anywhere else in the solar system. Just, don't be surprised if a few of the 1s and 0s get switched up.
@PART[Fomalhaut_Antenna_A]:FOR[Tantares]:NEEDS[AntennaRange]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 113549713200
		simpleRange = 321167088822
		maxPowerFactor = 8
		maxDataFactor = 3
	}
	MODULE
	{
		name = ModuleScienceContainer

		dataIsCollectable = true
		dataIsStorable = false

		storageRange = 2
	}
}

//title        = TK-CD0A Communication Array
//description  = An array of communication dishes mounted on a folding arm.
@PART[Alnair_Antenna_A]:FOR[Tantares]:NEEDS[AntennaRange]
{
	@MODULE[ModuleDataTransmitter]
	{
		@name = ModuleLimitedDataTransmitter
		nominalRange = 5000000000
		simpleRange = 14142135624
		maxPowerFactor = 8
		maxDataFactor = 5
	}
	MODULE
	{
		name = ModuleScienceContainer

		dataIsCollectable = true
		dataIsStorable = false

		storageRange = 2
	}
}

[OddFunction]

Hi toad,

Possible issue with "line of sight" not working. I should not have been able to control my ship but I could. Specifically, I could not control direction, meaning I couldn't turn at all, but I could toggle my engine on and off. I could not control direction when my engine was on, so RCS and gimbal or w/e obviously was disabled.

Here are some screenshots.

Line of sight is red:

http://i.imgur.com/7zh38ao.png

I can control my engine:

http://imgur.com/oB2Fh4R

My antennarange settings:

http://imgur.com/pCkEXds

I'm running Linux Mint 64 bit with 64bit KSP. I installed your mod via ckan. Version 1.0.4 of KSP.

Here is my output log:

https://mega.nz/#!dI1RTYqT!sCEZRURH-lTrQJNz2Yzw3NzoBCagtTdDouWqjcIDzD8

Please let me know if you need anything else. Thanks.

[jlcarneiro]

[...]

Line of sight is red:

http://i.imgur.com/7zh38ao.png

I can control my engine:

http://imgur.com/oB2Fh4R

[...]

Hi, I think I've noticed the same: you're pressing "Z" and "X", aren't you? AR blocks incremental changes ("Shift" and "Ctrl") but I it missed the full-throttle and zero-throttle hotkeys...

[OddFunction]

Hi, I think I've noticed the same: you're pressing "Z" and "X", aren't you? AR blocks incremental changes ("Shift" and "Ctrl") but I it missed the full-throttle and zero-throttle hotkeys...

Yea I'm pressing z and x.

[Handwich]

What if I used EC/sec instead of EC/packet for the power requirement? That seems like a much more intuitive metric and should make comparing antennas easier.

Yeah, I think that's a good idea.