TaxiService

Let's have a public discussion because it is a design dilemma of how a comm vessel handles one or more frequencies. I have a few things in mind when I designed this mod few months ago. 1. Each probe core/command module has one frequency and the vessel uses the dominant frequency. 2. Each antenna has one frequency and the vessel takes from its antennas and builds its the frequency list. 3. A vessel has exact one frequency to hold. Considering that KSP's CommNet is the simplified version of the real-life communication network or even RemoteTech, I chose the first option as it is aligned along with the CommNet's philosophy of simplicity. The second option would requires a player to keep track of comm sats' frequencies, risking a difficulty increase in context of CommNet design. Any thought on this? Hmmm, this is good idea but I want to expand it. Would a map filter (like RemoteTech's Multi-Path filter) of showing working connections of all vessels be nice? CommNet's filters are single-path, first hop, neighbours and all-network only. That's cute. This mod will never ever hold a candle to the RemoteTech 2.0 and its huge potential once it is eventually released. I need your output_log.txt and a screenshot of what happen after clicking App-launcher icon. I think the mod window was mis-positioned, out of your screen but it shouldn't happen.

Your guess is as good as mine :S That 2016 output_log.txt is at J:\SteamLibrary\steamapps\common\Kerbal Space Program\KSP_x64_Data? This is where the log is supposed to be written there. Yup, it is correct from what I understand from the codebase (MissionControlAntenna.cs seems to have a special flag for Dish consideration) and my test session.

I definitely want to look forward to your bug report because I can't figure out how in the world RT 1.6 and KSP 1.1.0 were reported.

@Zenithas Hi, Sigma88 informed that you had RT issues so I took a look at your output_log. I do not know what was going on your side but I found that your RemoteTech mod was somehow combined from RT 1.6 (your log said "RemoteTech v1.6.0.0 / v1.6.9") and 1.8 (RT's recently-added multi-path filter is clearly visible in your second screenshot). My best guess is that your RT mod (v1.6.9) was corrupted and could contain some bugs fixed in later versions. But I am afraid that I am unable to offer any further help as I am not familiar with RT 1.6, used by your KSP 1.1.0.

Thanks so much! I verify my mod is present in CKAN. I guess the guide I followed is bits outdated. Hmmm, do you have a suggestion on an useful purpose of that radio prop for CommNet Constellation? All I can come up with is the vessel's frequency can be changed from IVA instead of the outside camera. Thanks for suggesting the option of changing the ground stations' frequencies. I totally overlook this and will add another interface to edit the frequency of each ground station.

Can you check if I set up my CKAN index correctly? I uploaded my mod to SpaceDock and followed this CKAN guide to register it to CKAN. Now, my pull request is the remaining item to complete the CKAN registration.

Yup, this is on my To-Do list. I need to get some CKAN experience first.

Let's review few scenarios you could encounter. If you install RT on your in-progress Career game, all existing satellites will initially have no connections. As JayPee points out, RT Options window in the space center scene has this cheat to configure your antennas directly in absence of working connections. No need to use other mods to edit. If you uninstall RT from your KSP, all satellites with RT parts will be automatically deleted by KSP upon entry into your Career game. But your pre-RT satellites without any RT part will survive the RT uninstallation. Regarding the ground stations, I am pretty sure all ground stations have dish ranges of various ranges (copied from Omni's ranges in MM congifs). Let me check the codebase first and get back to you. Edit: @jofwu Yup, the ground stations do have the dish ranges. Enjoy your RT drive-test!

Hi! I post an official thread in the release subforum. Click

(screenshots inside) What is this? A gameplay add-on for Kerbal Space Program. The purpose is to transform the CommNet network of the single type into multiple constellations of different types. Major features: Make a group of satellites (a constellation) working together to archive a single purpose eg Global GPS, Ground-to-Air Communication Assign a vessel to one or more constellations Edit a ground station Colored connections and icons in Map View Built directly on KSP's CommNet infrastructure Many frequencies (up to 32,767!) to choose for a vessel or constellation Color Picker for "infinite" color choices User-friendly interfaces, included the sort and filter capabilities for the vessel list Bonus: Designed by a RemoteTech developer as a test bed on multiple features of RemoteTech 2.x re-development Why? Three reasons: In our real-life universe, we have satellite constellations of GPS, GLONASS and Galileo talking to their own members. So why can't CommNet have such feature? Every vessel in the whole network is talking to everyone within its root range model. This mod is a testbed for some features of the RemoteTech redevelopment project. (I am a member of the current RemoteTech team) Tutorials Frequent Asked Questions Mods required Module Manager Tutorials Basics and interfaces License GNU GENERAL PUBLIC LICENSE, Version 3 Download GitHub SpaceDock

Oh ok. RT 1.x, which OPM provides its own RT patch for, disables CommNet in place of its own network. OPM's RT patch supersedes the RT aka boosting RT's network system. Sorry, we only have internal develop builds for ourselves only so there is no alpha build for public.

Yup, as Kenny Kerman pointed out the RT issue #107, this auto-targeting mechanism has a large potential impact on gameplay and is debated for quite long time (as seen in the comments there). Although it is not settled for RT 1.x, the proposed extension for RT 2.x on this auto-targeting is on the feature list. For the omni-dish distinction , I checked the RT 1.x codebase and found that the separation of omni and dish (AbstractRangeModel.cs) is deeply embedded. Adding a toggle option of this distinction to RT 1.x would require a considerable work, something we are unwilling to invest in while developing RT 2.x features at the same feature. But based on our preliminary discussion of RT 2.x antenna system, it will be easier to keep the omni-dish distinction and other RT1.x rules as a gameplay choice in RT 2.x. Few of us in the RT team are discussing on this implementation of the targeting in VAB/SPH editors currently. We discover that many of information, such as vessels, required for targeting is empty in the editor because, well, the editor isn't flight. We are working out the cost of writing saving/cache of such data for the editor.

Do you mean activating and selecting each (dish) antenna's target in the VAB prior to the launch? It is not currently possible but I wonder how easy it is to add the target button to the VAB/SPH editor. I think the OPM overrides RT's antenna powers when the OPM is installed along with RT. You can undo OPM's RT tweaks by editting its cfg - OPM_RemoteTech.cfg. But I see it only affects the part RTGigaDish1 (the giant orange dish)

Yup, I understand this. I am opening up both limits on max ranges of omni and dish antennas to be customized in either default or player setting cfg. You are not going to like this. Our rough estimation for the first pre-release RT 2.x is in early Q3 2017 because we are essentially writing new non-infrastructure features. RT 2.x already has the basic infrastructure up and running (missing things are dish pointing and FlightComputer). But cheer up because we are still putting small improvements and bug fixes into RT 1.x, which is still cooperating with other third-party mods like Real Solar System mod. I am not sure if I understand your post correctly. You are unable to activate an antenna on your unmanned probe that you can remotely control? You should be able to activate the antenna when you have remote control of the probe. If no remote control is on the probe, you can't even right-click probe parts because most of the part-action menu would be just hidden. Yup, as Varsi pointed out, here's the post on difference between KSP's CommNet and RemoteTech. TLDR: CommNet has no signal delay, super-easy connection rules and no automation of next steps.

Hi, I am not sure if I understand your intention correctly. You would like to cut down from the default 100 times to 3-10 times the base omni range, right? I found this entry in the online RT manual, in which you could decrease the default value 1.0 of RangeMultiplier setting to 0.1 in the RT Option window in the KSC scene, to achieve the 10 times the base omni range. But this setting change would affects all dish and omni ranges, bringing down to 100 times the base dish range. Will this change in the base dish range be unacceptable to you? Edit: Yamori got a better idea - exposing both limits on the base-range boosts to the default or player setting cfg to be configurable. I estimate it is relatively trivial if implemented correctly.

Ouch. Calvin_Maclure explained well why it happened. Here is one trick for you to revert to a pre-change save. In KSC or Flight scene, press ALT+F9 (not F9) to open up a list window of previous manual and automatic saves. Some pre-change saves should be there. If you are unable to find any old save, i am afraid you are out of luck.

Hi, From what I understand your post, you launched and placed your com satellites prior to the RemoteTech installation but those sats were deleted by KSP for invalid parts after RemoteTech installation. Is this correct? Or are your com sats present but you can't make connections to any of the sats due to the signal rules of RemoteTech? If your com sats are still there, RemoteTech has a cheat toggle in its option window at the KSC scene to configure the antennas of your sats in absence of a connection. (Beware, RemoteTech rules make the sat communication much harder, like shorter omni ranges and limited-cone dishes)

@Bersagliere81 Yup, basically Currently, RemoteTech 1.x branch is what the public uses. We are supporting this branch with bug fixes and small improvements only. It disables CommNet permanently and runs its own network, just like RT 1.1.3. The RemoteTech 2.x branch is the new development onto the KSP's CommNet plus new features that are long requested/deferred/new.

No, it won't co-exist with RemoteTech 1.x branch because RT 1.x disables CommNet and operates its own network (until RT 2.x under development would run on CommNet). CommNet Constellation depends on CommNet to check potential connections between two satellites (think it as additional regulations on connections compared to CommNet's stock open-nature)

