[0.20] RemoteTech: Relay Network – V 0.5.0.1

[rosenkranz]

You can also get the first one up by going into a KSO orbit with a high arc ascent profile. Just go straight up until 50k then burn prograde until Ap hits 2868.75km. You'll still be LOS to KSC when you circularize at Ap. It's not the most efficient profile though, be prepared to spend some 5000+dv doing it. But for a small probe that shouldn't be that hard.

[Sma]

Awesome, I think thats the first time I've watched a video showing RT. It looks pretty cool, can't wait until RT2 is done. While I'm waiting I'm practicing SSTO space plane flying, or...crashing for the most part haha, and coming up with some designs for craft that will eventually fly when RT2 is ready.

Indeed there is. In RT2 you can input a custom delay by typing it in the lover-right corner field of the queue window of the flight computer.

Regarding getting into orbit, you're going to have to use the flight computer pretty extensively.

Here's a guide I made, showcasing the CAPFLYER method of attaining orbit. It's made in RT1, but the method would stay the same in RT2, just note that maneuver node integration is yet to be added in RT2:

[sirkut]

Great work guys. I honestly can't wait to use it when play testing is done.

[DMagic]

Since stock KSP has an abundance of great looking probe bodies, they are all SPUs now, ModuleManager makes sure of that. Only one of the bodies have Remote Command functionality; the stock large stacking body. You can always see what type an SPU is by looking at the part information in the VAB/SPH.

And by the way. The crew requirement is currently 6 kerbals, not 3. This might be tweaked further in the future. But don't expect it to be lowered. It's become far to easy to cram a single ship full of kerbals, and with the advantages they provide, I'd want it to be a real challenge to set up command stations.

I see now, thanks. I actually tried that probe core, but I was assuming the requirement was just three Kerbals. I'll give it another try later on.

[Kethevin]

Since stock KSP has an abundance of great looking probe bodies, they are all SPUs now, ModuleManager makes sure of that. Only one of the bodies have Remote Command functionality; the stock large stacking body. You can always see what type an SPU is by looking at the part information in the VAB/SPH.

And by the way. The crew requirement is currently 6 kerbals, not 3. This might be tweaked further in the future. But don't expect it to be lowered. It's become far to easy to cram a single ship full of kerbals, and with the advantages they provide, I'd want it to be a real challenge to set up command stations.

Sorry to be dense here. So the probes that show "Remote Control," and "Remote Command" are those you speak of? Also, since it's not listed on manned craft, I'm assuming just attaching a "Remote Command" probe to a ship that includes habitation areas, as long as the ship has a minimum of 6 Kerbals, anywhere in the ship, it will work? Or do they need to be gathered near the probe with the command function?

[Diche Bach]

Couple issues I'm having with the Flight Computer:

1. It seems you _must_ click the maneuver command after the node is set up and the throttle command has been sent. A small thing but worth noting if it is easy to reconfigure it somehow.

2. If you give it a burn command for which it doesn't actually have enough fuel, it seems to be very difficult to get to relinquish command. Clicking the Flight Computer off didn't give me back control of my throttle I had to right-click the engine to turn it off.

3. Can it handle retro-grade burns? I'm guessing it can and it was just that I set the countdown to be just past the node and so it didn't actually turn itself. 99% sure I setup it a retro manuever node then a delayed throttle command then clicked manuever, and instead of doing a retro burn it did a prograde burn.

ADDIT: yeah I'm pretty sure that when I plot a retrograde maneuver node, it is doing a prograde burn. I can do a quick Youtube video of what I'm doing if no one else is seeing this. It may just be that I'm doing something wrong.

Edited August 6, 2013 by Diche Bach

[Tommygun]

Has anyone noticed that the GUI for renaming the vessel is missing when this mod is installed or I'm I mistaken?

Edit: I'm referring to RemoteTech 2.

[Cilph]

Couple issues I'm having with the Flight Computer:

1. It seems you _must_ click the maneuver command after the node is set up and the throttle command has been sent. A small thing but worth noting if it is easy to reconfigure it somehow.

2. If you give it a burn command for which it doesn't actually have enough fuel, it seems to be very difficult to get to relinquish command. Clicking the Flight Computer off didn't give me back control of my throttle I had to right-click the engine to turn it off.

3. Can it handle retro-grade burns? I'm guessing it can and it was just that I set the countdown to be just past the node and so it didn't actually turn itself. 99% sure I setup it a retro manuever node then a delayed throttle command then clicked manuever, and instead of doing a retro burn it did a prograde burn.

