soranno

Yes, on my next flight up I forgot about the tests and carried the damn separators with me to my station. I`ll take a copy to test if/when you have something.

Hi again, another interesting observed behaviour for your attention, if you please Another decoupler one, and I would imagine given the circumstances of this, limited to decouplers I had a couple of contracts to test stack separators on sub orbital trajectories, so I put them on the nose of my rocket in order to stage them as I ascended. They all failed, and just exploded (not a complaint ) but more crucial is that the activation, while all contract conditions were green, was seemingly cancelled by the failure, and the contract went incomplete. It would seem that the part failing is just as valid a test result as anything else, haha, so it`s an unfortunate behaviour that the two systems are conflicting in this manner.

I wasn`t aware it could even happen in time warp when on rails, but I certainly don`t support disallowing the failures under any conditions. My space agency engineers have indeed come to the conclusion that automated vessels should not be interacted with unless absolutely necessary for fear of failures... also my engineers suffer nightmares of the day you figure out how to kill a part on an unfocussed ship. It had not escaped me that the majority of failures occur very early in part life, most of the failures I have experienced within the first 10 minutes of flight. However, it is reasonable to suggest the first 10 minutes of flight are potentially among the most severe and damaging of the journey (unless you plan to land on eve or something)

I assume that`s an issue limited to monoprop, and not other rocket fuel? Any ideas what caused the tank failure while in time warp? I had been quickly going back and forth between 100x and 1000x, seemingly generated some forces on the ship somehow

aHA! Nice catch! It is just the one tank, and the leak is draining all tanks. Disabling the crossfeed of the one tank does not stop the leaking, all the other healthy tanks continue to drain fuel into (and out of) the leaking tank (thus creating the illusion they were all leaking). In order to stop the leak all the vessel`s monoprop tanks must have their fuel flow disabled

That reminds me, although I had intended to mention it many times and forgot, the rocket parts container doesn`t have any entry in the tech tree. Easy enough to put it in somewhere, but maybe that being added at source might clear up that point with a few users. So, I experienced my first ever tank failures (was there any change made to those in the recent update?) It was quite an interesting failure.. on an unmanned com satellite (naturally) with 4 round monoprop tanks, and one 50 unit stack monoprop tank. I was in time warp, moving between 100x and 1000x, when suddenly the warp was terminated and all 5 tanks failed at exactly the same moment I was quite taken aback, as you might imagine. One of my stream viewers saw fit to suggest the `ruskies` were testing their space rifles. However, shutting off the fuel flow stopped the leaks. After that I throttled up the engines and used the fuel flow control for the stack tank like a throttle control. You can see the moment of failure at the start of this video clip ( and how I used the tank flow control to stop the leaks) http://www.twitch.tv/hoshizora/c/4844042 (language warning, sorry just a bit at the start) About the decouplers. I think it`s fair to say I see 50% failure on stack decouplers of all kinds. That said, they have the failsafe of just spamming decouple until they explode so it doesn`t really bother me. I just live in fear of engine failure on landing but the engines I use for landings have proven very reliable (24s and 48s, also 909) Just stay away from me with those 45s. I don`t care if it`s buy one get one free, or double points Tuesday, nothing doing!

Well done on the update, and thank you for continuing support of this great mod. I have managed to recreate the failures in question in test conditions and could successfully repair them, however it seems that either because the ships were launched before the update, or the failures occurred before the update, but those ships affected by the failures in service remain unrepairable ~ perhaps unavoidable. Anyway, new ships are unaffected. I might just edit the persistence file to remove the failure from them this time, and let them naturally fail again Edit: My attempt to edit the persistence file was successful, I was able to activate the repair altimeter button in the gui, and then make the repair in game I`m reminded of another issue, albeit one that I think is unavoidable. When you board a pod while carrying rocket parts, those parts are lost forever, as naturally enough there is no place in the pod for those parts to go. Maybe the simplest option is a warning upon trying to board the pod that carried parts will be lost? Not really sure how helpful or otherwise my answers are being just hoping to support as best I can without being a pest, hah! But by all means if there was anything else you could use my input on

It is bizarre, but perhaps I was just a victim of chance using 45s, but I was getting failures every flight on a second or third ignition. Comparing that with other engines, I`ve still never seen a 909 failure (other than the odd one after I had already dropped the engine) and using multiple 24-77s on one ship, and over dozens of restarts have seen only one or two failures of single engines. I will test some 45s into the ground and get some answers The thrust gauge, each occasion was similar in ciscumstance, and 75% of undocks have seen the failure. On all occasions there was one command pod on each vessel, thus two combined separating into one each. The failure occurs in the pod of the ship I have undocked from. That is to say, I`ve undocked, and receive the failure popup regarding the pod on the other vessel. Each time I have been undocking with a mk1-2 3 man pod, however the failing pods have been both mk1-2 and mk1 lander cans. Looking at the ship in the VAB, I can also see that there is an advanced inline stabilizer between the pod and docking port. Perhaps that has been playing a part. EDIT, after extensive testing at the launchpad, under hacked gravity conditions I must revise the estimate of failure rate to 40%, noting that in a sample of about 100 tests there was one occasion of 22 consecutive successful undocks. Testing also essentially confirmed the role of the advanced inline stabilizer in the failure, the ship design altered to remove that part could not replicate the failure in testing. The failure rate therefore doesn`t seem to be too much of an issue, however the condition persist that the failure is not repairable As to the bashing decoupler episode, on this occasion the decoupler had not been activated, but was part of a vessel that had no command parts at the time, and rather than exploding, the bash triggered a standard separation. However, I have since tested a bit on the launchpad, and following both successful decouplings, and part failures, the bash decoupler option is still available, and spamming it causes an explosion.

Hello again, I`ve come upon another issue I`d like to check with you. Incidentally, I`ve had very positive experiences with engine failurs (what an odd thought) since moving away from using lv-t45s, with apparently nice balance in the ignitor failures of mainsale, skippers and the smallers 48s and such. But anyway, having some issues with the thrust gauges becoming stuck in pods. This has occured several times now upon the act of undocking. Is there a specific trigger making that failure prone to occur on undock? Be that the case or not, the failure is not repairable! Upon evaing a kerbal over there with spare parts all options appear in the right click menu except for the one to repair the broken gauge. My Kerbals will soldier on to their Mun landing without a functioning gauge anyway, brave guys, but I assume this is unintended and should be repairable. If there is any further information I can supply to assist in correcting this issue, please let me know Also, while I think of it, this mod`s `Bash decoupler` functionality just saved my very expensive science ship from an unrelated docking port clipping error! With a spent stage clinging to my ship, and unable to control the decoupler anymore, it was without doubt that ability that saved the day Unexpected bonus

Not a bug, but an unintended (I think) side effect of the return of 50% throttle on loading a ship on the launchpad. The problem is, that if you set the throttle to 0% and then timewarp on the launchpad, the throttle resets to 50% after returning to normal speed. If you have any engine active at that time it starts burning. It seems to me unintended that this should be so, nevertheless I suggest that changes to the throttle persist through timewarping on the launchpad to avoid this issue.

Worked pretty well, even with the increments so small that the rotation of the planet was too quick for the rotation of the parts and with keys assigned to controlling the rotating parts, could freely operate the zoom and other camera controls with the mouse while tracking the objects manually all this said and done, you are still way better off to put the thing in orbit, hah!

I thought the free moving parts and the telescope`s own gyro might be the way to go too, but alternatively you can use the powered IR parts, and use the servo control to reduce movement speed to extremely small increments. It defaults to 1, and you can set it to anything, 0.0001 if you want. and you can make the change on the fly as you need it

Thank you for the insights, I figured it was beyond the functions of MM but thank you for clearing it up for me

Could any frequenter of this thread offer me some advice? I have.. through a serious of unconnected events, seen fit to use KAS to make separatrons grabble so EVA kerbals can carry them around, and when necessary attach them to things (including kerbals themselves) The problem is, that while a kerbal can activate a separatron that is attached to himself (and does so with maniacal enthusiasm) they cannot activate one that is attached to something else. I`ve been trying to find a possible entry to a modulemanager cfg file that might make it possible for the kerbal to activate a sepmotor attached to a part. Does anyone have any insight into what might work?

Thanks kalor, I`m looking through some of those things at the moment. I had thought to start with things like solar panels and antennas that evas can activate, but so far each one seems to be using a unique module for their actions. I`ll look into the link ability parts right away

I wonder if the fine people of this thread could offer me some advice... I have been having plentiful fun recently adding KAS grab function to parts using module manager, most notably the 1x1 structural panels (I`m going to build me a Mun house) anyway.. the most recent and promising one has been the sepratron. Making this little beast grabbable was a great move.. and I also decided to make them attachable to eva (i.e. onto kerbals) much hilarity ensued. Anyway the question Would anyone have an insight into what cfg entry one might have to make, to enable an EVA kerbal to activate a sepratron (one that is not attached to said Kerbal) Kerbals can control a sepmotor that is attached to them directly, but not one that is attached to another part object. Any advice is appreciated!

I can only assume it is mentioned in one of the last pages, but I can find it in search I think you missed a zero in the part costs for the 62.5cm inline radiator , I just got one hell of a surprise from my accountant

I love the idea then of electrical failures, and linking failures in cause and effect. Perhaps of the kind that, one failure doesn`t critically affect ship function, and so you may continue , however it significantly increases the chance of a subsequent failure if left unattended for too long. Also, I am very much in favour of the backup modules suggestion, for exactly the reason given, probe controlled ships I will also drop a link to a twitch stream highlight from a short time ago, showcasing the very two failures I was talking about earlier, and the wonderful enhancement to gameplay that has been this mod. I have noted that it is only the 45 engine that has failed for me this easily. No other engine has done so, in spite of a dozen or more ignitions of multiple engines. http://www.twitch.tv/hoshizora/c/4771898 (colourful use of language advisory) I did get one strange behaviour though. On descent to minmus I had a drop stage with a 909 engine under my lander, which I let loose about 300m up (if you can believe it, the decoupler worked) anyway, when I throttled up on the next stage engines I got a failure message for the 909 I had just dropped. Furthermore, at the time I didn{t realise it was the 909, and spent several seconds scanning my ship for which engine failed, to find they were all functioning, and so maybe the duration of the failure message could be extended, or perhaps highlighting the name of the part affected could make for easier acknowledgement of the message.

Regarding the decoupler, perhaps an alternate solution is to `manually separate` rather than repair. Similar to kicking the engine to get it working Engine failing has been on a second ignition, first staging while throttled, cut power then with x key, and then throttling up with shift key. I`ll do my best to gauge balance as I continue. Looking forward to the next unexpected failure, although the prospect of an engine failure during a landing cycle terrifies me!

I`ll raise a couple of my observed balance issues, mainly with the lv-t45 engine and the first stack decoupler, the name of which I have forgotten, the 1.25m one first on the decoupler, I`m finding that it fails almost as often as it works. A bit hard to balance failure on a part that has no longevity anyway, it only has to do its job once, but anyway my failures are always of the same pattern. I stage to separate, or rightclick to decouple, and nothing happens, no messages or anything. So I then proceed to spam the right-click menu decouple button 10 or 15 times, at which point the decoupler explodes and I get a failure message about improperly rigged explosives, I think. So it`s odd.. I expect it to fail rather than work, but at the same time it works everytime because I just have to spam that button until it explodes, thus separating what it was supposed to . The other is the lv-45 engine, I`ve had several occasions of it failing on launch, which is not a bad thing in and of itself (well, it`s pretty bad for the kerbal in the pod), but it seems a bit too frequent for the engine`s first service. It is always the ignition coil, and more often than not on the second throttle up of the engine`s lifetime. My experience of gameplay under these conditions is of course limited, and I still can`t even say for sure what is too much. For sure the engine failures have led to some comical moments of panicked kerbals evaing over the kick the engine 12 times until it works again It seems to me, it is also against the spirit of the mod for one to be certain of a part working even the first time. Space shuttles had false starts, and saturnV`s had engine failures on ascent. Enjoying the gameplay at the moment however, and I`ll give what feedback I can going forward

depends on the big two really, landing on eve and tylo. Everything else is infinitely withing range of 180 parts

EVA in low atmosphere in valiant attempt to repack a parachute.. He may not have made it back into the cabin... but BY GOD DID HE REPACK THAT CHUTE! So long Jeb

ninja`d by the man himself. Thanks for the quick update

Dare to believe! Download has begun

you also have the option of freely rotating parts in the infernal robotics mod