Peppie23

[1.1] RemoteTech v1.6.10 [2016-04-12]

Recommended Posts

Having Asperger's helps. I can't read a lot of contextual cues, even in person. ;)

No worries, this is why I asked for clarification. FWIW I think its a fantastic idea.

Share this post


Link to post
Share on other sites
(trying to remember if it will maintain control in blackout areas).

I think it won't. One of my first attempts of using mechjeb last week was to keep the heatshield of a test probe facing prograde during reentry. I set a timer to extend my antennas, and the moment I retracted them the probe went haywire.

Share this post


Link to post
Share on other sites

Is it possible to have a flight computer remember instructions that have been sent to it when focus leaves that vessel? I've just I want to be able to co-ordinate separate vessels that will have to be out of contact during the manoeuvre. I know that I will need need to have each vessel in focus to execute it's burn, which I'm using ksp alarm to kill warp for, but I need the flight computer to remember the instructions I sent the vessel to be able to do it.

EDIT: Also I seem to have hit a bug. I have a probe that has direct comms with KSC, but when I try to use the flight computer to orient it facing towards my manoeuvre node to probe just starts spinning. If I use the flight computer to try to kill rotation it rotates faster. I have to use mechjeb to kill rotation. Anyone else run into this?

Edited by Errol

Share this post


Link to post
Share on other sites
Hi there,

Just wondering if there is a way to disable the ability that the MechJeb AR-202 Case has that acts as if a Kerbal were steering the craft it is attached to. I would like it to act like any other probe body when it comes to requiring contact with mission control.

Adding this to the RemoteTech_MechJeb.cfg got me want I wanted. Figuring it out my self also made me understand a bit how module manager works and why it is pretty cool.


MODULE
{
name = ModuleRTAntennaPassive
TechRequired = unmannedTech
OmniRange = 3000

TRANSMITTER
{
PacketInterval = 0.3
PacketSize = 2
PacketResourceCost = 15.0
}
}

Share this post


Link to post
Share on other sites
EDIT: Also I seem to have hit a bug. I have a probe that has direct comms with KSC, but when I try to use the flight computer to orient it facing towards my manoeuvre node to probe just starts spinning. If I use the flight computer to try to kill rotation it rotates faster. I have to use mechjeb to kill rotation. Anyone else run into this?

Yes, I've seen it once on a satellite I put up. I forgot that the flight computer can't estimate the burn time on RCS thrusters alone. I had forgot to put on some type of regular thruster. I don't know if that was the cause but it was doing exactly what you said. MJ kill rot would stop it though. I've only seen this once. My other sats behave like they should.

Share this post


Link to post
Share on other sites
Yes, I've seen it once on a satellite I put up. I forgot that the flight computer can't estimate the burn time on RCS thrusters alone. I had forgot to put on some type of regular thruster. I don't know if that was the cause but it was doing exactly what you said. MJ kill rot would stop it though. I've only seen this once. My other sats behave like they should.

This happened to me when I was using a ship which I had built in the VAB and then later I used Select Root to change the root part, in this case from the probe core to a fuel tank so I could use the probe core with kOS (known kOS issue destroys a ship if the kOS module is loaded into a root part). When I rebuilt the ship in the VAB starting with the fuel tank so I didn't have to use Select Root, it worked fine with the flight computer.

Share this post


Link to post
Share on other sites

Well I've spent my afternoon on this post and found some pseudo-useful info for my problem but I can't solve it definitely.

The thing is: I've extracted RT2 several times to my GameData folder (including modulemanager.2.2.2.dll and everything in the .zip) but it just doesn't seem to work.

Is there anything I'm supposed to do with modulemanager2.2.2.dll apart from copying it to /GameData folder?

Symptoms:

*I have all RT2 parts available, but none of them seem to work (can't open context menus with right click)

*I can still control any probe (it doesnt matter wether it has transmitting devices)

*I can see the new buttons on Map view and the red dot at KSC, but nothing else (when I open the sat list on the right side of the screen, a grey empty box shows up, even though I launched several sats)

*Even when starting a new carrer/sandbox nothing seems to change

From what I've found here already, my modulemanager isnt doing what it's supposed to (whatever that is). I'm running KSP on Steam, Windows 8.1 (blargh) x64 (I don't know if the game version is x64 or x86)

My KSP Folders:

http://imgur.com/a/jJWtZ

Does anyone have any ideas?

Share this post


Link to post
Share on other sites

Does anyone have any ideas?

Try installing RemoteTech in a clean KSP and see if that works. Also not sure if it makes a difference but delete delete the version of module manager RT2 comes with and get the latest being 2.3.4 from here http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-1-5-6-%28Jan-6%29