ADDIT: yeah I'm pretty sure that when I plot a retrograde maneuver node, it is doing a prograde burn. I can do a quick Youtube video of what I'm doing if no one else is seeing this. It may just be that I'm doing something wrong.

Maneuver functionality isn't in. It's hotwired to Orbital Prograde.

Anyhow, just to let everyone know, I haven't been working on RemoteTech for the past week. Mostly been playing with my new PC really. I'm moving out this week as well so don't expect any work done for a little while.

Reminding that RemoteTech 2 is not an official release and is merely online to accelerate bug finding, of which there are a lot. A lot. If you decide to help out, please check the issue tracker on github for known issues and report it if you can't find it. Anything here on the forums is worthless. And if you find gamebreaking bugs, for the love of god include the log file under KSP_Data.

[Diche Bach]

Thanks for clarifying that Cilph. I'm having a lot of fun with this, so I'll have a look at the github issue tracker and see if I can make any worthwhile contributions.

Has anyone noticed that the GUI for renaming the vessel is missing when this mod is installed or I'm I mistaken?

Edit: I'm referring to RemoteTech 2.

It looks like I'm still using RemoteTech1, but now I haven't noticed that.

[NathanKell]

Because RemoteTech1 doesn't have that issue.

[Kethevin]

I have what’s probably a strange question.

It sounds like the update may be a while and I would like to begin with a few of my plans. From the post a few pages back, it sounds like the current version may prevent my craft being compatible with the update due to some parts no longer existing.

So what I’m wondering, is it possible to use the new version's parts only and none of the program so that when the new version goes live it will be a seamless integration?

Thank you. :-)

[Tommygun]

I have what’s probably a strange question.

It sounds like the update may be a while and I would like to begin with a few of my plans. From the post a few pages back, it sounds like the current version may prevent my craft being compatible with the update due to some parts no longer existing.

So what I’m wondering, is it possible to use the new version's parts only and none of the program so that when the new version goes live it will be a seamless integration?

Thank you. :-)

Yes, but it would require you to make a bunch of custom part configs for the new parts to make then compatible with the old plugins, resource, etc...

This can be time consuming. Make sure you don't change any of the part names.

When you want to change over, delete the old plugins, resource and other files. Then add the new Remote tech files and save over the part files.

Edit: actually you just need to delete all the old remoteTech and the parts and install the new RemoteTech when you are ready to change over.

Edited August 7, 2013 by Tommygun

[dirofblue]

I don't think requiring manned module command to operate unmanned craft is a good idea. Like someone already said sending a manned command craft ahead of an unmanned mission feels kind of wrong.

Haven't we already have some kind of relay networks these days that just pass the command to the next hop till it reach the craft then the command got executed there? Like in today's internet (or in RT1)

If you really think we need some kerbanauts on board the command station, could we at least have a few relay hops before the need of manned module? Like

[ KSC ] -> [ Relay probe ] -> [ Relay Probe ] -> [ Manned Command Module ] -> [ Relay Probe ] -> [ Relay Probe ] -> [ Unmanned Craft ]

[vardicd]

I'm having an issue where I'll set up a maneuver node set my burn, and tell it to execute, and my craft will just quiver, not line up on the node, and then just burn a random direction, but it isn't consistent. launched a probe last night, worked fine, went to work and came home, launched the same probe, total fail. anyone else seeing this?

[NathanKell]

Kethevin, Tommygun: That's safe as long as you're in antenna range. But since the way dishes track each other has changed, dish comms will break when switching from 1 to 2. Nothing a little persistence.sfs editing won't fix, but still.

[Sma]

You only need the manned craft if you want to get rid of the time delay. So you can still send unmanned missions first, setup a comm network around your target planet/moon(mun). Then at a later time send the command module with kerbals.

I don't think requiring manned module command to operate unmanned craft is a good idea. Like someone already said sending a manned command craft ahead of an unmanned mission feels kind of wrong.

Haven't we already have some kind of relay networks these days that just pass the command to the next hop till it reach the craft then the command got executed there? Like in today's internet (or in RT1)

If you really think we need some kerbanauts on board the command station, could we at least have a few relay hops before the need of manned module? Like

[ KSC ] -> [ Relay probe ] -> [ Relay Probe ] -> [ Manned Command Module ] -> [ Relay Probe ] -> [ Relay Probe ] -> [ Unmanned Craft ]

[noebl1]

