Starstrider42

I think it might be you-specific. I use flight computer delay all the time, and I've never accidentally triggered action groups or separated my capsule from the rocket that way. Given that a bug like this could come from just about anywhere, are you using 32- or 64-bit KSP? What mods are installed? No, it's not there at the moment. The flight computer's features are quite basic. Feel free to write a pull request, that one's a little more reasonable than "I want to duplicate all MechJeb functionality without installing MechJeb". That said, the map view should give you the time to both SOI changes and periapsis in real time, so you shouldn't need to do any math: just type "3m 30s" or whatever (THAT's a feature you might have missed).

Why would your ship need an ice cream machine? Minmus is right there. Thanks for the feedback, everyone -- as most of you guessed, it was supposed to be a more intuitive replacement for the planet icon in the current toolbar. With VaporTrail's permission, I'd like to incorporate their version into RT. That's correct -- there is absolutely no case where turning off a dish should cause you to have a connection that you didn't before. If you haven't changed the save game yet to the point where it's impossible to reproduce the problem, can you please post it and a bug report to the issue tracker?

Quick poll: if you saw the following button on RemoteTech's map view toolbar, what would you think it did? That's not too different from some of the suggestions floated in this discussion: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/107. TL;DR: while we're all open to different ways to make dish targeting simpler, we also all have different views on what would make the game too simple, and we never agreed on a single scheme that would make things easier while keeping the game balanced.

It is on the list: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/32, and I personally would like to see it because I tend to play with a lot of simultaneous flights. However, since we haven't had too many requests for it (you're the first since the new thread opened, I think) it's a lower priority than e.g. better network troubleshooting, with which we already have our hands full. I'm sorry to hear you're having trouble. The cone should appear whenever the second icon on the lower-right panel shows a planet icon instead of an "X" (and when the antenna is pointed at a planet). But the cone for the KR-14 is quite narrow (0.04°) so the odds of you hitting one of your satellites from just outside Kerbin's SoI (90,000 km away, or a 63 km diameter cone) are quite low. By the time you actually need to make a course correction to hit Duna, though, it will be a lot wider. As undercoveryankee said, one workaround is to point the dish at a specific satellite until you get farther away. Although it won't appear in the next release (at the moment it only works in one specific case), I've started work on some text-based reporting for, among other things, how wide your cone is: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/2#issuecomment-57039242. Feel free to drop some feedback on that thread.

*Deletes lengthy and no-longer-relevant quote* Aha, found the post you were referring to. Fine. But, for the record, the ModuleManager OP did not include the version 2 capabilities at the time that I wrote that patch, and the post that introduced them did not mention any convention or priority for :FOR names. I'd still prefer to keep the mod name as RemoteTech, so I'll see if the others are game for a DLL rename. With the exception of the FASA configs, which were misplaced, everything on master is the previous version. You want the develop branch (yes, it's an unnecessarily confusing system, and yes, we'll be changing it after the next release). That was in reply to RedAV8R's claim that RemoteTech must be run before all other mods. I know that it wasn't your point.

Wow, I definitely did not expect to trigger a huge discussion. In my experience, it's easier to look at what name is used in a mod's included config files than it is to figure out which DLL is the "main" one for a mod, especially if there are no DLLs or multiple DLLs from bundled mods (granted, neither of those applies to RT, but seeing it in other mods encourages certain config-writing habits). If some patches are running in :FIRST, please point to specific examples. I made a point of changing each and every patch to use :FOR, and nobody found anything missing before it got merged. That's a good point. I started writing up the for modders documentation this weekend, and I'll make sure the :FOR convention (whichever it ends up being) is up at the very top. Except somebody needs to realize that their configs are broken, and make the changes, and release them. There are plenty of widely used but rarely updated mods out there. And not so out there. Better to make a system that's robust to changes in the modding scene from the very beginning. As far as I know, there are no mods that RT needs to appear before/after. The only conflict I can think of is if somebody were to use MM to add a ModuleDataTransmitter to another mod's antenna, and I don't really see that happening. I agree that renaming RemoteTech2.dll to RemoteTech.dll would simplify things a lot. I'll bring up the possibility with the dev team, though I suspect it might meet some resistance from people who want there to be no confusion with JDP's original RemoteTech.

The use of :FOR[RemoteTech] instead of :FOR[RemoteTech2] was a deliberate design decision to establish a single, consistent name for the mod (what if we later have RemoteTech3.dll?). The way ModuleManager processes :FOR statements, there is no "proper association" to worry about -- any name ever used in a :FOR statement gets its own set of :BEFORE, :FOR, and :AFTER time slots, independent of what .dll and folder names are available. Also, we once tried to make changes to @PART[*] in the distant past, but people complained a lot. That's why we have the admittedly clunkier approach of adding modules to specific named parts. So, thanks for being willing to contribute, but neither of the changes in this particular pull request would get merged. Sorry!

