JDP

There is a difference, but only when it comes to structural integrity. the non-animated dishes can withstand much higher airflow than the animated ones. Just try launching with the animated dishes deployed and see what happens. Anyway I'm thinking of fazing out pretty much all the old dishes in favor of new animated target-tracking dishes. The first dish to fall will be the old remnant of the probodobodyne dish. I'm currently working on a neat little folding and tracking dish to replace it. Regarding the range gap, it's there for a reason, since intermediate dish ranges would be mostly useless. the low range class has a range that can just reach minmus, the mid range class has a range that can just reach duna and eve and the long range can reach pretty much any planet within the solar system. There would be room for a class intermediate between mid and long, but doing so might complicate gameplay a little too much.

the ranges are desplayed as <unpowered range> / <powered range>. Some antennae still have a small range even when unpowered.

I believe this is due to a weird behavior when it comes to unloading the dishes once they've been ripped off. If you open the debug console you will probably be spammed by a whole lot of red nullReferenceException messages. The easy fix is to simply explode the parts before they're unloaded. I'll make sure that happens in the next version. This issue is not found in the new shrapnel method coming together with tracking dishes though. Sadly neither the stock antennae or the satDish 9000 has an internal hierarchy compatible with the shrapnel method and they'll have to remain with the legacy method of simply breaking the part off and exploding it.

AFAIK unchecking "animate physics" helps a lot on framerates when you're animating objects with colliders. It might not be that big of a lag factor any more though, since the bug of the debug spamming "resetting inertial tensors" while animating colliders was removed somewhere between 0.18 and 0.19

For most of the animations you can substitute the RemoteTech partModule with the standard animation partModule. In some cases you will get a bit of trouble though. My animation modules allow for multiple independent animations that don't interfere with each other. To my knowledge the stock animation module doesn't do that. This is only really relevant when it comes to parts with multiple animations though, which right now is only the AeroProbe body + wing and the MicroSat. The easiest thing you could do would be to remove any and all moduleRemoteTechSPU in the configs and replace them with standard moduleCommand partModules. That way only the code relevant to animating antennae will be run. EDIT: Actually, now that I think about it, the antennae depend on the relay network being present too, but this won't cause any unnecessary lag since the network is only updated by vessels that carry a moduleRemoteTechSPU. It will add a couple of kb extra ram usage though. Whenever the next version of RemoteTech comes out (and I'm afraid that might be some time since I'm in the middle of some intensive thesis work) you'll definetely have to go with the second method, since tracking dishes will need some custom code to actually track their targets (which looks really awesome by the way )

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.

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.

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.

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.

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

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

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

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

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

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

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

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:

Thanks a bunch. Your work has saved me a lot of time (and money for a gamepad I maybe no longer need to buy). You might very well be on to something there. I'll see what I can do with the incremental axis and implement test support in the next release. Oh, and another thing. What I said about not calculating surface area for shrapnel air resistance... yeah... I might actually do that.

