JDP

I've just removed my modified Cart v1.32 plugin from the download. It's going to be very fun to play with all the new features in Cart .

That's the beauty of Russels teapot. They could add absolutely nothing, but merely announce that they did, and they'd still have added in an easter egg. Albeit a metaphysical one.

It should work just fine alongside SRN. Some of The_Duck's comsats are even recognized by RemoteTech, they just aren't recognized as having any antennae unless you put some RT antennae on them. I'll look into an image to go along with the "which parts are needed for what" chapter. The problem is just that there is a lot of imformation to condense, so an image that properly represents what you can do, could be more confusing than just doing it in text.

No worries. It's a lot of work and a lot of time spent. But it's also a lot of very rewarding fun

Don't worry. Those will never change, they've grown on me too much . And if I ever change them, I'll loose backward compatability with custom cfg edits too. It seems a lot of people have changed other parts to be RemoteTech and I wouldn't want to make them go through their entire parts library. And yes.. testing can truly be a *female dog* sometimes

Yeah, I could have slapped myself when I read Alchemist's idea. It's so awesomly simple! Maybe I shouldn't call it a beta, but a development snapshot, since that's more what it would be. The first version will mainly be a cleanup of the 0.34 code, with an optimized method for comsat recognition and an implementation of Alchemist's idea. Kreuzungs idea to do it in partModules will probably have to wait for a later beta release. I plan to do that together with adding Zool's modified activation method, since that (as far as I can see) needs to be done in partModules too in order to avoid the current rootPart bug. The part class names will stay the same, and the only possible change in the interface is a change of the RelayPath class, but I don't imagine you are even using that, since the only variables you'd need are inRadioContact, localControl and controlDelay. Those will not change in 0.4, so no need to postpone your release . The only other plugin than RemoteTech I use in testing is Cart, So you can allways count on RemoteTech having been tested with Cart before I release anything. And in 0.4 I will be switchig from my own modified Cart 1.32 dll, to the newest stock version. The finished version of 0.4 won't be released for a long (loooong) time, since I'm looking at a very long list of features, most of them interconnected, and having a lot less time than I had for 0.3.

It could very well be a KSP bug, but since so many other plugins are involved it could just as easilly be one of those, or a cross-effect between any number of them or even KSP. It's very hard to diagnose with this many possible factors. Thankfully it seems as though it's a rare bug. Still, I think I might build in a little extra bit of exception handling in 0.4 just to be safe. Since one possibility is that the problem shows itself because something throws an unhandled exception. A little more 0.4 news: Debris activation: I've taken a look at Zools major contribution to my debris activation method and am looking into adding it in 0.4. He basically found a way of keeping the staging setup in decoupled debris, which is a huge leap forward. Combined with Alchemist's idea for making crewable but uncrewed vessels remotecontrolled, this could be a great addition to RemoteTech. As it is right now, it will however not work with MechJeb. I'm looking into a way of disabling RemoteTech activation if there is a MechJeb present on the vessel, so I don't end up forcing you to chose between RemoteTech and MechJeb. autopilot: I've done a little conceptual work on a RemoteTech autopilot. Seeing as it will be neccesary for extraplanetary missions (and could be an awesome addition), I've decided to definitely add it. Basic engine control is easy to implement (burn engine at x% for n seconds). I would like to get basic attitude control working (alá Smart A.S.S.) before I release 0.4, which is a huge challenge, as it involves areas of coding that are completely virgin land for me. The autopilot will definetely not be anything to rival MechJeb, and it shouldn't be. It will be very basic and all burns must be guesstimated by the player. That way it's still challenging enough to make it a major achievement to orbit another planet, and even more so to land on one. I will probably be adding a very basic landing module, where you can set a specific vertical speed for it to maintain, and probably also a specific height at which to start breaking to the set vertical speed. 0.4 beta: I've been thinking about maybe starting to release the most current beta build of 0.4 as an alternative download to 0.34. You guys have been a huge help in the development of 0.3 and it could probably be a great help to have your continual input and bug reports during 0.4 development. But since 0.4 will be a huge release with a lot of new features, it stands to reason that it will have a lot of bugs, therefore I think it should only be released as an alternative to 0.34.