Edit: Noticed you installed KW Rocketry incorrectly You gonna fix that?

:sticktongue:

Edited by deepfield

Share this post


Link to post
Share on other sites
This happened to me when I was using a ship which I had built in the VAB and then later I used Select Root to change the root part, in this case from the probe core to a fuel tank so I could use the probe core with kOS (known kOS issue destroys a ship if the kOS module is loaded into a root part). When I rebuilt the ship in the VAB starting with the fuel tank so I didn't have to use Select Root, it worked fine with the flight computer.

Hmm, I too am a selectroot user, and I do believe I may have used the selectroot function to add extra batteries to my commsats when the mkIs died on the night side. That second payload of probes had the issue, but it was the second probe I tried to control, not first, and not counting the lift stages. It was odd because at first it would just not point in the right direction, it would be 90 degrees off in the same direction every time. MJ could point to a node fine though. I was only able to stop the spin with MJ if I made sure to stop sending kill rotation commands from the flight computer as well. It appeared to me that the issue was specifically a heading calculation error with the node command and somehow a spinning heading on the kill command.

EDIT: Are feature requests entertained in this thread? I would like a difficulty setting that causes omnidirectional antennas to be able to automatically connect to only the nearest other omnidirectional antenna in range. Each antenna can only have one task at a time. If you want an active relay from A > B through C then C needs two antennas. This way, for instance, if we are controlling a rover on the surface, in order to minimize blackouts it benefits us to built commlink sats with enough antennas to maintain connections with each other (2), the relay back to kerbin from where ever you are AND the surface.

Edited by Errol

Share this post


Link to post
Share on other sites
Try installing RemoteTech in a clean KSP and see if that works. Also not sure if it makes a difference but delete delete the version of module manager RT2 comes with and get the latest being 2.3.4 from herehttp://forum.kerbalspaceprogram.com/...-6-%28Jan-6%29

Edit: Noticed you installed KW Rocketry incorrectly You gonna fix that?

:sticktongue:

Ok, trying that now.

The KW Rocketry "wrong folder" is empty now, I noticed I messed it up so just fixed it and left the empty one there hahaha

EDIT: It worked! (: Thanks, apparently there's nothing a clean reinstall won't fix haha

Edited by guischmitd

Share this post


Link to post
Share on other sites

hello all a question about editing remote tech

is there a possibility to edit a part cfg so that it acts like KSC command center like on kerbin?

say a lab part that acts in that way and then send it to duna and have all the benefits of ksc thx

Share this post


Link to post
Share on other sites
hello all a question about editing remote tech

is there a possibility to edit a part cfg so that it acts like KSC command center like on kerbin?

say a lab part that acts in that way and then send it to duna and have all the benefits of ksc thx

Already in RT2. Any part that has ModuleSPU with isRTCommandStation = true will act as a control origin if it's on a vessel with at least six kerbals. Look at RemoteTech_Squad_Probes.cfg to see how the settings are applied to the large stack probe core.

The six-kerbal requirement is hardcoded in the current release, but will likely be made configurable in the future.

Share this post


Link to post
Share on other sites
Already in RT2. Any part that has ModuleSPU with isRTCommandStation = true will act as a control origin if it's on a vessel with at least six kerbals. Look at RemoteTech_Squad_Probes.cfg to see how the settings are applied to the large stack probe core.

The six-kerbal requirement is hardcoded in the current release, but will likely be made configurable in the future.

thx for a quick response :) so in other words no way we can change the 6 kerbal requirement for now?

Share this post


Link to post
Share on other sites
thx for a quick response :) so in other words no way we can change the 6 kerbal requirement for now?

Anyone who's comfortable downloading the plugin source code and compiling a modified version is welcome to take a crack at changing it, but the required change is inside the plugin and not available by normal .cfg editing.

I haven't gotten around to setting up a C# compiler, but I'll leave a hint here for any interested coders. The constant 6 is in a couple of places in ModuleSPU.cs.

Edited by undercoveryankee

Share this post


Link to post
Share on other sites
Anyone who's comfortable downloading the plugin source code and compiling a modified version is welcome to take a crack at changing it, but the required change is inside the plugin and not available by normal .cfg editing.

I haven't gotten around to setting up a C# compiler, but I'll leave a hint here for any interested coders. The constant 6 is in a couple of places in ModuleSPU.cs.

ok thank you

Share this post


Link to post
Share on other sites

I can remember RT included some mm config files for AIES. Where can I find them and why they are removed from the mod at all?

