TaxiService

Yup, and I think I misunderstand your second one. "all working connections" is what you will see all active connections on all vessels in Map View/Tracking Station. Unused connections will be hidden.

RemoteTech 1.8.10 for KSP 1.4.1 released This release 1.8.10 is standard maintenance, contained few improvements. What are fixed/changed: New cheat for line of sight against planets/moons Delay joystick inputs if signal delay is enabled Stop zero throttle when launching in RO 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.

As in actually connected that you control the vessel. If this meaning is right to you, I will add your German translation to the localization file.

Ok, folks so I played with KSP 1.4.1 (Mission Builder) for while. It seems all mods will be loaded into all missions. Dawn of the Space Age mission is already dead on arrival with all antenna parts hidden at the beginning. Or Trouble in the Void mission is made bits longer with no relay commsat. I think it is going to be pretty fun with communication-related problems arisen in player-created missions. I am going make a new official release for KSP 1.4.0/1.4.1 without any further change soon. Have fun!

Yup, your whole setup of networks doesn't have to be this way. Can try another setup: Solar Network (Frequency 1) with exit/entry comsats (Frequency 2 to N) for local space networks. Be creative!

No, there isn't any tutorial. So I make this tutorial: Basics Consider this picture of a 3-layered pyramid below. At the top, there are certainly sources that control unmanned vessels over great distances of void. These sources are Ground Stations, such as Tracking Station at Kerbal Space Center, and manned pods with antennas. However, the sources need a reliable way to send and maintain control to the vessels without signal collision. To accomplish this, communication networks in the middle come into this picture. One or more networks are known as 'constellations'. Each constellation is associated with a single frequency number with color for easy recognition. Zero or more vessels and control sources can connect to the constellation through this frequency. There will be always a single constellation (called Public or something) at the beginning and cannot be eliminated for accessibility purpose. Lastly at the bottom, there are antennas of a vessel that send and receive frequencies. Each antenna is assigned to a single frequency. This means a vessel with N antennas can connect to up to maximum number of N constellations at the same times. Moreover, two or more antennas can be set to the same frequency to combine their power ratings into a larger non-linear power rating than any of the power ratings. Interfaces There are three main interfaces in KSP. Control Panel at Map View/Tracking Station can be accessed from Application Launcher. It has three separate pages of Constellations, Ground Stations and Vessels. In the first page, you can modify or create constellations. In the second page, there are fixed number of Ground Stations on Kerbal that you can edit their names, colors and lists of frequencies. In the last page, eligible vessels with antennas are outlined with search filters. Every probe core/manned pod has the interface for managing the master list of frequencies, built from the antennas of a vessel. You can toggle off/on all or some antennas. This interface is accessible from the right-click Part Action menu. Every antenna has the interface for the configuration of frequency and name. Like the core/pod, the UI is available through the right-click Part Action menu.

Hi sarbian, I would like to inquire about the effect of MJ+RO on RT. With MJ+RT (exclude RO), I observe that on a vessel equipped with MJ part, RT is not able to enforce signal delay on its own commands (seem got bypassed by MJ). If a vessel is without MJ part, RT commands are correctly delayed. With RO+MJ+RT, every command part has MJ by default. As far as I can tell, signal delay is skipped on all commands issued by RT. The comment for DeactivateControl flag in MechJebCore.cs says MJ can be instructed not to control the vessel (not ideal for RT players who want to utilise MJ's control functions). The current MJ behaviour does not have the concept of signal delay and I do not see a way to shield RT commands from MJ. Is it correct? Thanks.

May I have your output_txt.log from KSP_x64_Data folder of your installation? The issue you describe is known (scenario error spam) and not specific to RT or CommNet Constellation mod (I got few player reports on this too). It exactly happens when reverting from flight and prevents you from exiting Editor or launching. Unfortunately, I could not find a workaround to this error, other than trying to clean up the save that causes the error.

Hmmm, I tested BDB and Constellation from a fresh save and could connect with different non-stock probe/antennas. My guess is that you installed Constellation onto your existing save and the effect taken place was not quite full (need one flight scene to fully initialise). I encountered this intermediate effect during my tests on existing saves. Does this description match to your experience with Constellation?

Bluedog-Design-Bureau, right? I look at the antennas and can see they have the ModuleDataTransmitter module to connect CommNet. But I notice most of their antenna powers are kinda small. Like F21 Helical Antenna's 125,000 against tiniest Comm 16S's 500,000. Try use biggest BDB antennas and see if they connect

Build a next rocket with (activated) longer-range antenna/bigger battery capacity! ;-) Not all antennas are activated by default and require constant supply of electricity to run.

No, RT and CommNet cannot be enabled at same time because of compatibility issue. It is either RT or CommNet at one time. Also, at the beginning of new game, the first step of RT was to disable CommNet. This is why you see CommNet bar in the first launch and then gone in subsequent launches. Based on what is transcripted so far, I think it may be usability. Can you build and launch a basic rocket with a short-range antenna and batteries? Does it eventually lose connection after some distance from launchpad? Yup, MJ is essentially separate Flight Computer integrated into every command part. MJ only checks with RemoteTech mod on the connection status and that's it. What do you expect to utilize both MJ and RT? I am trying to see how players may use MJ and RT at the same time.

