TaxiService

Oh, I see how my RT colleague came to know during RT redevelopment discussion on modular Flight Computer. I cannot separate current RemoteTech Flight Computer because of its deep dependencies to underlying RT workings. Only a completely rebuilt Flight Computer during RT redev is feasible. The way of adding ground stations should be still unchanged. Please try to click 'Reload' button in 'Presets' tab of RT Options window in KSC scene. It should reload the latest settings (constructed from your installed mods) into your save.

Isn't it essentially MechJeb (with new beta feature of scriptable commands)? Got any link or name to the said standalone Flight Computer?

Yes, updating the variable, RTCommandMinCrew, in ModuleSPU.cs and recompiling is all you need to do. But if you are applying your recompiled DLL on your existing save, edit your persistent.sfs to change the saved RTCommandMinCrew value in all ModuleSPU modules of your existing vessels.

Sorry, that mod author prefers to wait in shadow until everything is in order first. The stock plasma blackout (and its toggle option) is unfortunately located in the CommNet area, which is currently disabled by RemoteTech due to conflict. It would require own codes & toggle option to calculate the flag, which may come later. It seems you are using Contract Configurator and third-party Contract Pack for RemoteTech (not our own). Check out this post. I am afraid there isn't a RemoteTech tool/interface to see the RemoteTech coverage of a body at this moment.

RemoteTech 1.8.10.2 for KSP 1.4.2 released This release 1.8.10.2 is recompiled for KSP 1.4.2. 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. ---- RemoteTech 1.8.10.3 for KSP 1.4.2 released The change in this release 1.8.10.3 is very minor but critical to a third-party mod. 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.

Actually, I saw few KSP CommNet-related mods here like this baby that uses Unity Engine's visual stuff, rather than editing stock stuff. I want to learn and implement for own RemoteTech eventually. Though I can't give solid time frame because my situation is like other indie modders/developers: "developing video games is hard, yo"

Afraid not. Those stock ground stations are saved inside KSP's non-cfg Squad files.

@akron After some tests and code/cfg comparisons, I begin to think that there are really no changes in ModuleRCS's orientations. My issue encountered is likely an edge case of RemoteTech's RCS part. It performed terribly on large Moment of Inertia with small RCS thrust. My apologies for false alarm as my issue is not really related to your problem.

Nope, not possible because RemoteTech disables whole vanilla Comm Net (and vanilla ground stations) due to conflicts and use its own (or player-supplied) ground stations.