Sorry, but we need more detail than that. Are you using 64-bit KSP (which is pretty unstable, with or without mods) or 32-bit (which should work)? Can you upload a copy of your KSP_Data/output_log.txt or KSP_x64_Data/output_log.txt to a site like Gist or pastebin so we can check for error messages? Well, if you're getting a "no connection" error, that would suggest that the mod is correctly installed, at least. What antennas are you using? Are you using RSS?

There's an official tutorial on that very subject: http://remotetechnologiesgroup.github.io/RemoteTech/tutorials/reentry/. If you're careful, you can both save your antenna and have surface comms with no other mods needed. That said, SmartParts does make complex maneuvers a lot easier, so I highly recommend it. Not yet. I wanted to put up some documentation for interplanetary distances, but then got sidetracked. Thanks for the suggestion of making it like a delta-V map, though.

RemoteTech does have a cheat mode, yes. Go to the debug menu (alt+F11? F11? something like that) and turn on infinite EVA fuel. That disables line of sight checking. Short version: because it was the first RT antenna ever made. Long version here. If you or anybody else would like to submit a replacement dish, be my guest, but I don't think we have any modelers on the team at the moment. I've run into that bug myself, and I'm pretty-ish sure it's stock. My preferred workaround is boosting the time warp rate (since packets are sent based on real time, not game time) until the transmission is slow enough that my solar panels can keep up. Hadn't thought of changing physical delta, I don't like messing with options when I don't know what they do. That is weird, especially since it looks like you're losing atmosphere-proof dishes. I can't guarantee that it's a RemoteTech bug, though, since you seem to have a lot of mods installed. You can find the log in <KSP directory/KSP_Data/output_log.txt (or KSP_x64_Data if you're playing 64-bit KSP). Upload it to a site like dropbox or gist instead of posting it directly, because the log gets VERY long.

By default, the mod replaces the stock spawning behavior with a slower but steadier rate (see my response to Ratzap, below). Wait for a few days of game time and you should see asteroids showing up. If not, please post a copy of `KSP_Data\output_log.txt` or `KSP_x64_Data\output_log.txt` to the issue tracker. If you want the stock behavior (make lots of untracked asteroids when you don't have any, then no asteroids until you "clear out" the current ones), you can edit it by opening CustomAsteroids\PluginData\Custom Asteroids Settings.cfg in a text editor and setting `UseCustomSpawner = False`. The stock game does almost what you're describing -- if you have more than 8 or so untracked asteroids, it won't make any more. My mod does the opposite, where the appearance rate of new asteroids is fixed and doesn't depend on how many asteroids you know of at present. And it doesn't have any provision for changing settings on a per-game basis. Sorry!

Details, please. With what settings? How long did you wait (in game time, that is)?

Delete and reinstall the mod, and make sure while reinstalling that everything goes in <KSP directory>/GameData/RemoteTech2. For example, your textures directory should be Kerbal Space Program/GameData/RemoteTech2/Textures. Don't rename anything, don't reorganize anything, don't add extra folders. It should work after that. Hmm... the log doesn't say anything directly related to RemoteTech is causing errors... :/ You have a lot of mods installed, and at least two (LTScience and LTech, which I assume are the same thing?) throw exceptions before the one you pointed to. Do you think you could whittle down the mod list a little (e.g. with a seperate test install) and see which mods are absolutely required to produce the error?

RT at the moment has issues with unexpected root parts, whether you're using selectroot or whether you just started building your rocket from something other than the nose cone. Do issue #25 or issue #76 sound familiar? Still trying to figure out what's actually causing this, sorry for the inconvenience. FYI, we're much less likely to overlook feature requests if they're posted on GitHub. As for limited bandwidth for omnis, something similar has been suggested as issue #116 and issue #127. We will look into it, but right now the RemoteTech group is running a little behind, as you've no doubt noticed. Very strange. It sounds like you've installed everything correctly. If you open KSP.log and search for "[ModuleManager]" (without the quotes), do you get messages saying it's working?

This sounds like a known bug, but more info will be very helpful. Can you please post your KSP_Data/output_log.txt (or KSP_x64_Data, whichever applies) and preferably a savefile and modlist to https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/4? The logs will help us figure out where the exceptions are coming from. That has been the standard setup for most players -- have your "main" Kerbin comsats have a dish for each planet where you want relays. It does mean bigger satellites, but once you've launched them they work without further management.

Ok, I've made a test version for KSP 0.24.2, and thrown in a lot of debugging code. If you'd like to help hunt down the endless spawn bug, you can download the test version at https://github.com/Starstrider42/Custom-Asteroids/releases/tag/024test. If you do run into problems, please report it on the issue tracker (https://github.com/Starstrider42/Custom-Asteroids/issues/16), preferably with a copy of the full KSP log (~/.config/unity3d/Squad/Kerbal Space Program/Player.log on Linux, Files>~/Library/Logs>Unity>Player.log on Mac, Kerbal Space Program\KSP_Data\output_log.txt on Windows). Of course, if the bug has mysteriously vanished, I'd like to know that too.

I'm betting your Kerbin satellite is pointed to "active vessel" -- which, in the second example, is the lander. If you want to route a connection through a satellite while it's not the active vessel, you need to either target that vessel directly or, if you want to avoid the micromanagement the posters above you were complaining about, target the planet. This is the most frequently asked question; see http://remotetechnologiesgroup.github.io/RemoteTech/guide/overview/#connection-rules (particularly the bottom) for more info on how the connection modes work in the current version of RT. Hopefully the next version will make this a bit less of a problem, by having antenna cones apply no matter what is being targeted.

It is, but you need to have either "deploy antenna" or "toggle antenna" bound to an action group. Then, you can type in a delay, hit the action group, and the deployment will be scheduled. There's a bit more detail in the re-entry tutorial. The changes you need to make for an aerobraking flight path are pretty straightforward.

Neither of those is by design. The inconsistent cone behavior is a bug, and it's a big priority for fixing. I've added a search box to the feature request list, but it will be *very* hard to make work with the current framework. But do you really have 100 flights all in the same sphere of influence? If not, you can minimize the planets you're not looking for. To answer the original post, I'm already working on a debris filter, adding support for other spacecraft types shouldn't be too hard.

1.0.0 is the latest version, but it's not specifically built for 0.24.2. It sounds from the previous posts like it works fine on all platforms 32-bit, works fine on Windows and/or Mac 64-bit, and fails catastrophically on Linux 64-bit. I'll hopefully get some time this weekend to look at the code and coordinate with the Linux 64-bit users. But no promises on that, let alone a release date.

I'd actually say your optimum orbits are a little too high. If there were more overlap between the antennas, the network would be more resistant to satellites drifting out of formation. Still, those are very nice diagrams. Would you mind if we added them to the manual (giving proper credit of course)?

Hi all, Sorry for the long wait. Release 1.4.1 is now officially available at https://github.com/RemoteTechnologiesGroup/RemoteTech/releases/latest. This version is officially compatible with KSP 0.24, although those of you who have been using the dev builds shouldn't notice much of a difference. Features: Compatible with KSP 0.24. Some part costs have changed. Bug Fixes: Flight computer now slews much more accurately and efficiently. Flight computer will now take RCS thrust into account when slewing. Signal delay window is now sized properly for all Flight GUI settings. Ships can now be renamed from the right-click menu at any time. Note that they can still be renamed from the tracking station. Reverted 1.4.0 fix for electric charge consumption at higher time-warp factors (fix was causing electricity use to be underestimated). Fixed conflicts with mods that depend on RemoteTech. Reduced logging should cause less lag. One fix that unfortunately didn't make it into this release was the incomplete research bug that shows up in 64-bit KSP. Peppie23 has a fix for it, but would like more time to test it, and we voted that we shouldn't let it hold up the release any longer. The research fix will be posted as soon as possible, possibly as a 1.4.2 version. Version 1.5.0 will have some frequently requested features (e.g., customizable command requirements) and will hopefully be much more user-friendly than past RemoteTech versions. Sorry if we've been slow to respond to questions here, but all of us, myself included, haven't had as much time to devote to KSP as we would like. Rest assured the mod is not dead and we do appreciate your feedback.

Thanks for the offer. I think I will need Linux users' help with tracking down Linux-specific bugs (http://forum.kerbalspaceprogram.com/threads/90503). Unfortunately, I'm a bit busier in RL than I thought I would be, and I've somehow ended up being the RT2 manager even though I didn't intend to be. So actual coding for Custom Asteroids will probably have to wait a few more weeks. Sorry for the delay! @Gaiiden, I won't be using realistic elongation/brightness checks in CA itself, but people have requested support for telescope mods, so I plan to include that along with the "asteroid discovery API" mentioned in the first post. But that's a long term goal at present.

So basically, ask the people who reported the bug to try playing with a dev version? Fine, if that's what it takes...

Somebody recently posted a bug to the Custom Asteroids thread that only appears in 64-bit KSP for Linux, but completely breaks asteroids when it does appear. The problem? I only have KSP for Windows, and I've confirmed that the bug doesn't appear there. Any advice on how to diagnose and fix a problem when you can't reproduce the conditions it requires? Thanks!