[1.1.3] AntennaRange 1.11.4 - Enforce and Encourage Antenna Diversity

[toadicus]

cipherpunks, no, AntennaRange doesn't have any multi-mode capability at this point. It's not outside the realm of things I might do in the future, though.

ModZero, I offered CaptRobau a config for AntennaRange 1.10 compatibility in OPM, since he already distributes a patch with his mod. But, I happened to see that he's on holiday, so here it is:

@PART[commDish]:NEEDS[AntennaRange]:AFTER[AntennaRange]
{
	@MODULE[ModuleLimitedDataTransmitter]
	{
		@simpleRange = 800000000000
		@nominalRange = 22500000000
	}
}

@TRACKING_STATION_RANGES[*]:NEEDS[AntennaRange]:FOR[AntennaRange]
{
	@range,2 = 6000000000000
}

[ModZero]

Ah, thanks - that's great. I'm kinda trying to poke around making a fancy config by appropriating techinques I see in Smunisto's spreadsheets and some additional antennas, but I need to be properly awake to actually achieve anything in such a way :-)

[Skalou]

hi,

just to give you my feedback:

i use your mode with default "science mode" perfect for my actual skill,

i will upgrade to restrict to line of sight requirement and control for probe latter (time to upgrade the network),

i like the UI too,

some questions however:

After my upgrade, will the connection for control of probe cost more Ec ? depend of the connection quality?

Also do you know a mod that keep those antenna open after transmitting science? it's just cosmetic but i find it weird.

maybe a section in the 1st post with a small description and links to the differents patchs for other parts compatibility, gameplay balance config,.. working with your actual version?

Edit:

I use Scansat mod does it work with? ( EC cost for transmitting the "analyze data")

thank you

Edited June 14, 2015 by Skalou

[smunisto]

smunisto, I took another pass at your spreadsheet; see here: https://docs.google.com/spreadsheets/d/13BxJQrxNytTETv-YluwmPEq6xYcQrNRmy7kxHsYaOOc/edit?usp=sharing

I'm pretty sure all the math should be updated to reflect the way the mod works, and I think I've done all the right assignments to get the values that you want out of it. Take a look and see if that helps you out.

All's well now. I knew I am over-calculating something somewhere xD

The VLOOKUP was a nice idea too, I was too lazy to do it.

I have also updated my original Origami antenna post links with the most current information.

[toadicus]

Skalou, in general science costs will be about the same in most circumstances. In some circumstances, you might see big changes, depending on specifically how your network is laid out. In general none of the probes you have active should become non-viable.

There aren't any mods (that I know of) that do a particularly satisfying job of holding the antennas open. This is because Squad's transmit code manually sets them open and closed, step by step, and refuses to work if it's not in the state it wants. I might replace this code at some point in the future, but at this point I'm still calling it.

I'd like to improve some of the documentation and communication for this mod, particularly around user-contributed configs. I've got some ideas, but haven't put anything in motion yet.

I'm pretty sure Scansat will work just fine. It follows all the rules and transmits using the best IScienceDataTransmitter on the vessel, which is more-or-less necessarily an AntennaRange module when AntennaRange is installed.

smunisto, glad I could help.

[jedensuscg]

I have been using remote tech lately, and frankly when trying to start a new career, especially with kerbal construction time and no quicksaves/loads, getting your initial network into orbit is more hassle than fun. But I still wanted some sort of use for satellites, without the LOS requirement early on. I think might fill that void.

Just installed and will give it a shot.

[jpkerman]

I am one of many players who seem to want a variety of antennas in the game and like the additive features now incorporated but do not look forward to restructuring the ranges to fit in more antennas which offer the game only a different appearance or nice looking animations.

This is not intended to demand a feature but merely to put up a concept I have developed while looking at the latest AR changes and trying to add my five favorite AIES antennas back into the game.

If we correspond the three stock antennas as designating three range categories, Short-medium-long, rather than attempting a tedious restructuring to expand it to eight antennas I offer the following observations from real life on a planet far from Kerbin.

1. Different communication devices for spacecraft (hereby referred to as 'Antennas') were not for different ranges but different data types. in example, Voice/video transmissions had different needs than simple flight telemetry.

2. Some antenna designs were simply needed to fit the craft design/space limitations but had the same range as a different design.

With this in mind I am thinking of simply making my additions a multiple of three (six in this case) and staying with the three range definitions set by Toadicus to make my additions to the three stock antennas to equal three short, three medium and three long range antennas. At this point is when I thought of a different approach.