Announcement The pre-release version 0.4 is released (link). This is possibly the last pre-release version before I launch an official version 1.0 in the sub-forum of add-on releases. P.S. Please backup your precious saves before installing this mod.

@Blacks @JellyBlade @PhilMcgroin @Jobadiah My apologies for the log spam. I didn't anticipate such name variants of the Mission Control station from some map mods. Thanks for reporting this bug so quickly! As you already found out, a hotfix 1.8.6 was pushed to public few hours ago. P.S. Check the default settings in your GameData/RemoteTech folder and RemoteTech settings in your save folder for the correct "Mission Control" name if your problem persists. RemoteTech 1.8.6 for KSP 1.2.2 released This release 1.8.6 is a hotfix to the performance-killing log-spam related to certain map/system mods. Complete changelog is below: If you find any bug, please report them on our github (as it is hard to keep track of bugs here). Feedback is also welcome for the next release, here or on this github post. We are in the RT 2.x branch development and continue to support the RT 1.x branch

RemoteTech 1.8.5 for KSP 1.2.2 released (See 1.8.6 below) This release 1.8.5 is standard maintenance, contained several bug fixes and improvements What are fixed: KSP's autopilot (SAS) is no longer freaking out in presence of large signal delay Mission Control will be checked and relocated automatically to Kerbin/Earth on some Kopernicus or similar maps KSP's autopilot commands are now delayed properly (no SAS loophole for you) A new visual filter in Map View to display all working connections of all satellites, not just one working connection at any time The issue with not gaining any science data at the end of a science-data transmission should be gone for sure Complete changelog is below: If you find any bug, please report them on our github (as it is hard to keep track of bugs here). Feedback is also welcome for the next release, here or on this github post. We are in the RT 2.x branch development and continue to support the RT 1.x branch.

