[0.20] RemoteTech: Relay Network – V 0.5.0.1

[JumpsterG]

... I believe the issue is actually something to do with the probe compatibility patch from the original post, and some sort of issue with ModuleManager...

I can verify that RT1 is working for me with stock probes, but I did NOT use the compatibility patch or ModuleManager. I tend to edit the .cfgs myself to avoid potential problems like what might be happening here.

[Camacha]

I have no problem with automated launch programs, as long as automated launch in question presents challenges in its own right.

I agree, although I think automation is stretching it a bit if you have to write a whole piloting program to get anywhere, haha.

[Oinker]

I'm still pretty sure the problem isn't in my code. I believe the issue is actually something to do with the probe compatibility patch from the original post, and some sort of issue with ModuleManager....

In any case, using your provided configs and probe compatibility patch my SAS works as intended ("T" toggles stock SAS, KillRot is entirely separate and is enabled if the GUI button is highlighted green). I've uploaded an archive of all the RemoteTech related content in my GameData folder here, so you can check if using my exact setup resolves your issues.

Found it! I was using your pre-compiled dll from 9/7 10:01 AM. When I replaced the dll with the one in the zip of your latest GameData/RemoteTech, it worked as advertised. Now the only obvious difference between yours and the original is that the original shows the SAS indicator when you click Killrot on the FC. But this doesn't affect the intended flight characteristics so no big deal.

I just tested with 9/13 1:51 PM and it works fine; just without the SAS indication when KILLROT is clicked (green).

FOR EVERYBODY: http://ronwelch.net/images/RT%20.21%20compatibility.zip

Here are the configs and DBrickShaw's modded dll for .21 (ver 9/13 1:51 PM). The full "RemoteTech and MechJeb for All" will be updated on Spaceport when complete. But all the RemoteTech components and stock probes are here, as well as the base "for alls" for MechJeb2, Build Engineer, and Protractor. Also included are .21 "for all" patches for Deep Space Mission pack, Kosmos, Mercury/Gemini [FASA], and American Pack. Still to come are: B9, Firespitter, Soviet, HOME, and NovaPunch2.

Build engineer is back. I found that MechJeb's Delta-V info in the build screen was inadequate because I didn't have info for building landers (take-offers) for other planets/moons. So it's not redundant after all.

Feedback always welcome.

Edited September 13, 2013 by Oinker
forgot to include URL for the archive

[DBrickShaw]

I just tested with 9/13 1:51 PM and it works fine; just without the SAS indication when KILLROT is clicked (green).

Awesome, glad to hear you got that sorted out. Note that what you're seeing is the intended behaviour of my modifications. Since KillRot no longer replaces SAS you can actually toggle them independently (i.e toggling SAS on and off will change your flight characteristics even when the KillRot is enabled). I didn't change anything specifically to make the SAS and Flight Computer cooperate nicely, so when you enable both usually the stock SAS will just overpower the Flight Computer and prevent it from doing anything useful. On the other hand, I've found that occasional activation of the stock SAS with with the Flight Computer already enabled is sometimes useful to prevent the Flight Computer from overshooting it's desired attitude.

[NathanKell]

Yay! Will use.

Although... "FOR EVERYBODY: Here are the configs and DBrickShaw's modded dll for .21 (ver 9/7 1:51 PM)"

Where is here?

[Cypherwraith]

Hey, I tried RT2 and ran into a problem.

I was setting up a system of 3 satellites in geosynchronous orbit with dishes attached. I targeted one of the dishes with a vessel in a lower orbit for a Mun mission. When I switched to the corresponding satellite, it blew right the heck up. As far as I could tell, it had generated multiple satellites at one location and they clipped into each other. A possible problem might stem from the fact that these 3 satellites all had the same name, but I tried with a normal, uniquely named satellite and it gave me a similar result. Apologies if this has been brought up before.

[Oinker]

Another favor, if I may, Mr. BrickShaw,

Stock probes [0.21] already have electric requirement, battery resource, and "Unmanned" because that's defined in ModuleCommand with minimumCrew = 0. I'd like to be able to support adding RemoteTech to any part with [ModuleCommand] and minimumCrew=0. I can do this but this will add the electric requirement for RT and add the word, "Remote Control" to the part description. It is needed that you remove the additional electric requirement and the display of said requirement and the words, "Remote Control".

The Probe Compatibility by JDP deletes the ModuleCommand (and all definitions therein) and replaces it with ModuleRemoteTechSPU and unique values within for each part he defines. Currently, I have to do it the same way. I define each individual probe for stock and all other mods I want RT support by deleting existing ModuleCommand and adding RT module, battery, energy drain, crew=0,... using the ModuleManager.dll. This method won't work if I use wildcards because there is no way to customize the energy drain and battery power individually for each part. The parts' ModuleCommand and their values therein must remain so I don't have to create a special entry for each part.

