TaxiService

This only happens when there is a break/open in sight of lines between two vessels, causing the network self-refreshed. This is why it flashes fast at high time speed in the video. Therefore, I asked the user if it happens with his high count of 30 or 50 vessels (so many sights of lines)

Hi jimmymcgoochie, Are you able to do the 3 points of Logs, Installed Mods & Persistent Save at the halfway of the guideline? It will explain how to share online. Also, I have few questions to narrow down. Questions: Does it happen in both Flight and Tracking Station? Does this video look like your issue? It only happens at high time speed. Thanks

:-/ I have no choice but to disable the network optimisation. Kindly assist to try this latest develop build to see if it fixes your issue.

I double-checked at my end and the issues are fixed in ckan-downloaded v1.5 on clean install. Please assist to provide the output_log.txt for further investigation.

CommNet Constellation 1.5 is out for KSP 1.8.1 Supported DarkMultiPlayer mod properly Fixed 2 issues of brighter and blinking connection lines Updated CNC MM patch to execute last (no user impact) Linky

Hi all, I am having issue with fixing the last bug of full probe control so if you are keen to play KSP 1.8.1 with CNC mod, please download the latest develop build from the official GitHub site. I will release a new official version for KSP 1.8.1 once the last bug is fixed. Thank you.

Hi, do you feel it may be somehow related to the global setting issue of KSP 1.8? I am encountering odd setting-related issues since KSP 1.8 release, like not remembering my choice of Toggle Snap.

Hi, try RT 1.9.1 for KSP 1.6. The version 1.6.1 contains only 5 bug fixes and won't be affected by RT 1.9.1.

Yah, I am aware of at least 3 new bugs on KSP 1.8. Fast-blinking connection lines Thicker connection lines of Network mode Isolated Comm vessels have Full Probe Control I am fixing those bugs.

RemoteTech 1.9.4 for KSP 1.8 released This release is a compilation against the new Unity engine and KSP version. What are fixed/changed: Upgraded and compiled for KSP 1.8 and Unity 2019.2.2f1 Updated ModuleManager to 4.1.0 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.

Here you go though it is pending my minor correction on that inconsistent readings. Sorry, there isn't any support because it needs major amount of efforts to implement RPM interface and wire it to the component. For the first question, it is both benefits. It acts as a local control point controlling nearby probes far away from home. Second, to qualify for Command Station, any vessel needs to have min crew of 6 Kerbals, 1 or more antenna for comm and 1 giant probe core (I think it is called RC-L01 Remote Guidance Unit). Some time ago (40 page here?), I saw someone else accomplishing a similar mod (1 full-functionality part looking like an actual satellite) using this approach. You need to combine the majority of the patches for antenna and command parts into 1 patch for the specific part. Below may look like. @PART[probeCoreSphere]:FOR[RemoteTech] { //COMMAND %MODULE[ModuleSPU] { } %MODULE[ModuleRTAntennaPassive] { %TechRequired = unmannedTech %OmniRange = 3000 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 15.0 } } //ANTENNA @MODULE[ModuleDeployableAntenna] { %name=ModuleAnimateGeneric %allowManualControl = false %actionAvailable = false %eventAvailableFlight = false %eventAvailableEditor = false %eventAvailableEVA = false } %MODULE[ModuleRTAntenna] { %Mode0OmniRange = 0 %Mode1OmniRange = 2500000 %MaxQ = 6000 %EnergyCost = 0.13 %DeployFxModules = 0 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 15.0 } } }

Sorry, I am not able to advise as I am not familiar with RP/RO mod. There is no Flight Computer command for this automatic landing. At minimum, you need to do by hands some maths of engine deltas, gravity force, suicide burn timing and others to queue a series of individual commands to land safely. MechJeb2 may have this functionality and you should check out. There used to be a mod (Landertrons). There is a workaround to the problem: park a remote control station (crewed and minimum of 6 kerbals) orbiting Duna to reduce the signal delay to 0 sec so that you can remote-control the probe to land. Yes, there is one workaround. Get your crew out of the manned command pod (just hug the pod) and let the vessel to be remotely-controlled. After this, you can retract/extend the piston remotely. The problem is actually a stock bug, in which targetExtension set by player via PartActionMenu is not passed to targetPosition unlike other robotic parts like hinge.

The root range model is min(r1, r2) + sqrt(r1 * r2), where r1 and r2 are the ranges of 2 given antennas. Since the ranges of Com 16 and Mission Control are 1,250,000 m (0.5 antenna range multiplier) and 75,000,000 m (1.0 mission control range multiplier), the max range under the root model is about 11,000,000 m. It is almost close to Mun's distance from Kerbin, 11.4 Mm. The setting of tracking station upgradable range is only applicable when the tracking station is upgraded. So toggling the setting on max-leveled tracking station has no effect on current 75 Mm range of mission control. Hope this clarifies. Sorry, it is not possible to de-couple the flight computer as it is quite rooted in the underlying RemoteTech infrastructure. You may try out MechJeb2 as it is a more powerful tool. Here's the list. I am getting RT2 up to the current scope of RT1 first. I will consider this new input fields of Flight Computer window for PID when I have found some time. Repeated PID tweaking is getting annoying, every time new KSP version is released. Do you have any suggestion for the new input fields? May I have your full output_log file for further investigation, please?

