[1.11] RemoteTech v1.9.9 [2020-12-19]

[Nobody6]

Hi,

in order to use Peenemünde as a launch site (RP-0 with RSS Airports) I wanted to add a ground station there. So I looked up the position and what other ground stations looked like and came up with this:

			STATION
			{
				Guid	  = 5105f5a9-d628-41c6-ad4b-21154e8fc481
				Name	  = DE Peenemuende
				Latitude  = 54.16673
				Longitude = 13.76886
				Height	  = 160
				Body	  = 1
				MarkColor = 1,1,0,1

				Antennas
				{
					ANTENNA
					{
						Omni = 6E+05
					}
				}
			}

However, this had no effect. Is there something fundamentally wrong with my ground station? Maybe I edited the wrong file. Which (and where) would the file containing the ground stations be located in a RP-0 install?

Thanks

 

EDIT

Ok, figured it out. The "code" is correct, but the "RemoteTech_Settings.cfg" and therefore the list of ground stations is copied to the savegame. If I edit that one, or start a new game, the ground station is present and accounted for. :-)

Edited August 18, 2016 by Nobody6
Solution found

[Diche Bach]

On 8/16/2016 at 3:27 PM, przybysz86 said:

it does not matter as with anything that emits waves you can, with proper placement, amplify signal in some directions. They will no longer be "omni" but frankly even "real omni" antenna is not. Based on nearby metal planes you can attenuate signal in some directions and amplify it in others. Putting more than one antennas will also add to that - signal in some directions would be amplified while other can cancel out totally.
It's too complex to be easily simulated in games like KSP, we do not even have proper directional antennas now that have to be exactly directed toward the source - this is more of a concern in small probes without RCS than antenna heat.

Interesting. So using "multiple Tier 1" antenna to amplify and achieve the effective range of a "Tier 2  or 3.5 (or whatever)" _IS_ a real thing (albeit with tradeoffs in reduced range in some directions, which the game cannot really model . . .). Thanks for posting that.

On 8/17/2016 at 3:30 AM, przybysz86 said:

that makes much more sense - omni antenna emits energy roughly spherically (good enough simplification) and you can calculate how much will return just by calculating angular ratio between your ship and whole sphere (forgive my English but I think you will get the idea).
Then you have to check how many of that would be reflected, etc but it's not unlike the calculations done for IR radiation from Sun, etc

Yeah, even from my childlike view of physics that seems to make more sense: basically your antenna can turn into a "phaser!"

 

[przybysz86]

2 minutes ago, Diche Bach said:

Interesting. So using "multiple Tier 1" antenna to amplify and achieve the effective range of a "Tier 2  or 3.5 (or whatever)" _IS_ a real thing (albeit with tradeoffs in reduced range in some directions, which the game cannot really model . . .). Thanks for posting that.

normal antenna (like CB) is just a monopole, use two and you get dipole, use multiple and you get for eample Yagi-Uda antenna and so on.
It's not just matter of putting two or more so omni spam would be a stupid thing but technically in very specific setups it can actually work

If you want to see v. modern case where lot of small antennas create directional steerable source check this:
https://en.wikipedia.org/wiki/Phased_array
 

Interesting thing is that it works for both sound and EM - sound phased arrays are used on concert stages - speakers are tuned together so that sound is as even as possible along the audience and not loud in middle and quite on sides, etc.
More reading n EM phased arrays I suggest:
https://en.wikipedia.org/wiki/Passive_electronically_scanned_array
https://en.wikipedia.org/wiki/Active_electronically_scanned_array

 

this is just a beginning but will show you that EM propagation is much more complicated than you can imagine. There are lot of situation that are almost like "butterfly effect" when putting small thing somewhere or changing something by 0.00001m tend to dramatically change wave propagation and not always into negative side.

[garwel]

I don't know why it happened, but a week or so ago I noticed a significant framerate drop and I suspect it is caused by RT. The game used to run smooth in the past, but now, it only makes like 6 fps in KSC and around 3 fps on launch even with a simple rocket. The log shows a lot of RT activity, which doesn't seem right (e.g. lots of OnDestroy calls for various ships).

Any idea what might be wrong with it?

PS: It may be my imagination, but I also simultaneously noticed that one of my probes orbiting Minmus had lost connection that I swear it had had before. I have no idea how it might happen as RT hasn't been updating for quite a while. May be a conflict with another mod, like SCANsat?..

