Jump to content

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

Peppie23

By Peppie23
in KSP1 Mod Releases

 Share

Recommended Posts

monstah

monstah

Posted
Posted
(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.

Link to comment
Share on other sites
Errol

Errol

Posted
Posted (edited)

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
Link to comment
Share on other sites
deepfield

deepfield

Posted
Posted
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
		}
	}

Link to comment
Share on other sites
Bothersome

Bothersome

Posted
Posted
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.

Link to comment
Share on other sites
Drew Kerman

Drew Kerman

Posted
Posted
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.

Link to comment
Share on other sites
guischmitd

guischmitd

Posted
Posted

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?

Link to comment
Share on other sites
deepfield

deepfield

Posted
Posted (edited)

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
Link to comment
Share on other sites
Errol

Errol

Posted
Posted (edited)
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
Link to comment
Share on other sites
guischmitd

guischmitd

Posted
Posted (edited)
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
Link to comment
Share on other sites
dtoxic

dtoxic

Posted
Posted

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

Link to comment
Share on other sites
undercoveryankee

undercoveryankee

Posted
Posted
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.

Link to comment
Share on other sites
dtoxic

dtoxic

Posted
Posted
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?

Link to comment
Share on other sites
undercoveryankee

undercoveryankee

Posted
Posted (edited)
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
Link to comment
Share on other sites
dtoxic

dtoxic

Posted
Posted
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

Link to comment
Share on other sites
acc

acc

Posted
Posted (edited)

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
Link to comment
Share on other sites
deepfield

deepfield

Posted
Posted
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

Link to comment
Share on other sites
MaxShadow

MaxShadow

Posted
Posted

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.

Link to comment
Share on other sites
undercoveryankee

undercoveryankee

Posted
Posted
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.

Link to comment
Share on other sites
Mecripp

Mecripp

Posted
Posted
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.

Link to comment
Share on other sites
Superfluous J

Superfluous J

Posted
Posted (edited)

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
Link to comment
Share on other sites
undercoveryankee

undercoveryankee

Posted
Posted
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.

Link to comment
Share on other sites
Superfluous J

Superfluous J

Posted
Posted
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.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...