Now-defunct-thread-that-should-not-appear-in-google-search.

[NoMrBond]

I don't have a communotron 32, only the 16... Did I accidentally delete it or was it removed from the mod?

If you're playing in career mode you won't have access to the c32 until later in the tech tree?

[Rabada]

If you're playing in career mode you won't have access to the c32 until later in the tech tree?

Nope, it was a sandbox game. Is the C32 a RT or a stock part??

Edit: I re-downloaded RemoteTech off of the Space Port, I looked through the /Parts and found what I think is the C32 in /Parts/LongAntenna2. In that folder, there are no .mu or .mbm files like in the rest of the parts folders. Could that be the cause? If not, I run a lot of other mods, so perhaps they might be conflicting with RT.

Edited January 25, 2014 by Rabada

[Soda Popinski]

If anybody else was having the bug where your probe won't hold attitude, I seem to have found a work around.

There seem to be 2 basic things happening. 1) Attitude control cannot be maintained because thrust / torque isn't reduced enough when approaching the correct direction (look up PID control). 2) This can happen under at least 2 situations - A) An offset docking port is set as the control point and under some circumstances, setting ANY part (probe core, docking port) as a control point. In case B, I found this to happen with a probe I released from a mother ship.

Even though I had it pointed the correct direction, enabling attitude control still lead to crazy spinning / wobbling. What I found was, when I originally released the probe I switched the control point to the side docking port to RCS away from the mothership. The control point I think (originally listed as "ref = 0" after the "prst = FALSE" in the savegame), was set to the probe core ID number after I switched back to control from the probe core. Once that occurred attitude control went wonky. I fixed it by manually changing it back to "ref = 0"

So to sum up, open up your save file in a text editor (notepad), find your probe, find "prst = FALSE" and change the line below it to "ref = 0"

Remember to back up your file first, and don't blame me if you screw things up.

Here's a video showing the issue where attitude control can't be maintained even though the craft was already pointing in the right direction.

Here's a video showing the basic attitude control issue that occurs when using a radially mounted docking port. It can be recovered by setting control to the probe core, but it does continually wobble a little bit.

Edited January 25, 2014 by Soda Popinski

[Mecripp]

Nope, it was a sandbox game. Is the C32 a RT or a stock part??

Edit: I re-downloaded RemoteTech off of the Space Port, I looked through the /Parts and found what I think is the C32 in /Parts/LongAntenna2. In that folder, there are no .mu or .mbm files like in the rest of the parts folders. Could that be the cause? If not, I run a lot of other mods, so perhaps they might be conflicting with RT.

It's RT2 part just a re_scale stock part that's why there is no .mu or .mbm file.

MODEL

{

model = Squad/Parts/Utility/longAntenna/model

position = 0.0, 0.0, 0.0

scale = 1.0, 2.0, 1.0

rotation = 0.0, 0.0, 0.0

}

Edited January 25, 2014 by Mecripp2

[Wyrmshadow]

Has anyone found a fix for the spacecraft duplication bug? I sent 6 manned missions to the Mun, and each got trippled. So I don't want to access them from the map screen for fear they'll all explode because 3 bodies can't occupy the same space. I've got no problem erasing the duplicate probes, it's the manned ones I don't want to kill anyone in. I've only seen this bug with RT.

[Soda Popinski]

Has anyone found a fix for the spacecraft duplication bug? I sent 6 manned missions to the Mun, and each got trippled. So I don't want to access them from the map screen for fear they'll all explode because 3 bodies can't occupy the same space. I've got no problem erasing the duplicate probes, it's the manned ones I don't want to kill anyone in. I've only seen this bug with RT.

There's a hotfix.

[RabidMonkey]

There's a hotfix.

I've got the hotfix installed, but I'm still seeing duping. The difference is that if I catch it in the Tracking Center, I can delete the duplicate vessels.

[SkyHook]

Seriously!? I can't even rename my probe with no connection!?

Edit: I confirm the vessel duplication bug.

Edited January 25, 2014 by SkyHook

[Mystique]

Finally someone else reported wobble bug BTW, I recently found that it occurs even on max time warp - when I was warping all the way from Jool to Eeloo, my deep-space exploration ship was visually swaying a bit and it was also seen on navball. That definitely shouldn't happen on non-phys time warp =\

[AndreyATGB]

Seriously!? I can't even rename my probe with no connection!?

Edit: I confirm the vessel duplication bug.

Yeah I think it's pretty stupid. Renaming should be considered something KSC does and shouldn't require a connection.

[Cilph]

Yeah I think it's pretty stupid. Renaming should be considered something KSC does and shouldn't require a connection.

Sheesh, it was an oversight. Never thought people would bring that up so often. It's on the/a list.