Edited August 18, 2016 by garwel

[kR105]

2 hours ago, garwel said:

I don't know why it happened, but I recently noticed a significant framerate drop and I think it is caused by RT. The game used to run smooth in the past, but now, it only makes like 6 fps in KSC and around 3 fps on launch even with a simple rocket. The log shows a lot of RT activity, which doesn't seem right (e.g. lots of OnDestroy calls for various ships).

Any idea what might be wrong with it?

 

Same

[MaverickSawyer]

Quick question... does anyone have a MM patch or replacement .cfg that adds RT compatibility to DMagic's SIGINT dishes?

[Leszek]

RT Feedback.

I went back a couple pages looking for this, I am sure it has come up before.

None the less...

The flight computer desperately needs to know when it has missed a node.  If you get to the planned DV spent and are more than 10 degrees off the node cut throttle now.  As it is the craft will start to spin until it runs out of power in the most frustrating way.  Several game years to get there, careful planning of all the DV.  The flight computer has hit all the nodes up til now close enough.  And then WAM, sorry it is all wasted.  This thing will spin pointlessly until it is out of fuel while you watch helplessly.

The worst part, its sister probe on an even longer mission is probably going to fail the same way.  There is nothing I can do about it.  My whole days work is pointless.

[SilverlightPony]

@Leszek  You could always turn off signal delay and take manual control, at least for the time being.

[panarchist]

On 8/16/2016 at 4:01 PM, Siege said:

Actually, the more I look into it, it seems the larger concern (unless you have a great deal of impedance, or are trying to transmit huge wattages on a small antenna, or have a large dipole array or the like buried or semi-buried in the ground, which is a resistor) is less the heating of an antenna, but rather the antenna's emissions causing heating in dielectrics nearby them.

So it's not actually that they get hot themselves, but rather can induce heating in their nearby environment - depending on frequency, metals and liquids would be the prime targets. Dishes would be largely excluded (except for that note in the prior article about solar probes, and the dish reflecting heat at other parts of the spacecraft), but rather, omni-antennas radiating huge wattages and similar could heat up materials nearby. 

However, at this level, while I suppose it wouldn't be all *that* hard to simulate, I suppose it would be probably too minor in the long run to be a consideration for the RT maintainers to want to bother with... that said, maybe I'll see about brewing it up for myself, and if I can figure that much out on my own, well, we'll see.

Antennae generate a small amount of heat when transmitting, and very little heat when receiving (since the received signal is comparatively small).  Heat is also generated through induced RF, impedance losses, capacitance and voltage leakage, and other factors.  Almost all losses eventually become heat.  Again, most of the heat is involved in transmission, since the signal is several orders of magnitude higher than in reception.  Reception generates some heat in components used to detect and process the signal - mostly the amplifier.  A good reference to some of this is NAVEDTRA14092, the U.S. Navy's Naval Education and Training doc for the Electronics Technician rating.  You can expect typical losses of 4%-25% (more towards the small end for space-based antennae) 

[Salvator]

Hi everyone. I was wondering if there's a mod that would allow you to create custom vessel groups in the tracking station in the same manner you can create custom groups of parts in VAB and SPH. The number of communication satellites is too damn high and it would be great to be able to filter them, or vice versa: filter the rest of the unmanned vessels.

[Diche Bach]

On 8/18/2016 at 11:56 PM, MaverickSawyer said:

Quick question... does anyone have a MM patch or replacement .cfg that adds RT compatibility to DMagic's SIGINT dishes?

By this you mean: add data transmission and "active connection" functionality to things like the "Little Brother signals intelligence" telescope, etc.?

Sorry, cannot help, but I'd be interested in that too, though I'd have to think on it whether I'd consider it an "exploit" or not.

[gary.townsend]

An exploit? We are flying spaceships with vegetables as pilots, adding stuff in to help others find more fun is hardly an exploit.

[Diche Bach]

I don't care what anyone else does with their KSP install. Mod in dragons and power your space ships with unicorn farts, if you enjoy it, that is great. It's a single player, game so my mentioning of "exploit" as merely meant to refer to a personal decision about whether I'd consider it in my own install and I make no presumptions about judging anyone else's playstyle, or specific permutation of mods/add-ons.

