JDP

It does seem you're right about the delay. Perhaps Cilph meant to say Eeloo. Regarding the delay being for the full round trip of the signal. That is meant to model the delay in feedback from your probe. Any confirmation of signal reception, and audio-visual feed for that matter, will also be delayed. Just like in real life. Indeed there is. within GameData\RemoteTech2 there is a global config file for the plugin: "RemoteTech_Settings.cfg". Here you can specify the speed of light used. By default it i set to 3 X 10^8.

Indeed there is. RT2 has a global config file called RemoteTech_Settings.cfg, this can be found in GameData\RemoteTech2. open up the config in any text editor of your choosing and change EnableSignalDelay = True to EnableSignalDelay = False

That would be RemoteTech 1, which is no longer in active development.

For ease of accessibility and coordination, I recommend expanding and modifying the existing RemoteTech tutorials and documentation on the KSP wiki. Stylistically, the Micro- and AeroProbe would need somewhat of an overhaul. At least new textures would be needed to make them conform to the stock look of RT2. I've been planning on giving the AeroProbe a much needed rework in the modeling and plugin department; integrating all the landing wheels within the main body. I've been insanely busy with work lately though, so development is considerably delayed. After the tweaks to the AeroProbe is done, I'd need a good texture artist to do the rest (of course based on the existing Unity project and UV maps).

For the time being You'll have to plan your assent profile with signal connection in mind. If you use the dipole antenna you'll be able to maintain a connection within the atmosphere. Whenever Cilph releases the flight computer you can go for the CAPFlyer method. A while back I made a small tutorial on the method. The tutorial was made using the old RT1 plugin and flight computer, so how you input the heading and timed burn will be slightly different, but the method itself will still work. You can view the tutorial Of course, the easiest way to deploy a rudimentary relay network early on is to launch a manned payload vehicle.

Do Cilph a favor and post issues in the bugtracker

within the GameData/RemoteTech2 folder there are a couple of .cfg files from where you can edit the range variables. The two you will need to edit are AFAIK: RemoteTech_Antennas.cfg & RemoteTech_Squad_Antennas.cfg for omnidirectional antennae, the variable you will need to modify is; Mode1OmniRange for dishes, the variable is Mode1DishRange Edit: Derped a bit there. The range of KSC is sadly hardcoded. You could always just place a relay station on the ground near KSC.

The MicroSat and AeroProbe where themed along the old minimalistic-magenta RT1 style and not so much stock style. I'm currently working very much part time on optimizing the AeroProbe (integrating the landing wheels within the body). But making it stylistically sync with the stock look of RT2 will take some tender loving care of a great texture artist, which I definitely am not :-)

Congratulations! I'm very happy to see RemoteTech back in action, and You did some awesome work with integrating RT into stock game behavior to boot.

the solution to flickering could be simply replacing each instance of ModuleParachute with a custom module that derives from ModuleParachute, with the only addition of modifying the canopy rotation. Replacing this module could be done via ModuleManager or you could do it programatically yourself. public class ModuleParachute2 : ModuleParachute { private Transform CanopyToRotate; public override void OnStart(PartModule.StartState state) { base.OnStart(state); CanopyToRotate = part.FindModelTransform(canopyName); } public override void OnFixedUpdate() { base.OnFixedUpdate(); CanopyToRotate.Rotate(Vector3.left); } }

I trust you are aware that the ingame debug log has a verbose mode. in settings.cfg set: VERBOSE_DEBUG_LOG = True I'm not entirely sure this is what you'd be looking for, but at least it's been a lot of help with tracking exceptions to their culprit methods at runtime for me. oh, and regarding decompilers:

since ModuleParachute has a name variable for the canopy transform (canopyName) it's safe to assume that ModuleParachute sets the rotation of that transform based on frame velocity. Which in fact it does seem to do every fixed update. Sadly I can't see any way around this, safe for overriding ModuleParachute entirely, which of course is a possible solution. Probably in conjunction with ModuleManager.

if you are solely working with loaded vessels/parts, you could just use typecasting (like suggested above). If the part isn't loaded, you'll need to access the ConfigNode generated from the part config file. If memory serves, you'll need to do something like this: if (vessel.loaded) { foreach (Part p in vessel.parts) if (p.Modules.Contains("ModuleEngines") && (p.Modules["ModuleEngines"] as ModuleEngines).throttleLocked) { //do stuff. } } else { foreach (ProtoPartSnapshot p in vessel.protoVessel.protoPartSnapshots) { if (p.partInfo.internalConfig.HasNode("ModuleEngines") && bool.Parse(p.partInfo.internalConfig.GetNode("ModuleEngines").GetValue("throttleLocked"))) { //do stuff. } } } You cannot simply look through the persistence data (look into RT1 source here for example) since throttleLocked is not a persistant field. I'm not entirely certain that p.partInfo.internalConfig is in fact the configNode you'll need, since I've never had use of it. Neither have I checked under which circumstances it is loaded. It is however an informed guess. Play around with it a bit and see what works. In the case that you are only working with loaded vessels (ie.: FlightGlobals.ActiveVessel), you won't need anything more than the simple typecast.

