TaxiService

Hi, many thanks for your detailed report! I gave a quick test on KSP 1.3.1 with CNC 1.1.1 and MM 3.0.1 and found no connectivity issue. Based on the exceptions you found, it seems one or more antenna/probe-core parts involved may be incompatible, causing invalid CommNode data KSP was trying to read. So here're few questions for you: Can you recreate your vessel with stock probe-core & antenna parts and see if it can make connection at the launchpad? Can you list the non-stock probe-core/antenna parts involved in your vessel on the launchpad? Can you take a screenshot of your non-working vessel so that I can see what parts were on it? By the way, I remember ScienceRelay has its own CommNet function (inconsistent logic like transfer to another vessel without CNC connection) but you mentioned your existing vessels in space are working as normal. I don't think it has something to do with ScienceRelay. Thanks!

Hi, Can you elaborate on this? Did you delete the maneuver node after queuing a burn-node command, and then recreate a different maneuver node? The Flight Computer will delete the current node if there is a mismatch between the node referred by the burn-node command and the current node. If this is not in your case, please provide a screenshot of your node(s) and Flight Computer's command queue on map-view.

Hi nightingale, A couple of players reported a Reflection issue of Contract Configuration 1.23.3 against newly-released RemoteTech 1.8.9 on KSP 1.3.1. Here's my output_log file. Based on my investigation, the reflection issue seems to be due to the attributes of a new functionality added to RT 1.8.9. Here's the offending commit of RT codebase. I guess CC was compiled particularly against RT 1.8.8 and didn't expect the new attributes but I can hardly believe the reflection could fail against new attributes. If possible, please advise me on possible changes required to be make to RT codebase to resolve the reflection issue.

To my knowledge, there is no mod with this feature for CommNet yet. I do know that RemoteTech has one of the visual modes, MultiPath that displays all the working connections (aka shortest paths) of all vessels in the Map View but it does not use CommNet. Speaking of this, this MultiPath mode happens to be on my TODO list of CommNet Constellation as I need to replicate it for stock CommNet.

RemoteTech 1.8.9 for KSP 1.3.1 released This release 1.8.9 is standard maintenance, contained few improvements. What are fixed/changed: Flight Computer's modernised steering of a probe or rover Support for the two probe/drone cores of Mark IV Spaceplane System and VDS Hullcam 2 new power commands to hibernate and wake up (require care in scheduling to avoid eternal sleep) Functionality for third-party mods on relaying signals through designated probe cores 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 post. We are in the RT 2.x branch development and continue to support the RT 1.x branch.

Besides Akira_R's points on logic size, I have no idea how big the impact of this feature would have on the overall gameplay. Maybe it makes sense at early stage but it would reach the full scope of command station eventually. Pretty slow pace, I am afraid. I am shifting back to RT2 from RT1 maintenance, after resolving most of RT1 obstacles in way. Most of the CommNet core features from CNC are already committed to the RT2 codebase, with some non-CommNet features to be incorporated at various stages of RT2 dev later. At least, the big question of third-party mods fighting over CommNet is close to an end so I don't have to wonder about potential mod conflicts now.

Yup, your diagnosis looks correct. Your Du-R-Sat's antennas, Communotron DTS-M1 and HG-55, are Direct type unfortunately (linky). I am wondering if the second satellite you launch has indeed a Relay-Type antenna.

I am not really warm to this request of reduced functionality. You could schedule a sequence of timed commands in advance for the period of no connection or intersect some RT commands with MJ commands in coordinated sequence. Somebody with more experience on using RT and MJ could chime in on this. Yes, this change will work. There is only the single part with this command station function in RT.

Yup, if the vessel doesn't have any probe core (not crew pod) for remote control. Having a probe core will give you the local control status.

Log file: https://drive.google.com/file/d/0B5SB-NbR0T_1ZUN0YmlibU02UTA/view?usp=sharing Yup, it is an odd quirk of Flight Computer, even existing before the rewriting of PID unit. It has to do with the target roll of a kill rotation and Quaternion math, that I hesitate to resolve I don't understand fully. If you check the video you posted, you would observe the vessel's roll coming to a stop at the end after overshooting the target roll twice. Hi, I need few more details about your situation: What is the current range of each tracking station? 75Mm? Can you provide the map view of Kerbin and Mun (with the omni visual)? Your satellite is 3Mm (6.5%) away from max range 40Mm. I suspect your network (3 geo sats and 3 tracking stations) around Kerbin is spreading too thin, resulting in coverage gaps.

Yes, I am interested in this possible bug. Please provide the screenshot of your vessel (The parts influence the PID rotations greatly) and output_log.txt from KSP_x64_Data folder.

Hi all, I release a second beta version of 1.8.8 with modernized PID controller and new power-saving commands. Since PID is changed so much and the power command has the potential of eternal sleep, I don't want to release a new official release to public yet without throughout testing and feedback. If you find any problem with PID or power command, please provide screenshot of your vessel and output_log.txt from folder KSP_x64_Data. P.S. Please make a backup of your save first.

Do I have your attention now? This is the modernised PID controller of RT but I need your help to test your vessels in a wide range of scenarios. You can download the latest RT build and install. It is the same 1.8.8 with this PID update. If you find any problem with PID, please provide screenshot of your vessel and output_log.txt from folder KSP_x64_Data. P.S. Please make a backup of your save first.

