Jump to content

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

Peppie23

By Peppie23
in KSP1 Mod Releases

 Share

Recommended Posts

Mecripp

Mecripp

Posted
Posted
Is there a ... RT2 Map of sorts? Like delta V.. a map that shows each planets communication distances?

Do keep in mind that your RSS so someone might give you the wrong info there are mods that will tell you how far you are from a planet and you can find the range of the dishes and Antennas in Vab.

Link to comment
Share on other sites
Superfluous J

Superfluous J

Posted
Posted (edited)
I see. So the range values for distance are the same as the values the dishes use? What does Mm, Gm and Tm stand for?

This may help, it's a modman config for each dish that changes the descriptions to tell you how far each thing reaches from KSC...

The config file, just drop it into GameData along with ModuleManager.dll


@PART[RTShortAntenna1]:AFTER[RemoteTech2] {
@description = Hardy. Always on to start. Needed for a probe-only mission. Will work on any line of sight to KSC if below 150km altitude.
}

// Communotron 16 (Stock part repurposed for RT2)
@PART[longAntenna]:AFTER[RemoteTech2] {
@description = Will work on any line of sight to KSC if below 1960km altitude (Below Keosynchronous)
}

// CommTech EXP-VR-2T
@PART[RTLongAntenna3]:AFTER[RemoteTech2] {
@description = Will work on any line of sight to KSC if below 2460km altitude (Just Below Keosynchronous)
}

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

// Comms DTS-M1 (Stock part repurposed for RT2)
@PART[mediumDishAntenna]:AFTER[RemoteTech2] {
@description = Reaches Minmus. Cone covers Keosynchronous at Mun.
}

// Reflectron KR-7
@PART[RTShortDish2]:AFTER[RemoteTech2] {
@description = Hardy. Reaches all of Kerbin SOI. Cone covers Kerbin well within Mun's orbit, Keosynchronous well within Minmus' orbit.
}

// Communotron 88-88 (Stock part repurposed for RT2)
@PART[commDish]:AFTER[RemoteTech2] {
@description = Reaches Duna at all times, Dres on Kerbin's side of Sun. Cone covers Kerbin just outside of SOI. At Eve and Duna closest, cone will not cover Keosynchronous.
}

// Reflectron KR-14
@PART[RTLongDish2]:AFTER[RemoteTech2] {
@description = Hardy. Reaches Dres at all times, Jool on Kerbin's side of Sun, barely reaches Eeloo at its periapsis. Cone covers Kerbin from all planets. At Moho and Duna's closest approaches and when Eve is on the same side of Sun, cone will not cover Keosynchronous.
}

// CommTech-1
@PART[RTGigaDish2]:AFTER[RemoteTech2] {
@description = Hardy. Reaches everywhere. At Moho and Duna's closest approaches and when Eve is on the same side of Sun, cone will not cover Kerbin. On any inner planet (including Dres), Eeloo at closest approach, and Jool on the same side of Sun, cone will not cover Keosynchronous.
}

// Reflectron GX-128
@PART[RTGigaDish1]:AFTER[RemoteTech2] {
@description = Lightweight. Reaches everywhere. Cone will not cover Kerbin from low Sun orbit or Moho and Eve when on the same side of Sun, or a lot of Duna's close approach. All inner planets (including Dres) and Jool for all but when it on the opposite side of Sun, and about half of Eeloo's orbit the cone will not cover Keosynchronous.
}

// Old part - not in game anymore.
@PART[RTShortDish1]:AFTER[RemoteTech2] {
@description = Decommissioned part. Do not use.
}

// Old part - not in game anymore.
@PART[RTLongDish1]:AFTER[RemoteTech2] {
@description = Decommissioned part. Do not use.
}
// Reflectron DP-10

Edited by 5thHorseman
Link to comment
Share on other sites
Mecripp

Mecripp

Posted
Posted

The only one on that list that will be wrong for you is Minmus it's moved in RSS, I think it was the only one and the range in the

@description = Will work on any line of sight to KSC if below 4430km altitude (Well Above Keosynchronous)
will be off but the same dish to bodys will be the same but the 1.
Link to comment
Share on other sites
Starstrider42

Starstrider42

Posted
Posted (edited)
Can anybody give me a quick idea of how to land an unmanned probe back on Kerbin? I have a good comsat network around Kerbin, but when I undergo atmospheric reentry I either have to retract my antenna or have it get ripped off, both of which kill my connection.

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.

Is there a ... RT2 Map of sorts? Like delta V.. a map that shows each planets communication distances?

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.

Edited by Starstrider42
Link to comment
Share on other sites
Superfluous J

Superfluous J

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

The worst part is, when I made that modulemanager config I actually made a dV map for my own personal use.

Then I deleted it when I finished the config.

I actually still have it! But it's pretty ugly.

I'm going to export it as an ugly raw image. It's to scale, which makes it unusably large.

EDIT:

remotetech_dishes.png

Edited by 5thHorseman
Link to comment
Share on other sites
AetherGoddess

AetherGoddess

Posted
Posted
how does one make another command station, such as when im using the Kerbin-side mod?

i found this by mistake. in RemoteTech_Settings.cfg:


