[0.20] RemoteTech: Relay Network – V 0.5.0.1

[Kaa253]

I would love this.

And I would love this too. I would like it to have the functionality that mechjeb doesn't work and chatterer stops if your craft becomes disconnected. As a Mechjeb user/fan I never really had much interest in the flight computer.

[Starwaster]

hi all, I'm using RT1 in 0.21 and I'm trying to track down possible mod conflict when using the Flight Computer. basically what I'm looking for here is just to see if anyone else here has encountered this before I start standard troubleshooting which means disabling plugins and reenabling them with restart times of 3 minutes each time

problem is that when I click any nodes in the flight computer the craft sits there and quivers. I can see the inputs oscillating gently back and forth for pitch, roll and yaw. If the craft was spinning it seems to take the time to stabilize but then starts quivering.

the only thing that makes sense would be an MJ2 conflict but I've been using MJ all along

other mods with active plugins are procedural fairings, stretchytanks, modular fuels, docking alignment and thrust corrector. none of which seem like they would cause this.

so has anyone else run into this before?

[amo28]

@Starwaster: do you have SAS enabled? I'm finding that using the Flight Computer in RT0.5 with SAS enabled has an unpredictable outcome. Sometimes it will move to the node with SAS enabled, sometimes it wont. But release SAS and the Flight Computer works just fine -- I've even noticed that the controls are really smooth.

For anyone worried about RT2 delayed, just use RT1 with the compatibility .dll that was posted. I'm not missing any functionality.

This is my Skylab replica running RT0.5, Procedural Fairings, TAC Life Support, and FAR, using AIES antenna and dish for communication using a modulemanager config for compatibility. http://imgur.com/a/jLvt2

[Starwaster]

@Starwaster: do you have SAS enabled? I'm finding that using the Flight Computer in RT0.5 with SAS enabled has an unpredictable outcome. Sometimes it will move to the node with SAS enabled, sometimes it wont. But release SAS and the Flight Computer works just fine -- I've even noticed that the controls are really smooth.

For anyone worried about RT2 delayed, just use RT1 with the compatibility .dll that was posted. I'm not missing any functionality.

This is my Skylab replica running RT0.5, Procedural Fairings, TAC Life Support, and FAR, using AIES antenna and dish for communication using a modulemanager config for compatibility. http://imgur.com/a/jLvt2

no SAS isnt on. AND I've disabled MJ since it was my prime suspect and still no joy so a massive WTH right there...

there was a compatibility dll? I must have missed that. is it on the front page?

I'd give RT2 a try but I'm still too entrenched in my current established universe. how much does it break?

