ctbram

Well kip I have pretty much narrowed it down to the x-large universal as the problem or it's interaction with the 1.3 vers of the ADN mod. But there are still a lot of other variables that could be affecting it and I am no mod expert so this is just a "guess". I have not tried removing all other mods. But here is what I did. My transfer ship has a x-large universal at the front and a KW 3.75 at the back. Mostly there give me a place to add KSPI radiators. I was too tired last night to flip the ship around and try to dock the other end but I did that just now and the KW 3.75 docks to the Clamp-o-Tron SR as you would expect - the magnetic force kicks in around 1m and they connect the instant they made contact. So now I don't know what to do. You can see from the screen shot that my design has three x-large universals at the front. They thinner and more importantly lighter. This ship is 290t before I attached the science module (shown attached to the wrong end of the ship). Any thoughts on how I can proceed or is there anything I can post or send to help determine the problem? I have the latest universal docking adapter mod (kipEng 9.3.0) as well as the kipeng hubs installed and I reinstalled them last night being sure to replace the adaptivedockingnode mod with the latest 1.3 version. I can't really reduce the variables much using this ship as it is dependent on a good number of other mods (aies, kw, kspi, kosmos, kspx, sdhi, novapunch, b9) and those are only the parts mods. I'd have to go sandbox and build a new vanilla game folder but I am not really sure how to test much beyond what I have done by flipping the ship and attaching to the kw at the other end which shows docking and (adpativedockingnod 1.3) is working with the KW and COT SR.

I can't get them to dock regardless of speed or precision. I have a screen shot of them approaching at 0.1 m/s and after they meet the speed is nulled out and they are literally sitting exactly aligned (you can see perfect alignment from the navyfish docking camera) and yet they will not attach. I don't know if it's the x-large universal or the clamp-o-tron. I was to tired and frustrated to try ny experimenting last night after spending 5 plus hours trying to get the two parts docked. I burned through 1000 units of mono propellant trying every way I could to get them to connect.

By replacing the AdaptiveDockingNode mod in the with the 1.3 version I was able to get the KW 3.75m to dock with a clamp-o-tron sr the other day. But I would prefer to use your x-large universal as it's thinner which is what I need for this ship. However, I am having no luck at all getting a x-Large universal to dock with a clamp-o-tron sr. I get no magnetic attraction and regardless of how precisely I connect or what speed they just bounce off each other. I am quite frustrated as I must have spent 5-hours last night trying to get my science module connected to my DT-Vista transfer core and finally had to give up after running through 1000 units of monoprop!

Having trouble docking. I have universal docking v9.3.0 and adaptive Docking Node v1.3. I have a Clamp-o-Tron Sr. and a X-Large universal docking port and they slam into each other dead square in the center and simply refuse to connect! There is no magnetic effect. Nothing they just refuse to connect. I have been at it now for over 5 hours. I have tried everything. I have Mechjeb 2 b253 the latest jenkins build and although I generally do not use the docking AP I tried that as well and still no joy! I just changed the KW 3.75 big clunky docking port for the xlarge universal so this is the first time I am trying this combo. Is there something I am doing wrong? I am getting kind of frustrated. Is there any info I can give to help sort out why these docking ports are refusing to connect???

This is completely untrue! I did not instruct the chute to deploy. The stage with the chute was clearly 5 stages away from the launch stage! The chute was deploying or attempting to be deployed as the ship was being loaded on the pad! You could even see a message pop up just before the ship loaded and before the physics engine loaded. I did nothing to deploy the chute myself. I don't consider 8 mods to be "a hoard". Especially since at the time the only changes I thought I had made was updating Realchutes and SDHI (which accounts for 25% of all my mods) so naturally they were the only two things that I thought could have been causing the issue. I said I was sorry that I did not recall installing the universal docking system. I apologized and I drove the issue to ground and posted the results for everyone's benefit! You talk about crossing lines! I don't need to be lectured to by you. If you don't want to accept an apology then fine I don't really care.

