[0.20] RemoteTech: Relay Network – V 0.5.0.1

[Diche Bach]

I tell ya what, I'm having a ball with this mod and the various others I now have installed, most notably Mission Controller extended. This gives you a budget and you have to complete missions to get paid and get higher prestige missions that pay. I thought I was getting pretty slick with KSP, but I've had to restart about 4 times now just trying to get the first couple missions done and not screw up and get off to a bad start wasting money!

With NT Space Program and MC extended, you've got I think four mission packs that you can select missions from at start and generally all of them have about 1 mission that you can do first. For example, the first one in NT is something like "Alpha" and comprises launching a sub-orbital missile up to 75km and then getting it to land safely. There is an added incentive to land it on dry land and not water because you can recycle the vehicle for a higher rate when recovered from land.

So while it is a pretty mundane mission: go up high--then come back down and land safe, doing it with RT running and without any semblance of a comms network is actually slightly challenging.

1st attempt: overshot my target apo (75km) by a factor of about two and wound up losing contact before I managed to deploy a chute.

2nd attempt: something similar

3rd attempt: managed a nice vertical parabola trajectory, and kept it close enough to KSC to stay in contact almost all the way down. Still not knowing for sure at what alt I'd lose LOS I deployed my chute a bit high. Next thing I know, my craft has exploded at about 15km -> chute broke free!

Very nice how this mod interacts with missions to make it all much more engaging and challenging!

[rkman]

I'm still brewing on the idea of rkman mode. Up until now I've never been able to add it, since it makes the game positively unplayable from a UI standpoint. With the addition of more detailed relay rendering, where all possible connections can be shown, and coloured to reflect signal strength, it might be possible to enable the mode without it being impossible to keep track of effective ranges in-game.

I'm very pleased to hear that. I have not been using RT for some time (though not because of lack of an rkman mode), but i gave been following developments and i see there have been some interesting ones, with the rover computer and all that. I really think something along the lines of what RT does should eventually be part of stock KSP (and for all i know something like it is intended by Squad).

I'm not sure i see how 'rkman mode' would be problematic with the current UI (don't feel obliged to explain it to me, though i might come back to it later), but i figure it would (also) have other implications for RT gameplay.

Specifically i suspect it will require either unrealistically high power transmitters on spacecraft (given the constraints on antenna size), or having dishes at/near Mission Control so large that they can not realistically be put in space, meaning there would be a need for actual ground based tracking stations á la NASA's Deep Space Network (70 meters dish, gain factor of about 10 million), instead of putting tracking stations in Kerbin orbit. Otoh it might be a bit much to require building two of such large facilities elsewhere on the surface of Kerbin (one already being at KSC).

I've been thinking about solutions to that, and without going into detail, i think it might end up shifting some of the gameplay challenge that RT offers away from comms link management, toward craft building and planning wrt comms equipment.

[jrandom]

Whoa whoa whoa. Let's all remember this is a game.

I love creating my own relay network for the level of realism, but programming on python? Thanks, but no thanks.

I realise this will probably be optional, but still basing the concepts of this mod around executing commands via programming would make most people turn their heads away.

Simple assembly programming is playing!

Seriously, though, it's more fun than you think. If you just want to fly remote probes manually, send a manned mission instead. The only way to work with signal delay on distant remote probes is to create simple programs for them, or you've just defeated the purpose of having something like RemoteTech in the first place.

Edited August 2, 2013 by jrandom

[betaking]

@jrandom:

can I get a basic possibly pseudo-code-ish sample of what you mean by assembly?

[jrandom]

@jrandom:

can I get a basic possibly pseudo-code-ish sample of what you mean by assembly?

Assembly is just a simple mapping of short words or mnemonics that map directly onto the operations that the processor works with. You have a simple instruction set and each instruction does one thing.

Lets say our simple Kerbal processor has some small amount RAM, has Inputs ports 0-255 and Output ports 0-255 that are wired up to various parts of the ship (some of these would be defaults, some would be user-assigned), and four registers (each can hold a single value) ax, bx, cx, and dx. Ports and registers are... I dunno, integers? We'll say that our altitude is in input port 0, and our current throttle setting is in input port 1. Output port 1 will be used to set the throttle.