As far as I can tell in the codebase, there are no specific requirements on composite of min 6 crew. Could put full 6 scientists and it should work. Also, the RC unit is only required to function so any crew pod, such as the habitual module, is fine. Other than these above, I don't think you miss anything.

Ah no, you miss out couple requirements for a manned command station. This vessel must have at least six kerbals and has the big probe core in order to qualify for a command station.

You should be able to set up multiple maneuver nodes and click EXEC button on Flight Computer in RT 1.8.8. What is stopping you from doing so? If possible, please provide a screenshot and the output_log.txt in the folder KSP_x64_Data of your KSP installation.

Hi lemmenes, Indeed, I am the only person still working in the RT cleanup and development after one year. You are welcome to join us if you feel you can tackle the technical challenges of building an usable (and self-sufficient) antenna system in RT2. I can help to bring you up to date on RT aspects, development and C#. I am requesting one developer on board for document/sketch on his comm theory on the antenna system to be passed to next developers/saved for near future (there are some past messages on this in the RT chat channel I can pull out). I am not really familiar with the RF communication theory and applications. Let me know if you want to join us. Currently, hibernating the probe core will reduce the core's power consumption but its antennas' power drain is not affected. I think extending this hibernation to the antennas' power drain would mean a reduction in communication ranges, something requested for RT2 (https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/272). Akira, two new buttons to put the whole probe to sleep (no communication and probe-core hibernation) and wake it up (like the sleep button of a computer) in Flight Control are doable for the current RT. Obviously, care is required in scheduling these sleep and wakeup commands or say hello to the eternal sleep. Is this correct?

I do not have any better idea on how to visualize the diminishing connection strength. This works well in stock CommNet, where green and red colors are the strongest and weakest signals respectively. But this mod with all connection colors? I haven't figured out how to paint a connection (say flashing, dashed or thick lines) in KSP.

Ok, the latest log indicates pretty normal. I tested (should check in the first place) the CommNet range calculator with 56M and 2M on both sides and found that the estimated signal strength is close to what you observed (< 5%). The max distance of this connection is the square root of the product of the comm powers (stock CommNet rule) so it is no wonder this signal strength is so low.

Thanks, I found this strange contradiction on Altas III, which has a single frequency 11 in use, as shown below. Line 218689: CommNet Constellation -> verbose: CommNet Vessel 'Explorer II' has the single freq 0 of 250000 power Line 218693: CommNet Constellation -> verbose: CommNet Vessel 'Explorer III' has the single freq 0 of 5000 power Line 218697: CommNet Constellation -> verbose: CommNet Vessel 'Atlas II' has the single freq 11 of 2000000 power Line 218701: CommNet Constellation -> verbose: CommNet Vessel 'Atlas III' has the single freq 11 of 2000000 power Line 218705: CommNet Constellation -> verbose: CommNet Vessel 'Atlas IV' has the single freq 11 of 2000000 power Line 218709: CommNet Constellation -> verbose: CommNet Vessel 'Atlas V' has the single freq 11 of 2000000 power Line 218713: CommNet Constellation -> verbose: CommNet Vessel 'COMSAT-K1' has the strongest freq 10 of 22627682162.4946 power Line 218717: CommNet Constellation -> verbose: CommNet Vessel 'COMSAT-K2' has the strongest freq 10 of 22627682162.4946 power Line 218721: CommNet Constellation -> verbose: CommNet Vessel 'COMSAT-K3' has the strongest freq 10 of 22627682162.4946 power Line 218725: CommNet Constellation -> verbose: CommNet Vessel 'COMSAT-K4' has the strongest freq 10 of 45874783.7361884 power Line 218729: CommNet Constellation -> verbose: CommNet Vessel 'COMSAT-K5' has the strongest freq 10 of 45874783.7361884 power Line 218733: CommNet Constellation -> verbose: CommNet Vessel 'COMSAT-K6' has the strongest freq 10 of 45874783.7361884 power Based on this, the connection of K5 (very low power) and Altas III (2M) is using the frequency 11 and hence very low. Can you check-double the frequency list of Altas III and the activation of its dishes antennas (need to extend in order to use)?

The output_log.txt is up to the main menu only so none of the communication data is written to the log. If possible, launch KSP, resume into any vessel and then exit normally. The requested data should be written to the log by now. (What a fun timing with KSP 1.3.1 release) Edit: Nice. Both CNC and RT for KSP 1.3.0 are still working in KSP 1.3.1 so no need to recompile this time

Hi, Can you provide the output_log.txt in the folder KSP_x64_Data of your KSP installation, please? I deliberately wrote the communication info of every CommNet vessel to the log for such troubleshooting. It seems the total powers on Atlas III and K5 could be relatively low (you can try out this CommNet range calculator) but like you said, this doesn't make sense with these much powers.

Hi, Are the dishes of your Kerbin comm sats Direct-type? They won't relay any connection from your Mun sat, whose omni-directional antennas are direct. (I think it is stock CommNet rule) I tested another sat with Relay-type dishes and it connects to the Mun sat.

Hi, Sorry, we have no ETA on RT 2.0 because neitsa and yamori are not online for some time. I am porting the non-infrastructure parts of RT1 to the CommNet layer as the first step towards RT2.

Yup, a (manned) command pod doesn't have signal processor by design so you need to add a probe core in order to utilize this processor (as well as flight computer). The "local control" text means the local control by your crewed pod. Your relay is just ready for a remote connection should your crew be out of command pod.