In the game there are the following four definitions to be found in the cfg files of the 'Command' folder parts

vesselType = Ship

vesselType = Probe

vesselType = Rover

vesselType = Lander

What if an antenna was designated to be usable only for that type of part? Capsules would then need three types of antenna to cover all three range distances, probes, rovers and landers the same. This would give a reason to have more antennas other than just 'for looks' and would IMO add more flavor to a career progression.

I have been looking at the code (but my last coding days were 10 years ago in flash/php ) and am not sure at this point if the science experiments (which seem to be module defined) would have to check to see if the pod/probe/rover/lander they were a child to had the proper antenna for that root part. I have merely been looking at it in terms of a MM patch to make an antenna specific to vessel type. I also have been thinking that it might be advisable to make the three stock antennas usable to all four vessel types so players who do not add or add only a few favorite antennas can still play without undue complication.

I respect the amazing work/skills/insight of all here on the KSP forums so I ask; Is it an interesting idea or just 'whistling in the wind'?

[toadicus]

jpkerman, I'm still looking to foster a more-directed environment for user-contributed configs for part mods. Hopefully I'll get something moving in that regard this coming week sometime. A part of me really wants to jump in and help you all write configs for all the parts you could ever want to use, but another part of me knows that's a rabbit hole from which one scarcely returns with one's sanity. I've got a couple of ideas for a middle ground; we'll see what happens.

On the vessel type thing: my main complaint -- after basic realism -- is that vessel type is arbitrary. You can pick vessel type from the Rename Vessel dialogue any time you please, so it's not so much a restriction as a potential nuisance. Sure, a player here or there (perhaps yourself included) might find it a useful guideline to stick by, but because it's fundamentally arbitrary, I'd just as soon write it in the description and let you take it from there.

I think a 5 antenna pool actually works really well, and smunisto's got something good going with that for his Origami patches. Go back a couple pages and check them out; see if you can use some of his rationale to help you with the AIES parts. I don't know anything about the AIES parts or what they look like and do, but if they line up well enough, you could pick three of them to patch the stock parts, and two to be longer range, or some other permutation on that idea. Or you could try to find a 7-part balance!

The possibilities are literally endless, and that's the whole problem. I'd like to help, and I'll do what I can. Good luck.

[jpkerman]

Thanks Toadicus, I had not realized that vessel type is arbitrary, which exemplifies my hesitancy to offer a mod since I would probably not be much help if there were bug conflicts in other player's games. I'll continue to think on this.

[vardicd]

What would I have to change to alter the upgrading of the tracking station to Improve range values?

This line?

TRACKING_STATION_RANGES

{

range = 800000

range = 200000000000

range = 2000000000000

}

[toadicus]

Yes, that's where. Those are "max" values, not nominal values.