That's a known bug with MechJeb and with RemoteTech (it's # 3 in the list of known bugs). Alchemist had a brilliand idea for fixing it a couple of pages back, and the fix is planned for release in v0.4.

I'm going to give it a shot and if I find a way I'll add it in 0.4. As far as I can see, internalSpace is simply a partModule, and those should be simple to add and remove from parts at runtime. I'd think that the most challenging task would be how to determine which internalSpaces to remove and which to re-add. With the addition of staging in Debris, it's suddenly possible to have a mothership decouple any number of other motherships that can in turn decouple any number of vessels/motherships (in theory even doing this ad infinitum). It's pretty high up on a very long to-do list of features to add for 0.4. So if I find out how to do it, it'll probably be some time before I'll release it. I'll PM you with a code example once I'm done with the internalSpace code. That way, you don't have to wait for my release in order to update yours.

That is a known bug in the debris activation method Zool is using, it's based largely on a design by me, which is largely based on a design by r4m0n. There is some wierd stuff going on with ASAS activation and AFAIK there always has been. I'm not sure if it will ever be fixed. But then again I wasn't sure that proper staging control of activated debris could work. This is some truly monumental work Zool! care if i steal it for the next release of RemoteTech? And another thing: I'd recommend playing around with your plugin removing the internalSpace of all but one vessel.parts, and after decouple, re-adding the internalSpace of the debris.part with the highest crewCapacity. That way you should avoid the brightness glitch while still being able to have an internalSpace in your extra pods.

I just had time to quickly skim your source before goring to work. It looked like you may have solved the issue where stagin info is lost. If so, then this is just pure awesome! I'm going to test your plugin out over the next few days whenever I get time.

Not a day goes by without this community surprising me, Thanks a lot m8 . Yeah, maybe i do need to man up and start experimenting with part modules. Well, I'll have to learn how to work with partModules anyway since I'd probably want to remove the internalSpace of all parts except the command pod and then readding it for the part in the decoupled vessel with the largest crewcapacity. That way decoupled crewable vessels can still have an internal space, but without it glitching while it's still attached to the mothership. I'd also have to have MakeUnCrewable be contingent on the part.vessel having no crew to make sure that I don't accidentally delete kerbals.

Regarding making these extra pods work like regular command pods, I am still planning to make a custom plugin containing the debris activation method of RemoteTech and the attitude control fix used in RemoteSAS in one small plugin. No relay network stuff or anything fancy. The project stalled a bit however, due to heavy development needing to be done in RemoteTech. I actually just got an idea from Alchemist on how to make even empty pods controllable. I didn't think it possible. I'll be needing to test out his idea in a small test plugin anyway, before I include the more advanced debris activation in RT v0.4. So I could simply release the results of that development as a small standalone plugin, derived from-, but not requiring RemoteTech. I'd be happy to donate the resulting plugin to this pack:)

I thought about just setting the crew capacity to 0 but discarded the idea because I couldn't think of a way of detecting when to re-add crewcapacity once a kerbal wanted to enter. I must have derped a bit there. Since your idea is so beautifully simple . I think the simplest way of doing it would be having the removal and readdition of crew capacity being handled by each part. Aha, finally an incentive to having crewable RemoteTech parts & command pods. I could probably even remove any internal space on extra commandpods until they decouple from the main vessel, removing the current visual bug of more than one internal space. Wonder what the official stance of the devs are on bundling pretty much stock parts, with just a few config edits, in your plugin? AFAIK there are no other custom hatched command pods and or parts out there other than the crewtank. (edit) Ohh, and Kosmos, I see.

Thats bug # 3 in the list of known bugs (found at the bottom of the OP). I know of no fix for it, I've tried a few things, but all has failed and failed misserably. For the time being it sadly won't be possible. Let's see if r4m0n can work some magic in the next version of MechJeb, though I have no idea if he's actively pursuing a fix for this issue. He is working on fixing issues in MJ debris activation though.

Actually it can be done, with great difficulty. In testing the interplanetary class dish I went for a kerbol mission, taking my probe as far away from kerbin to give a delay of over 2 minutes. I found that it was actually possible to perform orbital maneuvers if you are very very patient, use low thrust and guesstimate at least 2 minutes in advance. The SAS fix i found and implemented all the way back in v0,30 turned out to be invaluable, as SAS actually functions as sort of an autopilot, only SAS activation/deactivation is delayed, but the attitude corrections applied by SAS aren't. I don't think it will be possible to actually land on any planets, but you could maybe get your probe in orbit. I do get your point about the RP value of having an override. So I guess I could add in a small PartModule in v0.4 (or at least before KSP 0.17). It could be added to any part config without interfering with anything else and I would probably make sure that it would only work if the vessel was in contact with the relay network and had a MechJeb module. Hmm... while thinking about this I got a completely different idea; I might actually have come to a level of programming skills where I'm able to make a very very simple autopilot myself. I'm unsure whether I can figure out how to make it automatically turn the vessel in the different directions (Something akin to Smart A.S.S), but I could definetely give it thruster control. You'd have to turn your vessel manually and with great care, taking into account the signal delay. But once you have your vessel oriented correctly (lets say retrograde) you could bring up the autopilot menu, tell it at what % you want your engines to burn and at what speed to stop the burn or how long you want the burn to last. If i wrote the autopilot myself it would be a lot more simple to integrate with signal delays (meaning that if the signal delay is 2 minutes it would take 2 minutes from the time you press "go" to it actually doing anything). Thinking further, I could probably also add the option of telling the autopilot to maintain a certain speed (for powered landing). This would probably make only stop-n'-drop landigs possible though. I'm getting all excited thinking about this possibility. I think a crude autopilot like this would fit well with RemoteTech; it's very low-tech, insanely challenging, but not at all the only option you have of doing interplanetary spaceflight. Oh, and BTW I just found an exploit that I should have forseen. Currently you have delayless control of your spacecraft until the signal delay has caught up. Giving my kerbol orbiting vessel two minutes of instant control each time i switch back and forward to it. Hurry up and exploit it before it's fixed in 0.4

It doesn't seem like I can do it myself, i'd have to get a moderator to do it for me. Since I've been releasing an update practically every other day, I didn't really want to constantly trouble them with updating my own thread. I decided that I wouldn't change the title for every smaller update (0.3x), but would change it to 0.4 once the planned big additions get released. But I have made it a rule to post an update notice for every small update of late. Exactly so people who subscribe to this thread would be notified. As of right now, I'm not planning on ever releasing a v0.35, in stead i'll be slowly working towards jumping straight to 0.4 with one big update. If I'm lucky (and very very multitaskingly fast), I'll get 0.4 all done and tested by the end of next week. If I'm not, you'll probably have to wait another month before I'm done, since I will be starting an internship which will probably take up most of my waking hours. But of course, if a really annoying bug is found, i'll release another bugfix. Though all seems good right now, it seems the major(ish) bugs that snuck in to 0.33 have all been found and gently showed the door (fingers crossed:D) Nah no need for any apologies. This is a very complicated plugin, and there is somewhat of a learning curve. It took the greater part of the community almost a week to get their heads around the core concepts. And the greater part of this community are awesomely intelligent people.

RemoteCommand will always require crew, since it doesn't really make sense if it where otherwise. You could just have all your unmanned vessels be command vessels and they wouldn't need any relay network at all. A very important point in this plugin is that unmanned craft should not be able to control themselves. In RemoteTech there always needs to be kerbals at the controls, even if the controls are at a command station millions of km away. RemoteTech is not just about letting you do cool things, but also to make it extra challenging to do those cool things. But if all you want is debris activation, completely autonomous vessels and none of the relay network stuff, then I'd recommend ditching RemoteTech and in stead only using MechJeb. Once debris activation is fixed in the next update of MechJeb it should work just as well as my debris activation, if not better. Actually (barring the currently very bugged debris activation in MechJeb) the only advantage in using RemoteTech for debris activation in stead of MechJeb is the addition of attitude control via RemoteSAS. And unless r4m0n does something very very complicated for the next update, RemoteSAS should work just fine with MechJeb as well, once MechJeb debris activation is up and running again.

If you really don't like delays but still like the other parts of RemoteTech, I would recommend that you go into the PluginData/remotetech folder, open the settings file in any text editor and setting the speed of light to a very high number. That way you won't have any noticable delay. It's a cheaty thing to do, but if it makes the game more fun for you it's all good

That's because the modified cart plugin included in this plugin is 1.32, not 1.33. I didn't think that the parts included in Cart v1.33 would be incompatible with the previous version, though it does make a lot of sense in retrospekt. For now you'll have to chose between Cart v1.33 with partial support for RemoteTech (going forward/backward and right/left is delayed, everything else is not) or Cart v1.32 with full support. Thank's for the heads up regarding part incompatability though. I'll add a notice about it in the OP.

If you could find a fix for this it would be pure awesome! I found the same issue in SAS on Debris. After forcing SAS to apply torque, it would act as if the center of gravity was still where it was before decouple. The SAS PID would run on killRot, but the error correction values would be way off.

Here is v0.34, a small bugfix-update to 0.33. But with it comes something extra: Changelog: fixed an annoying issue where "List Comsats" could lag the game under certain situations. Beefed up the link strength of all RemoteTech parts except antennae. (thanks to CrashnBurn for suggesting this) They should not be nearly as wobbly any more and should wobble exactly as much as the stock 1m fuel tank. Added two extra parts; Satellite Dish - Interplanetary class and Dipole Antenna. Both where awesomely made by rkman. The new dish has a range of 500 million km, enough to reach from Kerbol to the equivalent of the orbit of pluto. It is however also a lot bigger and weighs a lot more. The new antenna is purely aesthetic, it's a lot smaller and, I think, a cool realisticy adittion to the standard antenna. With the new dish and sudden possibility of deep space missions, I've found that "with great distance come great bugs". Nothing big though. The only two bugs i saw was a renderdistance of the blue line that did not scale properly, causing the line to dissapear at great distances from the camera. I also saw a wierd bug where range calculations are completely ignored at very high time acceleration. They kick back in the moment you return to normal time though, so it doesn't affect gameplay. Finding fixes for these minor issues will be a big challenge, and a whole new area of research in this project. I'm quite looking forward to that . But probably the fixes will not be released until the next major update (Where a lot of extra features will be added and RT will finally go to 0.4). -JDP

when i select, in relay setting, Point at... the satellite is supposed to turn at the selected object? Sadly no. My parts aren't that fancy. It seems that you use a custom dish. Have you edited the config to make it RemoteTech? Having the dishes physically pointing in a direction would require some PowerTech integration and parts that are a lot more complex. (edit) On closer inspection it looks like you have a RemoteCommand on your satellite. You really don't need that, you just need RemoteControl if you want it to be a remote controlled comsat. RemoteCommand is only for bigger command stations with crew to staff the station (by default 5 crew members are needed).

A very good idea, I actually tried something like that in the early days of writing the activation code. Sadly it didn't work. The vessel would cease to exist the moment i tried to fiddle with parent/child settings. Which i guess I should also have expected. Parent/child assigning is AFAIK only ever meant to be done in the VAB. parent/child is assigned outward from the Command Pod (in a normal vessel the Command Pod would always be the topmost parent). So as long as you dont put your engine directly on a decoupler it should always work. the topmost parent in the Debris would be whatever part was attached to the decoupler. That's a somewhat more complex one, since it involves more plugins than just mine. The bug might be with my plugin, but it could also be with one of the other ones that the ion engine relies on. It might also be caused by the engines being decoupled while they are powered though. As a safety measure, I always throttle completely down before i decouple RemoteTech debris. Try that a couple of times, and if you still get the bug, there might be somewhat of a compatability issue between RT and MechJeb Engines and/or whatever power plugin runs the rest of the ion engine. Curious. I've never had that happen in testing before (attitude control completely not working after decouple). The way I implement attitude control in debris is so simple that the only reason for it failing AFAIK is if the debris somehow thinks it's still attached to the main vessel. If you would like to troubleshoot, you could try launching the same vessel that has the problem now, with just MechJeb modules and RemoteSAS, no antennae or signal processors at all. If the problem stops showing itself it would indicate that there somehow is an interaction between MechJeb debris activation and RemoteTech activation.