TaxiService

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. 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 and prototype for one feature proposal of constellations in the RemoteTech project. (I am a member of the current RemoteTech team) Mods required * Module Manager License GNU GENERAL PUBLIC LICENSE, Version 3 Current status * Radio frequency for every CommNetVessel instance [completed] * A simple interface to assign a radio frequency [0, 32767] (short-type) to a specific eligible vessel [completed] * All vessels within the constellation of each radio frequency are connecting to each other (default frequency of 0 is public) [completed] * Frequency-associated color of vessel icons in KSP's mapview mode [completed] * Piggyback onto most of KSP's CommNet components and develop a layer onto CommNet for an eventual integration into RemoteTech codebase [completed with on-going refinement effort] * A control-panel interface to manage a number of constellations and satellites [completed] Links Download the releases List of CommNet classes RemoteTech's feature requests on constellation Release thread What can you help? Post some information about CommNet workings. I reckon that having such information available to public will help me or a third-party developer to speed up the development of a CommNet-based mod

>> Minor announcement << A little update on our public proposal of RT 2.x redevelopment. An introduction and list of proposed modules are added to this proposal. You should be able to get more concrete picture of what RT 2.x could eventually look like.

I think you may want to ask (with your output_log.txt) in the sub-forum of technical support (modded?) on the general performance. I have little idea of how the KSP performance goes with a number of mods installed. In each physic/time frame, KSP runs its CPU calculations and mods' CPU-dependent operations so this could be normal or not. :-/

That RT default settings in the preset window is MM-patched. I tested your second scenario of existing game and I can see the extra stations in the existing game after the overwrite. It is basically the codes of RT managing the RT network of connections so I doubt you can't just "make less CPU work" by deactivating some antennas. Is it becoming too burdensome on your CPU? I have encountered this misbehavior during my testing of the few previous releases. The typical cause is the Flight Computer tries to rotato the vessel to a specific point with the excessive torque on the vessel's tiny mass. The underlying codes for this rotation are sub-optimal and do not utilize the KSP's mature SAS yet. We are moving to the KSP's SAS in the RT 2.x redevelopment.

This picture and short description are not good enough to find out why. Please pass your log and save file according to this guideline plus the mod name of that weird cube thing.

1) For the first time, the stock antennas on your satellites will reset to the default RT state (editor/launch state aka not extended) so your satellites will float dead . You need to launch their replacements. Orrrr turn on RT's cheat of configuring antennas in event of connection loss. 2) RT has some non-stock parts. 3) Your stock satellites will still be there but see (4). 4) You need to edit this "EnableCommNet = False" in your persistent.sfs to get CommNet back. RT doesn't have the interface option of turn on CommNet anymore (due to the RT/stock conflicts) until RT 2.x P.S. Maka a save backup before installing RT if you are not sure

Hi! I am from the team of the RemoteTech mod. You may be interested in our new support for MM patches to modify our default settings. We have a new manual page on a patch for a player using your and RT mods.

Hi! I am from the team of the RemoteTech mod. I am following up on multiple bug reports by RT players on planets' conflicting body IDs when using planet-package and RT mods. You may be interested in our new support for MM patches to modify our default settings (included the body ID). We have a new manual page on a patch for a player using your and RT mods. Please disregard this post if your mod does not change the Kerbin's body ID of 1.

RemoteTech 1.8.2 for KSP 1.2.1 released This release contains the fixes to the few issues popped up in RT 1.8.1. What are fixed: Module Manager patches modify RT default settings. (New manual page) Satellite or space station contracts can be accepted or fulfilled. CommNet is permanently disabled by RemoteTech until RT 2.0 integration Complete changelog is below (include future plans and a warning): Hopefully, there aren't any more bugs found. If you find any bugs, 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. Lastly, this is the last release of the 1.x branch and we are already working on the 2.x. We, however, will fix any urgent issue found in RT 1.x branch, that ruins your adventure. Enjoy! (I am contacting the planet developers on the RT's changed approach of MM patches)

No, I am not but I did a lot (and lot) of academic and technical writing in a college.

@Yemo Hi, I put up a draft of the new manual page on the use of MM patches to edit RemoteTech's settings. Besides the RT develop-branch zip to test on your side, feel free to give feedback on the new page.

Each body of the stock kerbol system has unique ID between 0 and 16 inclusively (source). Basically, modders, not just us, follow the Squad's one-step method of identifying. Also, we don't want to pin permanently to the kerbin body as modders want to modify our body ID for their mods.

