JDP

I've been working a bit on the next experimental build of RemoteTech, refining the new debris activation method. One bug which I've fixed is an issue where Struts don't disconnect like they should. Wanting to really test the method, I decided to build a really massive and strutified ship. So I recreated the Venture Star of Avatar fame. It comes complete with an interplanetary transfer stage that holds a stock 3 kerbal command pod and 3 spaceplanes perfect for landing on any body with an atmosphere. I was able to keep it low on parts just enough so that it didn't lag too much on my pc, but still, it's a beast with about 350 parts and 9 stages (some of which are designed to be duplicated in staged, activated debris): I've only tested it's transfer capabilities with Duna though. I think it could probably reach Eve as well, but Moho and Jool would maybe need a lot of extra delta V. The transfer stage (Venture Star) comes complete with a RemoteCommand module, omnidirectional antennae, 3 dishes and one interplanetary class dish. The three landing craft (which I dub Hammerheads) have omnidirectional antennae and 2 dishes. They are also fitted with a RemoteTech powered mk1 cockpit, so they have RemoteControl functionality. This means that it is entirely possible to detach and land an unmanned Hammerhead remotely from the mothership if all 3 kerbals stay on board. I think the Hammerheads might have enough delta V to reach orbit from the surface of Duna (though I haven't tested it), so the Venture star could perform a rescue mission, rescuing as much as 3 kerbals in vastly different positions on the surface, and bringing them to orbit, for later pickup by an interplanetary transfer vehicle with 3 extra seats. It really amazed me what is made possible by the new activation method, together with the fix to allow crewless but crewable vessels to be remote controlled. You can make some pretty cool spacecraft Adding example spacecraft to RemoteTech I was thinking that I might want to bundle a couple of example craft with the next release of RemoteTech (I'd certainly want to show off the Venture Star). And I'd really love to include a couple of community created spacecraft as well. I might create a thread in the SpaceCraft Exchange subforum especially for sharing RemoteTech spacecraft. You'd all be free to post your creations and if I want to include one of your spacecraft in RemoteTech, I'll PM you for permission. The only recuirement for possible inclusion in RemoteTech would be that your craft use only stock and RemoteTech parts, since I would need to otherwise bundle other mods with my releases. What do you guys think. Would you be interested in sharing your creations with the world? -JDP

Nope they didn't. In the past, activated debris had to be a single stage. That's no longer the case. Now you can launch landers comprised of both a descent and ascent stage for example.

RemoteTech 0.3.5.3 Experimental build 1 - Now with support for staging in debris! One of the updates I wanted to get done by 0.3.5.3 was implementing a whole new way of debris activation. Zool found a method some time ago that allowed for debris to actually keep staging information. I've been working on an implementation of Zoolian debris activation for some time now and I think I have finally found a version of the method that I'm happy with releasing. But since this will be a whole new activation method, I expect there to be a lot of small hidden bugs, that I probably wouldn't be able to catch by myself. Therefore I'm releasing this experimental build of 0.3.5.3 to the community. The only thing changed in this build is the activation method, otherwise it's exactly like 0.3.5.2. For those of you so inclined, you can download the zip file and simply overwrite your (Version 0.3.5.2) RemoteTech.dll with this one. Any bug reports or suggestions would be much appreciated. Cheers -JDP

There already has been, since the very first release by the way . the RC Antenna is specifically designed for that purpose (RC stands for RemoteControl). It's even got a tiny little antenna so it doesn't need other antennae, as long as your're somewhat close to a command station (250 km). It's very good for rovers with a landing station close by, that can relay long range signals to it. It's also proben itself to be very good on small satellites. But you'd need to also add an antenna to boost the antenna range a bit. The dipole antenna is the smallest, but still has a decent range.

RemoteTech V 0.3.5.2 released Another week and another update. I've fixed the big joystick bug, but also had time to do a little more development. RemoteTech is now partially MechJeb compatible, so those of you who want to RP a proper flight computer now have the option of doing so. I've also done some more work in controlling crewable but empty vessels. With permission from the guys at squad, I've now made it possible to mix and match as many pods and cockpits as you want on a single vessel and even have a crewable vessel be completely without crew from the get go. So unmanned rescue missions are finally a reality . Changelog: Fixed compatability with joystick throttle. Bought a joystick to test it this time. Added compatability with MechJeb. Here by popular demand, now MechJeb will be able to activate local control. Added in-game stats drawn from the part config file. in the same way you'd normally check stats like specific impulse, crew capacity and so forth, you can now check each parts RemoteTech Stats. Added support for crewable CommandPods that don't spawn crew when the flight starts. With permission from the guys at Squad, I've included two sets of modded stock pods; one thats available together with the stock pods but doesn't spawn crew, and one thats available with the normal parts. All modded pods carry some RemoteTech gear with them. All the 1 man pods are RemoteControl and the 3 man ones are RemoteCommand. I am somewhat excited about what interesting missions can be conducted with this addition Cheers -JDP

hmm, that's odd. If your capsule doesn't have either a RemotePod, RemoteControl, RemoteCommand or RCAntenna module (signal processors) attached to it, the RemoteTech window shouldn't even be visible. I tried recreating the bug by launching a vessel with staging exactly like yours and the only way I could recreate a result resembling what you described was to put one of the four modules mentioned above on the capsule itself (and in case of the RCAntenna, making sure that I decouple the pod somewhere where it wouldn't have a signal connection to another command station). In that case I could always regain control of the pod simply by turning on local control. Are you sure that you decouple all signal processors from your pod? This does sound very strange. Whenever you remove all signal processors from your vessel, you are in effect also removing RemoteTech code from the vessel. Allmost no RemoteTech code should be running at all, certainly not the bits that draw the window. I've just ammended the OP with an explanation as to where to actually find the config file . In addition to the part config files, RemoteTech uses a global config file for global settings. What you're looking for is at the bottom of the file.