GroundStations
{
    STATION
    {
        Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488
        Name = Mission Control
        Latitude = -0.131331503391266
        Longitude = -74.594841003418
        Height = 75
        Body = 1
        Antennas
        {
            ANTENNA
            {
                Omni = 7.5E+07
            }
        }
    }
}

so probably that.

Link to comment
Share on other sites
Noorbi

Noorbi

Posted
Posted

Hi there!

I have some problem: sometimes the game crashes(or freezes for minutes and then crashes). Mostly when i set an order to my remote controlled vessel and it takses more than 1 min to be done.

Is it the RT2 or some other mods? Any tips? [sorry for my english]

Link to comment
Share on other sites
Tadeáš

Tadeáš

Posted
Posted

Hi!

I have started to use this mod today but it probably does not work. I installed it as usual (just put RemoteTech2 folder to GameData), however, even if I have many antennas on my probe, it constantly shows "No connection".

Any ideas to fix it or what am I doing wrong? I read tutorials and still...

Link to comment
Share on other sites
Starstrider42

Starstrider42

Posted
Posted
Hi there!

I have some problem: sometimes the game crashes(or freezes for minutes and then crashes). Mostly when i set an order to my remote controlled vessel and it takses more than 1 min to be done.

Is it the RT2 or some other mods? Any tips? [sorry for my english]

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?

Hi!

I have started to use this mod today but it probably does not work. I installed it as usual (just put RemoteTech2 folder to GameData), however, even if I have many antennas on my probe, it constantly shows "No connection".

Any ideas to fix it or what am I doing wrong? I read tutorials and still...

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?

Link to comment
Share on other sites
Noorbi

Noorbi

Posted
Posted

I use 32bit KSP.


d3d: failed to create 2D texture id=673 w=15 h=15 mips=5 d3dfmt=21 [invalid call]
allocation 0x00000000 already registered @ :l297 size 1197; now calling from :l297 size 21?

(Filename:  Line: 1134)

d3d: failed to create 2D texture id=1233 w=2 h=2 mips=3 d3dfmt=21 [invalid call]
allocation 0x00000000 already registered @ :l297 size 1197; now calling from :l297 size 21?

(Filename:  Line: 1134)

d3d: failed to create 2D texture id=1235 w=2 h=2 mips=3 d3dfmt=21 [invalid call]
allocation 0x00000000 already registered @ :l297 size 1197; now calling from :l297 size 21?

(Filename:  Line: 1134)

d3d: failed to create 2D texture id=1251 w=2 h=2 mips=3 d3dfmt=21 [invalid call]
allocation 0x00000000 already registered @ :l297 size 1197; now calling from :l297 size 21?

(Filename:  Line: 1134)

d3d: failed to create 2D texture id=1257 w=2 h=2 mips=3 d3dfmt=21 [invalid call]
allocation 0x00000000 already registered @ :l297 size 1197; now calling from :l297 size 21?

(Filename:  Line: 1134)

d3d: failed to create 2D texture id=1263 w=2 h=2 mips=3 d3dfmt=21 [invalid call]
allocation 0x00000000 already registered @ :l297 size 1197; now calling from :l297 size 21?

(Filename:  Line: 1134)

d3d: failed to create 2D texture id=1267 w=2 h=2 mips=3 d3dfmt=21 [invalid call]
allocation 0x00000000 already registered @ :l297 size 1197; now calling from :l297 size 21?

(Filename:  Line: 1134)

d3d: failed to create 2D texture id=1273 w=2 h=2 mips=3 d3dfmt=21 [invalid call]
allocation 0x00000000 already registered @ :l297 size 1197; now calling from :l297 size 21?

(Filename:  Line: 1134)

d3d: failed to create 2D texture id=1279 w=2 h=2 mips=3 d3dfmt=21 [invalid call]

Link to comment
Share on other sites
disoculated

disoculated

Posted
Posted

I'm having a problem with RT2 on 0.24.2, 32 bit windows, similar to what people above are seeing. I have had several ships in orbit inside of Kerbin (specifically orbit over Eve, and low-ish orbit over the Sun) that freeze the game after vehicle load. There's no messages other than the vehicle load lines in the log file, and the game doesn't actually crash. Even if I leave it up for hours and come back, it's still a frozen screen with no time passing, and I can't alt-tab out of KSP. Much like when you're loading a large ship in the VAB and accidentally attach 8 copies of itself together, and you can't alt-tab and have to wait forever for the game to come back, but in this case it never does.

I can repeat this if I go to the affected vessel via the map, kerbal alarm clock, or the tracking station.

The only way I found out that it was RT2 doing this was that I had to disable mods one by one until the problem resolved... renaming the rt2.dll to dll.old and preventing it's load fixed the problem. I tried viewing the debug (f12) log on-screen, but it does this irritating thing where it scrolls up during vehicle load and then the game is frozen before I can scroll down to see what's happening. Is there a way to dump that log to disk? Or a way to force a game dump?

I can send you logfiles, but I don't know if they'll be useful. I'm trying to find out the things that all the affected vessels have in common and what I've come up with is this (and I've no idea if it's relevant):