@Errol, @Jiraiyah, @Nemesis bosseret So far, I read multiple reports of yours on the Kopernicus and planet-package dependencies. It is pretty clear that there are patch conflicts when Kopernicus/planet packages were trying to patch our RemoteTech 1.8.1 (like Body=1). I apology for your trouble because RemoteTech 1.8.0 and earlier versions (as far as Sept 2015) did not have any precedence order for third-party RT tweaks when building up overall settings from our own settings and these tweaks. In RT 1.8.1, I tried to fix this setting feature when dealing with the filed reports of setting override/conflicts, accidentally disabling the function of third-party mod interactions. But cheer up, Yemo (SETI developer) and I had long discussions on a better and safer approach of using MM-patches (precedence order, necessary values instead of full settings) to deliver tweaks directly to our RT settings instead of our current but old approach of reading static RemoteTech_Settings.cfg from third-party mods. Our RT develop branch already has the implementation of this MM-patch approach (I tested it with my very own MM patch of disabling signal delay and adding extra ground stations successfully). Along with new fixes to the few urgent issues reported, RT 1.8.2 should be out in next few days. I will add a new page to our online manual on this MM-patch approach and explain how a modder should convert his/her RemoteTech_Settings.cfg to a MM patch.

Hmmm, I looked at your initial description of the bug again. You are right that your bug is the same bug @NemesisBosseret had (patch conflicts among RT, kopernicus, planet packs). Contact him to ask how he corrected his own bug (something setting the correct values). If not, please file a bug report to our GitHub and upload the required files. It is difficult to determine the exact problem without those files. Thanks!

I advise not to use any pre-release package because it often contains unfinished features (just like this label 1.8.1) or present bugs.

Yes, this is what happened in RT 1.8.0. We didn't change stock antennas in any way until we started add our own modules to them in RT 1.8.1. But I think we are going to mess with the stock antennas' modules in RT 2.x

It sounds like you found the source of this mess that was caused by the planet pack, not our RemoteTech. Best wishes on this.

The thing is I check the files of KSS and Kopernicus and find nothing cfg related to the extra ground stations. :-/ I am puzzled at why it was working before KSS and Kopernicus updates when there was no SETIremoteTechConfig mod that adds the extra ground stations. Anyway, you can reinstall the SETI and perhaps add SETIremoteTechConfig as well. I guess you may have to reinstall RT and SETI to just be sure. (It is getting late for me. Best wish to you on the reinstallation)

Thanks, I discover why you can't get the extra ground station. It is because you didn't include the optional SETIremoteTechConfig mod. Please stick to RT 1.8.0 for while because we broke the function of third-party mod interaction in RT 1.8.1 and are fixing it.

@Yemo We like your proposal of using MM-patches to add tweaks to our default settings. Layered onto the previous approach of third-party modders' static RemoteTech_Settings.cfgs, this better and safer approach is outlined below. Can you please download our develop-branch zip to check if we are in right direction (i.e. allowing MM modifying RT's default settings, that will be used when creating a new game)? For your convenience, I included my test GameData/TestMod/rt.cfg below If you find that this fix restores the RT's expected interaction with third-party mods' RT tweaks and this fix represents our approach of MM-patches, the next release will include this fix and a new page (overdue) will be added to our online manual, explaining we are dropping the old approach of reading a third-party mod's RemoteTech_Settings.cfg for a better and safer approach of ModuleManager.

No, neitsa is leading the RT team of about 3 or 4 members. I am just a coder and thread-sitter.

I asked my RT team on this matter. This feature is not supported currently, and has been requested for while. My own opinion is: Once we move to KSP's CommNet in 2.x, it is possible for your side to query CommNet's active links (Look up to CommLink class) to determine if it is direct to home.

It does appear that this Transmitter module is indeed optional. In fact, I checked the cfg for one RT antenna: @PART[RTShortAntenna1]:FOR[RemoteTech] { %TechRequired = start %MODULE[ModuleRTAntenna] { %IsRTActive = true %Mode0OmniRange = 0 %Mode1OmniRange = 500000 %EnergyCost = 0.01 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 15.0 } } %MODULE[ModuleSPUPassive] {} } To be sure, I deleted the TRANSMITTER module in this cfg and tested a vessel with this RT antenna at KSC's launch pad. I was unable to transmit science because I got error message saying no com device found for science or something.

I doubt this choice matters. Go ahead, thanks!

When you create a new game with RT 1.8.0, no ground stations are found, right? If so, please zip your new save folder and send so that I can at least look into the files there. I have a feeling something in your list of mods is broken and it isn't from our RT but I want to confirm with your zipped save :-(