The last experimental release does not fix any compatability with MechJeb. It was mostly meant to address the joystick bug in the current stable release (0.3.5.1). Which it failed to do misserably . No throttle fix for joysticks yet. I found that I really needed a joystick to properly test and develop joystick compatability. So I've dug a bit into my savings and found enough money to buy one. It should be arriving sometime this week, and I plan to take a half-day off this weekend to work on a proper joystick fix. Maybe, if I have the time, I'll also implement a low-brow MechJeb fix (where local control is enabled by MechJeb modules).

That's actually what I meant. Regarding your suggestion, I might implement it like that. But I'd also need to implement some sort of throttle fix for MechJeb probably. I'll look into it as soon as I get the time.

Currently remote controlled vessels have to be one-stage. It shouldn't mess with the staging of your main vessel though. Regarding your control issues. Have you remembered to add antennae to your vessels? or you might simply be out of range. I've had no luck trying to recreate your bug so I think it might be caused by your vessels not having a signal connection. Sure. As long as the parts are not allready using a plugin you can freely edit the parts config file for it to be RemoteTech, RemotePod or RemoteSAS, depending on what function you want it to fulfill. But remember that other variables are needed too. Look in the config files for the RemoteTech parts to see what variables you will need. Thanks for the tip. I'll look into it as soon as I get the time. The interplanetary class dish included in this plugin has more than enough range for interplanetary travel (hence the name ). You don't really need crew on your vessel in order to be able to control it. The only crew requirement I've set is that you have at least 3 for RemoteCommand to work and at least 1 in order to use local control. It doesn't matter if the crew are in a strut, pod or any other kind of part.

Dang! I think I'd need a joystick to properly implement and test this. Which is somewhat of a problem since I don't really have the money to buy one. I'll see what I can figure out. Don't count on it hapenning anytime soon. It would be a whole new line of programming for me to get acquainted with and I don't simply want MechJeb to be able to activate local control. I'd want there to be signal delay for each MechJeb button press. So basically I'll probably write a basic autopilot for RemoteTech before I make it fully MechJeb compatible. I think that would probably be easier.

No problem. I'd recommend that you link to RemoteTech and not include the dll in your download. It isn't a requirement though. Regarding limitations, I'd like some extra weight or drag on RemoteCommand and interplanetary range dishes. No omnidirectional antennae should have longer ranges.

I don't think I did. Did you remember to delete the old config file from 0.35? Unfortunately the throttle fix does break some MechJeb compatability. I basically had the choice between compatability with KSP or MechJeb. It might be possible to do som pseudo complex trickery to re-add MechJeb compatability though. But it would take quite a bit of work to do so. I've taken another crack at implementing joystick controls for throttle and I think I should have fixed the issues of inverted controls (basically I guessed wrongly in 0.3.5.1) And I've done some work to make joystick-throttle controls work at the same time as keyboard-throttle controls. I've attached the test-build here. Try it out and let me know if it works properly now. If it does, I'll release it in the OP.

No need to apologize. Thanks for the bug report though. I don't have a joystick and didn't really think about implementing axis controls in the fix. But now that you mention it, it's obvious to me that my fix excludes joystick users. I've tried to rewrite the code a bit, though I have no way of knowing if it works now. I didn't, until a few hours ago when I finally found out how to do it. I've implemented the feature in V 0.3.5.1

RemoteTech V 0.3.5.1 released For the first time in ages comes a release of RemoteTech that adds features. This one is a biggy Changelog: Changed the version naming convention to comply with kerbal.net standards. Made it possible to remote control crewable vessels without any crew on board. Big thanks go out to Alchemist and Kreuzung for helping with this. It turned out to be a bit more complicated than the simple fix we theorized ages ago. Actually I'd relegated it back into the realm of the impossible, but reading the chatter in the thread motivated me to give it another try. Now you can remote control crewable vessels, even when they don't have any crew (for example an empty pod, crewtank or DEMV rover) Hopefully fixed compatability with axis controls for throttle. I Don't currently have a way to test this, but I wrote a bit of code that hopefully restores axis compatability to RemoteTech vessels. Please provide any feedback as to whether it actually works now.

