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!

A Call to vote for RemoteTech features in RT 2.x Now RT 1.8.2 is released and the fact that we already started to work on RT 2.0, we'd like to get some feedback. We have a dedicated page for feature requests in the up-coming RemoteTech v2.0. We'd simply like some feedback from the community about what you would really like to see implemented. Note that some feature (not present in the above list) will be de facto implemented (Porting RT over CommNet, Making a modular version of RT and a complete overhaul of the Flight Computer) How to vote? Thanks to @cyberpunkdreams you can go to the following form: https://goo.gl/forms/GlSuxkNSGvenmkRg2 I'd like to see something else implemented which is not in the list, what do I do? Please open an issue on our github issue tracker explaining what you would like to see implemented. This will get added to this ballot paper and our feature request recap page. I'd like to see something implemented which is already in the list but isn't exactly 100% similar to the original request, what do I do? Go to the related issue on our github issue tracker and explain what are the differences you would like to see implemented in contrast of the original issue description. This will be added to the recap page. Do all the features in this list will get implemented? We don't know. There are some feature requests that we like very much and some less. Nonetheless, we'll implement the feature requests that have been the most upvoted by the community. When does the vote close? A month should be enough. And even when it's closed, you'll still be able to comment on our issue tracker. From the whole RT team, thank you very much for your time!

@Simon Link could you please post a complete bug report (at least persistent save + log file) either in the RemoteTech forum thread or on the RemotTech github? Thank you! Note: If you have a problem with a mod, it's easier for the devs to see it if it's in the dedicated forum thread, I stumbled upon your post and could have missed it.

We tracked the problem and a working patch was already pushed. The patch release is scheduled for 1.8.2 (in a few days).

This is tempting but Nah, especially if that's the only possibility. Players usually don't want to deal with configs and all those stuffs, the burden should be on programmers side, not on players. OTOH, that could be an option though if that would allow players to override (for any reason) the default config, but not as the only option. @James3838 could you post an issue on github so that we could make a full repro please?The save file only should be enough if the vessel in question is not using other mod parts (otherwise we'll need a full bug report). This bug seems to keep resurfacing but no one want to share their saves: and without save files, no bug fix...

We decided to go that way with RemoteTech, like a month ago. At first the decision was made for players (using only the part in RemoteTech they wanted, in our case: Delay, Flight Computer and Antennas are in the process of being separated), but it has proven to have some side-effect benefits: 1) Making the mod to be modular forced us to do a full code review - Eliminating dead or un-useful code (compatibility code with older versions) - Rewrite some parts that are hardly understandable at first sight - Follow Unity optimizations (remove bloated LINQ, foreach loops that generate boxing or memory allocations, etc.) [there's some very good literature on this subject [1] [2] [3]) 2) This full code review made us enforcing new coding practices,even for a hobby project: - It forces us to use good "industry practice": use known patterns; decouple classes (Dependency injection ; Inversion of Control); Remove god classes, etc.). TL;DR : making a big enough plugin modular is a good chance to review your mod code.

Hmmm, I'm not sure if that answers directly your question but I think we have something similar in RT: https://github.com/RemoteTechnologiesGroup/RemoteTech/blob/develop/src/RemoteTech/RTPartInfoReloader.cs It updates part information each time your enter the editor (VAB / SPH).

@Errol Nop, we'll keep RT antennas in 1.8.1. I'm quoting @TaxiService on this one: Thanks a lot @chrisl for the report this will help us a lot! I'll check and debug this one tomorrow morning.

@ii_DyNaMiCs_ii, @ROXunreal : we checked your issue with @TaxiService about contracts being not properly fulfilled but couldn't repro the bug... So, we need a little bit more than a simple description: a complete bug report would really help us; at least : logs + saves + mod list as explained here. Thanks a lot!

@chrisl : It is very hard to do something with just the information that you provided (although your bug report is quite detailed). A complete bug report (logs, persistent save, etc.) would help, otherwise I'm afraid we can't do anything... This is probably related to issue #667 (which seems to be related to R0 or RP-0), but we don't have a complete bug report for it, so if you could do one, that would really help us to chase this bug down. Thanks a lot Note: feel free to post a new issue on our github (or maybe here, although keeping track of things on the forum is a nightmare) and not necessarily on issue #667.

Hello we have a problem with a specific type of stock contracts and RemoteTech (more precisely "have a vessel in orbit with this <type> of part and this <type> of part") Is it possible to spawn a precise type of stock contracts (career mode) rather than waiting for it to appear? Thanks a lot