TaxiService

Announcement Pre-release 6 of the coming CommNet Constellation 1.1 is available for public feedback. Further play-test may be required to be sure there are no more big bugs. Please backup your saves before installing this potential-destruction version. Link: https://github.com/KSP-TaxiService/CommNetConstellation/releases/tag/feedback.300717

@Bonus Eventus @xEvilReeperx Do you have some keywords/tips on BaseEvent, BaseAction and GameEvent for this functionality to help my learning? I am testing some of these things, included UIPartActionController. EDIT: Never mind, I found one easy way. ModuleDeployablePart has two EventData for moving and stop animations. I just add my own callback to these and both ActionGroup and extend/retract click call mine. Thanks for pointing me towards EventData!

Hi, I am trying to find out if KSP has a GameEvent or some kind of notification on part deployment (can be antenna, solar panel, landing gear etc) and ActionGroup (eg toggle antenna extend/retract). The closest one I can find is `GameEvents.onPartActionUIDismiss` which is almost suitable for me. But I am not finding an easy way to hook to ActionGroup activation. The reason for this is to run some update codes on demand, rather than FixedUpdate() pulse to check and run if change is detected. Thanks!

Hi, thanks for letting me know on the action group of deploying. I am fixing up on the vessel staging event.

Hi, We are aware of this issue of node chasing. This usually happens when the TWR of your vessel is too high and the vessel starts to chase the node point around, trying to archive the zero dV fruitlessly. One or two improvements on the maneuver node execution were already in the develop branch to terminate instantly when the lowest point of dV is reached (rather than trying to reach the zero point). The other issue of excessive/little torque may be related to the experimental PID codes in RT (see this issue for interested). This outdated PID handles the torque workings, and in turn controls the pitch, roll and yaw of your vessel but it does poorly nowadays. We plan to attempt to separate and update this outdated codes with the latest codes from either kOS or MJ soon. Frankly, I have little experience with the RT's science experiment handling now. This is the first time I hear of this kind of problem and am not sure how I should analyse and decide how to proceed. Maybe down the road, I might take a close look at this.

Hi, I haven't researched into this feature of adding extra ground stations besides the stock ground stations yet. This is one of the RT-related things I planned to do on this CommNet testbed after releasing this coming major version 1.1.

Announcement Pre-release 5 of the coming CommNet Constellation 1.1 is available for public feedback. The remaining tasks are another code review and play-test to decide whether the official version 1.1 can be launched. Please backup your saves before installing this potential-destruction version. Link: https://github.com/KSP-TaxiService/CommNetConstellation/releases/tag/feedback.160717

That's the thing. I observed manned pods are given ModuleSPUPassive (lacking Flight Computer) while probe cores get ModuleSPU (with Flight Computer). In my quick check, I can't find any obvious code that assigns ModuleSPUPassive to manned pods.