Edit: Would it work if I simply use the mm config file for AIES from an older RT2 version?

Edited by acc

Share this post


Link to post
Share on other sites
I can remember RT included some mm config files for AIES. Where can I find them and why they are removed from the mod at all?

Edit: Would it work if I simply use the mm config file for AIES from an older RT2 version?

I found a AIES config for RT2 somewhere on this thread but can't find it again. Here is the one I use

https://www.dropbox.com/s/5hzacplkn86ehod/RemoteTech_AIES_3.cfg?dl=0

Share this post


Link to post
Share on other sites

I have a problem with this mod. Not sure if it's already addressed. The problem is that suddenly all my antennas and dishes have 2 target buttons, 2 activate buttons and 2 status texts. Like if there were 2 identical parts in the same place. Everything was working fine a few days ago, but now this is happening, and sometimes my dishes don't target my active vessel because they loose connection even when in range.

Share this post


Link to post
Share on other sites
I have a problem with this mod. Not sure if it's already addressed. The problem is that suddenly all my antennas and dishes have 2 target buttons, 2 activate buttons and 2 status texts. Like if there were 2 identical parts in the same place. Everything was working fine a few days ago, but now this is happening, and sometimes my dishes don't target my active vessel because they loose connection even when in range.

Duplicate buttons mean two copies of the module are being applied to the parts. Make sure you have only one copy of the plugin and only one copy of the ModuleManager config files.

Share this post


Link to post
Share on other sites
I have a problem with this mod. Not sure if it's already addressed. The problem is that suddenly all my antennas and dishes have 2 target buttons, 2 activate buttons and 2 status texts. Like if there were 2 identical parts in the same place. Everything was working fine a few days ago, but now this is happening, and sometimes my dishes don't target my active vessel because they loose connection even when in range.

To add what undercoveryankee is saying also check to make sure you have only 1 ModuleManager *.*.* installed, mods don't do anything special to ModuleManager so you can delete the lesser number.

Share this post


Link to post
Share on other sites

You're right, there was an older modulemanager.dll inside KerbPaint folder. I deleted it and now everything works fine. Thanks!

Share this post


Link to post
Share on other sites

I'm having a problem with RemoteTech 2 v1.4.1 where KSP (.24.2 32-bit) is locking up within seconds of going to the tracking station screen. Not getting a log because I have to kill the process from the windows task manager. It doesn't happen if RemoteTech isn't installed. Any suggestions?

[h=1][/h]

Share this post


Link to post
Share on other sites

I'm working on a modulemanager config that will change the funny-but-not-useful dish/antenna descriptions with dry-but-useful information about the parts' best uses. I'm new to RemoteTech (which is why I want this help) so I have no idea what actually should be in each description. So I'm wondering three things:

  1. Would something like this help anybody else? I'll happily maintain it with any suggestions.
  2. What should the descriptions contain? I don't want to just duplicate what's already there I want the descriptions to contain useful derived information from the dish/antenna stats.
  3. Should this be in its own thread? If nobody cares, then it can just die as my little side project that helps me a little but nobody else. If people like it, I figure it should probably get its own thread so as to be findable and not muck up this thread with side chatter.

Anyway, here's the config as I have it now. It's a bit sparse and I got the info from the wiki and a little calculating and drawing and remembering (way) back to trig classes.


@description = Will work on any line of sight to KSC if below 150km altitude
}

@PART[longAntenna]:AFTER[RemoteTech2] {
@description = Will work on any line of sight to KSC if below 1960km altitude (Below Keostationary)
}

@PART[RTLongAntenna3]:AFTER[RemoteTech2] {
@description = Will work on any line of sight to KSC if below 2460km altitude (Just Below Keostationary)
}


@PART[RTLongAntenna2]:AFTER[RemoteTech2] {
@description = Will work on any line of sight to KSC if below 4430km altitude (Well Above Keostationary)
}

@PART[mediumDishAntenna]:AFTER[RemoteTech2] {
@description = Reaches Minmus. Cone covers Keostationary at Mun.
}

@PART[RTShortDish2]:AFTER[RemoteTech2] {
@description = Reaches all of Kerbin SOI. Cone covers Kerbin well within Mun's orbit, Keostationary well within Minmus' orbit.
}

@PART[commDish]:AFTER[RemoteTech2] {
@description = Reaches Duna at all times, Dres on Kerbin's side of Sun. Cone covers Kerbin just outside of SOI.
}

@PART[RTLongDish2]:AFTER[RemoteTech2] {
@description = Reaches Dres at all times, Jool on Kerbin's side of Sun, barely reaches Eeloo at its periapsis. Cone covers Kerbin from Minmus' orbit, Keostationary outside of Kerbin's SOI.
}

