TaxiService

@DStaal @roruwok Whoops, my bad. I added something new to the upgrade-version system. The new pre-release should be able to preserve your existing vessels now. @Oectacan Yup, at this moment, the frequency list only reads the antenna data at the beginning of flight and does not react to any antenna change yet. As a workaround, just switch to next vessel or exit/re-enter the vessel.

Announcement Pre-release 1 2 of the coming CommNet Constellation 1.1 is available for public feedback! Note that some of things are incomplete. Please backup your saves before installing this potential-destruction version. Big Picture: http://i.imgur.com/2PvQlBX.png Link: https://github.com/KSP-TaxiService/CommNetConstellation/releases/tag/feedback.090617 Link: https://github.com/KSP-TaxiService/CommNetConstellation/releases/tag/feedback.110617

CommNet Constellation 1.0.2 is out! Recompiled for KSP 1.3.0 while I am working on the frequency list of a craft

Yup, an antenna with the 'Active Vessel' targeting will follow whatever vessel you are actively flying. If you switch to another vessel, the antenna will jump to this switched vessel from the previous vessel. Very useful for one scenario of controlling multiple probes on SOI exits but too tedious to switch back to comm sat(s) to re-target a next probe before jumping to that probe.

RemoteTech 1.8.7 for KSP 1.3 released This release 1.8.7 is standard maintenance, contained several bug fixes and improvements What are fixed: Throttle-loss bug when toggling SAS on a remote-controlled craft was fixed Few improvements in the interaction between Flight Computer and KSP's Autopilot RT mod is dynamically found now (work inside GameData/GameData/Remotetech or even GameData/Squad folders) 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.

Hi, thanks for providing a temporary recompiled DLL! We could not build right away because our master builder was on business leave at the time of KSP 1.3 release.

Hi there, Just an update on the development and the impact of KSP 1.3. Going through KSP 1.3's underlying objects, I discovered there is significant amount of improvements and changes to the CommNet. I need to make major changes first in response but the upside is some of CommNet things are now exposed I want to take advantage of.

I found the likely culprit behind this anomaly. You have this config of your SETI mods (thread), which enables probes to be controlled without a connection. This results in "Local Control" status, which is yellow for the menu. So it is pretty normal for you with this SETI config ;-)

Announcement For your information, KSP 1.3 released yesterday/today crashes under RT 1.8.6. We are going to compile and ship a new one (with the new fixes added since) after our validation tests.

The "Connected" text is only used instead of "D+ xxxs" when the signal delay is disabled. The menu button should be green if the probe has no kerbal onboard and has working connection. I wonder if this probe is stock or third-party mod part? Can you upload your output_log.txt (from KSP_x64_Data folder) and some screenshots of your vessel with the RT text & button please? This sounds very odd.

Actually, the text "Local Control" is independent of whatever color chosen. The color is initially red to indicate no working connection, and only changed to green when a probe has any working connection. But the codebase doesn't have the yellow color for this text. Maybe you were thinking of the KSP mission time above? It becomes yellow whenever the KSP performance deteriorates. Edit: Checking more to be sure

I will chime in this thread and provide some insight into this exception. Both RemoteTech and CommNet Constellation (CNC) are installed in his installation. These mods are not compatible to each other because RemoteTech disables stock CommNet infrastructure and runs its own infrastructure but CNC requires stock CommNet infrastructure to operate (I should put this in my CNC page). It is quite likely CNC is fighting with RT, resulting in data conflict related to RemoteTech and confusing ContractConfigurator. But I am not sure how this conflict occurred because RemoteTech never interacts with stock CommNet in anyway, other than the IsCommNetEnabled check and DisableCommNet command. I did not interfere with antenna parts in CNC v1.0.1.

Nah, CommNet Constellation is not compatible with RT or RT2. It is just a testbed for me to develop, test and port codes over to RT2 redevelopment.

Sorry for the delayed response. I had unexpected short-term commitments in my real life and it should be gone by now. Given that so much codes in my mod are changed and no testing feedback yet, I do not want to release a next official version in one go. Instead, I will release in my other dev thread a number of pre-release versions to gather some pre-release bug reports and feedback. You can expect a first pre-release version within a week. I finished the ground-station GUI, individual antenna GUI, master list of frequency in a vessel, the underlying changes in the network connections. I am doing a GUI for the vessel master list and later a strongest-connection change. Edit: Oh and input locks whenever a GUI is up! No more surprise staging when pressing the space key