AFAIK all rigidbodies whithin a vessel will be kinematic while timewarping (except if you use physics timewarp), hence physics will not be applied to the vessel while timewarping. You could possibly modify the orbit directly. You could calculate acceleration from the vessel mass and whatever force the sail should apply. I quickly threw together a small proof of concept plugin, you can view the source here. Since the sail wont be generating power, you don't need to be running all the stuff in ModuleDeployableSolarPanel, so I just extended ModuleAnimateGeneric and did the obstruction detection and area-facing-the-sun calculations myself. Note that the plugin I've linked is very much something I threw together, I haven't tested it in-game, so it might very well have some bugs, and modifying the orbit velocity in the way I've done was just an idea, I don't really know whether it will work or not (it might be entirely impossible or, more likely, something different/more needs to be done with the orbit). Maybe you'll be able to get a couple of hints from the HyperEdit source.

Also, GetKeyDown() already returns a bool (true once while down, false otherwise), so for simplicity's sake you should just have: if(Input.GetKeyDown(KeyCode.Z)){ print("Z pressed!"); }

I'm telling you to turn off the setting in the part config file that forces the generator to not be toggleable. For further reference, here is an excerpt of the module as defined in the config for the stock RTG. I've highlighted the parameter you'll need to change to false. MODULE { name = ModuleGenerator [b]isAlwaysActive = true[/b] OUTPUT_RESOURCE { name = ElectricCharge rate = 0.75 } } I'f it's still not working, feel free to post a pastebin, or whatever you prefer, of your config file. It's always hard to bugtrack when you don't have a complete overview.

Great catch! It would seem that there has been a couple of extra benefits from getting Romfarer as a dev. the packing thresholds seem to be fully vessel-specific now. Which makes me very much giddy. I can get away with much larger RC ranges now. It does seem like the old method no longer will work though. Since the thresholds are now vessel specific, you'd need to modify the vessel of the targeted node.

You can get the MeshFilter thusly: MeshFilter meshFilter = (MeshFilter)clone.GetComponent<MeshFilter>(); AFAIK that is only the mesh, you may also need the MeshRenderer (accessible through gameobject.renderer I think). Also note that there are typically many transforms with MeshFilters contained within the part hierarchy. You'll probably have to do a bit of iteration. Of course you could just destroy all the unwanted components from your instance (e.g.: GameObject.Destroy(clone.rigidbody) it's a bit of a workaround. but at least you wont be keeping unneeded instances around.

The 200m threshold is not one of loading, but of packing. You can change the packing and unpacking thresholds thusly: OrbitPhysicsManager Manager = (OrbitPhysicsManager)GameObject.FindObjectOfType(typeof(OrbitPhysicsManager)); Manager.distantLandedPartPackThreshold = Manager.distantPartPackThreshold = 2250; Manager.distantLandedPartUnpackThreshold = Manager.distantPartUnpackThreshold = 2000; Of course there might be some additional limitations within ModuleDockingNode itself. That I haven't tested. Don't overdo the range boost btw. It can cause quite some lag if you set the OrbitPhysicsManager to unpack too many parts at a time. Romfarer overdid it a bit for his Lazor plugin and it caused him nothing but grief. This code snippet is from RT1. Here I set the packing and unpacking thresholds to be just within the loading range (2500 m). I've had good experiences with this, it seems I found the sweet spot. I did however implement a toggle to turn off the range boost. I'd recommend you do the same if you choose to implement this.

ModuleGenerator has the requisite KSPEvents (and KSPActions btw) to allow toggling on/off from either context menu (right-click) or action groups. These are however not available if you've set your generator up to be always active. You should have this in the config for the module: isAlwaysActive = False

[PLUGIN, 0.21.1] Docking Strut 1.0.1.0 Download: source here. (This plugin is free to use and modify as long as the original author is credited.) Description This plugin enables you to strutify docked vessels to make more sturdy spacebuilt space stations and spacecraft. Created links can be unlinked and relinked as many times as you want and in any configuration within the range of the strut (10m by default, can be changed in the config file) and provided the strut wont be obstructed by other parts.

if you set VERBOSE_DEBUG_LOG = True in settings.cfg you get a more detailed output to the dev console, displaying which method ultimately threw the exception.

That depends a lot on which class you derive from; MonoBehaviour, Part and PartModule would be the big three. For MonoBehaviour there might be some delegates in GameEvents you'll be able work with. For PartModule, it's as simple as overriding the OnLoad and OnSave methods.

Sadly, no. The moment RT2 is sufficiently bug-free I will change the OP to reflect this. There are, at least, still a couple of bugs with the relay network backend and some tweaks needed to the flight computer.

Well, if you have a Vessel reference, to get it's world position, you don't need to do anything with latitude and longitude. You can simply get the coords from Vessel.CoM (center of mass) or even Vessel.transform.position if you don't need fine resolution. If you want to get world coords from latitude, longitude and altitude in reference to whatever CelestialBody is the mainBody of your object you can get the coords from mainBody.GetWorldSurfacePosition(latitude, longitude, altitude).