You may be thinking of The_Duck's plugin, maybe you're using the PowerTech PowerSat satellite? That satellite is not all that compatible with RemoteTech, just The_Duck's. RemoteTech doesn't need your satellites to be named anything in particular, it just needs your satellites to have the right parts. You can change the name of your satellites in the same settings menu where you set up your satellite dishes. If you where just thinking about changing the names/descriptions of the parts, you can do that without a problem in the config file in each part's folder.

Depending on what you want your plugin to do, it will be anything from very easy to extremely hard. I'd recomend that you start with reading the ksp wiki pages for plugin developers: http://kspwiki.nexisonline.net/wiki/Plugins I use visual studio express, it's very noob friendly and integrates nicely with the classes inherent in ksp When you've experimented with the examples in the wiki a bit, the next step would be to browse through the source code of other plugins to learn the intricacies of ksp plugin development. When it finally comes to you making your own plugin, you'd first need a good idea. Something that would add to the game in some way. That's almost the hardest part. I had it easy. The idea of RemoteTech came to me before I decided that I wanted to make a plugin.

Hopefully it will. Or maybe it would be possible to reinitialize the icons on load somehow. I experimented with it a bit, but without luck. Please feel free to tinker as much as you want. RT is very much a community-driven plugin, so extra developers and modelers are always welcome . I just flew my very first completely unmanned interplanetary mission, without using localControl or any autopilots. Dang that was exciting! Here's how I did it: step 0: fix you patched conics to show you multiple encounters. set it to something like (in the ksp settings.cfg): CONIC_PATCH_LIMIT = 10 step 1: Establish a relay network around Kerbin. step 2: Send a command station to your target planet. (your command station needs to have a crew of at least 3, and a RemoteCommand part, and antennae/dishes of course). step 2b: Establish a relay network around your target planet. (remember to add interplanetary class satellite dishes). (Step 2 and 2b can be combined in one mission by attaching decoupleable relay satellites to your command station composed of; RemoteControl, antennae/dishes and whatever propulsion you see fit. When you decouple the satellites, they will be activated by the RemoteControl and will become controllable Vessels in themselves) step 3: build your unmanned interplanetary probe as you wish (remember the interplanetary class dish), and let it sit on the launchpad for a bit while you set up your relay networks. Both your Kerbin relay satellites and those in orbit around your target planet should have an interplanetary dish pointed at your probe. step 4: Wait for Kerbin to be in the correct orbital position for you to be able to get a trajectory with an encounter with your target planet (in the case of Duna, Kerbin should be a little "behind" it). Launch into a low orbit and burn prograde until your trajectory leaves Kerbins SOI, keep burning until your trajectory around the sun intersects with your target planet and you see an encounter in the patched conics (this will only be possible if you've fixed your patched conics in step 0). step 5: while in orbit around the sun, point your interplanetary class dish at whatever planet is nearest to you. At the beginning this will be Kerbin, but when you get near to your encounter with your target planet, that will be nearer. When you get close enough to your target planet, the signal delay should drop to a couple of seconds, small enough to allow for careful course corrections. step 6: Once captured by your target planet, your signal delay should be very short, allowing you to maneuver more freely and attain an orbit through whatever means you wish (e.g. either a retrograde burn at periapsis or aerobraking) step 7: Rejoice in your first completely unmanned interplanetary mission

You practically read my mind. I actually implemented it in 0,35 (see attachment for my rendition of the needed icons) but had to remove the feature again. For reasons beyond me, using custom stackIcons would create vessel-sundering Exceptions in remote controlled debris, once you shift focus to- and from it. I lost a lot of test sattelites to sudden space cthulhu attacks. Please feel free to play around with it though. I think I'll be waiting for the hotfix until I dabble in icons again. Hopefully the code will be a bit more robust by then.