I went to post at the kip Engineering universal docking port forum and apparently they had already discovered the compatibility issue with SDHI. There was an updated AdaptiveDockingNode 1.2 mod which is in my link below. I have confirmed it resolves the deploy on craft load to the launch pad issue. However, be aware that there still seems to be some kind of issue with incompatible docking port combinations between universal docking ports and stock. Here is a link http://forum.kerbalspaceprogram.com/threads/73005-0-23-5-Kip-Engineering-NEW%21-Adaptive-Docking-Node-by-Toadicus-Fix-%2829th-Apr-2014%29?p=1140125&viewfull=1#post1140125

okay update guys - I installed the updated AdaptiveDockingNode 1.2 patch to univDockingPort and it fixed the chute deploy on craft load to the launch pad. But I see from another post that there might still be an issue with docking port type combinations so I will keep a watch on the this thread for updates. I will post an update over at the realchute forum as well.

ah thanks I was jsut about to post about the sdhi and realchute incompatibility. I was getting chute deployment on ship load to the pad and so I'd get the nastygram from shdi paradock about not being able to deploy the chute until negative vertical velocity. I will check the updated adaptivedockingnode and let you know if it fixes the problem. I will also update my post over on the realchute page. My last post identified adaptivedockingnode mod as the cause of the problem before I saw this post.

@Starwasher - I tried activating the engine via it's context menu pretty early on in trying to debug this and the chute still tried to deploy. I have found the apparent culprit (99.99999999% sure in fact) and I want to apologize. I am normally extremely methodical about adding mods and keeping track of things. However, I guess I was tired and installed several updates in addition to Realchute and SDHI and it turns out that one of those mods components is definitely causing the chutes to deploy on craft load. I installed a mod from kip engineering call universal docking ports -> http://forum.kerbalspaceprogram.com/threads/73005-0-23-5-Kip-Engineering-NEW!-Adaptive-Docking-Node-by-Toadicus-Fix-(29th-Apr-2014). The latest version comes with a mod called AdaptiveDockingNode and it is this mod that appears to be deploying chutes on craft load. You can even see the message about negative velocity flicker on the screen during the craft load to the launch pad. What I did to track it down was... 1. uninstalled realchute and sdhi and then reinstalled in my current game and when this failed to resolve the issue 2. I installed a completely vanilla 0.23.5 and only realchutes and sdhi and this did resolve the issue -> which implied the problem could be with a mod conflict so, 3. to eliminate the possibility of a corrupt persistant.sfs issue I went back to my career game and creates a new sandbox game and removed (deleted and pasted to a new folder) all my mods except realchute, sdhi, and the stock two mods. I created a ship and launched and the chutes not not deploy -> so it's was now likely to be a mod problem, so 4. I reinstalled about 1/3 of my mods, built and launched a ship and the chutes once again tried to deploy on launch (at this point I noticed the message flicker as the ship loaded to the pad) -> this really implied a mod issue so, 5. I systematically removed mods until the deploy on ship load stopped and drilled down to a single mod as the culprit -> AdaptiveDockingNode which is a sub mod of Universal Docking Ports from Kip Engineering at http://forum.kerbalspaceprogram.com/threads/73005-0-23-5-Kip-Engineering-NEW!-Adaptive-Docking-Node-by-Toadicus-Fix-(29th-Apr-2014). I will put a post on their forum page letting to make them aware of the bug. I am sorry to have blamed both the SDHI and the Realchutes authors for this bug. I hope this will be helpful to any others experiencing this chute deployment on craft load to the pad problem.