So far, all have been inside Kerbin's orbit (Eve, Sun, etc).

All ships have had both Commutron 88-88 and Commutron 32 antennas.

All ships have had an Okto2 probe core somewhere on the vessel.

Interesting things not in common:

Ships with crew as well as those without have been affected.

Fairly certain that ships have not had the same uplink paths, but, again, hard to tell when the game crashes on load of that ship.

Mods:

Chatterer

Active Texture Management

b9 Aerospace (old version with patch)

Mechjeb2

Precisenode

Engineer

Deadly Reentry

EVE

FAR

KAS

Procedural Fairings

Realchute

Scansat

TAC Fuel Balancer and Life Support

Kerbal Alarm Clock

US Core

Is there any other information I can get you? I can send you the logfile and/or save game.

PS- I really do enjoy this mod, it adds a lot to the game, and I hope we can get this fixed so I can continue to build my mega-sat empire across the solar system :)

Link to comment
Share on other sites
Pirsig

Pirsig

Posted
Posted

Hi, so I took the liberty of quickly changing remote tech's configs so that they all have proper :FOR statements for MM. This had been done in a couple places already, but incorrectly as :FOR[RemoteTech]. Since the .dll is named RemoteTech2, in order to properly associate these changes it needs to be :FOR[RemoteTech2]. I've also removed the current probe configs and replaced them with one that adds RT functionality to any properly configured probe core. Exceptions are added afterwards and I've already included those that were already in place. (large remote guidance as command station, ar202 and explorer probe not having a passive antenna) Nothing has functionally changed, this just adds better compatibility.

I don't really know what the policy is so I wanted to post here before just making a pull request. My fork can be found here

Link to comment
Share on other sites
Peppie23

Peppie23

Posted
  • Author
Posted
I'm having a problem with RT2 on 0.24.2, 32 bit windows, similar to what people above are seeing. I have had several ships in orbit inside of Kerbin (specifically orbit over Eve, and low-ish orbit over the Sun) that freeze the game after vehicle load. There's no messages other than the vehicle load lines in the log file, and the game doesn't actually crash. Even if I leave it up for hours and come back, it's still a frozen screen with no time passing, and I can't alt-tab out of KSP. Much like when you're loading a large ship in the VAB and accidentally attach 8 copies of itself together, and you can't alt-tab and have to wait forever for the game to come back, but in this case it never does.

I can repeat this if I go to the affected vessel via the map, kerbal alarm clock, or the tracking station.

...

Hi disoculated,

your error seems to be related to https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/139

Please use this dll https://www.dropbox.com/s/7hszm2m6havieyh/RemoteTech2_debug_dll_only.zip to reproduce this again. After your game crashed go to your ksp directory and copy the log file for me. You can find the log: KSP_INSTALL_DIR/KSP_Data/output_log.txt (this file can be huge for this error, please zip this file)

Link to comment
Share on other sites
Starstrider42

Starstrider42

Posted
Posted
Hi, so I took the liberty of quickly changing remote tech's configs so that they all have proper :FOR statements for MM. This had been done in a couple places already, but incorrectly as :FOR[RemoteTech]. Since the .dll is named RemoteTech2, in order to properly associate these changes it needs to be :FOR[RemoteTech2]. I've also removed the current probe configs and replaced them with one that adds RT functionality to any properly configured probe core. Exceptions are added afterwards and I've already included those that were already in place. (large remote guidance as command station, ar202 and explorer probe not having a passive antenna) Nothing has functionally changed, this just adds better compatibility.

I don't really know what the policy is so I wanted to post here before just making a pull request. My fork can be found here

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!

Link to comment
Share on other sites
Pirsig

Pirsig

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

I don't really get what the complaint could be, but whatever. As for the the :FOR's, perhaps I should clarify what I mean by proper association. Obviously it will work fine if you call it RemoteTech, you could have a different pass name on every config if you wanted. That doesn't fit with the naming conventions defined by MM though. That means that someone has to actually go look at your configs to find out some are running in first and some are running in RemoteTech, neither of which are the expected RemoteTech2 pass (to match the dll and folder name). It doesn't break anything to do it your way, but it's not friendly to other modders either.

Link to comment
Share on other sites
undercoveryankee

undercoveryankee

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

I don't really get what the complaint could be, but whatever. As for the the :FOR's, perhaps I should clarify what I mean by proper association. Obviously it will work fine if you call it RemoteTech, you could have a different pass name on every config if you wanted. That doesn't fit with the naming conventions defined by MM though. That means that someone has to actually go look at your configs to find out some are running in first and some are running in RemoteTech, neither of which are the expected RemoteTech2 pass (to match the dll and folder name). It doesn't break anything to do it your way, but it's not friendly to other modders either.

I think the ModuleManager developers do recommend using your folder/plugin name as your :FOR pass, so other patch authors don't have to read your config files to know what pass you're running in. If you would like to keep a uniform pass name between versions that might have different folder/plugin names, that makes sense too, but I would recommend that it be pretty prominent in any "for mod authors" documentation.

And if there are patches that don't have :FOR[RemoteTech], it wouldn't hurt to go through and make them consistent.

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