[0.20] RemoteTech: Relay Network – V 0.5.0.1

[DoubleOSeven1]

Still relativly new and are having troubles getting a basic Kerbin network (Full planet coverage) and interplantary commmunications. can anyone help me get this setup?

[JDP]

Still relativly new and are having troubles getting a basic Kerbin network (Full planet coverage) and interplantary commmunications. can anyone help me get this setup?

I wrote a small mission description of how I normally establish my first relay networks a couple of pages back. You can read it here.

And another small dev video. I've mostly been working on the custom drag model for the shrapnel created when dishes come apart. I had a bit of an inspiration to make the model take more acurate account of the physical aspects of the shrapnel (mass and area facing the airflow). the model does both now, both are procedurally calculated from the attached collider. All I need to input is a drag coefficient and density in the part config. Here's how it looks:

Edited April 27, 2013 by JDP

[xZise]

[…]The changelog has become very very long, I used to have it displayed in the OP, but with spoiler tags not working, it simply took up too much space. In stead I now include the changelog in the readme.txt included with the plugin.

Yep that would be fine. Although you could link the changelog posts in your first thread

About your shrapnels: I hope it won't kill the framerate

Fabian

[Camacha]

A quick question; I thought the RemoteCommand module acted as if someone was on board, thus making it effectively a new control center. However, when I built a craft with the module, I still needed an antenna to get any response and contact. Was my assumption wrong?

[Cilph]

Brrr. Did my first interplanetary mission today where signal delay really mattered. It's tough landing a rover with 3 minutes of signal delay. Loved doing it though.

I'm considering extending RemoteTech with some sort of AI support where you can essentially write a script or state machine for your probe that triggers actions based on sensor data. What does everyone think?

[JDP]

A quick question; I thought the RemoteCommand module acted as if someone was on board, thus making it effectively a new control center. However, when I built a craft with the module, I still needed an antenna to get any response and contact. Was my assumption wrong?

Yep it was a bit off. RemoteCommand enables sending signals. So if you have at least 3 kerbals on board a ship with RemoteCommand, other ships and satellites will be able to get their control signal directly from your command ship just like they'd normally get from KSC.