[antkatcin]

Hello.

I'm sorry, probably that question was discussed here a million times, but there are a hundred pages in this topic and search didn't help me a lot.

I have installed both kOS and RemoteTech 2 and i have a problem that kOS (fixed version for 0.23) interrupt program execution when vessel lost mission control connection. Just trying to understand is it a bug or feature? Is it possible to tweak cfg files to turn off any kOS and RemoteTech 2 integration so kOS will work independently even without connection. Of course perfect solution is just to disable send messages in offline mode and allow program execution if it was run online, but in case if that's not implemented i'm looking for any workaround to use kOS in offline mode.

[Mecripp]

Hello.

I'm sorry, probably that question was discussed here a million times, but there are a hundred pages in this topic and search didn't help me a lot.

I have installed both kOS and RemoteTech 2 and i have a problem that kOS (fixed version for 0.23) interrupt program execution when vessel lost mission control connection. Just trying to understand is it a bug or feature? Is it possible to tweak cfg files to turn off any kOS and RemoteTech 2 integration so kOS will work independently even without connection. Of course perfect solution is just to disable send messages in offline mode and allow program execution if it was run online, but in case if that's not implemented i'm looking for any workaround to use kOS in offline mode.

Not AT this time MJ and Kos all have to have connection. Its should have been made as long as the input was sent before lost of connection, it would still work but that might be the hard part,for now we are forced to use the flight computer.

[erendrake]

Hello.

I'm sorry, probably that question was discussed here a million times, but there are a hundred pages in this topic and search didn't help me a lot.

I have installed both kOS and RemoteTech 2 and i have a problem that kOS (fixed version for 0.23) interrupt program execution when vessel lost mission control connection. Just trying to understand is it a bug or feature? Is it possible to tweak cfg files to turn off any kOS and RemoteTech 2 integration so kOS will work independently even without connection. Of course perfect solution is just to disable send messages in offline mode and allow program execution if it was run online, but in case if that's not implemented i'm looking for any workaround to use kOS in offline mode.

Just FYI Cilph and I have talked about this and I just added a ticket in the github issue tracker.

[Sma]

I've got the hotfix installed, but I'm still seeing duping. The difference is that if I catch it in the Tracking Center, I can delete the duplicate vessels.

Yep this is what I've been doing. Luckily the first time I had a rapid unplanned disassembly(when I switched to something that had been duplicated) I had a clean quicksave I was able to reload. Now I try make it a point of checking the map/tracking center before switching to something to make sure there aren't any dupes. Usually they end up at the top of the list so it's easier to find them.

One time it happened as I was following a spent rocket body down, once it hit it duped all the debris, game crashed, i reloaded and map showed around 200 debris when I only had around 60, it was kinda funny lol. I'm a little behind on this issue but it only seems to happen when I undock multi sats from a launcher and/or switching back and forth. Currently it's a problem I can work around so not a big deal to me.

[Rabada]

It's RT2 part just a re_scale stock part that's why there is no .mu or .mbm file.

MODEL2

{

model = Squad/Parts/Utility/longAntenna/model

position = 0.0, 0.0, 0.0

scale = 1.0, 2.0, 1.0

rotation = 0.0, 0.0, 0.0

}

Hmm.. Must be a mod conflict then. I'll have to try a fresh install of KSP.

[AndreyATGB]

I know there's a lot of suggestions and bug reports already, but something that came back in my mind is that I can't select "activate" for an antenna/dish that's already active. I'd like to be able to do this so I can use the flight computer to turn the antenna back on after aerobraking. Right now the only way to aerobrake an unmanned probe is to have 2 dishes on it and switch them with the flight computer.

[gleedadswell]

You mean 0.75 units/s on the first available solar panel. I've already halved the consumption twice (quartered? quadr-alved?)

OK, there seems to be a "dueling mods" thing going on here. I'm seeing a very different value from 0.75/s. Obviously you can't account for every possible set of mods that every user will install so this is perfectly understandable. I've done some testing to try to figure out why. Here are some results for a few parts in the game run from a clean directory with different mods installed. For each part I give the name of it as it appears in the game and the id it has in the persistent.sfs file, to avoid confusion:

Stock KSP (I'm sure you know this)

ST1 solar panel (solarPanels5): 45/min (i.e. 0.75/s just as you say)

CommTech EXP-VR-2T (RTLongAntenna3): NA since it isn't a stock part

Comms DTS-M1 (mediumDishAntenna): 15/packet

Directory with just RT2 (I'm sure you know this as well)

ST1 solar panel (solarPanels5): 45/min

CommTech EXP-VR-2T (RTLongAntenna3): 0.18/s

Comms DTS-M1 (mediumDishAntenna): 0.82/s

With various realism mods (more or less the suggested list for the Realistic Tech Tree LITE)

ST1 solar panel (solarPanels5): 1.1/min

CommTech EXP-VR-2T (RTLongAntenna3): 0.18/s

Comms DTS-M1 (mediumDishAntenna): 0.82/s

So one of the mods in the "realism" combo is radically reducing the power production of the solar panel. I'm going to guess it is the Realism Overhaul Tweak/Resize Pack since it changes a lot of parts (right?). I'll test further to try to verify this. In any case it is resulting in very unrealistic Comm Sats, as I mentioned. On another thread http://forum.kerbalspaceprogram.com/threads/58135-TechTree-0-22-Milestone18-Realistic-Progression-LITE-%28Get-on-TreeLoader!%29/page59 NathanKell suggests an edit I can do to Remotetech2_settings.cfg to reduce the power consumption by the antennas. I'll try that but I'm wondering why the solar panel power output is so reduced. I'll also make a post about this on a thread related to the Realism Overhaul family of mods.

Cheers!

----Edit later----

Aha! I had missed copying the RemoteTech_Settings.cfg over from the RPL Tweak Pack into the RT2 folder. Doing that rebalances the antenna power requirements with the solar cell power production. So things are looking good.

Edited January 26, 2014 by gleedadswell
further investigation

[AndreyATGB]

RealismOverhaul changes how power works, it effectively replaces the ElectricCharge resource with watts. This means the numbers will be higher, but not necessarily more energy is being stored. I think RT2 configs were talked about since it consumes ElectricCharge and not watts.

[Cilph]

The antennas consume ElectricCharge per second, so that would make stock consumption more like Amperes.

[theSpeare]

Just completely out of curiosity Cilph, but what's the ETA on the next release?

[Draft]

Okay, here's the idea for dish targeting:

...

OPINIONS?

I like modes one and two, since they're pretty much making behaviors more consistent.

As for mode three, as presented it seems very overpowered. Some suggestions to balance it:

• Limit the allowed size of groups, either by SOI, by some arbitrary number, or some other metric of dishes. Maybe have it so each kind of dish has a maximum group size it can track?
  
• Add additional signal delay to dish-group communications based on how large the group is, to simulate the time wasted by track-checking. Not sure how to balance such a thing p
  

[S4qFBxkFFg]

I've had this mod installed for a while, and just started using it, but have encountered a problem - I can't stage on an unmanned craft.

mod+L disables the manual staging lock (I can confirm this in the debug window) but I still have an "RTLockStaging" visible

Strangely, the "RTLockRCS" and "RTLockSAS" are also visible, but I'm able to activate and deactivate both RCS and SAS.

Is there any way to fix this?

(Other than by removing the plugin, which I can confirm works.)

[Cilph]

Just completely out of curiosity Cilph, but what's the ETA on the next release?

No ETA. Probably around 0.24. There's stuff I want to implement and even less time to work. For example I started rewriting the core routing logic today to increase performance.

I've had this mod installed for a while, and just started using it, but have encountered a problem - I can't stage on an unmanned craft.

mod+L disables the manual staging lock (I can confirm this in the debug window) but I still have an "RTLockStaging" visible

Strangely, the "RTLockRCS" and "RTLockSAS" are also visible, but I'm able to activate and deactivate both RCS and SAS.

Is there any way to fix this?

(Other than by removing the plugin, which I can confirm works.)

I'm not sure how to handle crafts that are both unmanned but contain no RT2 support such as signal processor modules in the probe bodies or antennas, so behaviour there might be a bit finnicky. The "RTLock*" is visible because I intercept all calls and execute them myself.

You should definitely be able to stage an unmanned craft where RT2 functionality is integrated, so let me know if that isn't working. The staging light should be activated at all times since I'm technically locking it.

Edited January 26, 2014 by Cilph

[S4qFBxkFFg]

I'm not sure how to handle crafts that are both unmanned but contain no RT2 support such as signal processor modules in the probe bodies or antennas, so behaviour there might be a bit finnicky. The "RTLock*" is visible because I intercept all calls and execute them myself.

You should definitely be able to stage an unmanned craft where RT2 functionality is integrated, so let me know if that isn't working. The staging light should be activated at all times since I'm technically locking it.

Ah, that explains some of it - after first encountering this issue I was only testing whether I could get the light back to green. I'd restarted KSP in the meantime, which probably solved the original problem, although I didn't realise as I wasn't actually trying the spacebar. I can't reproduce the problem anyway so I'm now not even sure it was in RT2.

(For the record, it was the Stayputnik probe core, with 2 dipoles on the ascent stage and 2 communotron 16s on the probe body.)