JDP

Your Gameobject needs both a collider and a Rigidbody in order for physics to do its work. Here's a look at how I implemented physics way back in the old RT1 code. This snippet has to do with antennae breaking apart under high airflow, just like solar panels do. So the Gameobjects handled are all preexisting objects within a part hierarchy, which all have a collider of some sort. In order for the detached objects to behave properly within the drag of an atmosphere, I wrote a DragModel to handle that. Also to make sure that the objects are deleted once they go beyond the loading range from the active vessel. Looking at my code now, I see that I actually forgot to implement the last part. In any case, you wont have to go overboard with adding a custom drag model. You can simply add the stock physicalObject to your GameObjects to make them behave properly within KSPs fiddly physics. SomeRockGameObject.AddComponent<physicalObject>() And of course make sure that your GameObjects have both a collider and a RigidBody (that has a mass of >0).

AIES probe cores and antennae are not implementing RemoteTech by default IIRC. AIES probe cores act as a valid command part (just like a manned pod) enabling local control, even when out of contact (which you would be if only using AIES antennae, since the stock antenna module cannot work as a RemoteTech antenna). MeCripp posted a config file to make AIES parts use RemoteTech modules about a month ago. You can see it here.

True. Maybe it would be safer simply to deactivate the action: Actions["SomeNamedAction"].active = false; If this will cause an update in the visual action list within the editor is a different question.