I see nothing RT issue in your log, other than the ModuleManager exceptions (you got bunch of ModuleManager versions with 3.0.1 being latest). In referring to your screenshot, I notice the RT delay window is not displayed as it should per my own picture below. CommNet bar is disabled and hidden. It seems your RT is somehow turned off. Can you check RemoteTech_Settings.cfg in your save folder to see if RT is enabled and CommNet is disabled? RemoteTechSettings { RemoteTechEnabled = True CommNetEnabled = False ... }

This comm bar is belonged to stock CommNet. RemoteTech 1.x is not compatible with CommNet and thus disables it to run its own infrastructure. On Github page, you can find the detailed manual link to learn about RT mechanisms. With this said, may I know your KSP and RT versions plus output_log.txt in KSP_x64 folder? If I recall right, MechJeb and RT are fighting with each other over the same KSP's flight controls. Hence they are not compatible with each other. I think I need to play with MJ and RT to see how it happens. I never use MJ before so I appreciate this if you can give some quick reproduce steps to use MJ interface/trigger the fighting. I can't guarantee this can be fixed though. Thanks. Edit: Found how signal delay is ignored on the combination MJ and RT. If a MJ part (pod or box) is attached to the vessel, it acts as an independent command source, completely bypassing the signal delay. If the vessel is without MJ part, signal delay is in effect. I am messing with MJ at this moment to see if more MJ-RT issues can be found.

If I read your screenshot correctly, your probe was trying to connect to Mission Control whose max range is only 75Mm. That 75Mm is only enough to cover both Mun and Minmus. You need a commsat with a long-range antenna in Kerbin's SOI to connect to your probe. Why don't we just skip this and go straight to this point. I am too lazy to cherry-pick some newer fixes into a new RT for 1.2.2. Since KSP 1.3 is KSP 1.2.2 with extra languages, I just re-compiled the latest codebase (RT 1.8.9 plus few new fixes). Here's the unofficial release RT 1.8.9.122 for KSP 1.2.2. Enjoy! (It should work fine. I tested on 1.2.2 quick)

Hi, Is it happening when you revert from launchpad/runaway back to Editor? I have a few player reports (seems happen with other mods) on this issue and can not determine how the hell it happened. In addition, can you provide output_log.txt from KSP_x64_Data folder of your KSP installation, please? Thanks!

@Elouda @5ardaukar I manage to reproduce the zero-throttle bug with re-compiled RO mod. It seems your launch clamp has ModuleCommand (RO is not responsible) that sets RT control state to Local Control at the beginning, as shown below. Once I stage the clamp (and drop the pod instantly), the RT control state is switched to Delay seconds, causing the throttle bug. I will log this bug in Github and analyse and fix the transition from Local Control to Remote Control. Edit: I fixed it and made new build. Can go and test out on your side to see if it is resolved.

Oh right, I forgot about RO. Thanks for informing me!

Yup, possibly not warrant an investigation for this bug type yet. But it is my first time of hearing this scenario of ullage. Why do you need to fire ullage motors to accelerate little before the start of maneuver burning?

This line? //nullify throttle autopilotfs.State.mainThrottle = 0f; Looking at the RO's dependencies, I think it is better and faster to receive your gamedata folder (minus RP-1 if you think unnecessary) if you are okay with uploading the big size. What do you mean by "activated flightcomputer"? The stock SAS on (Key T)? If so, I know why it happened because I miss out some inputs like the joystick feedback.

How did you fix the 1.8.9v FlightComputer.cs? The line 376 of 1.8.7v is shifted by later code changes and I would like to know where you commented out in the 1.8.9 codebase. Also, I want to test the combination of RO and RT since you confirmed 5ardaukar's suspicion. Do you know where can I find latest Realism Overhual version for KSP 1.3.1? All I can see is RO v11 for KSP 1.2.2. If not, I go download and recompile for 1.3.1. Thanks.

Thanks for your log and screenshots. I unsuccessfully tried to reproduce this issue on my side with RT only. On launch clamps, the control is always remote control. In another scenario of a probe rocket with manned pod attached to get the local control in first place, my engine never got shut down upon releasing clamps and then dropping pod. Can you try again with a stock engine instead? I am wondering if another mod or modded part is messing with throttle control.

Ehhh, I wonder what was changing the stock Comm 16 on your side that RTLongAntenna2 (Comm 32) is copied from and scaled up. On my side with CNC only, no nullreference exception appeared. I think Comm32 is still working in your installation, just missing drag data.

Hi, Can I have some screenshots of your unmanned rocket, please? With RemoteTech, remotely controlling needs electric charge to power antenna and probe core so a battery is required to run. By your account, it sounds like the rocket has no electric charge left once the clamps are released. In addition, can you provide your output_log.txt in KSP_x64_Data folder in case I can't identify the root cause in your screenshot? Thanks

Side note: I notice RemoteTech is installed along with CNC in your installation. Both are not compatible with each other if both are running at the same time. But this does not cause this error. Side note 2: I never test both Kerbin-Side continued and CNC at the same time before. So I am not sure if they are compatible with each other. To elaborate HaullyGames' comment, I have seen this Scenario.Load spam before. It usually happens in the VAB/SPH editor when KSP is trying to read the multiple stock & mod scenarios from your save file, not just CNC's scenario. My best guess is one of mods handle its scenario incorrectly, resulting in an error that propagates through other scenarios. I am unable to reproduce this error on my side and can't find a workaround to resolve the error too. Do you remember anything particular interesting/unusually about steps prior to the error spam?