The official way to change it would be with a ModuleManager patch (definitely do this if you're going to distribute your changes):

@TRACKING_STATION_RANGES[*]
{
	@range,1 = 400000000000
}

The ",1" is a zero-based index, so that example would change the second entry (Tracking Station Level 2). Non-career games use only the third entry.

[vardicd]

Yes, that's where. Those are "max" values, not nominal values.

The official way to change it would be with a ModuleManager patch (definitely do this if you're going to distribute your changes):

@TRACKING_STATION_RANGES[*]
{
	@range,1 = 400000000000
}

The ",1" is a zero-based index, so that example would change the second entry (Tracking Station Level 2). Non-career games use only the third entry.

I have no plan to distribute, this will be a for me change only, I want to reduce the upgrade range, maybe even limit it to the first level only. [ so the range never increases] forcing you to use relay sats, which I've balanced by moving all the antenna's up in my tech tree. Thanks for the help.

[Gribbleshnibit8]

I have a probe in orbit of Ike with a small antenna on it, and another probe in orbit around Duna with the large dish. However, instead of talking to the dish and on to Kerbin, the small probe is attempting (and failing) to get a direct line to kerbin. Upon further inspection, ALL of my probes are now taking direct lines back to Kerbin instead of linking through the closest lower power link. My tracking station is fully upgraded, line of sight is off, additive ranges is on, and I'm running the update from the other day. They were working properly before the update, so I guess I'll revert to the last version, since I really need those science points!

[KerbMav]

My tracking station is fully upgraded, line of sight is off, additive ranges is on

Especially this I would guess is responsible?

[toadicus]

Gribbleshnibit8, by "before the update" do you mean "with dev builds using additive range before the release" or "with version 1.9.x"? Also, because I've made mistakes in the "LOS is off" side of things before, do connections work as anticipated when LOS is on?

Also a Comm. 16->Comm. 88-88 connection has a maximum range of 25,806,976 m. That's quite a bit beyond Ike's 3,296,000m apoapsis, but it's worth mentioning in case your 88-88 is in a really high Dunan orbit (well outside Ike's orbit). Are your vessels in range of each other?

- - - Updated - - -

Update with two more relevant questions: had the active vessel just undocked from the probe to which it should have been transmitting? Sometimes that messes things up, but should fix if you change vessel.

From which probe were you observing this lack of connection? I just duplicated something like your scenario, and when I was observing from the relay satellite (in Dunan orbit), the Ike probe did not have a connection but when I was observing from the Ike probe, it did. This is a bug; I'm looking in to it, but it might present a workaround for now.

Edited June 17, 2015 by toadicus

[toadicus]

Another update: I found the bug preventing vessels from using the active vessel (and actually a lot of other vessels as well) and squashed it. I'll try to release that tonight.

[Gribbleshnibit8]

Well I reverted back to version 1.9.1 (from 1.10), and everything worked as expected, with a few blackout spots in the various orbits due to distance. When I first noticed the issue, it was an inability to transmit science. So I exited to the space center, loaded another ship, and from that ship put focus back on Duna. All ships (I currently have ships in orbit around Kerbin, Minmus, Kerbol, and Duna) had lines drawn directly back to Kerbin, ignoring any closer links.

The setup is: Probe on Ike with Comm. 16 -> Satellite in orbit of Ike with Comm. 16 -> Satellite in orbit of Duna with 88-88.

Running the current version from Kerbalstuff, this is the communication path around Duna.

When viewed from another probe, and previously from any ship, this was the configuration of paths.

When viewed from the Ike satellite, it connects normally (though had not before). I believe that yes, the initial issue was after having detached from the 88-88 carrying satellite, without changing scenes or switching vessels.

I don't think I'm being entirely helpful, sorry.

[toadicus]

I'm guessing the next version will fix your issue; on average about half of all relays were unavailable to half of all relays.

Basically, I build a list of relays that should be checked against during searches. But I also started searches during that the loop that builds the list, which means vessels that come "early" in the list (sorting is probably arbitrary but consistent) do not have access to vessels that come "late" in the list. I didn't notice it because I was always testing with networks covering much smaller distances, and always focusing on the active vessel, which always checks last.

I'm now starting searches from a post-loop after the build, so that problem should go away entirely.

[toadicus]

AntennaRange has been updated to version 1.10.1! This version fixes an issue that prevented relays on about half of vessels from targeting relays on about half of vessels. This should correct the circumstance reported by Gribbleshnibit; thanks for reporting!

CHANGELOG:

v.1.10.1 [2015-06-17]
* Fixed a bug that prevented relays on about half of vessels from targeting relays on about half of vessels.

[Geschosskopf]

Before I do this, though, I'd like to hear cases for ground stations that address at least two of these three criteria: realism (is the concept grounded in reality? how?), "fun" (does the concept offer challenging but rewarding gameplay? does it help the player feel clever or successful? how?), or educational (does the concept help teach new players how to play the game? how?). I'm willing to concede realism to some degree, but since I'm guessing the ISS blind spots are the fault of oceans or political gamemanship, and the latter isn't modeled in KSP, and since real-world space programs managed to negotiate nearly worldwide coverage at the very dawn of space exploration, it feels like a weak argument on its face.

I strongly encourage you and other interested parties to make such cases. I really am very happy to listen and have my mind changed.

Hope this poll is still open .

Anyway, I'm totally with you on avoiding tedium and rewarding cleverness, and consider AR's lack of needing either 360^ of ground stations or 360^ of commsats both fun and realistic. I say keep on without making players do anything to create an infrastructure at Kerbin or, at most, make creating Kerbin infrastructure an option. I say so for the following reasons:

REALISM:

Realstically, KSP is in another universe where all 4 of the fundamental forces are radically different than in this universe. As a result, nothing on our periodic table can exist in the KSP universe, and from there on all things diverge even further. Thus, all so-called "realism" features and mods in KSP are actually exactly the opposite because they impose Earthly conditions and physical properties on a place where they can't possibly exist, or impose human biology on totally alien (from their very chemical elements on up) Kerbals.

Do not give in to this vile temptation. Denouce the false prophet of so-called "realism" and accept the true reality of KSP. And that reality is that ultra-dense Kerbin provides grovides gravitational lensing to any ground-based antenna on its surface, so the tracking station at KSC can talk in all directions all the time, based on the KSP universe's theory of General Relativity, which naturally is totally different from ours.

That's the best argument I can come up with for this point, but iit's still true no matter how silly it sounds. My main issues are below:

FUN:

Requiring "push-button" purchases of additional tracking stations is no more than levying a tax on players who use this mod. There is nothing less fun than paying taxes.

REWARDING CLEVERNESS

Any cleverness in setting up relay networks takes place far from Kerbin. Anything that happens at Kerbin is just a prerequisite for using the mod at all, a mechanical must-do. Push-button tracking stations are in the same category as RT's geosynchronous network.

Edited June 19, 2015 by Geschosskopf

[Olsson]

I can't find the second antenna anymore. I think my KSP got bugged somehow after I installed remotetech, RSS/RO and then uninstalled it because it wouldn't work correctly with contract configurator.

So I uninstalled all that and reinstalled AntennaRange for my modded KSP but now the second antenna (not the whip or the dish one) wont show up in my VAB/SPH parts even though I've unlocked the tech that it requires!

[Probus]

I'm sorry if I missed this earlier, but I have a bit of a visual bug. AntennaRange is working perfectly, except all the pretty lines are red except my active ship. I've uninstalled and reinstalled and updated to the latest version, but to no avail. About 1/2 my antennas are AIES antennas with an AntennaRange patch. Could it be outdated and causing this problem? Just curious if anyone else has experienced this. I love those AIES antennas. If there is a more updated patch or something I could add to the current one, I would love to know.

Thanks!

[vardicd]

I have a question, I'm not sure if the line of sight Fudge factor is actually working. I have the fudge factor set to 0, yet I still get some relay connections to pass through Kerbin and other objects, when I feel they shouldn't, But I'm not sure if maybe the line of sight option isn't 100% sensitive to the actual surface of objects? Like, It can't tell exactly when the surface beaks line of sight, so it guesses? Pics of what I mean:

Thanks for your time, and sorry if I haven't explained this clearly enough.

[toadicus]

vardicd, you're on one of the edges of the solution I'm using, and an optimization is throwing away the proper solution. Basically when I check if a body is blocking line of sight, I draw a line from the source probe to the target probe. Then I draw a perpendicular line from that line to the center of the body in question. If that second line is shorter than the radius of the body (or the radius * .95, if you're using the default fudge factor), the body is blocking.

But, before I do that, I do a couple of checks to see if I should bother testing at all. One of those tests is "is the body in question farther from me than my target? if so, assume it is not blocking". This lets me speed things up a lot by not checking against Moho or Jool or the Sun, for example, when I'm trying to resolve line of sight for a Minmus probe to Kerbin.

The line of sight check is the slowest piece of logic in the loop, and I've worked hard to speed it up as much as possible. I should probably do something a little differently for probes that are less than radius * 2 distance from the body in question... but just checking for that slows things down a little. I'll take a look and see if I can find a good option.

[vardicd]

vardicd, you're on one of the edges of the solution I'm using, and an optimization is throwing away the proper solution. Basically when I check if a body is blocking line of sight, I draw a line from the source probe to the target probe. Then I draw a perpendicular line from that line to the center of the body in question. If that second line is shorter than the radius of the body (or the radius * .95, if you're using the default fudge factor), the body is blocking.

But, before I do that, I do a couple of checks to see if I should bother testing at all. One of those tests is "is the body in question farther from me than my target? if so, assume it is not blocking". This lets me speed things up a lot by not checking against Moho or Jool or the Sun, for example, when I'm trying to resolve line of sight for a Minmus probe to Kerbin.

The line of sight check is the slowest piece of logic in the loop, and I've worked hard to speed it up as much as possible. I should probably do something a little differently for probes that are less than radius * 2 distance from the body in question... but just checking for that slows things down a little. I'll take a look and see if I can find a good option.

It's okay, Its a small thing, If I go much farther along it breaks connection, I was just curious. It's not something that needs fixing if its working, I was just wondering.