Very sorry did not mean to imply anything bad about either of you. I really appreciate both mods and just wanted to try and clearly document the issue as I am seeing it. I just made a camtasia vid of my entire launch sequence so you could actually see what I am seeing. I am hoping there will be an easy solution for this for as I said I really use both mods extensively. I have at least half a dozen crew transport ships that I switch between that are dependent on both mods. I apologize if I came across as being upset with either of you guys. paradock is a chute and something is instructing it to deploy. I don't know the inner workings or which mod is doing what. But I do know that it has nothing to do with the staging or whether the autoarm is set to true or false. I know the chute is starting deployed as I can set "no down" to true and as soon as I launch the chutes deploy. So although I do not know which mod is instructing the chute to deploy something has to be! I am going to create a vanilla game with just realchute and sdhi and verify that the paradock chute is starting in a deployed state with no other mods as instructed. I am going to use the same craft file. I also recorded an entire launch but I can't get to youtube right now to upload it. I am trying to provide as much information as I can guys. Making new game now. Doh! Obviously I cannot use the same craft file as it has lots of non-stock parts. So I made a ship consisting of the mk2 command module, the paradock, a 2.5m decoupler, a 2.5m reaction wheel, a grey 1/4 orange tank, and a skipper engine. I did not get the chute attempting to deploy at launch. Going back to existing career game and building the same ship as a test. Okay I build the same ship in my current career game - paradock, mk2 capsule, decoupler, tank, skipper and as soon as I press the space bar I get the warning that the chute has attempted to deploy and is awaiting negative vertical velocity. So from this I can deduce it's not craft file specific. Next I will uninstall sdhi and realchute completely and then reinstall them to see if something within either mod got corrupted. I guess the next step would be to remove all mods but sdhi and realchute in a copy of my current game and see if the problem goes away. If it does I'll do a binary addition of all the mods back to see if one is causing the issue.

I just checked the RealChutes_settings.cfg and AutoArm is set to false by default so this does not appear to be the cause of SDHI paradock thinking that the chute has been given the command to "deploy". I have not seen either source but I am guessing that realchute's pre-arm for pressure or altitude base auto deployment is being interpreted by paradock as the command to deploy?!?!? REALCHUTE_SETTINGS { //If the parachutes automatically arm or not when staged autoArm = False

It's not happening "for the majority" of other people because I suspect the majority are not using both REALCHUTE and SDHI. It is an incompatibility with SDHI and the way it is interpreting REALCHUTES pre-arming of the chutes to auto deploy based on pressure or altitude. I have no control over these settings in the AG editor for the SDHI paradock. Nor would anyone else using this mod and chute and all 100% of the people using this will have this problem unless something can be worked out between SDHI and REALCHUTE authors. You can see there is no realchute configuration gui in the ag editor for the SDHI paradock. But is was designed to work with realchute using it's own right click context menu. The SDHI author suggested turning off the auto-deploy in the realchutes .cfg file but I think gimping realchute is not the right answer! I'd rather see paradock fixed to work properly and NOT interpret "pre-arming" as "deploying". I mean can't the two guys cooperate and work out a way to make the paradock chutes just work properly with realchute as they were intended?

It's in the same place it was day before yesterday BEFORE I updated REALCHUTE and it was working fine without the annoying yellow text complaining about my chute being deployed at the time I launch!!!! Seriously I am not a rtard! I will post a screen shot of the staging. You will see it's WAY at the top of the stack. It appears this problem has two causes - one is from realchute which apparently "arms" that is to say "attempts to deploy" the parachute from the SDHI paradock the instant the ship loads and the other from SDHI where they automatically set the chute not to open unless you are falling. If I had to chose I'd say I would prefer my chute NOT try to deploy the instant I load my ship! However I can see having autodeploy based on pressure or altitude makes sense but that should not trigger sdhi or which ever mod to assume on chute is trying to "deploy" until it actually tries to friggin deploy! The chute is right where I need it to be in the staging stack! I have laucnhed this ship or some variation of it dozens of times without issue until I updated realchute and sdhi yesterday. and here is what I see from the instant I press the space bar until my mission is over and I am deorbiting the crew!!!

Okay can I get that again in laymen terms? Are you saying I can turnt he message off? That is all I care about other then the chutes actually working when I need them too of course. What do I have to change exactly in the .cfg file to make this annoying message be gone? I mean seriously, for the entire time you are flying your mission you have this really annoying text splattered in the center of your screen and can't make it go away! I was really quite mad. I was in the middle of a long mission and did not want to start over but that damn message was driving me insane!