@PART[RTGigaDish2]:AFTER[RemoteTech2] {
@description = Reaches everywhere. Cone covers Keystationary from any planet.
}

@PART[RTGigaDish1]:AFTER[RemoteTech2] {
@description = Reaches everywhere. Cone covers Keystationary from any planet.
}

@PART[RTShortDish1]:AFTER[RemoteTech2] {
@description = Decommissioned part. Do not use.
}

@PART[RTLongDish1]:AFTER[RemoteTech2] {
@description = Decommissioned part. Do not use.
}[/noparse]
[noparse]@PART[RTShortAntenna1]:AFTER[RemoteTech2] {

Edited by 5thHorseman

Share this post


Link to post
Share on other sites
I'm working on a modulemanager config that will change the funny-but-not-useful dish/antenna descriptions with dry-but-useful information about the parts' best uses. I'm new to RemoteTech (which is why I want this help) so I have no idea what actually should be in each description. So I'm wondering three things:

  1. Would something like this help anybody else? I'll happily maintain it with any suggestions.
  2. What should the descriptions contain? I don't want to just duplicate what's already there I want the descriptions to contain useful derived information from the dish/antenna stats.
  3. Should this be in its own thread? If nobody cares, then it can just die as my little side project that helps me a little but nobody else. If people like it, I figure it should probably get its own thread so as to be findable and not muck up this thread with side chatter.

Anyway, here's the config as I have it now. It's a bit sparse and I got the info from the wiki and a little calculating and drawing and remembering (way) back to trig classes.


@description = Will work on any line of sight to KSC if below 150km altitude
}

@PART[longAntenna]:AFTER[RemoteTech2] {
@description = Will work on any line of sight to KSC if below 1960km altitude (Below Keostationary)
}

@PART[RTLongAntenna3]:AFTER[RemoteTech2] {
@description = Will work on any line of sight to KSC if below 2460km altitude (Just Below Keostationary)
}


@PART[RTLongAntenna2]:AFTER[RemoteTech2] {
@description = Will work on any line of sight to KSC if below 4430km altitude (Well Above Keostationary)
}

@PART[mediumDishAntenna]:AFTER[RemoteTech2] {
@description = Reaches Minmus. Cone covers Keostationary at Mun.
}

@PART[RTShortDish2]:AFTER[RemoteTech2] {
@description = Reaches all of Kerbin SOI. Cone covers Kerbin well within Mun's orbit, Keostationary well within Minmus' orbit.
}

@PART[commDish]:AFTER[RemoteTech2] {
@description = Reaches Duna at all times, Dres on Kerbin's side of Sun. Cone covers Kerbin just outside of SOI.
}

@PART[RTLongDish2]:AFTER[RemoteTech2] {
@description = Reaches Dres at all times, Jool on Kerbin's side of Sun, barely reaches Eeloo at its periapsis. Cone covers Kerbin from Minmus' orbit, Keostationary outside of Kerbin's SOI.
}

@PART[RTGigaDish2]:AFTER[RemoteTech2] {
@description = Reaches everywhere. Cone covers Keystationary from any planet.
}

@PART[RTGigaDish1]:AFTER[RemoteTech2] {
@description = Reaches everywhere. Cone covers Keystationary from any planet.
}

@PART[RTShortDish1]:AFTER[RemoteTech2] {
@description = Decommissioned part. Do not use.
}

@PART[RTLongDish1]:AFTER[RemoteTech2] {
@description = Decommissioned part. Do not use.
}[/noparse]
[noparse]@PART[RTShortAntenna1]:AFTER[RemoteTech2] {

Per http://remotetechnologiesgroup.github.io/RemoteTech/guide/parts/ , the outer-planets dishes are too narrow to cover keostationary orbit from planets that the medium dishes would reach, so I wouldn't say they cover keostationary orbit from all planets. I'd also suggest editing the stock antennas' descriptions to include the same information.

Share this post


Link to post
Share on other sites
Per http://remotetechnologiesgroup.github.io/RemoteTech/guide/parts/ , the outer-planets dishes are too narrow to cover keostationary orbit from planets that the medium dishes would reach, so I wouldn't say they cover keostationary orbit from all planets. I'd also suggest editing the stock antennas' descriptions to include the same information.

Good catch. I was actually using that exact page for my notes but I seem to have forgotten to carry a 1 or something, and I'll fix those.

And the stock antennae and dishes are in there already. I should add comments for each one to say what it is named in the game.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.