Yes, it is possible to have such GUI to configure each antenna from a non-flight screen. In fact, this feature is in early development of my other mod (RT testbed), CommNet Constellation, to choose/configure antennas from the central list in non-flight screen. Given that the delay issue is highly dependent and does not affect the whole thing, I suggest that you pause your testing and wait for a next RT release. We have a few fixes added, included a new improvement round for the interaction between RT's Flight Computer Flight and KSP's stock autopilot.

It is good to hear that you were narrowing down the root cause of the no delay. On this throttle up/down, does this issue match what you are experiencing? It was fixed recently but we haven't made a new RT release yet. I will be honest with you on this. The development pace is slowing down as we are busy with our families and jobs this quarter, unlike the Q4 2016 when we had plenty of free time. I am refining and expanding the functionality of CommNet and Comm vessel in my other mod, which is a testbed. I also am messing with the KSP's new DialogGUI components to design and build interface windows. Yamori is still working on the antenna system and KSP's underlying comm layer, which is unexpectedly harder than anticipated. Neitsa is working on the command queue and abstract commands.

Hi, Yes, this is correct. The CNC mod will act exactly like the stock CommNet with this frequency of 0. Anyway, both KK and CNC are not compatible on the extra ground stations. I worked with and gave advice to KK's author (Ger_space) on the extra ground stations (see this link) but I haven't gone over the extra ground stations on my own side yet. Pinging @Ger_space for comments.

Can I see your output_log.txt per this Log section in the guideline, please? On KSP 1.2.2 with CNC 1.0.1, I could turn on/off the extra ground stations and correctly connect to the stations when on. The mod does not directly interact with the extra ground stations as it only reads the extra ground stations, controlled by the KSP settings. @Bit Fiddler Edit: I just realize that I have worked with KK's author on the extra ground stations. I gave him some advice on how to handle the extra ground stations but I haven't set up mine on my own side. KK and CNC are not compatible yet. Sorry, this edit ability of the ground stations is not available to the public yet because it is implemented only recently. I haven't tested RSS compatibility before but I preserve the Comm Power of the stock antennas. You may have difficulty of connecting two probes far apart in RSS.

I tested the KSP 1.2.2 with RT latest develop, DMagicScienceAnimate, Coatl Aerospace and Firespitter and verified the delay is present when controlling the probe core (WASD keys or setting wheel slider) or engine. I think one mod in your mod list is interfering in RT's control line but I can't find any obvious mod there. Do you have some ideas on which mod? 1. Is this cheat option enabled in yours? 2. If I recall correctly, Outer Planets Mod already has its own RemoteTech config to boast the antennas' ranges by a lot. You should be able to play nicely in Outer Planets with RT. Enjoy!

Many thanks for uploading your output_txt file! The 'RemoteTech.cfg' in 'GameData\Coatl Aerospace\ProbesPlus\Compatibility' indicates that only four out of the Coatl probe cores (Quetzal, Torekka, Barquetta and Tatsujin) are patched with RemoteTech processor. As such, all the other probe cores are never patched to utilise RemoteTech functionality like this local control of the 'Fomalhaut' Lander Probe below. Given the Coatl mod is in beta stage, it is likely that some parts, included the antennas parts) are not patched for RemoteTech yet. You could post a notice on the Coatl's probe cores in the Coatl thread.

Honestly, even with some optimizations (cache, arithmetic shortcuts and logical rules etc), implemented in the RT codebase, the computational basics of network edges and nodes are still unchanged. At a minimum, for n nodes and m connections of a network, every connection (distance, angle, body occluder) between two nodes is tested at every CPU-physic frame (not graphical frame). This gives you a O(n+m) time complexity for this task, meaning the CPU-demand growth is linear when your network grows (which is good). So, it will consume a lot of your CPU time when your network is big.

:-/ then, I need your output_log.txt to see what else was going on.

Yup, the SETI RemoteTechConfig v1.2.2.0 sets EnableSignalDelay to false. Do you have this optional config?

Hi, can you post your output_log.txt as per Log section of bug-report guidelines? I need to see your logs if the EnableSignalDelay setting is False.

I think I need to implement the antenna functionality core first to get some gameplay insight. At this point, I am 70% certain that this edge case of a very early playing without resorting to antenna parts is possible. For your first question part, I echo what DStaal said. Assumed the antenna change is implemented, the stock CommNet is a special case of this mod because the CommNet network is of exact one frequency and the green color. So any vessel requires the minimum number of one antenna (either antenna part or internal antenna in probe core/kerbal cockpit) to communicate to every other vessel in the green network of the same frequency.