Like I said, " I'd be interested in that too, though I'd have to think on it whether I'd consider it an "exploit" or not."

[LessrOf2Weevils]

During a capture burn around Moho, I noticed that the flight computer significantly over estimated the burn time resulting in the burn starting too early and, well, a new crater for Moho.  A revert and some additional finagling got me the capture, but it got me thinking about what happened.

It appears to me that the flight computer bases its burn time estimate on the current mass of the vessel, but this can be way off with big burns.  In my case, my probe shed 63% of its mass during the burn.  I believe I have a formula that calculates burn time taking into account changing mass.

t = (Isp*m*g_0)/T * (1 - exp(-dv/(Isp*g_0)))

Isp := well, ISP
m := initial mass
g_0 := gravitational field constant (9.8)
T := thrust
dv := delta-v of the burn

I'm not sure if you want it, but here it is.

Regardless, I do love this mod.

[Shikashi]

Any DMagic orbital science integration planned? I would LOVE to use the giant dishes for high power long distance calls

Awesome mod BTW, already got connections to minmus!

[Diche Bach]

17 hours ago, LessrOf2Weevils said:

During a capture burn around Moho, I noticed that the flight computer significantly over estimated the burn time resulting in the burn starting too early and, well, a new crater for Moho.  A revert and some additional finagling got me the capture, but it got me thinking about what happened.

It appears to me that the flight computer bases its burn time estimate on the current mass of the vessel, but this can be way off with big burns.  In my case, my probe shed 63% of its mass during the burn.  I believe I have a formula that calculates burn time taking into account changing mass.

t = (Isp*m*g_0)/T * (1 - exp(-dv/(Isp*g_0)))

Isp := well, ISP
m := initial mass
g_0 := gravitational field constant (9.8)
T := thrust
dv := delta-v of the burn

I'm not sure if you want it, but here it is.

Regardless, I do love this mod.

I have noticed similar things, and while I haven't analyzed as thoroughly as you have, your conclusions seem like they might be valid and I applaud you for the formula!

