[0.20] RemoteTech: Relay Network – V 0.5.0.1

[drakesdoom]

Would it be possible to release the flight computer separately? The way it handles maneuver nodes seems much more accurate than any other flight assistant I have seen.

[MaHuJa]

- delayed execution of thrust command

...haven't found anything like that using search.

Well of course not, since it's already in. The remotetech flight computer has an attitude window and a thrust window. The thrust window lets you select engine power, duration of burn (in seconds or m/s) and a delay before burn start. And once you set it, it will perform that burn even if it has since lost contact.

[Legwan]

Well of course not, since it's already in. The remotetech flight computer has an attitude window and a thrust window. The thrust window lets you select engine power, duration of burn (in seconds or m/s) and a delay before burn start. And once you set it, it will perform that burn even if it has since lost contact.

The mystery of the second row solved. Thanks! (how could I not find this...)

[JDP]

Would it be possible to release the flight computer separately? The way it handles maneuver nodes seems much more accurate than any other flight assistant I have seen.

The core functions of the flight computer is very very much inspired by Smart ASS as found in MechJeb 1, it was only by the grace of r4m0n that I was even able to add it, since I wasnt able to write such a complex PID controller myself back in the day. The maneuver node integration featured is entirely done by myself, but it was so simple to implement that I'd imagine the implementation in MechJeb is equally good, if not better. Also r4m0n knows exactly what I did to implement maneuver nodes since I told him the very second I did it. Developing for 0.18 was a very hectic period and us modders kind of stuck together in the process. I guess you players could feel that as well, since pretty much every major plugin was updated for 0.18 in record time, some going live within minutes of the 0.18 release.

So if all you want is a flight assistant, I'd advise you give MechJeb a go, it should have all you're looking for, and then some .

Don't be too hard on yourself, I mean, at least all your code is split into logical classes/sections. I even saw some Hashset/foreach usage which is pretty impressive for a beginner project...

Well I can't take complete credit for that. The A* search implemented in findShortestRelayPath was actually written by gresrun and only slightly modified by myself. Hadn't it been for his implementation I wouldn't know about the advantages of using Hashsets for iterations.

One of the greatest lessons I've learned while developing RemoteTech is to accept and respect the work of those more experienced and knowledgeable than myself

Some time in the future I might want to try writing my own pathfinding implementation. Of course my knowledge of the most current state of research is limited, but I would like experimenting a bit with D*-Lite or possibly Anytime D*. Especially if I implemnt an Anytime D* search it would make sense to move the pathfinding method into the RelayPath class since it's my understanding that the search will need to save variables between each time it runs.

Oh, and I'll take your input regarding file names into account. what I call support classes is purely based on my own private convention .

[Cilph]

If you're like me, the transition between C++ and C# will be absolutely euphoric. It felt like I was literally jumping 20 years into the future of programming. I had no idea how _awful_ C++ was until I had used C#. At this point I'll probably never go back. Hopefully the experience will be just as interesting for you.

Not really. I'm mainly into embedded so when I made the transition from C++ to Java a year back I was absolutely annoyed by the lack of memory control and disgusted with myself for using ArrayLists and HashMaps everywhere. *shudder*.

Anyhow, I was thinking of writing a parser that opens up a basic and modified subset of LUA to the user. Here's an example I'm coming up with right now, based on Expression2. Would convert into a single LUA function:

// Header
%name TestProgram                         // Name used for saving/loading.
%interval 10                                    // Would run the script every 10 frames.
%cinterval 10                                  // Would run the script every 10 frames regardless of events.
%event Sensor.Acceleration > 1.2        // Fire the script once if abs(Sensor.Acceleration) > 1.2 
%cevent Sensor.Radar < 10000           // Fire the script every interval tick if Sensor.Radar < 10000.
%persist I D                                     // Persistent states used for PID control.

// Body
if (#Sensor.Radar) {
    // if Sensor.Radar was responsible for the trigger.
    if(Sensor.Radar < 0.5 && (Sensor.Acceleration - Sensor.Gravity) < 0.01) {
        // I think we've landed?
        done(); // Completes program, prevents further execution.
    }
    ASAS.SetPitch(90*(1-Sensor.Radar/10000));
    // Do some PID magic here to set throttle.
}

Just brainstorming.

Edited April 28, 2013 by Cilph

[razark]

Would it be possible to release the flight computer separately?

I find that I very often put a RemoteTech on my ships, just for the flight computer.

[Camacha]

Is it possible to time the other functions, like you can with the throttle?

[JDP]

Is it possible to time the other functions, like you can with the throttle?