Because of the remote-controlling nature, player inputs can be only intentionally passed to the target moving part while the stock action route is blocked. However, this limitation is only applicable to remote connections and the manned vessel (under local control) should not experience this limitation (I haven't checked yet).

RemoteTech 1.9.3 and 1.9.3.131 for KSP 1.7.3 and 1.3.1 released This release is an update for Breaking Ground Expansion plus couple of quality-of-life improvements. What are fixed/changed: Support for robotic parts and Custom Axis Groups introduced by Breaking Ground Expansion Limited support for deployable ground parts (Omni 400km range to control station only) Improved PID Controller on torque forces Persistent position of Flight Computer window across play sessions 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.

This is one of the common discussion points, which we conclude it would be eventually discouraging because of the tedious management and recovery. It is doable but I haven't seen much enthusiasm on this feature over time. It is displaying of connections only. You can safely ignore this error if it does not impact your gameplay or network correctness.

Hi, if I read your non-dependency statement right, you only need to check if RemoteTech's API class is available to call (linky). Within this API, you can use two methods, HasAnyConnection to check if the vessel has working signal, and HasLocalControl to skip manned-crewed vessels.

Yes, RT 1.9.2 is working fine with Breaking Ground, included robotic parts, except for non-response ground station parts and remote-controlling hydraulic parts. The next version will be mostly robotic fixes and support for the stations. You need to toggle this setting in RemoteTech_Settings.cfg in your save folder. FCOffAfterExecute = False What it will do is to turn off Flight Computer after executing a maneuver command.

Hi, just a quick update on new RT version for Breaking Ground expansion. I gonna to wait until 1.7.3 with bunch of fixes and changes to see if the robotic and science station issues are resolved.

It is not really bug. Both NODE and EXEC commands are separate operations. Once EXEC command starts, preceding NODE command will be removed. THis EXEC command has own NODE tracking rather than depending on external NODE command. Sorry, I am not familiar with RP-1 to advise on the ground station unlocking. But I thought all ground stations are supposed to be shown immediately at the beginning? Like something "dsn.cfg" in RemoteTech or RP folder in GameData?

@kcs123 Wow, you are right. This signal modulation is too complicated and not something I or non-technical players can understand in short time. But I agree on the distance and signal-to-noise ratio being good factors of signal quality, in which this is why I use the theorem for clear understanding (I think?). It is the global position of the craft (x,y and z) so you better come up with a way to float your radio station above surface (maybe a balloon?) Sorry, you need to check with Kerbalism team and provide the save to replicate the error. It looks like unexpected result is generated when calling RT's API (HasDirectGroundStation) on a given craft.

So this is what the signal modulation is utilized for. I had trouble of understanding the modulation uses, other than increasing the bit rate per wave. Analog/digital signals seem to be boiled down to the frequencies (1 to 100 Ghz) used, which strongly influence the desired properties of signal, isn't it? You could try out the comm model implementation once it is implemented sufficiently to be public for feedback. The realism of the RT2 comm model has to be verified in actual gameplay before further enhancement could be made. All I have is a theoretical paper with zero experiment results.

Signal strength is not very good indicator on radio signal quality, especially if you want to planning a timed transmission of big science dataset. Shannon–Hartley theorem will be the end-result formula to calculate the data rate at the receiving end. I will quote this from the example section of RT2 thesis. Basically, major inputs for the theorem are (1) signal power received, (2) noisy space conditions the signal propagated through and (3) frequencies. With these (most of?) factors known, you can budget for downlink rates on science transmissions in opportunistic windows. I am not sure if the analog and digital types are related to the following planned overhaul. All the antenna parts in the tech tree are to given additional attributes required for RT2 comm model: (1) surface area, (2) antenna efficiency and (3) frequency restrictions (not exhaustive list). The earliest antenna would be primitive with lousy attributes, and higher-tier antennas would be better in attributes and additional abilities (phased array?). Folks in RSS domain say RT2 comm model is more realistic than their current reworking (CommNet-based RealAntennas). I managed to provide limited support to the deployable science parts: 400km Omni range to control station Connection will be lost if the science cluster has insufficient or no power Unable to support the dish part as it is not physically linked to the control station (unlike a LEGO-style vessel) Much of the science part codes are unmoddable to control the background deployed science transmissions (it will transmit in background regardless of RT connection). Right now, it requires too much work for little results from this.

No, it is not. The design choice of deployable science parts is strange and doesn't conform to a typical vessel design we modder are familiar with. Its power is just 0 or 1 and parts are not physically linked. I am trying to get RemoteTech to work with the science stations but I am not optimal.

There is the separate signal delay mod for CommNet at this thread. It is working fine with CNC mod. ---- CommNet Constellation 1.4 is out for KSP 1.7.1 Supported deployable controller and dish of Breaking Ground expansion (should work fine in KSP without the expansion) No more blurry interface textures if your texture resolution setting is not full Scroll lists will start at top instead of middle. Linky