Labels end with ':' characters - the name is arbitrary. Comments start with ';' and go to the end of the line

altitude_check:
    port_in ax, 0        ; Read altitude from input port '0' and put in to ax
    cmp ax, 10000        ; Compare contents of ax with 10000 meters
    jlt altitude_check   ; JLT is "jump if less than" - jumps work on the results of the most recent cmp instruction
    port_out 1, 0        ; Kill the throttle by sending a value of '0' to output port '1'

This simple little program will keep looping until the altitude passes 10,000 meters and then kills the throttle. With inputs and outputs related to orientation reading and thrusting (SAS, RCS, etc...), ground altimiter radars, and whatever other useful "standard" inputs/outputs are designed, you can easily write small, simple programs to carry out tasks. Call/ret can be used for reusable subroutines ("call" jumps to a label, "ret" returns to the line after the most recent "call"), and small flight plan programs can be written, modified, and sent back out to probes in flight.

The small RAM restrictions (there could be models with 64, 256, 512, and 1024 bytes of RAM) force the player to avoid giant unwieldy programs. There's no issues with OOP design or big languages with big standard libraries. Just a simple set of instructions, some RAM, some inputs, and some outputs.

And this would be awesome. It is exactly what I want from something like RemoteTech -- otherwise I can't quite see the point of having it.

Edited August 2, 2013 by jrandom

[Toyotawolf]

Assembly is just a simple mapping of short words or mnemonics that map directly onto the operations that the processor works with. You have a simple instruction set and each instruction does one thing.

Lets say our simple Kerbal processor has 256 bytes of RAM, has Inputs ports 0-255 and Output ports 0-255 that are wired up to various parts of the ship (some of these would be defaults, some would be user-assigned), and four registers (each holds a value) ax, bx, cx, and dx. We'll say that our altitude is in input port 0, and our current throttle setting is in input port 1. Output port 1 will be used to set the throttle.

Labels end with ':' characters - the name is arbitrary. Comments start with ';' and go to the end of the line

altitude_check:
    port_in ax, 0        ; Read altitude from input port '0' and put in to ax
    cmp ax, 10000        ; Compare contents of ax with 10000 meters
    jlt altitude_check   ; JLT is "jump if less than" - jumps work on the results of the most recent cmp instruction
    port_out 1, 0        ; Kill the throttle by sending a value of '0' to output port '1'

This simple little program will keep looping until the altitude passes 10,000 meters and then kills the throttle. With inputs and outputs related to orientation reading and thrusting (SAS, RCS, etc...), ground altimiter radars, and whatever other useful "standard" inputs/outputs are designed, you can easily write small, simple programs to carry out tasks. Call/ret can be used for reusable subroutines ("call" jumps to a label, "ret" returns to the line after the most recent "call"), and small flight plan programs can be written, modified, and sent back out to probes in flight.

And this would be awesome. It is exactly what I want from something like RemoteTech -- otherwise I can't quite see the point of having it.