Try launching the included demo vessel. when you reach orbit and decouple one of the satellites you can see that it gets its command signal directly from the mothership (click on the yellow text telling you signal delay in the main RT window and you'll get a detailed description of the relay path).

Brrr. Did my first interplanetary mission today where signal delay really mattered. It's tough landing a rover with 3 minutes of signal delay. Loved doing it though.

I'm considering extending RemoteTech with some sort of AI support where you can essentially write a script or state machine for your probe that triggers actions based on sensor data. What does everyone think?

Great job! landing under signal delay can be close to impossible and would be completely impossible where it not for the flight computer. I've been thinking about adding a landing mode to the throttle computer myself. where you add first a delta-v burn and then a series of "keep velocity=x from altitude =y". Assuming you've put the attitude computer into retrograde mode such a module should make it possible to set up a landing profile for the ship to follow.

Edited April 28, 2013 by JDP

[zalzane]

Are there any plans to fix the lag bug that occurs when you have more than one remotetech antenna on a ship? The last time I tried this mod a few months ago it was pretty much the only reason I didnt use it, kinda disappointing that it still hasn't been fixed.

[Camacha]

Are there any plans to fix the lag bug that occurs when you have more than one remotetech antenna on a ship? The last time I tried this mod a few months ago it was pretty much the only reason I didnt use it, kinda disappointing that it still hasn't been fixed.

I don't have any lag. I equipped a rocket with 20 antennas to test this and still no lag

[JDP]

Are there any plans to fix the lag bug that occurs when you have more than one remotetech antenna on a ship? The last time I tried this mod a few months ago it was pretty much the only reason I didnt use it, kinda disappointing that it still hasn't been fixed.

That's probably because it's a bug I've never heard about or experienced. Sounds very odd indeed, sorry if I overlooked any previous bug reports on this issue. Can you go into a little bit more detail? Maybe post a link to the output log found in \KSP_Data\output_log.txt

Edited April 28, 2013 by JDP

[zalzane]

That's probably because it's a bug I've never heard about or experienced. Sounds very odd indeed, sorry if I overlooked any previous bug reports on this issue. Can you go into a little bit more detail? Maybe post a link to the output log found in \KSP_Data\output_log.txt

https://dl.dropboxusercontent.com/u/6789520/output_log.txt

Steps to reproduce:

-Have at least 6 probes with omnidirectional antenna on or around kerbin, I have tested with a set of probes in orbit, the debug log above is 6+ of those all in one satellites strewn around the space center.

-Have a medium sized ship with 2 or more omni antennas on it. I used this ship; which was built on a game that included the isp mapsat and mechpleb addons in addition to remotetech.

https://dl.dropboxusercontent.com/u/6789520/Rover%20Delivery.craft

-After the first 2 stages, the game's fps drops from around 35 to 6ish. I'd say it typically happens around 5 to 12k in altitude.

-Lag disappears if there are zero antennas on the ship. Lag is slightly reduced if there is only one antenna on the ship.

Everything about it irks of pathfinding overhead issues, I might crack open the source later to see if I can see any useful tidbits.

[zalzane]

just ran another handful of trials - the lag occurs at the moment the path length to KSC is >6.00km. Ran a trial with debug console open and there wasn't anything terribly suspect.

[JDP]

https://dl.dropboxusercontent.com/u/6789520/output_log.txt

Steps to reproduce:

-Have at least 6 probes with omnidirectional antenna on or around kerbin, I have tested with a set of probes in orbit, the debug log above is 6+ of those all in one satellites strewn around the space center.

-Have a medium sized ship with 2 or more omni antennas on it. I used this ship; which was built on a game that included the isp mapsat and mechpleb addons in addition to remotetech.

https://dl.dropboxusercontent.com/u/6789520/Rover%20Delivery.craft

-After the first 2 stages, the game's fps drops from around 35 to 6ish. I'd say it typically happens around 5 to 12k in altitude.

-Lag disappears if there are zero antennas on the ship. Lag is slightly reduced if there is only one antenna on the ship.

Everything about it irks of pathfinding overhead issues, I might crack open the source later to see if I can see any useful tidbits.

Couldn't see much from the log, if I understand correctly the log isn't of a mission that included the lag you experience, it could be a big help to look through such a log.

I don't think it's a pathfinding issue since pathfinding is done in the same way regardless of the number of antennae on a vessel. Basically the antenna ranges of every vessel are simplified to a single float value for use in the relay network since I only ever need to take the maximum antenna range into account.

If you want to look through the source you'll want to start in the RelayNetwork class, specifically the GetCommandPath method.

just ran another handful of trials - the lag occurs at the moment the path length to KSC is >6.00km. Ran a trial with debug console open and there wasn't anything terribly suspect.

This is getting curiouser and curiouser... maybe you should rerun your trial without any ISA MapSat or MechJeb parts, just to make sure it's not some strange strangeness caused by either one of those two mods or any combination of the three.

Edited April 28, 2013 by JDP

[zalzane]

I found that virtually all of the pathfinding stuff only eats about 15ms every 5-10 seconds, so you were right that it's not the issue. I found that the drive method of the flightcomputer class was eating 5ms every time some event was calling it (every tick maybe), but commenting out that jazz didn't really affect performance as much as I thought it would.

Gonna go pull the mapsat/kethane/mechjeb sources and see if there's a conflict of interest somewhere.

[Cilph]

I've been thinking about adding a landing mode to the throttle computer myself. where you add first a delta-v burn and then a series of "keep velocity=x from altitude =y". Assuming you've put the attitude computer into retrograde mode such a module should make it possible to set up a landing profile for the ship to follow.

I was thinking of something like Half-Life 2's Garry's Mod's WireMod's Expression2 system (what a mouthful), except more basic. You could write some basic event-driven routines ingame (or save/load) and upload that via antenna.

Haven't brainstormed much on this so there's still a lot to figure out before I could even start implementing this.

[zalzane]

Confirming that the issue is with ISA MapSat. The lag only occurs when both a remotetech instrument and an isa mapsat dish are on the vessel. I couldn't tell you whether ISA is causing something in remotetech to lag up the place or vice versa because ISA's sourcecode is in one 1300 line file, and I'm way too inebriated right now to profile the crawling chaos that is a beginner programmer's project.

[Emeegeemee]

Confirming that the issue is with ISA MapSat. The lag only occurs when both a remotetech instrument and an isa mapsat dish are on the vessel. I couldn't tell you whether ISA is causing something in remotetech to lag up the place or vice versa because ISA's sourcecode is in one 1300 line file, and I'm way too inebriated right now to profile the crawling chaos that is a beginner programmer's project.

Its more than likely ISA.

Yes the source code is one hell of a mess, but I was actually able to fix the stuttering, so right now I'm currently waiting for the owner to reply to me to see if I can get it updated.

[JDP]

I found that virtually all of the pathfinding stuff only eats about 15ms every 5-10 seconds, so you were right that it's not the issue. I found that the drive method of the flightcomputer class was eating 5ms every time some event was calling it (every tick maybe), but commenting out that jazz didn't really affect performance as much as I thought it would.

Gonna go pull the mapsat/kethane/mechjeb sources and see if there's a conflict of interest somewhere.

I'm not that worried about the flightComputer, the drive method doesn't do anything aside from checking a couple of bools if the flight computer isn't active, and even when it is active, the load doesn't scale.

What I was worried about is the WindowGUI method of the RemoteCore class. Due to an oversight on my part it actually runs the patfinding A* search for each RemoteTech vessel every frame. In my latest dev build I've scaled that back to once every 100 game ticks and on top of that I'm running all pathfinding within its own dedicated thread. Thankfully it was possible to use multithreading for this despite the constraints posed by Unity.

but even the lag generated from the WindowGUI method couldn't cause the lag you see, as it's contingent only on the "list comsats" menu being open.

I was thinking of something like Half-Life 2's Garry's Mod's WireMod's Expression2 system (what a mouthful), except more basic. You could write some basic event-driven routines ingame (or save/load) and upload that via antenna.

Haven't brainstormed much on this so there's still a lot to figure out before I could even start implementing this.

Sound like a cool idea. Maybe you can look a bit into Autom8. A simpler and less auto-piloty analogue to Autom8 could fit in very well with RemoteTech. Personally I wouldn't want it to be too automated. In my mind, a "land at" button would kind of defeat the challenges purposefully posed by RemoteTech.

Edited April 28, 2013 by JDP

[JDP]

Confirming that the issue is with ISA MapSat. The lag only occurs when both a remotetech instrument and an isa mapsat dish are on the vessel. I couldn't tell you whether ISA is causing something in remotetech to lag up the place or vice versa because ISA's sourcecode is in one 1300 line file, and I'm way too inebriated right now to profile the crawling chaos that is a beginner programmer's project.

Hey, so is RemoteTech as you can probably tell now that you've been through my source . When I released the first version of RemoteTech it embodied my entire experience in C#, and to a great extent still does. Before I started working on RemoteTech I only had a bit of elementary knowledge of Java and some training in formal logic.

Still I'm glad to hear that the issue isn't with RemoteTech. Especially since I had no idea what could cause it.

Edit: Props on the "debugging under the influence" ability you've displayed

Edited April 28, 2013 by JDP

[Cilph]

Sound like a cool idea. Maybe you can look a bit into Autom8. A simpler and less auto-piloty analogue to Autom8 could fit in very well with RemoteTech. Personally I wouldn't want it to be too automated. In my mind, a "land at" button would kind of defeat the challenges purposefully posed by RemoteTech.

Completely agree. If a user wants to have a universal launch/land-at, he will have to do that using the basic functions provided and write his own subroutines for that. You would only be able to use data that the probe could realistically obtain on its own, like acceleration and rough altitude. That should be enough (I think) to provide estimates for periapsis/apoapsis and do what we commonly call gravity turns.

I've got about 5 years of experience in C++ but much less with Java and C# so it'd be somewhat of a learning experience for me as well.

[JDP]

...You would only be able to use data that the probe could realistically obtain on its own, like acceleration and rough altitude. That should be enough (I think) to provide estimates for periapsis/apoapsis and do what we commonly call gravity turns.

Potentially you could simulate gps functionalities by looking at how many satellites you are in direct contact with and then applying dithering to any data based on that. I've also been thinking about doing something with that functionality for a bit of time, mainly for use in a orbital information window but maybe also for use in the flight computer. However this would add a considerable amount of difficulty, the velocity vector is so important to most calculations done. I might need to add a couple of custom sensors, like a camera for stellar cartography that would give you a rough position from which a velocity vector can be calculated.

I've got about 5 years of experience in C++ but much less with Java and C# so it'd be somewhat of a learning experience for me as well.

No worries. I have a little under 1 year of experience and I seem to manage, mostly. C# shouldn't be difficult at all for you. Let me know if you need anything though. I'd be glad to add some functions to RemoteTech if they're needed and if you ever want to do a straight up collab on your project I'd probably also be happy to straight up implement it in RemoteTech.

[Matthew51]

I can't get RemoteTech to work with MechJeb. The Local Control button stays red even when I'm sitting on the launch pad with a MechJeb modules on the rocket. Older versions that button switched to MechJeb Control, and it would take over.

Remote Tech version: 5.0.0

MechJeb Version: 1.9.8

KSP Version: 0.19.1.54

[LIVEitup472]

I can't get RemoteTech to work with MechJeb. The Local Control button stays red even when I'm sitting on the launch pad with a MechJeb modules on the rocket. Older versions that button switched to MechJeb Control, and it would take over.

Remote Tech version: 5.0.0

MechJeb Version: 1.9.8

KSP Version: 0.19.1.54

Same problem, same versions. I tried MechJeb 2.0 as well and no luck. It seems that the only non-working element is the throttle. Directional control work, however, anything with direction and throttle only does direction.

[Interfect]

I have it working with MechJeb 2 (I believe 2.0.7). RemoteTech 0.5.0.0 isn't compatible with MechJeb 1.x anymore, though, as far as I can tell.

[zalzane]

Hey, so is RemoteTech as you can probably tell now that you've been through my source . When I released the first version of RemoteTech it embodied my entire experience in C#, and to a great extent still does. Before I started working on RemoteTech I only had a bit of elementary knowledge of Java and some training in formal logic.

Still I'm glad to hear that the issue isn't with RemoteTech. Especially since I had no idea what could cause it.

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.

The only 'gotchya' I saw was that SupportClasses.cs didn't actually contain support classes. Generally the term 'support/helper class' refers to a static class that has helper methods that take and input and return an output. For example, you might have a support class that contains different kinds of pathfinding functions that just take an input and return a result. Generally for everything else, every single enum/class/struct gets its own file. That way it's easier for a maintainer to visualize the flow of your program by just looking at the filenames in the project.

I've got about 5 years of experience in C++

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.

Edited April 28, 2013 by zalzane

[Legwan]

First of all I want to say that I love this plugin! It gives such a big deal of realism into the game!

There is one suggestion I would like to make - is it possible to add either:

- queue list of commands including thrust and wait periods

- delayed execution of thrust command

This will give the ability to send such program in advance for operations like capture burn for further planets - one could plan everything ahead and send a set of operations not worrying about loss of contact later. It will immensely help for burns at the back side of target planet where there is no chance for communication. Also I believe it is also the way real deep space operations take place. Hope it's not too difficult from technical side (programming is not my thing). But it is only a suggestion - sorry if repeated, haven't found anything like that using search.