Is there any reason to delete the ModuleCommand and replace it with ModuleRemoteTechSPU as JDP does in the compatibility patch and his configs for the RT SPU's? I have defined both in parts.cfg's and not found any problem. Additionally, Kerbal Build Engineer won't display unless the root part has ModuleCommand... so leaving it alone will kill two birds with one stone.

[NathanKell]

You get two control-from-here's and rename-vessel's in your actions menu, but otherwise it works fine.

(I need to leave modulecommand too, in my case for the FAR GUI).

[danderson]

I've been testing RT2, and I can't seem to get remote command to work. I have the stock 3-person capsule (fully manned) with a small omni, and one of the RT microsats within 100m (antenna and solar panels deployed), but the microsat still says it has no connection. Am I doing something wrong, or is remote command not functional yet?

[NathanKell]

RT2 has six-crew minimum.

[danderson]

RT2 has six-crew minimum.

Ah, that would do it. Works fine with >=6 crew. Thanks!

[Oinker]

You could set the minimum crew required in the Plugin Data - Settings file before. I bet you can in the new one too. (can't test it. it was so buggy, I went back to the old one)

[brienne]

I wait for IsaMapSat and Remotech to be updated. Those 2 mods give a more realistic touch to the game.

I ll also use Kos, scriptable autopilot.

So, here are my questions. Does RT2 work? Is it reliable?

Thanks for your answers.

Edited September 15, 2013 by brienne

[Tygroux]

Yes, no.

More detailed answer: it will work, but expect your probe to start spinning without reason, engines kicking at the worst moment, random contact loss, and other amusements.

[Ralathon]

Not to mention KOs and RT are currently incompatible. When you have both and you try to program something the controls aren't locked (I presume due to alternate control routing for signal delays) so you end up messing your craft rather badly. I didn't test this, but I presume delay will also be present on the KOs command execution.

I prefer KOs over RT so I dumped the latter until they are compatible (and a bit more stable). I installed Figaro Satellite constellation so I still have a reason to build networks around planets I need.

[Tygroux]

Weren't mechjeb and RT1 compatible?

I believe in this case Mechjeb orders were overriding the signal delay.

Maybe this system could be generalised to KOS?

What would be cool would be that these mods would not be subject to signal delay, or didn't even need a signal to execute their command... but the command/programmation would still be subject to time-lag.

I think i see how it could be done with KOs, now, since mechjeb is working with manoeuver nodes, i have no idea how one could do it without rewriting everything.

[LittleBigKid2000]

I can't close windows such as the Antenna Configuration window in RemoteTech 2.

[JumpsterG]

brienne, and anyone else trying to get a version of RT working: Hidden a couple pages back, users DBrickShaw and Oinker posted files that modify RT1 to work well in 0.21.1.

Note that this is possibly not compatible with the existing stock probe compatibility package and you may have to edit the .cfgs for probes and antennas to make them work. What I did: check out the .cfgs included in the stock compatibility package and copy just the RemoteTech modules directly to the existing parts in the squad folder (I don't trust ModuleManager for this one, but you can probably clean up the .cfgs and make it work correctly)

So I know RemoteTech 2 is just around the corner, but I just can't bear playing KSP without a (mostly) stable RemoteTech version. To solve my issue, I decided to make a couple quick fixes for version 0.5.0.1 that address the most annoying compatibility problems with 0.21.1:

- Flight computer now recognizes all new reaction wheel modules when calculating available torque. This will allow the flight controller to properly control your rockets without burning away all your RCS. Note that the flight computer does not actually calculate the available torque in the direction it plans to rotate, but rather it averages the pitch, yaw, and roll power of the reaction wheel module.

- KSP default SAS and Flight Computer KillRot can now be toggled independently. Flight Computer KillRot is now only enabled by pressing the GUI button (SAS shortcut key will only toggle default KSP SAS).

The code is hosted on GitHub. I've sent a pull request to the main repository, but I understand if you don't want to take on the responsibility of maintaining 0.21.1 compatibility with RemoteTech 2 so close and much work to be done. For people who'd like to try out my fixes without compiling themselves, I've hosted the modified RemoteTech.dll file here. To install, just drop that file under "GameData/RemoteTech/Plugins" (it should replace the existing one).

These are really just my own band-aid fixes and I haven't tested them too extensively, so use these at your own risk. If you're concerned about downloading a DLL from an untrusted site (as I probably would be), I encourage you to build the fixes from source.

Agreed that RT2 is way too buggy to be playable and is a long, long, long, way from being a release candidate. The old one must be brought to .21 compatible. Thank you for your effort so far. I was re-working the RT configs to be .21 compatible and in-line with stock part values and noticed that I couldn't enable SAS on a ship with the RT module (running under your modified dll). The most basic switch to a .21 config is to change part type from CommandModule to Part, remove old SAS values, and ensure SAS module and Reaction Wheel modules are defined. Under the old RemoteTech.dll, I could toggle SAS but couldn't get the flight computer to rotate the craft. I never noticed that didn't work with .21 because I use MechJeb to steer instead of the delayed flight computer. Could you get your modded dll to work with the modified configs?

Modified RemoteTech .21 configs available here: http://ronwelch.net/images/RT%20.21%20configs.rar

They will be included in the upcoming update to "RemoteTech and MechJeb for All". I'm working on .21 configs for all the other mods it supports. Most say they are .21 compliant but have .20 leftovers or horrible resource balance.

Sorry for the longish quotes, but didn't want to leave anything out in case it's important to someone.

[amo28]

Module Manager configs work great for this, and it allows me to modify one file to make changes rather than 20. My MM config for RT 0.5 enables RT functionality for all command pods from AIES, KOSMOS, HOME, and B9, as well as stock. It also enables RT antenna and dish functionality with all AIES antennas and one comm modules from KOSMOS.

When I find something wrong with my edits, I just do a find & replace for everything at once. Definitely a time saver.

TL;DR -- Do not be afraid of Module Manager! It's a fantastic tool!

[molunbun]

Looks interesting but will I lose control over my existing probes if I install this mod?

[JumpsterG]

With only the RemoteTech package installed, probes from squad or other mods are unaffected (though you can modify .cfgs or crafts in saves to add the functionality). The included "SPU" probe cores are the only ones that induce the requirements by default.

[Sma]

With only the RemoteTech package installed, probes from squad or other mods are unaffected (though you can modify .cfgs or crafts in saves to add the functionality). The included "SPU" probe cores are the only ones that induce the requirements by default.

Right, but in RT2, there is no included SPU, as it adds that functionality to the stock probe cores, at least that is my understanding. I imagine you could modify it and add the old probe cores in and disable the RT2 function on the stock probe cores.

Then again I haven't been keeping up with everything lately. Maybe with the modifications the others have made to RT1 to make it compatible with KSP 0.21 wouldn't cause problems with stock probe cores.

[Cilph]

JDP and Cliph are propably waiting for the release of v0.22, which will change and add many things regarding a vanilla networking system to transfer data back to Kerbin, based on the vanilla antenna and dish.

I bet once that's released, they will start adapting RT2 to 0.22 and release it eventually.

EDIT: What I said is maybe not that accurate. I just read a post from a moderator stating that 0.22 is not even in testing yet, so release might be over a month or more in the future.

I haven't actually worked on RT2 in ages. KSP interest has faded. You'll most likely have to wait for 0.22 before I get back into it again. So consider RT2 to be on hiatus until 0.22 or JDP starts pushing me.

Edited September 18, 2013 by Cilph

[Sandworm]

That is horrible news, but before anyone abandons this mod I'll make a suggestion for saving it: take the working bits of RemoteTech2 and release them as RemoteTechLIGHT.

(1) Dump the flight computer/autopilot. Players can hand-fly connected craft. This would mean that disconnected craft will not be able to perform maneuvers (unrealistic) but would require players to carefully plan when/where maneuvers happen (realistic).

(2) Dump the time delay. Without a flight computer, hand-flying via a delay is impossible. This feature was never very realistic anyway. Calculating in how many seconds a maneuver should happen was burdensome, especially as KSP does not provide proper thrust data until an engine actually starts. Asking a craft to execute a maneuver at a specific time, as opposed to after a specific delay, would be more realistic but difficult to implement given KSP's limitations.

With those features gone, RemoteTechLIGHT would keep RemoteTech's concept of connected/disconnected craft (the antenna system) and could be released without major recoding.

[FellipeC]

That is horrible news, but before anyone abandons this mod I'll make a suggestion for saving it: take the working bits of RemoteTech2 and release them as RemoteTechLIGHT.

(1) Dump the flight computer/autopilot. Players can hand-fly connected craft. This would mean that disconnected craft will not be able to perform maneuvers (unrealistic) but would require players to carefully plan when/where maneuvers happen (realistic).

(2) Dump the time delay. Without a flight computer, hand-flying via a delay is impossible. This feature was never very realistic anyway. Calculating in how many seconds a maneuver should happen was burdensome, especially as KSP does not provide proper thrust data until an engine actually starts. Asking a craft to execute a maneuver at a specific time, as opposed to after a specific delay, would be more realistic but difficult to implement given KSP's limitations.

With those features gone, RemoteTechLIGHT would keep RemoteTech's concept of connected/disconnected craft (the antenna system) and could be released without major recoding.

I would love this.