I had a Minmus Lander probe that wound up orbiting the sun because he seems to have missed his burn or done it improperly or something. I atttibuted it to either me not understanding exactly how the RT flight computer works, else me failing to allow it to stop time warp, else attempting to stack maneuvers before and after an SOI change (which I'm still not sure if that is a generally bad idea in the game in general, or especially with remote control).

I've found that: as long as I am there "watching it" in flight mode when it does its burn (and do not warp past the time for it to do its maneuver) everything works fine. Amazingly well in fact. So I'm a little bit skeptical that the problems you've encountered have to do with failing to account for mass change during the burn; if that were the case, then I would've expected to see poorly executed burns by the flight computer a lot more than I have. Instead, like I said, as long as I jump to the ship when it prompts me and slows down warp, and then do not warp past the burn, the flight computer seems to execute maneuvers setup in the flight planner perfectly, better than I do in fact.

But these are just anecdotal observations of course.

[COL.R.Neville]

Somebody wanted a patch to make the dmagic sigint dishes antennas? 

Spoiler

@PART[dmSIGINT]:AFTER[DMagicOrbitalScience]:NEEDS[RemoteTech] // Oversize sigint
{
    !MODULE[ModuleDataTransmitter] {}
    
    @MODULE[ModuleAnimateGeneric]
    {
        %allowManualControl = false
    }
    
    %MODULE[ModuleRTAntenna] {
        %Mode0OmniRange = 0
        %Mode1OmniRange = 450000000000
        %DishAngle = 15.0
    %EnergyCost = 5

        %DeployFxModules = 0
        %ProgressFxModules = 1

        %TRANSMITTER
        {
            %PacketInterval = 1
            %PacketSize = 2
            %PacketResourceCost = 0.5
        }
    }
    
    %MODULE[ModuleSPUPassive] {}
}

@PART[dmSIGINT.Small]:AFTER[DMagicOrbitalScience]:NEEDS[RemoteTech] // mildly Oversize sigint
{
    !MODULE[ModuleDataTransmitter] {}
    
    @MODULE[ModuleAnimateGeneric]
    {
        %allowManualControl = false
    }
    
    %MODULE[ModuleRTAntenna] {
        %Mode0OmniRange = 0
        %Mode1OmniRange = 450000000000
        %DishAngle = 15.0
    %EnergyCost = 5

        %DeployFxModules = 0
        %ProgressFxModules = 1

        %TRANSMITTER
        {
            %PacketInterval = 1
            %PacketSize = 2
            %PacketResourceCost = 0.5
        }
    }
    
    %MODULE[ModuleSPUPassive] {}
}

@PART[dmSIGINT.End]:AFTER[DMagicOrbitalScience]:NEEDS[RemoteTech] // mildly Oversize sigint
{
    !MODULE[ModuleDataTransmitter] {}
    
    @MODULE[ModuleAnimateGeneric]
    {
        %allowManualControl = false
    }
    
    %MODULE[ModuleRTAntenna] {
        %Mode0OmniRange = 0
        %Mode1OmniRange = 450000000000
        %DishAngle = 15.0
    %EnergyCost = 5

        %DeployFxModules = 0
        %ProgressFxModules = 1

        %TRANSMITTER
        {
            %PacketInterval = 1
            %PacketSize = 2
            %PacketResourceCost = 0.5
        }
    }
    
    %MODULE[ModuleSPUPassive] {}
}

it replaces the ModuleDataTransmitter with the antenna and data transmitter you can tweak the angles ranges and what not.

[LN400]

Sorry if this has been brought up and explained before but:

On the flight computer panel there are two arrows in the upper left. Clicking those gives me a 2nd panel with the buttons:

Tgt.

Hdt.

Fine

alongside a slider labeled Wheel.

There are also these boxes

LAT

LON

Speed

Looking at the documentation https://remotetechnologiesgroup.github.io/RemoteTech/guide/comp/ I can't seem to find any reference to any of this. Is there a description of what all of the above is, how it works and how to use it?

 

[aluc24]

Hey, @tomek.piotrowski , I just noticed that signal delay is now included for ALL actions (including pitching, throttling, etc.) for probes, whereas earlier, only things like staging, science gathering were delayed. With this new mechanic, how do I control the probes and drive rovers? Am I missing something obvious? Sorry if this was asked before.

 

P.S. I know I can disable signal delay in settings, but I don't want to disable it altogether, I just want to drive my rover.

Edited August 27, 2016 by aluc24

[SilverlightPony]

Just now, aluc24 said:

Hey, @tomek.piotrowski , I just noticed that signal delay is now included for ALL actions (including pitching, throttling, etc.) for probes, whereas earlier, only things like staging, science gathering were delayed. With this new mechanic, how do I control the probes and drive rovers? Am I missing something obvious? Sorry if this was asked before.

Option 1:  Use the flight computer to pre-program actions.

Option 2:  Turn off signal delay in the RT options (it's on another tab from the main options).

[aluc24]

Just now, SilverlightPony said:

Option 1:  Use the flight computer to pre-program actions.

Option 2:  Turn off signal delay in the RT options (it's on another tab from the main options).

How do I program driving rover, for example?

Turning off it in settings disables signal delay altogether, which isn't what I want... I like signal delay, but some actions can only be done real-time.

[SilverlightPony]

Just now, aluc24 said:

How do I program driving rover, for example?

Can't help you with that one; I went with Option 2. 

1 minute ago, aluc24 said:

Turning off it in settings disables signal delay altogether, which isn't what I want... I like signal delay, but some actions can only be done real-time.

As far as I'm aware, it's all or nothing.

[aluc24]

1 minute ago, SilverlightPony said:

Can't help you with that one; I went with Option 2. 

As far as I'm aware, it's all or nothing.

Well, what the heck. The previous mechanic (only experiments/staging delay) made so much more sense. I guess I'll have to disable it too, I just love my Duna rover too much. @tomek.piotrowski , this is a serious issue with otherwise great mod. Just my two cents...

[SilverlightPony]

1 minute ago, aluc24 said:

I guess I'll have to disable it too, I just love my Duna rover too much. @tomek.piotrowski , this is a serious issue with otherwise great mod. Just my two cents...

Personally, I rationalize Option 2 as "I'm playing the part of the computer, rather than some schmuck in Mission Control".

[aluc24]

Just now, SilverlightPony said:

Personally, I rationalize Option 2 as "I'm playing the part of the computer, rather than some schmuck in Mission Control".

Yeah, but I mean, the whole idea of signal delay becomes obsolete if it makes some things (like rovers) impossible to control...