Correct, Method 1 is what RemoteTech calculates exactly. On given list of omni (or same-target dish) antennas, it takes the biggest Omni range and stacks up with 50% of each other antenna. (@Bersagliere81 sorry, I didn't realize Multiple Antenna Multiplier is also applicable to dishes aimed at same target)

Unfortunately, it is not possible to have this due to different designs of stock CommNet and RT. You need to manually enable CommNet in ksp settings. The installation of RT automatically disabled CommNet to avoid conflict.

See this RT setting on multiple antenna multiplier (only applicable to omni antennas). The default value of 0.0 means no range boast from having extra omni antennas. That's it, there isn't any other advantage.

Hi, I received one RemoteTech report on this RCS misbehavior and I also got hit by this in my personal play session. Your issue description is exactly matched to what I am seeing (inverted RCS-related orientation). RT Flight Computer oscillates in RCS thrust direction rapidly. I am trying to figure out what was changed in ModuleRCS & part cfg.

No, I don't find any cfg in RemoteTech folder for Tantares Check this. I got hit by RCS misbehavior on my personal side too. I am figuring out what change was made to RCS orientation.

Stock CommNet is about launching and forgetting comm sats. In KSP 1.1 or earlier, you can control your vessels anywhere and anytime. Now, you need antennas and active connection from Mission Control or high-level Pilot for the same control task. That's it. RemoteTech adds a difficulty layer to player's gameplay. Besides requiring connection to control vessels, it has signal delay (+16 sec between Kerbin and Eve), dish targeting, Flight Computer (less powerful version of MechJeb), and other bunch of things. Players like to play hard ball with this. Sometimes, I wonder if it is case of excessive CPU calculations. On my side, there were so many mod-related things running at same time and it was tanking my FPS rate.

Yup, I am often getting questions about how it works. Unfortunately, I have no or limited resources to make tutorial videos (no mic, no video editing etc). I will look into your report on science bonuses later when I update CNC for KSP 1.4.1. Can you please provide output_log.txt at C:\Users\YOURUSERNAME\AppData\LocalLow\Squad\Kerbal Space Program?

@flart @cakepie Yup, lot of ambiguity in English language words. This Active word is certainly better than Working. The localisation file is updated, except for 3 translated phrases. They will be eventually corrected later. Thanks!

That issue of post-burn chasing maneuver node is resolved a few version ago. It is related to the detection logic not RCS torque glitch. I revised the logic to quit when it detects no "useful" burning delta left. You should be able to enjoy using RCS now. I tested the RCS-Translate parts and some or most seem to use non-stock modules (eg RCSFX) that Flight Computer can't detect. So I think it definitely impacts how Flight Computer sees when doing RCS. You can always resort to stock SAS, which is very good at RCS, but like I said, stock SAS can't see non-stock RCS modules too. Thanks for your files (a lot of mods though). I replicate your RCS problem now but there are several different issues in this problem. First, few RCS parts, like Cross Arcjet RCS, don't even work under stock SAS (Key T) despite visual effects. Second, something (nasty mod combination?) is nerfing/impacting RCS forces so much that Flight Computer & stock SAS is aggressively overblowing RCS thrust. Third, even stock SAS is suffering from the same agressive RCS thing. Stock SAS does the same slow rotation or no rotation, like Flight Computer, though it is doing better job at RCS. Right now, my suggestion is to experiment with different RCS parts to see which are good for SAS/Flight Computer, or to use stock SAS for navball orientations. I am not sure if I can find some ways to lessen/resolve this problem

It is working in 1.4.1 (apart from mis-sized buttons). This is on my to-do list after clearing out RemoteTech stuff.

Definitely not expected behaviour. Please help to give (1) .ckan to install your mods on my side and (2) output_log.txt in c:\Users\<your username>\AppData\LocalLow\Squad\Kerbal Space Program. Thanks.

Hi Schemelge, Purpose of this maneuver node execution is pretty simple. Upon the clicking of EXEC button, Flight Computer queues two commands of (1) rotating the vessel to the maneuver prograde (blue marker) through torque force (reaction wheels and/or RCS), and (2) firing engine(s) at precalculated time until remaining delta is zero. This (1) command is exactly the correction you made prior to the burning. You don't need to issue separate commands for corrections as Flight Computer will automatically do it. Unfortunately, the potential torque from RCS is strange/buggy since KSP 1.2 (see link, link) and gives wild random values at one or another time. It gets worse on a light-weighted vessel with big RCS torque. In comparison, reaction wheels have constant torque potential, where we (modders/players) can apply rotations reliably. This is also why we prefer to use reaction wheels (dont draw monopropellant) or place relatively small RCS on a heavy-weighed vessel (not so overwhelming RCS torque). By the way, Flight Computer can execute a queue of multiple commands, even when connection is down. Have fun with planning on scheduling commands in zero-signal areas! I am going to try smooth out the RCS calculations inside Flight Computer later but I am not optimized as long as the RCS torque bug is not fixed.

Hi Schmelge, Was your vessel (very) aggressively burning RSC towards the blue marker on the navball? Something like rotation oscillations? I am seeing this behaviour too but it happens mostly on sub-orbital paths within 70km atmosphere. Flight Computer is possibly overreacting to the variables constantly changed inside atmosphere. Is yours RT 1.8.9 or 1.8.10 and KSP 1.3.1 or 1.4.x?

Hi DMagic, I would like to let you know that Russian, Spanish and German localizations are included in CommNet Visualisation now. Thanks.

Thanks, I added your translation to the codebase. I didn't touch the default line thickness. I thought it was too thin too but I let it slide to see how it works out eventually. One change in KSP 1.4.x is this thicker line when zooming out enough.

RemoteTech 1.8.10.1 for KSP 1.4.1 released This release 1.8.10.1 is a hotfix to the botched fix to the zero-throttle bug (#744), affecting stock KSP. 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.