Not currently. I could possibly add it to the attitude computer by allowing you to write a time in the text field normally desplaying the countdown. I'll look into it.

Edit: and now it is. I also took the liberty of expanding the input to also allow you to type in days, so now it's dd:hh:mm:ss.

Edited April 29, 2013 by JDP

[Cilph]

Alrighty, read up on C# and the Unity API and set up a GitHub repo. Hope to be contributing to RemoteTech soon. Source looks like it could use a serious cleanup as well .

@JDP: Hit me up on twitter for contact information.

[CAPFlyer]

JDP - one thing I am still semi-struggling with is having a satellite execute pre-planned maneuvers after loosing radio contact. I was under the impression that 0.5.0.0 allowed for this and I have had it work on a couple of occasions, but lately even with the satellite in contact when I send the burn timing command and the satellite retaining node orientation at the prescribed time, the throttle does not always activate at zero like it should. Is this capability not there?

What I am trying to use this for is establishing the initial data relay network. I launch the vehicle and establish the initial apoapis then plan a circularization burn. I set "Node" orientation on the flight computer and then enter a 100% dV burn timed for apoapsis. I ensure this is all done before it drops over the horizon from KSC. The system says "Sending>>>>" and the countdown runs, but when it hits 00:00:00, nothing happens.

[Camacha]

Edit: and now it is. I also took the liberty of expanding the input to also allow you to type in days, so now it's dd:hh:mm:ss.

Very awesome!

[JDP]

JDP - one thing I am still semi-struggling with is having a satellite execute pre-planned maneuvers after loosing radio contact. I was under the impression that 0.5.0.0 allowed for this and I have had it work on a couple of occasions, but lately even with the satellite in contact when I send the burn timing command and the satellite retaining node orientation at the prescribed time, the throttle does not always activate at zero like it should. Is this capability not there?

It should work just fine. The only times I've had it not work was because I forgot to activate the engine. It is currently possible to kind of break the system if you timewarp past the countdown.

What I am trying to use this for is establishing the initial data relay network. I launch the vehicle and establish the initial apoapis then plan a circularization burn. I set "Node" orientation on the flight computer and then enter a 100% dV burn timed for apoapsis. I ensure this is all done before it drops over the horizon from KSC. The system says "Sending>>>>" and the countdown runs, but when it hits 00:00:00, nothing happens.

I know, I've allready dubbed this the CAPFlyer profile. I've launched a couple of satellites in this fashion and had it work every time, except one where I forgot to activate the engine and one where I didn't notice that I hadn't gone completely out of timewarp.

I think I'll build in a safe measure, where the vessel automatically exits timewarp when the burn starts.

[SierraKhaar]

JDP , can you please add smaller parts like the QBE or OKTO's to your remotecontrol, or simply edit the QBE OKTO to only work together with your mod.

Because I like building my own satellites and while your mod is awesome in its foundation, not be able to build my own "micro"satellites is kinda of a deal breaker for me.

I like those parts for satellites probes, and rovers.

And remote controlling them works fine without antennas and stuff.

Or am I missing something big here?

Edited April 30, 2013 by SierraKhaar

[rosenkranz]

JDP - one thing I am still semi-struggling with is having a satellite execute pre-planned maneuvers after loosing radio contact. I was under the impression that 0.5.0.0 allowed for this and I have had it work on a couple of occasions, but lately even with the satellite in contact when I send the burn timing command and the satellite retaining node orientation at the prescribed time, the throttle does not always activate at zero like it should. Is this capability not there?

What I am trying to use this for is establishing the initial data relay network. I launch the vehicle and establish the initial apoapis then plan a circularization burn. I set "Node" orientation on the flight computer and then enter a 100% dV burn timed for apoapsis. I ensure this is all done before it drops over the horizon from KSC. The system says "Sending>>>>" and the countdown runs, but when it hits 00:00:00, nothing happens.

I get around this by launching strings of probes with a manned carrier. Once in the proper orbit it breaks off a sat, fires it up and moves on. When the last sat is placed it returns to KSC

[JDP]

JDP , can you please add smaller parts like the QBE or OKTO's to your remotecontrol, or simply edit the QBE OKTO to only work together with your mod.

I believe you're looking for the probe compatability pack. It modifies the config files of the stock probe bodies to use RemoteTech. It also makes the stock antennae work as RemoteTech antennae.

[SierraKhaar]

Well then!

Problem solved, why not just adding it to the main mod? Just my opinion

Thanks for answering quickly!

[Fyrem]

Sierra, because many players wish to be able to choose wether or not to use Remote-Tech, on a ship by ship basis. If the probes were modified in the base mod, then every ship is Remote-tech'ed.