I'm actually looking forward to being able to do some programming to control probes or rovers. I had thought about maybe writing up a plugin myself until I saw RT2 was going to have the ability. I remember a game back in the 90s (now countless clones) my friend used to play where you would to write basic AI for these little robots to fight each other in a virtual arena. Right now sending a distant probe without any "local" command station is tough with the delay, and I agree it sort of feels sort of backwards to send the local command station for what should be a remote probe to investigate first... Definitely will bring a pretty interesting challenge/realism to be able to actively program a probe or lander. I've held off using MJ as felt it was sort of "cheating" (not literally, but more as I wanted to learn to play before I relied on computers.) Having to actually program a DCPU (hoping for C like over assem personally) takes that extra step of not just pushing a button, but actually needing to put some logic and thought behind it just like NASA/ESA/etc would. Definitely add a huge new level to the game.

Another tangent idea I had would be remote programming and image acquisition from probes or rovers via the RT network. Imagine sending a rover out, and send it an updated program via the RT network with speed limitations/delays based on distance, probe going out of range, etc. You could have relay satellites that store and forward, etc. Or part of the programming have the rover take a series of pictures, and have to send them back to mission control with the same issues of speed, transfer interruption, etc. Not sure if it's something RT can handle, but would add yet another level of depth.

[crooks4hire]

It kinda seems like people fussing about the programming and time-delay features are misinterpreting this mod. RemoteTech is intended to add some realism to unmanned missions. The biggest realistic issue with an unmanned mission is the delay between command inputs and probe execution and overcoming this issue via communications arrays/relays. You're not going to be required to rewrite an operating system to get your rover to drive the next few kilometers. The programming that some people fear could be as simple as:

send.throttle_up25.pro.10000;

which, in probe-language means

increase throttle to 25%, point attitude prograde, hold for 10sec(10,000ms), shutdown

I doubt very highly you will require any prior knowledge of coding to manage RT2 programming.

As for sending a manned mission to complete an unmanned mission (ie: we'll need kerbals in Low-Duna orbit to manage rovers on the surface effectively). This is simply to decrease the time-delay effect. If you think you can't manage to control a Duna surface rover from Kerbin, send some kerbals closer to bridge the time-gap. It's not required. It's just more convenient...

[noebl1]

It kinda seems like people fussing about the programming and time-delay features are misinterpreting this mod.

I was responding to this previously from Cliph:

"This functionality is in the new standard flight computer. On top of that I hope to finish DCPU integration so you can program probes in fictional assembly or C like Progcom."

[crooks4hire]

I was responding to this previously from Cliph: ...

Derp, I'm sorry. Lazy and didn't read back very far...

Don't get me wrong though, I'm not picking on anybody. I just think the negative reaction to the DCPU was a bit of kneejerk panic.

[Sma]

Another tangent idea I had would be remote programming and image acquisition from probes or rovers via the RT network. Imagine sending a rover out, and send it an updated program via the RT network with speed limitations/delays based on distance, probe going out of range, etc. You could have relay satellites that store and forward, etc. Or part of the programming have the rover take a series of pictures, and have to send them back to mission control with the same issues of speed, transfer interruption, etc. Not sure if it's something RT can handle, but would add yet another level of depth.

I like the idea of image acquisition, could take photos during decent/landing as well, just like the real thing.

As for programming pre planned maneuvers, I think it'll end up being easier than actual programming, like crooks4hire mentioned, but time will tell.

[noebl1]

Derp, I'm sorry. Lazy and didn't read back very far...

Don't get me wrong though, I'm not picking on anybody. I just think the negative reaction to the DCPU was a bit of kneejerk panic.

No worries, you had me second guessing myself for a moment too

I agree though, I think people should wait and see what it's like before worrying. I think some of the new features like the DCPU (which sounds optional) will help people that occasionally post "Well I sent a probe/lander to all planets and moons. I'm bored now, what do I do now?"

[crooks4hire]

"...I think some of the new features like the DCPU (which sounds optional) will help people that occasionally post "Well I sent a probe/lander to all planets and moons. I'm bored now, what do I do now?"

A thousand times this. Lol. The DCPU is going to add a whole new level of probe-immersion. You won't have to sit and wait for your probe to come back into communication to do stuff. You could write entire missions while it's on the other side of the Mun!!

[crooks4hire]

I just started playtesting RT2 and I haven't had time to explore it much (currently at work x.x). I believe I read this earlier but can't find it... Do the stock probe cores count as spu's?

[FellipeC]

I just started playtesting RT2 and I haven't had time to explore it much (currently at work x.x). I believe I read this earlier but can't find it... Do the stock probe cores count as spu's?

Yes, they count, tested few hours ago