neitsa

Hello All Just a quick note on the poll, I had started to sort the results but just finished lately when @TaxiService reminded me of them. You can download a summary here: https://dl.dropboxusercontent.com/u/19010758/RT_Poll.pdf Note: Tables are to be read from bottom to top (e.g. in the "Most Yes" table, the entry with the most yes is at the bottom). No real clear "winners" (maybe #516 & #436) but some entries were clearly rejected (#456 received some tomatoes :p).

Yep, but I don't know if it prevents drift for synchronous orbits though (especially with high time warps). I always have modified the SMA (semimajor axis) of the satellites manually in the save file. This is cumbersome but I haven't fond a better way There was a feature request for RT (namely issue #115) where RT would automatically set the SMA for a group of sats (under certain circumstances). We haven't discussed it, but if you have an opinion about this issue, we would be glad to hear it. I haven't a precise idea on how we could / should implement it, but my preference goes over pjf comment. We have a plan for RT where we would allow various group of sats, so we could had this option within a group to set the SMA of all sats in the group to the same value...

AS @Varsi said, I can't think of any scenario in which you could transmit from a vessel to another one: if the first vessel is not connected to KSC that would mean that the second vessel is also not connected to KSC. KSC <--> VesselA <--> VesselB VesselA could transmit commands to VesselB, but VesselB is already connected to KSC (through A). VesselA <--> VesselB If you remove control from KSC, VesselA can't be controlled, thus it cannot transmit anything to VesselB (which is itself not controllable). But one possible way though would be to add a specific planned command for VesselA with a condition [*] : If vesselA is within antenna reach of VesselB, transmit commands (commands in a specific buffer for ex.). I don't know if it would be be useful though... Not related to commands, but one thing that was discussed is issue #43 where vessels could transmit science to other vessels. We will implement it as there are some scenarios where that would be quite useful. [*] we are working on conditional and planned commands for RT Flight Computer, like "Do x if condition is TRUE | FALSE", e.g.: Deploy parachutes IF altitude < 20 km AND surface_velocity < 300 m/s

The only thing I can say for sure is that it will not be ready in a few weeks (not even in Q1 2017) We are rebuilding RT from the ground up and we try to take cautious steps for nearly everything (discussing the idea, modeling the ideas in terms of code [classes or interfaces], how to implement it correctly, can it be used outside of RT or on its own, does it integrate well with other components, is it fast enough, etc.). It just takes time and we don't want to rush. We don't have a clear view on when it will be released though.

We have 2 rolling releases that are developed in parallel: One that targets KSP 1.1.3, which is RT 1.7.2 One that targets the lastest KSP version (KSP 1.2.2 as I'm writing this) which is RT 1.8.3 as of now The RT branch for KSP 1.1.x is meant as a support branch for people that haven't migrated yet to the latest KSP, mostly because their mods aren't updated. Sadly, GitHub doesn't allow for multiple "latest release", so the latest published release is the one tagged as such: we can't do anything about that... It's just a matter of checking carefully which KSP version is targeted by the RT release (it's written at the top of the release notes) if you go through Github though. It might be confusing but yeah, really nothing we can do...

@Errol : As @garwel hinted, we'll restrict the flight computer capabilities to the probe capabilities (by default; this will be probably customizable in settings if you want to override it.). @WildLynx: Looks like a bug, yep. We'll see if we can repro (with only KSP + RT) & find the root cause. @Sumu : Try RemoteTech 1.7.2 (it seems you are still on 1.7.0 although it shouldn't have given this problem whatsoever) if you are still on KSP 1.1.3. I can't get what's wrong though if you have only KSP + RT... That sounds strange... From the root folder of your KSP install, it should look like this: The RemoteTech assembly (*.dll) must be located in "/Plugins" folder.

As a side note: As I'm the RT maintainer I'm taking care of managing (repo organizations, continuous integration, packaging, etc.) the various modules but by no means I'm the only one to code on it. @TaxiService and @Yamori Yuki are working hard on RT 2.x. RemoteTech-Complete (as it name implies :)) will be the complete package with all RemoteTech modules for RT 2.x If you want to follow the other packages, please go to the group page: https://github.com/RemoteTechnologiesGroup ("RemotTech" repository is the current RemoteTech 1.8.x & 1.7.x branches) I would advise against even testing RT 2.x until we release an alpha. It is very rough as of now and far from being finished (crash and corruption are possible outcomes).

Depends: if you think the actual CommNet behavior is a little bit to simple / easy, I would recommend to give a try to RT. As of now (RT 1.8.x branch), RT and CommNet are mutually exclusive. If you install RT, then CommNet is disabled. The next major version (RT 2.x) is built on top of CommNet for a better integration with KSP, but using (nearly) the same rules as before. So yeah, for 2.x the integration will be mostly transparent to the player. Simply put, RT 2.x is a beefed up version of CommNet with a lot more options.

Nope, not a silly question, especially if you never used RemoteTech (RT) before CommNet was introduced. As of 1.8.x version of RT: Different antennas Harder rules for controlling probes (if you have no connection your probe is just an expensive flying brick... it wont respond to any commands) Delay (speed of light effect): if you probe is around duna (without any in between relay) you get approximately a 1 minute delay for each command (i.e. if you press a key or a button the effect is seen only after 1 minute has elapsed in the game) Different range models: CommNet use a easier range model than RT (how far you can be from any other connection point to get a signal); RT has two range models. A flight computer to enter command ahead of time (due to the connection delay you have to make a flight plan ahead of time) RT version 2.x - currently in the making - will add other (completely optional) options.

It was released for (and tested on) KSP 1.2.2 (although it should work on the whole KSP 1.2.x branch (from KSP 1.2.0 to KSP 1.2.2) but we haven't tested it on previous KSP versions)

Hello, The only thing I can think of is: buy good book(s) about the language. The C# Player's Guide (2nd Edition) C# 6.0 in a Nutshell: The Definitive Reference Microsoft Visual C# Step by Step (8th Edition) I'm not very fond of general online tutorials as a starter, they are good to expose specific features but won't teach you the basics, at least they can't rival a 400 to 600 pages book after all. If you have a specific question about how something works, go to the Microsoft (MSDN) web site (there are also some good guides | here there). There's usually an example about the feature you are searching for (e.g What's a static class and static members). Lastly, if you are interested in KSP plugins development, you should at least: Understand the basic principles of the engine Read tutorials dedicated to KSP Note that Unity is still stuck at the 3.5 framework features but you can still use some of the features of the C# 6 language (e.g. Null propagation or interpolation strings) in a KSP plugin: the framework and language versions are two different things.

Yes the "Gm" is for gigameter but 1 Gm is 1 billion meters (1*10^9)

Ok @Jiraiyah I understand now. No, technically the color is dimmer because the GUI is locked. If you can read C# it happens here: if you don't have local control of the vessel (i.e. the vessel is not crewed), RemoteTech is locking the KSP GUI so clicks don't pass through and never get to KSP. The original intent was to tell players that the vessel was not under direct / local control. The plan for RT 2.x is to remove all the locks altogether and "hijack" the KSP buttons so RT knows that they are pressed before the click goes to KSP, push the command (e.g. SAS, RCS, Light , Gears, etc.) on the vessel flight computer and when the delay time is elapsed, pop the command and execute it. It requires quite an amount of code to do that (and more code means possibly more bugs lurking around :p) and we alos have to play nicely with other mods locking the GUI (MechJeb is one of them), so we haven't made it possible yet since we took RT maintenance. Nonetheless, this is a planned feature for RT 2.x.

The fact you can't use the buttons on the navball (you have to use key bindings instead) is there since at least 1.7.0. Something changed in KSP at some point (around KSP 1.0 release). There are multiple issues about that (#605 and #646 at least) and it would require a big amount of work to be able to use those buttons through the UI. We plan to fix this issue for the RT 2.x branch. Hmmm there's definitely something wrong if key bindings don't work. I remember testing this for RT 1.8.2 but the conditions under which I made my tests might be different from yours. I'll made a new test.

@cyberpunkdreams Good idea! I'm not very familiar with Google forms so if you can make it, that would be great. Let me know if you have done it so I can update my above post. Thank you!