@nickicool@KerbMav You miss out one more square bracket at the end: @PART[*]:HAS[@MODULE[ModuleCommand,#CrewCapacity[>0]]] Nevertheless, it doesn't work in my RT tests. It seems there are both design separation and guard in the codebase. As far as I can see, there is one workaround to have Flight Computer available for manned vessels is to attach a probe core to the vessel. It will act like a local computer to use in absence of working connection, as shown below.

Thanks for your log! This telescope part is belonged to the ResearchBodies mod and has the invisible manned capability (this is why you got local control). But it doesn't look like this mod supports RT, sorry. This orange and green color has nothing to do with RT. It is KSP's indication about your computer performance (blinking orange means moderate/heavy CPU load). We have a branch on RT 2.0, which has this constellation/frequency idea in its proposal (eg #187). So it will be eventually included ;-).

Yup, I add the new ability to block all keyboard inputs in the coming release 1.1 This is an interface bug of unable to rebuild the frequency list under certain scenarios. I fixed it in the next pre-release version. Yup, this is a CommNet conflict which I lost to. Kerbalism has its own CommNet feature: You are able to set up each antenna in VAB or SPH (assumed you are using CNC 1.0.2). Just right-click any antenna or probe core and configure away

Hi! This yellow icon means your vessel is controlled locally (act like it is manned). Seeing nothing manned pod on your vessel, your probe core may be unsupported (not patched by RT). Can you tell me which mod this probe core is from? Or you can look at our cfgs for supported mods at this link (eg FASA, B9) If possible, please give us your log below.

With two or more CommNet subclasses, there would be conflict among host mods and KSP will pick one out of those to run. I do not think your issue of antennas being locked is related to the occlusion. This occlusion tests on the line of sight between two points It seems to there are multiple causes to lock antennas - RT, time acceleration, within fairing, part clipping, old UI bug :-/

Do you mean this occlusion setting of CommNet? Set to the max value and connections will not penetrate planet/moon surface.

It could be done but it is not simple because every UI and computer action has to be hooked. Take a look at one of the RT classes involved in the delay process. It has a lot of wrapping codes around those actions. I rather not spend a lot of time on re-inventing the signal delay in this mod.

This stock facility has 3 levels in total. Level 3 is the final RT range of 75Mm. But I think these levels are extensible through mods. If a mod adds Level 4 and more, the range of each subsequent level will stay at 75Mm because RT settings have only 3 values for the first 3 levels.

Hmmm, I tested a fresh career session and could see the 4Mm, 30Mm and 75Mm text when upgrading the tracking station. Can you describe the "upgradable" setting? The closest thing I can find is the advanced tweaks option in the game settings. Your log indicates the expected loading, except for this error below. [ERR 17:02:17.723] Couldn't open /home/ricardo/Documents/KERBAL SPACE PROGRAM/KSP_linux/KSP_Data/Plugins/x86_64/liblingoona.grammar.kerbal.so, error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /home/ricardo/Documents/KERBAL SPACE PROGRAM/KSP_linux/KSP_Data/Plugins/x86_64/liblingoona.grammar.kerbal.so) I do not think this error has anything to do with the RT not functioning. I cannot see anything else wrong. Maybe install this missing library and see how it goes? Also, does RT 1.8.6 work in KSP 1.2.2?

Actually, this 75,000,000 range is Level 3 of the Tracking Station. The Levels 1 and 2 are 4,000,00 and 30,000,000 respectively. Hi, can you provide your output_log.txt from the folder 'KSP_x64_Data' with both RSS and RT installed, please? I need to look at the output to see what was going on your side. If I understand correctly, the maximum range is capped at a specific factor in the Default_Settings.cfg. Here're the responsible codes in AbstractRangeModel.cs: /// <summary>Can't boost the range of an omni antenna by more than this factor, no matter what.</summary> private static readonly double omniClamp = RTSettings.Instance.OmniRangeClampFactor; /// <summary>Can't boost the range of a dish antenna by more than this factor, no matter what.</summary> private static readonly double dishClamp = RTSettings.Instance.DishRangeClampFactor; Good news is these factors are now configurable in RT 1.8.7 (link).

Announcement Pre-release 4 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. Link: https://github.com/KSP-TaxiService/CommNetConstellation/releases/tag/feedback.020717

@KerbMav @cyberpunkdreams @Alshain Yup, this well-known problem occurs under certain scenarios with the excessive TWR of a vessel. I took a shot at this and applied some tweaks to terminate the burn immediately at the lowest dV and remaining burning time.

No worries, I can drop and compile it quick. Here's the compiled 1.0.2 version with this code block removed. In my quick test, it seems a relay will talk with its members and public unless the only-member option is turned on. Actually, this is pretty doable to simulate this original function as a new management tool in the revamped system. In this tool, if you input X constellation, the whole list of constellations would be replaced with the X and public constellations, each with the same combined Comm Power of all antennas. If you tick the member-only option, it would remove the public constellation and keep the X constellation. In background, it would automatically update all antennas to the X constellations.

Yup, this is intended behaviour because you set the relays to the public constellation only. According to the feedback on the version 1.0, this is restricting the main functionality too much. I am revamping the entire system to give a dynamic list of constellations per vessel to talk with, instead of a single constellation per vessel (look this pretty picture in the previous post!). It will be in the next major version 1.1.

Announcement Pre-release 3 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. Link: https://github.com/KSP-TaxiService/CommNetConstellation/releases/tag/feedback.170617

Hmm, this OnDestroy() calls come from KSP's PartModule, which ModuleRTAntenna is based on. It seems nothing actionable on our side, other than turning off the verbose. Thanks for your report on our RT Github. I verified this bug is only reproducible if there is another vessel within the physical range of active vessel. You are correct. Flight Computer doesn't have any automatic action to switch to next node if available, after executing current node. A manual click is required to take up a next node but it is useless in presence of long delay or no connection. It looks doable to search for and take next node automatically in the codebase.

It is a simple verbose of notification whenever an antenna is destroyed. But you said it wrote every second? What were you doing, resulting in antennas getting destroyed repeatedly?