EDIT: Ok now THIS is interesting. I toggled off reaction wheels and the input oscillation changed to stronger input attempts. then I realized that this probe (unlike most that I've fielded) actually had RCS so I turned that on and it behaved as expected and responded to flight computer instructions... so the issue is that for whatever reason it cant or wont use reaction wheel torque. that gives me something new to search the thread for. (and yes, plenty of electricity)

Edited September 24, 2013 by Starwaster

[amo28]

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.

@Starwaster: See the quoted thread for DBrickShaw's modified dll. I think his notes might be exactly what you're looking for. And I may be wrong, but I believe based on his Github page that he manually modified the PID controller, which would explain why I'm seeing smooth controls when using Flight Computer. Big Thanks DBRICKSHAW!

[Starwaster]

@Starwaster: See the quoted thread for DBrickShaw's modified dll. I think his notes might be exactly what you're looking for. And I may be wrong, but I believe based on his Github page that he manually modified the PID controller, which would explain why I'm seeing smooth controls when using Flight Computer. Big Thanks DBRICKSHAW!

Reaction wheels, so that is what's happening to me. So bizarre that it was working before...

I think what might have happened is that I applied a MM patch to remove all legacy SAS functionality... that left only the reaction wheels so the flight computer choked?

[Tygroux]

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.

Wouldn't it be possible, maybe even easier to work on and maintain, to drop completly the flight computer, and replace it by a KOs compatibility with time delay?

That would be a good compromise, and that would avoid the waste of having yet another kerbal autopilot. (not disregardiging all the work done, but the more we simplify things the better.)

Total noob about that, i never even used KOS. (waiting for 0.22 and loading times back going back to bearable levels to play again.)

[FellipeC]

Wouldn't it be possible, maybe even easier to work on and maintain, to drop completly the flight computer, and replace it by a KOs compatibility with time delay?

That would be a good compromise, and that would avoid the waste of having yet another kerbal autopilot. (not disregardiging all the work done, but the more we simplify things the better.)

Total noob about that, i never even used KOS. (waiting for 0.22 and loading times back going back to bearable levels to play again.)

Great idea. kOS already compute distance and number of antennas to determine if you can control the vessel. Remote Tech and kOS are begging to be united and/or integrated. They are awesome!

[Sma]

Great idea. kOS already compute distance and number of antennas to determine if you can control the vessel. Remote Tech and kOS are begging to be united and/or integrated. They are awesome!

Except kOS is only checking to see that you have a dish/antenna on your ship. It's not actually "connecting" to the archive. As such it wouldn't relay around like it does in Remotech. At least not at the moment anyway, maybe in future versions it'll get more complicated.

[Tygroux]

Except kOS is only checking to see that you have a dish/antenna on your ship. It's not actually "connecting" to the archive. As such it wouldn't relay around like it does in Remotech. At least not at the moment anyway, maybe in future versions it'll get more complicated.

And that's exactly what we're talking about here. Integrating it.

switching KOs can_i_haz_antenna? to RT can_i_haz_signal_link? could be a simple question of wiring the box together, and adding a signal delay might be as simple as transforming

add_program(kos program)

to add_program(kos program, remotetech timelag)

Now, that's a lot of maybe and simplification of thing that probably aren't, but K.I.S.S.! =D

[Sandworm]

kOS? No. Bad idea imho.

kOS is a very cool, very l33t, tool. But it only adds complexity. My point was that, to save this mod and make it accessible to all, remotetech needs to be simplified. I say abandon any concept of an autopilot. That removes the need to deal with all sorts of interactions, not to mention comparabilities with other mods. Boil down remotetech to the core that makes is unique: the need to connect back to base via a network of powered sats. With that working, players can then add whatever autopilot they like,

Also, to simplify comparability with the various autopilots, disconnected sats could power down by setting a massive power drain. That would disable mechjeb/kos/engineer without getting into the specifics of comparability.

[NathanKell]

Um...that's far past simplified and into broken, I'm afraid. RT needs some way of queuing commands when probes are out of contact.

Another stab at flight computer simplification would be to replicate (borrow?) MJ's "execute node" functionality. Then you just have to create your series of nodes, using existing KSP functionality, and flight computer will execute them. No new commands to learn, just stock KSP.

[Sandworm]

Yes but remotech2 doesn't have that atm and one of the key developers has expressed disinterest in continuing the project. So unless someone steps up to do the hard work of developing an autopilot, the only route forward is to take the working bits and move on without one.

I'm looking at the code, but it's been a very long time since I wrote anything original. Even paring down Remotech2 is beyond me at this point.

[Albert VDS]

It might be a much better idea to make existing flight computers compatible with RT.

That way you don't saturate the "market" and give the users the ability to choose.

I would love to see RT compatibility for KOS.

[FellipeC]

It might be a much better idea to make existing flight computers compatible with RT.

That way you don't saturate the "market" and give the users the ability to choose.

I would love to see RT compatibility for KOS.

I agree. Don't know if this could be arranged with Squad and/or mod community, but would be awesome if we have this kind of behavior:

- Autopilot installed (Mechjeb/kOS/ORDA/Whatever...) alone = Works normal

- RT installed alone = Just build relay network and prevent hand fly when not in contact.

- Both installed = RT exposes connection status and delay for the autopilot. Autopilot check this and choose to control or not the ship or to delay or not the commands.

I think this would be best of both worlds. People that wish to K.I.S.S. just get Remote Tech and built their relay network. If you want to draw maneuver nodes and send they to ship execute, or if you with to point your craft to some direction and fire for some time, Mechjeb could handle that. If you wish to write instructions to the probe, kOS will do the trick.

Anyway I don't know the internals of this, but IMHO connectivity should be like a resource. For instance, to a probe core works, it need energy, to works and obey commands/delivery science, need to have radio connectivity.

[Tygroux]

kOS? No. Bad idea imho.

kOS is a very cool, very l33t, tool. But it only adds complexity. My point was that, to save this mod and make it accessible to all, remotetech needs to be simplified. I say abandon any concept of an autopilot. That removes the need to deal with all sorts of interactions, not to mention comparabilities with other mods. Boil down remotetech to the core that makes is unique: the need to connect back to base via a network of powered sats. With that working, players can then add whatever autopilot they like,

Also, to simplify comparability with the various autopilots, disconnected sats could power down by setting a massive power drain. That would disable mechjeb/kos/engineer without getting into the specifics of comparability.

*

We are obviously absolutely not talking about forcing KOs and autopilot.

The default mod would be current RT without any kind of delay or autopilot.

We are talking about an (optional) compatibility option, that would allow to use KOs with RT.

Basically, the idea is that KOs would be used the exact same way, but program transmission would require signal link and take delay into account before being loaded in the probe.

Then you can use is as you want:

-Delayed command only, like RT 0.20.

-Manoeuver node planned in advance.

- or full KOs, but you would need to program your flight in advance, and/or take timelag in account for manual correction.

The main advantage of KOs on Mechjeb autopilot function is that KOs load a program then execute it, where Mechjeb just override your inputs.

That means that fight program and signal transmission is far easier to manage, and realist (and needing advanceplanning) where as Mechjeb was just an intelligent autopilot taking full control of the craft.

Of course that woul'nt be for those who want to have full control of the craft and enjoy piloting it, and more for those of us that just love to perfectly plan and design years in advance, then watch the perfectly oiled machine unfold itself. In a more or less controlled manner. Some of us play KSP as a space flight sim, some of us as a Real Time Strategy/Gestion game.

And if the player want/need to have real-time control of your craft, the player would need to have a local control base, inciting to set up planetary bases and station and giving them another true use.

Then again, it would be the player choice to use or not. Tastes and color, all that. Mods are about customization after all. =D

Edited September 25, 2013 by Tygroux

[amo28]

This seems like a kOS compatibility patch rather than a RT patch.

Since RT 0.5 works in 0.21 already (with a modified .dll), and so does the flight computer, I would suggest figuring out a way to add an additional option to the flight computer to execute action groups on a time delay. Then you can program kOS to execute a script when that action group is hit. I nominate DBrickShaw.

I have found no reason to want or wait for RT2 yet. No advanced features have been suggested that make it any better than RT 0.5, other than the improved antennas that JDP made. Does anyone have any information that could suggest otherwise?

[PatriotBob]

From my understanding RT 2.0 was a complete rewrite of the original to try to escape the technical debt associated with the original codebase.

As much as I would like to say we could discuss putting a generic "auto-pilot interface" that RT could use and change the associated mod implementation... (MJ, RT, kOS, etc) I don't think that's going to work as well as it might seem.

RT uses little more than a queue of commands with a possible delay.

MechJeb does... well... everything. From node planing, execution to time warp modification and landing.

kOS can do anything between RT and MechJeb (and beyond).

They all go about "auto-pilot" in fundamentally different ways.

About the next best thing, would be looking at adding connectivity and delay information to a module and having MJ/kOS integrate the delay on their end. Any way we could try to inject a delay or loss of control into them through RT may work for some cases, but for each new feature added to other mods will then force RT to update to take that into account. A code maintenance nightmare.

The best thing RT can do is make the delay and connection information available for easy integration with other mods and then community pressure to have MJ, kOS, etc integrate with RT.

But no other developer is going to integrate with a mod that essentially isn't maintained, like RT is. The last release is still 0.5, any 0.21.1 compatibility is community made, and 2.0 has halted and the developer has stated it may resume "later".

Is JDP the primary developer or Cilph?

[Tygroux]

(This plugin is free to use and modify as long as the original authors are credited.

This plugin, and derivatives thereof, may only be hosted on kerbalspaceprogram.com.)

RT2 devellopment can be taken by anyone.

The code is hosted on Cilph's githup, so i guess any right go to Cilph unless explicitely stated otherwise.

[PatriotBob]

Silly me, I was looking for a proper license in the repository.

While that's great that it has a fairly permissive license, forking projects is only worthwhile if the original is no longer being maintained. Otherwise it fragments the community and helps no one.

Another problem with taking over maintaining the project is that as far as 2.0 is concerned only JDP/Cilph know the project's current state. What needs to be done, what direction it is going in, etc.

The project would suffer greatly unless the two current maintainers stayed on, minimally in a management role, until the burden of knowledge is handled. All in all not a lot of good options. :/

Unless they state being open to pull requests, so they don't have to do as much but still maintain authority over the project and the code quality Because I don't see a fork working out well anytime in the near future.

[FellipeC]

I have .NET skills. But know nothing about Unity or game dev, but I'll try to at least compile it here. Maybe, with a lot of lucky, I can help.

[BGog42]

And that's exactly what we're talking about here. Integrating it.

switching KOs can_i_haz_antenna? to RT can_i_haz_signal_link? could be a simple question of wiring the box together, and adding a signal delay might be as simple as transforming

add_program(kos program)

to add_program(kos program, remotetech timelag)

Now, that's a lot of maybe and simplification of thing that probably aren't, but K.I.S.S.! =D

Interesting that you mention it. I'm currently working on an integration between remote-tech and kOS. I'm mostly doing it for my own fun but I'll release it if it turns out well.

[Rockstar04]

Interesting that you mention it. I'm currently working on an integration between remote-tech and kOS. I'm mostly doing it for my own fun but I'll release it if it turns out well.

I would suggest throwing it up on GitHub! That way more of us can see how your progressing, give feedback and suggestions, and then you would have an easier time sending the pull request to the main branch of remotetech2 once its ready for primetime!

[Camacha]

Interesting that you mention it. I'm currently working on an integration between remote-tech and kOS. I'm mostly doing it for my own fun but I'll release it if it turns out well.

An integration that takes kOS functionality (without the weird requirements for multiple antennae) and the RT requirements for line of sight, a number of (stock looking) dishes and some sort of signal delay would be ideal for me. With kOS there is no need for a RT flight computer. The basics of a long distance communication properly translated into a mod will do perfectly.

Somehow kOS' attempt at 'realistic' long distance communications just does not work out (for me) as it is artificial and not very logical, and the same goes for the flight computer attempt RT made as it is very limited. I can only dream of a game where I need to maintain contact for direct control or to upload code and where my crafts can operate independently according to scrips/code when contact is lost, whether that is intentional (circulization burns on the far side of bodies) or accidental (forgetting to deploy a critical antenna). Pretty much just like the real thing.

[drtedastro]

Agreed. Good points. That would be a very nice blend of the best of the two mods.