Starstrider42

KAS has some conflicts with RT (in particular, never try to attach an RT2 antenna using KAS). Also, as noted above, MechJeb acts like there's a human doing all the maneuvering. Those are the only compatibility problems I know of. When you say no option, do you mean that if you right-click on an antenna you don't get two buttons (one to activate/deactivate, the other to pick a target)? No, there's no fallback target. At least, not yet. It's been discussed before but it's quite a controversial idea, and that's leaving aside the potential that it would create more bugs. So I can't say whether or not it will be implemented, but it won't be soon. Sorry! That said, most situations where a fallback option would be needed can be dealt with judicious use of cones and active vessel. Is there a specific scenario you're thinking of? Remote Technologies Group has not yet discussed whether or not we'll be implementing the groups idea. Aside from breaking compatibility with previous RemoteTech versions, it would require a huge rework of the code. We're not quite ready for something on that scale yet.

Sorry, MechJeb doesn't support RemoteTech signal delay at the moment. With the stock settings, it will act as if the player were entering all autopilot commands (i.e., subject to signal delay, and only works while in contact). You can get MechJeb to respond instantaneously by deleting the RemoteTech_MechJeb.cfg file from the RemoteTech2 directory, but that will let you send commands to MechJeb when you shouldn't be able to. Pick your poison.

Bleh, that sounds like the exact opposite of a bug we fixed in the release. Can you please post to the issue tracker so that the other devs are aware of it? Thanks!

No, we haven't added EVA comms yet. It's on the list, but it may be a while before we get to that. That's intended behavior, and has been the case for all previous versions of RemoteTech as well.

AFAIK the current version of RSS does not change any of the body names. I'm guessing bugs like this are probably why.

Not yet. If I understand the discussion on the issue tracker correctly, that one only happens if you have KAS installed, right?

I'll post an issue about it. As a temporary workaround, you can see what the files are supposed to look like here: https://github.com/RemoteTechnologiesGroup/RemoteTech/tree/master/GameData/RemoteTech2. Pick a file name, then click "Raw" on the toolbar on the next page to get the correct line endings. Edit: BTW, if you're adding blocks for other probes, you're better off doing it in a separate file rather than the ones that came with the mod. That way they won't get overwritten with each new release. Code is the same, and as long as they end in .cfg and are somewhere in your GameData directory they'll get read.

Not yet, but it's being reviewed (https://github.com/RemoteTechnologiesGroup/RemoteTech/pull/93) and will probably be in the next release. It looks like your drag suggestion won't make it, though, since ferram says you can't use the Cd value like that. Sorry. MJ time delay will have to be done on the MJ end. See my response to Garek a few posts above.

Oops, apparently that's a Windows name (yes, my computer is unclean, sorry). A quick forum search claims that the file you want is ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log. If you open the file in a text editor, it should start with "Initialize engine version" instead of "Kerbal Space Program" like KSP.log does. It will appear after you've started the game once. As previously requested, I'll add that detail to the manual soon. That sounds like a line ending problem...? What operating system are you on, and what program are you using to open the files?

Can you post the output_log.txt (or at least the part with the exception) in the issue tracker? Please don't send KSP.log, that doesn't have enough information for us to figure out where an exception is coming from. It's still in the works, but from the kOS side. Ask erendrake about it; I don't know the details myself. As for kRPC, you'll have to ask them to integrate with the RemoteTech API, much like kOS is planning to. It's not something we can do from our end. Please post this to the duplication thread on the issue tracker, following the guidelines listed on this thread's OP. The trouble with the duplication bug (in its current incarnation) is that it's very intermittent, so we need the exact setup: save game, modlist, output_log.txt, the works. If we can't reproduce it, we can't figure out where it's coming from.

"Connection packed" should only show up if you're using time warp. Does it still show up even if you go down to 1×? I'm not sure I understand your second question. If you can see your signal delay, then you should have a connection. Are you saying that, despite being officially connected, nothing shows up in the computer queue?

No, because the HotRockets patch would still get applied. While using ModuleEngines* is obviously the more flexible solution, it will only work if every mod that affects engines decides to use it. Which, IMHO, will never happen. Hence my suggestion that HotRockets be the one that changes -- that way, the fix only needs to happen at one point.

I think I've found a conflict between HotRockets and Near-Future Propulsion. The latter has a part config that changes some parameters of the ModuleEngines module in the stock nuclear rocket... except that HotRockets already removed it. I can imagine similar conflicts happening with other mods that assume stock engines have ModuleEngines. Given the large number of potential mod conflicts, I propose that the HotRockets configs be modified to use either :FOR[HotRockets] or (if possible) :FINAL, ensuring the ModuleEngines->ModuleEnginesFX conversion will be applied after any non-HotRockets-aware mods' patches. That should prevent conflicts like this one from arising in the future.

No, that's not a bug. Any probe core that doesn't have a RemoteTech module in it can be controlled, like in the stock game. And it's neither possible nor legal to change that (since that would require changing stock code).

No, nothing of the sort. And as long as you're not using the Reflectron SS-5 and Reflectron LL-5, you won't be affected when we do delete parts. Correct. N/A means no RemoteTech parts whatsoever, including no antennas. Otherwise, anything that can be controlled without a network connection is Local Control. Kind of an odd distinction, I know.

Ok, I've seen stuff like this happen when tweaking RemoteTech, but we didn't see it with the official build. Is it just the mission control dishes that are broken, or all of them? Edit: Glad to hear it's working now, though? No, this is a standalone version. I can't guarantee what will happen if you try to install the community hotfix on top of 1.4.

No, it supercedes the community hotfix. The hotfix was only a temporary workaround for 1.3.3.

It's a known issue, but we've never been able to reproduce it consistently. If you could upload a copy of your save file (preferably with as few mods as possible) and KSP_Data/output_log.txt to the issue tracker, it could help us pin it down.

...aaaand we have our first bug report. I could swear I updated the file before we packaged everything. Thanks for the info, I'll get a corrected copy up ASAP. EDIT: fixed. It's on the to-do list, don't worry.

And RemoteTech 1.4.0 is released under new management: http://forum.kerbalspaceprogram.com/threads/83305. Enjoy!

Yes. Both satellites need to target each other. You can target the new satellite's dish by right-clicking on it, then clicking the button labeled "No Target" (it's actually easier to do this before launch; you can change targets while the dish is closed). If TelstarC-1 isn't targeting its dish at anything yet then you're in trouble, since you have no way to send the retarget command.

Not blasphemy at all. Here's my (incomplete) analysis of the three resources: http://forum.kerbalspaceprogram.com/threads/40667?p=1087168#post1087168. Last sentence is basically what you just said.

The tracking station coordinates are set in GameData\RemoteTech2\RemoteTech_Settings.cfg. However, you might ask around on the RSS thread; I think NathanKell mentioned that somebody was working on configs that would define real-world ground stations for RSS+RT games.

This usually happens if you download the DLL (e.g., from the community hotfix) but none of the parts or textures. Try downloading the file at https://github.com/RemoteTechnologiesGroup/RemoteTech/releases/tag/v1.3.3, and THEN apply the hotfix on top of that.

Haven't tried the latest version of FF yet, but it sounds like a problem with Active Texture Management. Maybe the endurance ribbons aren't covered by the ATM config?