[SierraKhaar]

Sierra, because many players wish to be able to choose wether or not to use Remote-Tech, on a ship by ship basis. If the probes were modified in the base mod, then every ship is Remote-tech'ed.

Sure I can understand that but my point was if people don't want 100% remote control, why don't they just send sat's up and pretend they are involved in some remote network? (vanilla KSP).

Guess I'm just one of those few "eat the cake or leave the cake" people .

At least the main mod needs a BIG pointer to "Probe Compatability".

Because it's nonexistent.

[CAPFlyer]

...At least the main mod needs a BIG pointer to "Probe Compatability".

Because it's nonexistent.

Really? I see it linked on the next line below the link to the main plugin.

Download:

Get the core plugin here. (source here.)

Get the probe compatability pack here. (a pack of modified config files to add RemoteTech functionality to the stock probe cores and antennae)

(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.)

(Emphasis added)

JDP -

It should work just fine. The only times I've had it not work was because I forgot to activate the engine. It is currently possible to kind of break the system if you timewarp past the countdown.

I know, I've allready dubbed this the CAPFlyer profile. I've launched a couple of satellites in this fashion and had it work every time, except one where I forgot to activate the engine and one where I didn't notice that I hadn't gone completely out of timewarp.

I think I'll build in a safe measure, where the vessel automatically exits timewarp when the burn starts.

I've made a new set of launches and I think you're right. I think I didn't get all the way out of warp or just missed hitting the send button in time. I launched 2x TDRS satellites last night and had no problem putting them in orbit working only with KSC active. Got the first one in orbit over KSC and was able to at least put the second one into Kerbostationary orbit although I need to spend some time phasing it into the right orbit 120* off the first (it's only about 50* off right now). It is still really satisfying, even using MechJeb2 to plan the maneuver points (and make a few of the maneuvers) to be able to successfully start launching these satellites into orbit knowing that one false move means I lose the satellite forever.

Oh, and I'm humbled to have something named after me. I'm totally not deserving.

[Frostiken]

Any chance of having a way of collapsing the Relay Information Window more? I like the idea of having them collapse down into little icons like Chatterer and ISA Mapsat does - messing with right-click menus is a little clumsy methinks.

[SierraKhaar]

Really? I see it linked on the next line below the link to the main plugin.

(Emphasis added)

Oh I'm sorry, I'm afraid I was not very clear. Yes it is very obviously visible on the forums.

The problem is not everyone uses these forums but they are probably downloading mods.

And the actual place where you download it (kerbalspaceport) it IS nonexistent.

[JDP]

Oh I'm sorry, I'm afraid I was not very clear. Yes it is very obviously visible on the forums.

The problem is not everyone uses these forums but they are probably downloading mods.

And the actual place where you download it (kerbalspaceport) it IS nonexistent.

Maybe I could advertise the probe compatability pack a bit in the main RemoteTech plugin page. I initially kept it out to make the download page TL;DR friendly and to let spaceport handle any and all suggestions. But since such functionality hasn't been added to spaceport I could probably add a link to the main page.

Just as a hint though. providing the mod dev has used tags as intended, you can view all RemoteTech related addons by browsing the "RemoteTech" tag.

[SierraKhaar]

Ah yes, but when I searched for mods I used logic because lets face it, the spaceport is not perfect .

So I searched for downloads and rating, and you sir have a very popular mod.

How about having a folder in the main mod that says "Optional-RemoteTech_Probe_Compatability", its only 8kb and it kinda is part of the mod .

I'm having a blast with your mod (with the addon) since it adds value or purpose to satellites.

And I just hope other people are not missing out because they missed the probe comp. addon.

[Frostiken]

Still loving this mod.

One thing I'd like - besides a more effective and faster way of shrinking the relay information window - is more antenna diversity. As an example, I can't actually tell what the difference is between the Deployable Antenna (white ball) and the Communotron (extendable whip). The Communotron weighs much less, has better range (not sure what the first number mean though, the Communotron is 2Km / 9Mm, Deployable is 20Km / 8Mm), and looks better.

So yeah. A larger variety of antennas including ones that look snappy. Also, some sort of dish mounting system would be cool. Right now the dishes just sort of stick onto the side of whatever, and they look kinda ****. I like the ISA MapSat dish as it both moves and is mounted like... well a dish should be. Also, is it me, or is the power draw of these things not... very much at all?

[Camacha]

The big problem with the ISA MapSat dish is that it is a pain to fold into a fairing without it poking its nose out. Something preventing that with RT would be appreciated