ummm, okay next silly question. Why are my chutes armed before I am launching? I am using the sdhi paradock and I have seen some comments about them starting pre-deployed. Is this what is happening to me because it's damn annoying seeing that message on my screen for my entire mission and not be able to turn it off!!!! Well apparently I am seeing the same thing. Everyone of my crew transfer ships I have several US and RUSSIAN style crew transfer vehicles use the SDHI paradock and ever since I installed the update 1.1.0.1 yesterday from the instant I press laucnh I get a VERY ANNOYING message about "waiting for negative velocity" and the damn message cannot be turned off until I actually complete my ENTIRE mission and deorbiting!! It really ruins the game to have this gaudy yellow message constantly showing my vertical velocity for several hours spattered in the center of my damn screen!

I just installed the update and launched my crew transfer vehicle - what is with the "awaiting negative vertical velocity". it's kind of distracting. what is it for and can I please turn it off?

I am assuming that I no longer need the kerdlls.zip that was a fix for version 0.6.2.3?

Making these so they could be assembled in space would solve the huge problem of on orbit construction. Docking ports and KAS struts do not work!

[PROBLEM] using jenkins 239 career 0.23.5 - The latest update seems like the chasing the target node issue is now even worse. Seriously, I have a very small and nimble ship and I end up doing cartwheels at the end of every burn! I have to click the x to stop the burn with 2 or 3 dv left or I end up flipping and in at least three recent burns I got so far off that my burn bar actually started going back up and MJ deorbited me!!! [PROBLEM 2] - rendezvous AP still tries to kill me by setting optimum phasing orbits that go sub-orbital! I have to keep manually killing the AP. establishing a HIGHER orbit then give control back to MJ.

I want to thank everyone that helped to resolve the fusion reactor shutting down when I would leave the active ship and then come back. I salvaged my transfer stage in orbit by replacing the two DT Vista engine pods. I had four 1200Ec batteries in the core section so I just added two more on to each of the DT Vista pods on the sides for a total of 8x 1200Ec batteries and now the reactor continues running when I switch and return to the ship. Here is a shot of the fixed ship. The tug used to connect the engine module is still attached on the port side. You can see the four 1200Ec batteries on this side of the ship. I have to send a crew up to attach the KAS struts. The ship is still quite wobbly when I fire the engines. I wish someone would create a rigid docking system for orbital construction. I have a self imposed restriction on the max width of anything I put into orbit so unless I can dock side modules I cannot build anything like this on kerbin.

[Question] Using MJ jenkins 238 and career 0.23.5. I am constantly forgetting to turn off MJ when I dock. So as soon as I undock MJ remembers the last thing that was on and invariably spins the ship all out of control and of course I am five ]'s from getting to the ship that has gone rogue and mayhem ensues! My question is - Is there a way to tell ALL possible control points to have MJ OFF? Purge all or something so you don't have wild out of control undocks or I have even had instances where one MJ is trying to override others and I have to literally undock my entire ship to find the rogue MJ and then redock everything and remember to turn ALL MJ's off before actually making contact! This is really hard to do and a simple command option to PURGE ALL MJ UNITS setting them all to OFF would be such a useful thing.

[Question] I am using mechjeb jenkins 238 and career 0.23.5 and I have always wondered just what rcs balancer does? It has always confused me. When I turn it one it seems to cancel my ability to fire my RCS continuously. I have to keep tapping the keys and I just get little puffs and I eventually just turn it off. What I would like is the ability to stabilize unbalanced payload by providing a corrective force to prevent tumbling. Can anyone please explain the proper uses of the RCS balancer and what it's options (over drive, rcs control rotation, advanced, etc.) do?

Yes I agree and understand but it seems to have become amplified since build 236ish. I also added another comment about some odd rendezvous AP behavior

[COMMENT 1] using jenkins build 238 with 0.23.5 career and just wanted to mention that for the last couple builds burns are getting really squirrely at the end. My ships are doing summersalts trying to burn the last couple tenths of dv. [COMMENT 2] the rendezvous autopilot it trying to get better phasing orbits by lowering my orbits into the atmosphere (below 75km for kerbin). It nearly killed all three of my orange suits before I realized I had become suborbital!

Thanks that would be very nice. I have bumped heads with trying to make informed decisions when adding power to my ships with this mod before. But this one had me ready to go out a strangle a bunny rabbit! We really need critical information about power requirement BEFORE we build things and ship them to eeloo!