Just a quick example on how to modify actions on other modules: public class ModuleDoStuff : PartModule { public override void OnStart(StartState state) { //find any ModuleEngines within the same part as your module if (part.Modules.Contains("ModuleEngines")) { //clear any actions. part.Modules["ModuleEngines"].Actions.Clear(); } } } This will simply clear all actions, but you could just as easily remove specific actions. The hitch is that your module would need to be started after the ModuleEngines you wish to make changes to. IIRC, the modules are loaded in alphabetical order, but this might not be the case. Especially in case of modules added by ModuleManager. In any case, this should be a starting place from which to do a bit of experimentation.

I did a bit of experimentation a while ago using the stock ConfigNode system and got some promising preliminary results. Being just an experiment to keep myself entertained on a blissfull day off it was never completed, and thus never made it to a Pull Request. Most command types are implemented though, so feel free to grab any inspiration you wish from my fork (i'll make sure to comment the commit a bit to make it more clear what I did). In my small experiment, I simply hooked into the stock persistence handling, but it might be prudent to have a custom persistence system in place, so that the data can be saved on a per-vessel level and not per part. It will also cordon off a lot of clutter in the stock persistence file. Especially if you want to make DelayedFlightCtrlStates persistent. Regarding the other devs. As with any hobby, activity levels tend to ebb and flow (case in point; the commit above, coded in july, and left hanging until this brief spur of forum activity by yours truly). I'm sure at least some of them will be back in time. And if not, then the beauty of the mod no longer being dependent on a closed group is that new devs are free to join.

It looks like it. I also took a look at the persistence file, and no moduleSPU was added to the probe core. tmk that can only happen if the game overrides the changes made by module manager by loading a saved craft created before the patch was applied. Odd though that the attached antenna has the correct RT modules. Possibly it was attached later in construction, thereby loading its config directly from the patched part config.

The MicroSat, AeroProbe and non-AIES tracking dishes where all made by me. Feel free to repurpose them and reupload anyway you want (given that credit is given and of course no profiting)

Possible, yes. But somewhat complicated and possibly very laggy to implement. The way the plugin currently finds a valid connection is roughly looking for the closest approximation to a straight line between each command station and the satellite, then choosing the shortest resulting path. Doing this takes a bit of toll on your computer and if done inefficiently or excessively will cause lag. Let's say you want to the system to predict just 1 hour in the future and want a resolution of 1 second. That would mean that your computer suddenly has to find 3600 connections where it would normally only have to find one.

That would only work if the sat had only one dish. A relay sat can typically need at least two.

That's actually a very good idea. Of course I'd have to take a look at infernal robotics to see how to properly move attached parts with the joints. All in all it shouldn't be too hard to write up. I do believe that I'd have to restrict attachment of dishes to only attach nodes, since only one dish should be placed on the joint and the direction vector of any attached dish should be constant. Of course this still is in need of a model. I could make it myself, but I've never been good at anything but the minimalistic look of RT1. I'll make a mockup once I get to a computer (I'm currently on a tablet) and any part modelers will be welcome to contact me with their designs. And of course this would only be a visual enhancement, just like it was in RT1.

Tracking dishes where implemented in RT1 and ever since RT2 started development it has been one of the most often suggested features. I did in fact implement tracking dishes in the old RT2 repo under Cilph, and adding them here would be no problem. The main issue is with the part models themselves: none of the dishes added by RT2 or already present in stock have the needed joints to rotate. So in short; it would be easy to code but would necessitate all new dish models and maybe some custom code for each of the stock dishes. Since RT2 is in short supply on modelers skilled in making stockalike models I sadly don't see tracking dishes being implemented anytime soon. I could reimplement tracking dishes in the code though, so prospective RT modelers have something to work with.

It should be coming in a later version. See Issue#84

Yep they do. There is a feature suggestion on github to add it though, Issue#32

Hi all, as a responce to philly_idle I've just removed the spaceport provision from the license in the OP. Now you should be able to do whatever you like with the original code.

Just quickly surfacing out of my own work-induced exile. You need not worry about dissapointing me in any way. Quite the opposite, I've been extremely impressed with what you where able to do with the core concept; far beyond my own coding abilities. If work leaves you no time and energy to continue the mod, then I wholly accept, and indeed recommend that you stop developing. Remember, that's exactly what I did myself when you took over. My current work is simply too time-consuming, exhausting and rewarding to do much else. Modding is a hobby, and done entirely because it's fun. With such things, IRL always comes first. You've done very well in your tenure as lead dev. If you have to pass the torch to whomever wants to continue the mod, or let the mod pass into oblivion, then that's not at all a bad thing, it's simply how modding works. tl;dr

to just make a quick and dirty line, you can use a LineRenderer from the unity API. For how to implement the line within the game, you can take a look at the old RT1 source. Secifically the RemoteCore class.

You can do a lot of stuff with the action groups. for example, toggling SAS could be done by: vessel.ActionGroups.ToggleGroup(KSPActionGroup.SAS); or turning off RCS: vessel.ActionGroups.SetGroup(KSPActionGroup.RCS, false);

Indeed I am the JDP of RT1 fame. Ever since I finished my studies and found full time employment, Cilph has taken over the plugin and only a neglible part of the RT2 source can be traced back to contributions by myself. I do what I can to keep up to date on the forum, but that's pretty much all my spare time gone. I would like to re-release the AeroProbe. But doing so would require a couple of days of intensive dev work (both coding and part modeling), which I haven't really had for the last 6 months. You could probably still use the MicroSat, as long as you edit the config to use the relevant RT2 modules. The AeroProbe would need a couple of custom modules not included in RT2.

Maybe you could use the connection cheat. By enabling infinite EVA fuel in the regular cheat menu, any vessel with a SPU will register as in connection. From briefly browsing through the source, it seems the cheat should still be implemented. Doing this, you could buy yourself the needed control to properly orient any antennae needed.

Indeed, as Sacred Aardvark pointed out, infinite eva fuel does indeed override LoS checking (proof here). It also stands to reason that the signal would relay through a satellite, since KSC does not have the needed range to reach Moho. It could however seem like there isn't a connection between the relay sat and KSC... hmm... maybe the sat is somehow registering as a command station, AFAIK there are still a couple of bugs with command stations. Back to the LoS issue. If you don't have infinite EVA fuel enabled, it might very well be due to some rounding issue. Since KrakensBane keeps the coordinates of the active vessel at (0,0,0), moving the rest of the universe around it (think: Futurama), the coordinates for Kerbin would contain a couple of very large numbers, and would be traveling at very high speeds. So there might very well be the possibility of all sorts of rounding errors. Edit: Having infinite EVA fuel disable LoS checks has been in RT since the very old days of RT1. I put it in specifically for testing (and cheating ), since infinite EVA fuel effectively does nothing while controlling a ship.

It looks like the textures aren't loading. This might be due to the textures not being there (they should be in: GameData\RemoteTech2\Textures) or the game not being able to load them. If you have your KSP folder within documents, you might want to try moving it somewhere else. There could possibly be an access issue there.

In GameData\RemoteTech2 you can find the global config file for the plugin; RemoteTech_Settings.cfg Within the config you can modify the omni range of mission control MissionControlRange = 7.5E+07

TBH I didn't know either. A quick look through the source tells me that it puts sets the reference frame to be parallel to the target.

Hey, I did say it was small

Here you go; I made another vid of a flight computer assisted launch using the new flight computer. Hopefully I didn't go through things too fast.