Near the KSC, I tested a probe with battery and Com 16-S and Com 32 antennas underwater. So far, I maintained the working connection all way down until the battery was flat. (I landed on water very softly to save the antennas from breaking) Seem a connection can be made under ocean surface.

I think I know what you are talking about. Take a look at this issue and is it what you means? Autopilot/SAS commands on all probes are not delayed by Remotetech. A fix to this issue is already being worked out.

To expand Yamori's post, the CommNet in KSP 1.2 has almost everything the RemoteTech 1.x branch requires in order to manage a communication network of vessels. CommNet has nodes, links, paths, com-modules and range models. Every vessel (with or without antennas) has CommNet variable (mesh of RT SignalProcessor, FlightComputer and others). CommNet has all ground stations and occlude info of every celestial body. Even, KSP has the new autopilot (SAS + pilot skills). So basically, CommNet has the entire infrastructure laid down, removing the need for RemoteTech to operate its own increasingly-complex infrastructure (huge fraction of RT codebase is dedicated to this). With this out of our way, we the RT team have a lot of free rein to design and build multiple non-infrastructure features, that are long requested/deferred/new (link). An antenna simulator on science, power and range data Next generation of antenna system (you saw the detailed exchange between Yamori and NemesisBosseret above; RT 1.x has a binary antenna system - 100% or 0% signal strength) UI Visualization of colored icons, vessels, range edges etc Queue of active and timed commands (gears, landing, fire at 250m alt, toilet flushing) In simple words, RT 2.x branch is sort of a "new" mod with some RT 1.x parts, piggybacking on CommNet infrastructure. We are currently developing new features, which can take some time. Of course, we are not neglecting the RT 1.x branch. Since the last release RT 1.8.4, some bugs are fixed and small improvements are added.