I get what you are saying but I think for the vast majority of mod users(I said majority folks don't lynch me), this would be really complex and some might like a more GUI contextual type of programming much like queuing nodes via MJ. Which is again why I asked if MJ was out of scope for RT2

[Diche Bach]

I agree with you Toyota that a lot of the mods users might not get into that stuff. But as long as it is 'optional' and in addition to the functionality that is currently in the mod, I don't see why it would turnoff anyone.

I have not yet got MechJeb to work; but based on one tutorial I watched, it is my understanding that this sort of functionality actually exists within that mod already.

[Toyotawolf]

I agree with you Toyota that a lot of the mods users might not get into that stuff. But as long as it is 'optional' and in addition to the functionality that is currently in the mod, I don't see why it would turnoff anyone.

I have not yet got MechJeb to work; but based on one tutorial I watched, it is my understanding that this sort of functionality actually exists within that mod already.

True I think it does I just enjoyed the compatibility that existed in RT1(0.5.1) where they played nice together

[csiler2]

I've been following the thread for a couple days and I'm confused. Is the new Remotetech going to require that players use programming to operate probes, or will this be an option that can be turned on/off?

[jrandom]

I've been following the thread for a couple days and I'm confused. Is the new Remotetech going to require that players use programming to operate probes, or will this be an option that can be turned on/off?

No idea what the status of programability is, but I'm calling for it because it's darned-near required to operate/land remote very-distant probes because of the signal delay. We need the ability to write programs for probes.

[Kimberly]

I've been following the thread for a couple days and I'm confused. Is the new Remotetech going to require that players use programming to operate probes, or will this be an option that can be turned on/off?

RemoteTech won't require anything of the sort. It gives players an option they didn't have before; to write programs for their probe that can be executed with remote instructions. Say you wanted to make your probe land in the previous version, and your signal delay is 10 minutes-- good luck landing anything when the controls take 10 minutes to respond to your input. In the new version, you can write a landing program that starts a deorbit burn, orients the craft away from the surface and starts a burn if the altitude is below a certain number, then extends the landing legs below a certain altitude, then switches off the engines.

Or, you might write a program that checks the battery power level, and if power level goes below a certain value, it executes an emergency procedure that turns off unnecessary equipment and extends solar panels. (At least, I hope that'll be possible!)

Basically, it gives you a lot of flexibility in controlling craft remotely. If you choose to to just deal with the signal delay and use full manual control, that's fine too.

Edited August 2, 2013 by Kimberly

[Kaleb]

I agree with you Toyota that a lot of the mods users might not get into that stuff. But as long as it is 'optional' and in addition to the functionality that is currently in the mod, I don't see why it would turnoff anyone.

I love this mod, but if this were a mandatory part of this mod, I'd probably stop using it regularly. I'm already considering doing that anyway, which pains me...

So far (with the old version) I've only been traveling within the Kerbin/Mun/Minmus system, so signal delay hasn't been an issue, and I don't think I've once had to touch the existing flight computer. I'm a programmer at my day job, and I'm not really sure I want to do more of the same when I'm playing. Maybe once I start moving out of the system, I'd take another look at that option, but at that point I'd probably rather just set up a manned remote command post.

For the short term, I'd rather just have the actual parts, and the ability to create a network, so I can get back to building up my infrastructure in 0.21...

Edit:

To clarify, I'm not against having this functionality, I just think that it isn't necessarily needed in the first release, and definitely shouldn't be required for everything (from Kimberly's post it sounds like it won't be. I hope that's true). To me it feels more like an addon, or a secondary, compatible mod. Aren't there already mods that do this, anyway?

Edited August 2, 2013 by Kaleb

[Lexif]

Kaleb, I guess there will always be the option to modify the speed of light with a config edit, as it was in the last version. I actually turned up the speed of light by an order of magnitude. That way I could land a probe on Eeloo, the half second time delay that remained made it already noticably more difficult.

In the new version, I might experiment with the flight computer to automate what happens when out of contact etc., like I did in the previous version: preplanning burns for orbital insertion etc. Also, maybe a few scripts to try different com paths when out of contact, or what happens when power runs out... But I guess I will increase the light speed again to land probes manually. I need the experience from manually landing probes to practice for my first manned interplanetary missions, especially with FAR and Deadly Reentry.

Edited August 2, 2013 by Lexif
deleted extra word

[Kimberly]

I love this mod, but if this were a mandatory part of this mod, I'd probably stop using it regularly. I'm already considering doing that anyway, which pains me...

Did you enjoy using the previous version? Because this is basically the system you had as before, but with useful extra stuff. You're being provided more tools to deal with the challenges the mod already imposed before.

[CAPFlyer]

I too would like expanded programming, but not command-line programming. I'm not a big fan of that kind of programming, but I want the difficulty of the delay and I want more "pre-programmed" maneuvering than exists in the current RT.

However, instead of doing anything really complex, why not just allow RT to execute a limited number of maneuver nodes? Squad did a lot of work to make that system work as it does and it would allow for you to use MechJeb fully, but yet not have some of the "issues" of what happens if you loose contact.

The idea would be that I could (for example) setup MechJeb to make the Holmann transfer to Duna and a mid-course correction and then let the probe "sleep" and not worry about it's signal until it got out to near the SoI change at Duna when I need to start making my insertion burn(s).

I would also like to have the option to command at the end of those maneuvers or at an SoI change (or something like that) to have an action group activate (say orient in a certain attitude and then deploy a dish and target Kerbin or something like that).

That way, in the meantime I can't change the commands, but the ones programmed will execute (like it would on a real satellite) and then be able to re-establish contact in time to send the next set of commands (which will take time to be sent and then "upload") requiring me to ensure contact be held for long enough for that to occur (i.e. require 5 second for each maneuver node or action group to upload plus the signal delay).

This way we get the challenge of having to pre-program things and make sure we do it right, but not without having to learn a programming language or spend time actually putting it in.

[SnappingTurtle]

I got this mod and sent a mission to Duna but I have no idea how to land a rover with a 3 minute delay.

[NathanKell]

Bump about ModuleCommand - JDP, Cilph, would you mind mentioning why this is removed from probes? It breaks control/rename functionality (and FAR, which is kinda necessary for the realism style that RT seeks!)

[Diche Bach]

Is there a "how to use the Flight Computer in RT2" kinda tutorial or guide somewhere? I'm completely baffled at trying to "queue" commands into it to get a sat to orbit and de-orbit despite losing contact.

[togfox]

Ive searched this thread to work out what v2.0 is about and what i might expect if i become an early adoptor. If this is described somewhere then a simple link will send me on my way. Thx.

[Dappa]

I've searched this thread to work out what v2.0 is about and what i might expect if I become an early adopter. If this is described somewhere then a simple link will send me on my way. Thx.

At the moment? Version 2 is still a little buggy. Expect that signals usually take no more than 2 hops (you really need 3 to get around the entire planet), and be prepared that satellites don't always connect when you expect them to. Those are currently the most important bugs (in my opinion), hope/expect they'll be fixed soon though.

[JDP]

Massive update to the rover computer. In need of testing.

I've just uploaded what I've been working on the last couple of days. The rover computer is now back and better than ever. Here's the commit message:

-Added keep heading mode.
-Added drive to target mode.

After punching in your desired numbers, simply press return to send the
command.
In case of target mode, you can input coordinates by holding <modifier
key> and left clicking where you want the rover to drive to. This works
both in flight and in map view. If you want to immediately send the
drive command, hold <modifier key> and click the right mouse button
where you want to drive.

I've had a lot of fun commanding my little wheeled minions around KSC. Now comes the testing process. Feel free to grab the latest test release from the github page and take it for a spin.

Note that there are still some backend bugs with the relay network which Cilph is currently hacking away at.

As always. Remember that this is still a test build, and I would only recommend you install it to help in the development of RT2.

Regarding tutorials and guides: Until we are fairly certain that the plugin is finalized, we aren't likely to spend too much time on writing up howto's. In the mean time, feel free to lean on each other, and of course Cilph and myself. Just don't expect us to have too much time to correspond with you right now .

When RT2 is released, I plan on making a small series of howto videos. I'd like RT2 to be a bit more documented than RT1, and I get the feeling that videos would be the way to go to best show the plugin in action.

[Jong]

At the moment? Version 2 is still a little buggy. Expect that signals usually take no more than 2 hops (you really need 3 to get around the entire planet), and be prepared that satellites don't always connect when you expect them to. Those are currently the most important bugs (in my opinion), hope/expect they'll be fixed soon though.

I found a workaround for that. You can get your relay satellites to work properly by targeting them with a Comlar 1 dish on a craft within comms. This doesn't seem to work with the big reflectron, comtech-2 and cp-1.

[Diche Bach]

Totally reasonable on the tutorials thing Keep on trucking on the coding toward final!

[Ricardo.b]

is ther any satellite dish that reaches very long distances? for interplanetary communication

update:

anybody tested on 0.21?

Edited August 3, 2013 by Ricardo.b

[Ralathon]

is ther any satellite dish that reaches very long distances? for interplanetary communication

update:

anybody tested on 0.21?

Yes, there are. In the old version you have 2 with a 50Gm range (good for Duna) and 1 with a 100Gm range. In RT2 there are also interplanetary discs.