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

[KerbMav]

This is what the part looked like.

MODULE
{
name = ModuleAnimateGeneric
animationName = sci1
startEventGUIName =  Deploy equipment
endEventGUIName = Retract equipment
}
MODULE
{
name = ModuleAnimateGeneric
animationName = sci2
startEventGUIName =  Deploy dish
endEventGUIName = Retract dish
}
MODULE
{
        name = ModuleDataTransmitter

        packetInterval = 0.18
        packetSize = 2

        packetResourceCost = 20.0
        requiredResource = ElectricCharge

        DeployFxModules = 0
}
MODULE
{
name = ModuleAnimateGeneric
animationName = light
startEventGUIName =  Lights ON
endEventGUIName = Lights OFF
}

And this is what my MM file looks like.

@PART[sci_generic]
{
	!MODULE[ModuleDataTransmitter] {}

//	@MODULE[ModuleAnimateGeneric]
	@MODULE[*]:HAS[animationName[sci2]]
	{
		allowManualControl = false
		!startEventGUIName =  DELETE
		!endEventGUIName = DELETE
	}

//	@MODULE[ModuleAnimateGeneric]
	@MODULE[*]:HAS[animationName[sci2]]
	{
		@allowManualControl = false
		!startEventGUIName =  DELETE
		!endEventGUIName = DELETE
	}	

	MODULE
	{
		name = ModuleRTAntenna
		Mode0DishRange = 0
		Mode1DishRange = 200000000
		EnergyCost = 0.82
		MaxQ = 6000
		DishAngle = 45.0

		DeployFxModules = 0
		ProgressFxModules = 1

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

	MODULE
	{
		name = ModuleSPUPassive
	}
}

I can still manually deploy the antenna bit - activating RT does not deploy the antenna - science transfer with undeployed antenna but active RT is possible.

[Andy81le]

Hi there,

I am having trouble with RemoteTech: My rocket, equipped with the Stayputnik, stops responding after reaching 3000m above ground level. It then falls back towards the surface and as soon as it is below 3000ft, it starts up again, and so forth.

Now, I read that there might be a conflict with MechJeb and that the newest dev build of MechJeb would solve this issue. However, using Mechjeb 2 2.1.0.0-119 didn't help, unfortunately. Deleting MechJeb didn't help either, deleting RemoteTech did. So, there is likely something wrong in RemoteTech or I am really doing something wrong here.

My other mods are: Editor Extensions, RBR Chatterer, TAC Life Support, Alarm Clock, Universe Replacer

Cheers

[Draft]

Did you put any antenna on the ship? Probes can only see 3km, aka 3000m by themselves

[BigD145]

You will need an antenna or dish that does not break while your ship accelerates within the atmosphere. If you put an antenna on it probably broke.

[Frederf]

Well, it's happened.

Through a slight miscalculation in saving and loading I've stranded a vessel because the command queue isn't saved with save game files and thus a craft that was absolutely on track to reestablish contact on its own has suffered short term memory loss and isn't going to do the set actions that makes that happen.

The command queue REALLY REALLY REALLY REALLY needs to be saved. Did I say REALLY enough?

[paxy97]

Is there a debug menu of some kind to disable Remotetech temporarily without quitting KSP?

[Fuzzwood]

Quick question. Through how many satellites can I bounce a signal? Consider the following scenario. Using the part names, I have four mediumDishAntenna and 1 LongDish1 on a probe orbiting between mun and minmus. I also have 3 satellites geosynchronous with kerbin, each having 4 mediumDishAntenna properly set up as they all can see eachother.

Now, when I try connecting with a probe orbiting the Mun which is at a position between the outer and inner satellites but not intersecting the LOS to the outer satellite, I get no connection although the connection line is visible.

[jrandom]

I'm running into an odd issue where my crewed FASA Gemini pod is being treated like a probe core and cannot be controlled when it's out of range of the KSC. Is there an easy way to fix this? (A line I need to add to a .cfg file, maybe?)

[Hodo]

BTW, if anyone would like to know. It officially sucks trying to land a probe on the small crater island on Eve with the 74 second signal delay. It took me over 100 tries and several days, but I managed to do it. And you know what, I am NEVER doing that again.

[jrandom]

I'm running into an odd issue where my crewed FASA Gemini pod is being treated like a probe core and cannot be controlled when it's out of range of the KSC. Is there an easy way to fix this? (A line I need to add to a .cfg file, maybe?)

Ignore me, problem with a work-in-progress .cfg from another user for the Realism Overhaul rescale. More specifically, I suspect this entry:

	MODULE
	{
			name = ModuleSPU
			IsRTCommandStation = False
	}

[Camacha]

Does this play nice with kOS? I seem to remember seeing that, but I can not find any mention now.

[razark]

Does this play nice with kOS? I seem to remember seeing that, but I can not find any mention now.

I thought the two had some problems (the kOS terminal not catching space or backspace keypresses, for example), but I was able to use them together without noticing any problem the other day.

[SergeantBlueforce]

So is there are way to modify the config files of antenna parts added by mods to make them compatible with RemoteTech?

[KerbMav]

The same way the .cfg files of RemoteTech change the stock parts - take a look into them and you should be able to figure out how to add entries for the modded parts you are using.

[AdmiralTigerclaw]

So I finally got around to wiping and updating all my mods and had a go with the flight computer the other day. After the initial growing pain of figuring out HOW to make it work I ran into something I think could use adjusting. If it's already been suggestions, my apologies.

Anyway, I noticed that every command you input into the queue is immediately sent to the actual operation queue for the vehicle as you enter it. This means that you have to not only worry about getting your timing down on your commands, but you also have to get the speed in which you enter your commands for a quick series of events down crisp and clear as well. As every space between each command has its own delay and will be sensitive to any mistakes you make while trying to set up a queue.

I think that rather than immediately sending each command directly to the onboard queue, you have an 'upload queue' that you can line up all your commands with delays set between them as you see fit, and then upload them all to the vehicle at once with a master delay before first command execution. This way you can set up event sequences without having to deal with the unexpected side-effects of trying to frantically perfect how fast you can efficiently zip through your command sequence. This seems a lot more user friendly than trying to work out the exact delay from NOW that each command would require and making yourself into a formula one vehicle programmer.

Q upload >>

MASTER DELAY (1024 sec)

- Command 1 (Executed immediately after master delay)

-- Command 2 (5 second delay after previous [Command 1])

-- Command 3 (3 second delay after previous [Command 2])

-- Command 4 (Immediately following previous [Command 3])

-- Command 5 (30 seconds after previous [Command 4])

And since the sequence queue would not upload until the user tells it to, an additional ability to drag and move each command in the setup queue to reorganize it would also be nice. So you can set up a sequence of commands, realize you need to move say, a prograde command in front of the burn command, and simply drag it forward instead of having to clear half the queue and reenter it to fix the error.

The other thing I noticed is that the FLComp sits on top of the direct command interface and piggybacks it... So you have to actively go back and zero out the command queue delay time if you want to control the vehicle in real time (not including lightspeed delay), otherwise it throws all your commands into the queue. We need an option where direct commands simply bypass the FLComp when you close its window or 'turn off' the flight comp.

[KerbMav]

So you can set up a sequence of commands, realize you need to move say, a prograde command in front of the burn command, and simply drag it forward instead of having to clear half the queue and reenter it to fix the error.

This would be really useful, but I think the actual queing could be implemented easier:

A first Initial Command (IC) will start a countdown as usual.

Instead of entering a fixed delay, let the player enter a time difference like "+3m30s" for the next commands.

They only start running their own countdown as their predecessor has run out, so it will be possible to make changes afterwards.

That way we could que commands like "In 100s burn 500m/s, in +30s retract solar panels, in +600s deploy parachutes, in +200s extend landing gear, ..." or whatever.

We could still add commands with a simple countdown by entering "100s" as usual.

The other thing I noticed is that the FLComp sits on top of the direct command interface and piggybacks it... So you have to actively go back and zero out the command queue delay time if you want to control the vehicle in real time (not including lightspeed delay), otherwise it throws all your commands into the queue. We need an option where direct commands simply bypass the FLComp when you close its window or 'turn off' the flight comp.

This is presumably necessary to enable entering key inputs like CTRL and SPACE to the que.

But you already proposed a solution to this.

[SergeantBlueforce]

The same way the .cfg files of RemoteTech change the stock parts - take a look into them and you should be able to figure out how to add entries for the modded parts you are using.

I may need some help with the syntax.

[Diesel5187]

I am creating a com probe which purpose is to land on Duna and provide an area where I can aim and land a full science rover, analyze the density of the atmosphere, and provide communications back to Kerbin.

Problem:

(Deadly Re-entry mod, 1.25m heatshield on probe.)

While testing in Kerbin, my communotron 32 antenna is breaking under the stress on re-entry, which means that I somehow need to deactivate it during reentry to then reactivate it.

How do I get around this issue?

[Frederf]

BTW, if anyone would like to know. It officially sucks trying to land a probe on the small crater island on Eve with the 74 second signal delay. It took me over 100 tries and several days, but I managed to do it. And you know what, I am NEVER doing that again.

We must be twins as I just did that only with a parachute lander and hoping for flat ground. The difficulty was less but a complex reentry sequence made timing a pain. I think we both need to write kOS scripts for first run accuracy for these kind of missions.

[Ralathon]

I am creating a com probe which purpose is to land on Duna and provide an area where I can aim and land a full science rover, analyze the density of the atmosphere, and provide communications back to Kerbin.

Problem:

(Deadly Re-entry mod, 1.25m heatshield on probe.)

While testing in Kerbin, my communotron 32 antenna is breaking under the stress on re-entry, which means that I somehow need to deactivate it during reentry to then reactivate it.

How do I get around this issue?

Add a decoupler with a probe core, a solar panel, a dish capable of reaching Kerbin and a omni antenna. Decouple it a couple of days before you land and thrust away from it to build up distance. You can then land using that as a temporary relay. It will probably crash land a couple of minutes after you land, but that's all you need.

[KerbMav]

I may need some help with the syntax.

Just to show of my insecurity: I hope you do not mean MY syntax?

Open the RemoteTech_Squad_Antennas.cfg file, copy an entry - you might want to pick a section that belongs to a comparable antenna/dish, meaning antenna or dish, deployable or not ... - and paste it into a new cfg file for your mod.

For example:

@PART[longAntenna]
{
	!MODULE[ModuleDataTransmitter] {}

	@MODULE[ModuleAnimateGeneric]
	{
		allowManualControl = false
	}

	MODULE
	{
		name = ModuleRTAntenna
		Mode0OmniRange = 0
        Mode1OmniRange = 2500000
		MaxQ = 6000
		EnergyCost = 0.13

		DeployFxModules = 0

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

	MODULE
	{
		name = ModuleSPUPassive
	}
}

Then - in this example - change "longAntenna" to name of the modded part.

PART
{
name = [I]this one here, mind capiTilZation[/I]

Edited December 5, 2013 by KerbMav

[K3-Chris]

Is there an upper limit on the number of RT2 equipped ships or something of that nature? I just deployed a mesh around eve of 10 parts and halfway through detaching them from the carrier all connections died, went back to kerbin to see what's going on with my link to KSC, all my sats around kerbin had no signal including ones within omni range of KSC and within line of sight, rover sitting next to KSC with an omni antenna on it has no signal.

[AdmiralTigerclaw]

Is there an upper limit on the number of RT2 equipped ships or something of that nature? I just deployed a mesh around eve of 10 parts and halfway through detaching them from the carrier all connections died, went back to kerbin to see what's going on with my link to KSC, all my sats around kerbin had no signal including ones within omni range of KSC and within line of sight, rover sitting next to KSC with an omni antenna on it has no signal.

Jeb pulled the Kat5 cable out of the wall at the tracking station.

[Cilph]

Is there an upper limit on the number of RT2 equipped ships or something of that nature? I just deployed a mesh around eve of 10 parts and halfway through detaching them from the carrier all connections died, went back to kerbin to see what's going on with my link to KSC, all my sats around kerbin had no signal including ones within omni range of KSC and within line of sight, rover sitting next to KSC with an omni antenna on it has no signal.

Well, there was an issue with 1.2.6 that limited it to 49 satellites.

[AdmiralTigerclaw]

This would be really useful, but I think the actual queing could be implemented easier:

A first Initial Command (IC) will start a countdown as usual.

Instead of entering a fixed delay, let the player enter a time difference like "+3m30s" for the next commands.

They only start running their own countdown as their predecessor has run out, so it will be possible to make changes afterwards.

That way we could que commands like "In 100s burn 500m/s, in +30s retract solar panels, in +600s deploy parachutes, in +200s extend landing gear, ..." or whatever.

We could still add commands with a simple countdown by entering "100s" as usual.

This is presumably necessary to enable entering key inputs like CTRL and SPACE to the que.

But you already proposed a solution to this.

The only issue I really have with that is that it doesn't make any sense to send one command to the spacecraft and then build the sequence in behind it.

Imagine it as programming a PLC (Programmable Logic Controller). You don't upload the very first line of ladder logic into a PLC and then write the rest of the code and upload it while a PLC is actively sitting there making code passes. That's how you get people killed with industrial equipment and take millions of dollars and light it on fire. Try explaining that to both OSHA and the CEO of a company.

What I'm suggesting for the computer is to hold off sending the commands to the vehicle until the player clicks 'upload command group' button or something similar.

That, and seperate the flight computer from direct control inputs so the player can do direct control vs computer control. (FComp interface open, inputs go into the queue like it does now. FComp interface closed... behave as if attempting direct control.)