RemoteTech 0,35 released. After a long delay, RemoteTech is finally 0.17 compatible. Lets start out with a brief changelog: Applied the 0.17 compatibility fixes developed by community members. these cover the new way of handling coordinates in KSP, which was what caused the old version of RT to lag horribly. This version should not lag at all, and moreover, the handling of interplanetary relay paths has been much improved. This fix is wholly the work of Spaceghȫst et al. fixed an exploit that could give zero delay at interplanetary distances. This exploit is as old as the idea of relay network plugins (going all the way back to the original from The_Duck). fixed the buggy throttle controls introduced in 0.17. Gone are the days where you spend ages getting up to full throttle, only to be stuck there. In a rare fit of mercy I changed the default crew requirement for RemoteCommand to 3. I'd hoped that 0.17 would include a stock crew tank. And seeing as I don't want my plugin to require anything else, I chose to lower the requirement. Unfortunately I couldn't find a way of stabilizing the visual signal path. It seems to be a visual bug inherent in the conversion from local- to scaled space. I might someday try to find a way of doing all the graphical work exclusively in scaledSpace, eliminating the need for conversions. It seems like there are some delay issues, coupled with some floating point errors. Thanks and credits: Safe to say, I would not be able to release this version without the phenomenal work of this community. It is a rare thing for so many people to step up and volunteer their time and work, and spontaneously do it in a coordinated fashion too! My main thanks go out to the community at large, but I really should mention the following people: Spaceghȫst: For refining and assembling the final community build. Tomato: For more or less starting the whole thing. BoJaN: For finding a method of coordinate conversion. Mortaq: For finding the exact same method, at the exact same time. On his first forum post I might add. With this done, I think I shall spend the rest of my Sunday establishing my first interplanetary relay network . Cheers, -JDP

Thanks a lot for all your work on singling out the incompatability . I was afraid that the krakensbane would throw a wrench in RT. I haven't looked into the ksp assembly yet, but i know they've implemented a whole new way of handling coordinates. I'll look into a fix, but since i have a small exam this week, I won't have too much time. As soon as I get the time to troubleshoot, I'll get working on fixing RemoteTech to be compatible with 0.17. In the mean time, if any of you coders out there stumble on the solution before I do, feel free to pm me, and I'll include your fix.

When RemoteTech has run once in the game, it creates the config file. You can then find it in your KSP folder: PluginData/remotetech/Settings.cfg You can open the config file with something like notepad. Change; //Here you can edit the required crew for a command station (Minimum: 1, Default: 5) RemoteCommand Crew = 5 to //Here you can edit the required crew for a command station (Minimum: 1, Default: 5) RemoteCommand Crew = 3

I know the most current version of MechJeb has a lot of issues in it's debris activation method, which (I guess) might theoretically be exacerbated by my activation method. I don't really use MechJeb myself and haven't really had the time to test my plugin with it. That being said, I'd for sure like my plugin to be compatible, since so many players rely on MechJeb. I would be very thankful for a list of any and all bugs you may find. But make sure you tell me: what happened how it happened and make sure the problem is not solely with MechJeb (I.e.: the bug goes away if you do exactly the same but have removed all RemoteTech parts from the vessel) These kinds of bug reports are a huge help in development, as you guys are in essence all beta testers . r4m0n will probably be changing debris activation quite a lot in v1.9.2 of MechJeb, fixing the current issues with MechJeb and, I expect, improving the current knowledge on how to do debris activation. so I will understandably be a bit cautious with doing too much compatibility work before then. Regarding having the current version of RemoteTech be compatible with MechJeb 1.9.1, I'd advise you to follow CAPFlyer's advice. I'd add that the absolute safest place to put your single MechJeb is somewhere where you never decouple it from the main vessel. That way, MechJeb activation should never even try to run. This way, you will sadly loose any MechJeb functionality in your decoupled vessels. Personally, I can live with that, since my plugin is all about the challenge and the very punishing and exhilarating possibility of complete fantastic failure. RemoteTech 0,4 status update: Zools method is a planned feature for 0,4. The current version of RemoteTech only supports single-stage debris and will not work with Zools mod. As of now, development of 0,4 is temporarily on hold. It will be some time before I can resume work on the plugin, as I've since summers end become an intern. This first period of the internship is very intensive and leaves me just about enough spare time to sleep, eat, and occasionally write some responses here. Once September draws to a close, I should have time to restart development on a part time basis. But for the time being, my patients must take precedence over this project. I hope you all understand

Whenever you control unmanned vehicles you are in fact remotely controlling them. Try flying an unmanned mission to minmus (for example use the RemotePod) and you will really start to feel the signal delay in the control signal. The main purpose of this plugin is to make the game a bit more realisticy and a lot more challenging, by adding in unmanned vehicles that still cannot control themselves, but need kerbals somewhere at a command station. If you just want unmanned vehicles (and controllable debris), but don't want to worry about relay networks and control delays, I'd recommend MechJeb, which is indeed an awesome plugin.

That sounds like the known MechJeb bug. try removing all MechJeb from your 4 secondary satellites and the problem should be gone. Remember to add a RemoteSas though, since it gives you'r debris gyro control and you won't have to rely on RCS.

Yeah I've been playing with the idea of doing a video tutorial. Though it will have to wait a long time, since I'm currently way to busy to do any work on this plugin. For now, you will need to do some reading. the "which parts are needed for what" tab in the OP is a very good place to start. It gives you pretty much all the basic info you need.