TaxiService

A) It is actually easy to switch to the tabbed interface since much of the interface is based on my interface-tab work in RemoteTech 2.x. I would do it some versions later. B) To your mod question, I plan to add via MM my own antenna module to every part that has ModuleDataTransmitter module. As such, probe cores and manned cockpits contain ModuleDataTransmitter. But those internal antennas have very weak stock Comm Power. How would you deal with this weak power even if my mod can support and preserve the internal antennas? Maybe a third-party MM patch to increase those powers by a factor? Edit: I realise a third-party mod like Radio-Free Kerbin can change these Comm Power so I can grab the power variable of ModuleDataTransmitter. I forget about this stock's antenna-power combination as It is too subtle to notice in my play sessions. You should be able to change your multiple antennas to the same frequency to boast the signal power. I will try to preserve this combination there. I updated the change list on this stock combination.

As you may be aware of, there is certainly a lot of room for improvements over the initial single-frequency interaction (it is too simple as you pointed out). I propose these major changes below. 1) Antennas of a host vessel Assignment of one frequency to each antenna A custom name to distinguish from other identical antennas on the host vessel Can only key in one of the existing frequencies with a few exceptions (when an existing constellation is deleted, only update vessel's frequency list) Stock Comm Power of the antenna will be preserved By default, the frequency will be the public one (0) The stock antenna combination will be preserved though it is applicable to the same frequency. 2) Probe core/manned pod parts of a host vessel Each part stores a list of frequencies persistently. In the scenario of a multi-staging vessel (mothership and landers), newly-staged vessels rebuild their lists from their own antennas By default, the list of unique frequencies is constructed from all the antennas A button in the Part-Action menu to bring up an user interface to manage the said list 3) Management interface of a host vessel The obsolete "Talk to members only" option will be removed since desired frequencies can be explicitly assigned to the vessel Display a stored list of frequencies (Active Frequency List) Optional functions on the list Activate/de-activate some antenna-frequencies in the list (the whitelist/blacklist) ??? 4) Connection between two nodes based on their Active Frequency Lists Since the antennas of a vessel can be configured independently, the connection will be the strongest link of the antennas' matching frequency, instead of juggling multiple matching frequencies. For example, Vessel A has Antenna X of Freq 1 and Comm Power 50k and Antenna Y of Freq 2 and Comm Power 10k. Vessel B has Antenna Z of Freq 1 and Comm Power 20k and Antenna Y of Freq 2 and Comm Power 30k. Then, the connection between Vessels A and B is the link of Antenna X and Z since this link is stronger than the link of Antenna Y's. What is your feedback on this? I have trouble of thinking up more management functions on the frequency list.

The interface for editing ground stations is committed to the codebase. What is your feedback on this? By the way, I am re-reading your posts on the frequency & antenna functions.

@MaxPeck Grab the latest pre-release version and test in your normal playing session. I added a temporary workaround to use the text button when the texture is unreadable. Let me know if this work on you and I will push this fix to the normal codebase.

Here's the debug-mode release. Just replace your whole CNC mod with this.

I will put up a non-release DLL without this button image soon. What about TextureReplacer mod? It seems to mess with focusEye image.

Indeed, I am changing to have each ground station/vessel a list of frequencies, instead of single frequency. A) Total 32,768 frequencies (0 to 32,767) B) The craft list is directly tied to the Map View's filters. Go click the type buttons and be amazed! (I better write down this question in FAQ) C) I deliberately design the interfaces to easily update with new content over time. Hence, the initial version has lot of empty spaces.

The core rule is two vessels/ground stations can talk to each other if and only if they have the same frequency. A vessel of frequency #1 cannot talk to another vessel of frequency #2 and vice versa. Likewise, if a vessel is visible to the ground stations of the same frequency, the vessel will connect to those stations. Yup, I should expand the mod description as it was only two sentences. The first page is edited now. Better understanding?

Figuring out it is better to address with your hypothetical example. In this example, your lander craft will immediately connect to the Duna network (Duna Local), which in turn is in contact with Kerbin (DSN). This effectively routes the lander's connection through this Duna network to Kerbin. If your lander is set to the DSN frequency while being in the Duna SOI, it will connect to Kerbin directly. Back to your main post, the UI mode of displaying working connections only, like RemoteTech's Multi-Path mode, is on my feature list. I didn't add it in the initial version as I found CommNet's UI bits hard to understand. Each tracking station is going to have a list of frequencies, not single frequency so by default, it will have the global frequency initially. So when you feel like to add another network, you add the new frequency to the station's list.

CommNet Constellation 1.0.1 is out! Two NullReferenceException fixes. Anyone, please let me know if you can see the newer version on CKAN to update. I tried it but I can't figure out how to force-update over CNC 1.0 on my side.