I think it might be time for another small dev video (I've learned how to youtube, and I'm currently in a "youtube all the things!" phase). I've tweaked the drag model I've written to take account for how the shrapnel is turned towards the airstream. it does lend a lot of neat realityness to the drag model without being actually real (I don't calculate surface areas or anything I just take the dot product of the shrapnel forward vector and the shrapnel velocity in stead of calculating the magnitude of the velocity vector) The dishes aren't this sensitive by the way. They only broke because I told them to via a dev command. I'll use the same MaxQ value as I've used for other antennae, so these dishes too will break off at around 60 m/s at kerbin sea level.

It works completely on it's own. With r4m0ns permission (and considerable help I might add) I implemented the PID controller used by MJ1 Smart ASS. I did update it for 0.18 myself, so it's a bit different from what's curently used in MechJeb. The numbers flashing are there to tell you that a signal is being sent + how long until it reaches the ship. But if you only have milliseconds of signal delay they're only visible for a single frame. Go out further where the signal delay is measurable and you'll be able to see them for longer. As has been said by toril, the antenna won't break apart if you keep it retracted, just like solar panels. 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.

The old throttle issue came about when I fixed the input delay method for 0.18. The fix involved beefing everything up so that RemoteTech completely took over vessel flight inputs and took them directly from keypresses. What I failed to take into account was axis controls. This issue is thoroughly fixed since I grab the same axis input that the stock game does. To make it properly work I even bought a joystick for testing. The axis inputs in stock KSP haven't changed at all and to properly research the issue I'd need to replicate the circumstances, i.e.: buy a gamepad... this hobby of mine is starting to become mighty expensive . Dev note: Who would I be if I didn't show off a daily dev video. Here's a test of the tracking dish while deorbiting. This test was focused on the break functionality. I had to write a custom drag model for all the pieces flying off the dish due to the krakensbane. But it was worth it in the end. I've also made sure to take dish direction into account when calculating airflow. So if your dishes are rotated towards the horizon they might just make it intact, but the moment they turn their broadsides towards the airflow, they're gone:

low speed? at kerbin sea level you need to travel at around 210 kmh (or 130 mph) before it breaks off. You will exceed this speed while launching and deorbiting easily though. Indeed I intended for it only to be usefull in orbit, since it has such a long range compared to weight. Use either the dipole or deployable antenna for atmospheric communications. I'd like to. When it comes to functionality MechJeb is far superior to the flight computer. But disabling input in the MechJeb gui is something that can only really be done within MechJeb itself so It'd be something r4m0n and The_Duck has to do. Whether that will ever happen is very uncertain, they both have a lot to do with MJ2 as it is, so I'd imagine they wouldn't be keen to work on interfacing with other plugins at the moment.

It will work just fine, and since you'll be outside the SOI of minmus you can just point the dish at minmus, that will be enough to make contact with any omnis in orbit. You best be very carefull when setting up your orbit though. Your semimajor axis needs to be pretty much exactly equal to that of minmus, or else you will drift from your relative position. small dev note I've just finished the rough coding of a new animated antenna module based on what I've learned from my custom gimbal module. I didn't really plan on it, but I kind of ended up implementing target tracking. So this will definetely be a thing in the next release. Another thing I've implemented is behaviour similar to solar panels: if you deploy your dish while traveling at high speed in a thick atmposphere it will blow apart in a lot of pieces and look awesome while doing so. I'm unsure whether more tracking dishes than the small-range I've showcased will make it into the next release, but at least that one should make it in. I've also redone optimized the way relay data is calculated a lot. the experimental multithreading I've implemented without much hope of working has actually worked without a hitch. this, coupled with the buffered calculations for the "list comsats" window has made the game run a lot smoother. I still need to stress test it all though. I'll have to launch somewhere between 50-100 RemoteTech vessels in order to feel certain that the lag issue is sufficiently fixed. Oh and the "throttle at 50% on window unfocused" bug; equally fixed

I don't think I'll be allowing surface attach out of the box. Since the satellite is so small and light weight I really don't want it to have a dish. For larger dished satellites you'll have to wait. I have a sneaking feeling that something awesome is around the corner . Many things can be added as partModules. If you want the satellite to have MechJeb you can just add the MechJeb PartModule. And the same thing is true for all stock sensors. I'm unsure if ISA MapSat has converted to PartModules though and lights of course won't work unless the part has a light source, which it doesn't. I might turn down the SAS values for the part a bit in the next release. That's somewhat of a problem. Especially the AeroProbe does a lot of things and screen space becomes an issue when you both need to display stats from all the partModules on it and a long description. I'll see what I can do to add clarity though.

I tend to agree with the other helpfull people that the issue is due to your dishes not being pointed at each other. Another note: when you're in orbit around Kerbin you will not be able to get any kind of connection from a dish that's pointed at kerbin. You'll need to point it directly at a vessel, and have either an omni or a dish pointed back at you on the other end. For low kerbin communications omnis are really the way to go. They have plenty of range to stay in contact even in kerbosynchronous constellations. Indeed it will work. You'll start to really feel the signal delay though. I just sent a probe to Eeloo and the signal delay clocked in as high as 14 minutes. That's when the flight computer comes in really handy. On the subject of dishes. the low-range target tracking dish is coming along nicely. Pretty much all that's left to do is texturing. Here's a small sneak view of it in-game: