Jump to content

soranno

Members
  • Posts

    227
  • Joined

  • Last visited

Reputation

6 Neutral

Profile Information

  • About me
    Spacecraft Engineer
  1. 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.
  2. 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.
  3. 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)
  4. 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
  5. 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
  6. 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!
  7. 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
  8. 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.
  9. 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
  10. 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.
  11. 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!
  12. 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
  13. Thank you for the insights, I figured it was beyond the functions of MM but thank you for clearing it up for me
  14. 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?
  15. 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
×
×
  • Create New...