For now, I am retaining the probe core functionality while adding the frequency function to antenna parts. I am thinking over possible functions of probe cores while the antennas handle the frequency assignment. I will write major view on the design of both probe core and antenna later. Could a probe core contain a list of pre-determined frequencies (up to the max no of antennas attached) to be used for certain scenarios? Like a mothership probe with a landable rover with single antenna-frequency? Whoops, you found NullReferenceException spam on EVA! I will push couple of fixes to this EVA NullReferenceException and another UI NullReferenceException soon.

The RT mod has its two own MM patches for FASA, RemoteTech_FASA_Antennas.cfg and RemoteTech_FASA_Probes.cfg, which should work on your computer. But they are last updated in 2015 and I see the FASA mod is not updated since KSP 1.0, besides the community patches supplied. You may want to post a question to the FASA thread to ask about any recent change in community FASA patches prevent the RT's FASA patches from working.

You are possibly right on this name since this texture is only the one getting blocked while all other unique named textures are not. I go ahead and preemptively rename the texture now. Hopefully, it won't get blocked on next release!

@Shadriss @MaxPeck Yup, the air-to-ground frequency idea is quite good and goes well with the ground-station interface I am coding. It looks like you could dedicate one frequency to this air-to-ground purpose completely. I think the "Talk Only to Members" option is going to be obsoleted by the multiple antenna-frequencies and ground-station interface, isn't it? @Shadriss I didn't touch anything related to the transmission distances. @Crimeo I agree with your assessment on the initial mod version because I didn't get motivated much when play-testing it on my own personal save. These features of multiple antenna-frequencies and ground-station edit have good value addition to this mod. On your request for the RT discussion related to the proof-of-concept, I actually generalise these multiple RT topics to the concept of satellite constellations: Add frequency Revised targeting system Auto-targeting Vessel groups Besides these, I researched into breaking into and hooking up KSP's CommNet mechanisms so that I can port my CommNet codes and bug fixes to RT 2.0 project.

Erm, I made up both RemoteTechVanillaDSN and RTDSN names because the filename itself does not matter because ModuleManager only looks inside the cfg (@RemoteTechSettings). Now, I realise I forgot one very important thing in my previous post. Currently, RT loads your RT settings from your own save folder and ignores the starting RT settings built from the various cfgs, included the cfg of extra ground stations. To force your RT to take these starting settings, open the RT Option window in the space center scene and go to the Presets tab to click the button there. The ground stations should be included into your play session. Sorry for not mentioning this thing before!

No worries. This is why I decide to go ahead and release to public instead of archiving it after prototyping, to get feedback and gameplay ideas to improve this mod from the initial concept of network segmentation. Like this option two of building frequency list from vessel antennas. It is pretty clear from public opinion that the option two offers a better incentive over the current design of one frequency per probe core plus solving one or two potential issues of docking and dominant frequency per vessel. Right now, I am writing up the interface and backend for ground stations' frequencies before moving to the larger change of implementing the option two. For now, the development of RT takes a higher priority over this.

Hi! Two users of my mod reported the issue of one texture file being not readable. I suspect this TextureReplacer mod is the potential cause so I tried to resolve it with "cnc_texturereplacer.cfg" below. However, it didn''t work according to one user. His log shows: Any idea what I did wrong? Thanks!

Ok, thanks for testing. I will go and ask in TextureReplacer thread on this.

@justspace103 @MaxPeck I found out the possible cause behind the unreadable texture issue. Your Texture Replacer mod somehow manages to render the texture file inaccessible. Can you do me a solid by copying this cfg as "cnc_texturereplacer.cfg" into your CommNetConstellation folder and letting me if it fixes the issue, please?

This mod is essentially a proof-of-concept on a a future RemoteTech feature request. As you may be aware of this, the RemoteTech mod is oriented towards more difficult network management, when compared to stock 'launch and forgot' CommNet. You are spot on a higher risk of a comms blackout, just like RemoteTech ;-)

Sorry for making you running around. There is a MM cfg in the much earlier page (page 35?) that adds those ground stations to RT. Copy and paste below as RTDSN.cfg and toss into your RT folder. Enjoy!

Yup, there is another player reporting this target texture being inaccessible, resulting in the toolbar interface crash. I do not have a Mac computer so I can't figure out why this particular texture is blocked there. Any Mac user can assist on this issue?

You can also do in the Map View of the flight scene, not just from Tracking Station. I overlooked the ability of changing the ground-station frequencies during the development. It will be added to a next version.

I will wait more input from public on the frequency design for more inputs. It looks like it is heading for the option #2 surely. Thank you for the screenshot and log. I found the cause on why no reaction is given when clicking. An exception below was thrown: The CommNetConstellation interface crashed when trying to access the target texture. Strangely, this texture is already loaded and all other textures, included the blue global icon, are accessible. Does this problem appear in every session or one-time?

Yes, please submit a feature request to our GitHub on this ability to edit each ground station's attributes through an interface rather than MM/cfg (not necessarily frequency though). This will give us something to think about over time.