Galane

Something persists because when reloading a quicksave or resuming using the persistent file, the part that had control when KSP was quit still has control. Question is where is that data kept?

Video of an old attempt at this.

Put a couple of them and a small probe body on a small mono tank and it can do a Kerbin escape going straight up. (Fly monopropellant only to...) Whether or not any changes get made to those engines, I'd like to see fuel bar graphs for them like the other thrust engines have.

If you measure the settable limits from both sides of center and the problem is with the center slipping under strain, thus both settable limits slip the same direction... don't depend on an undependable position marker. How about setting each end limit measuring from the "physical" default end limit positions which should be hard coded in the parts somewhere? Re-zeroing the center setting could be done by either measuring from each default end limit or the zero could be set to the center of the settable limits by subtracting the "physical" limits from the set ones then splitting the difference. A similar method should work to re-set pivot axes that have been pulled out of place. The parts start out with that in a defined relative location, so it should be known where the pivot must be in relation to at least two, preferably three, other known and fixed points on the part. If that relationship does not match what the numbers say it should, move it back. Think of it like a CNC machine tool. There's two ways to control the positions. Open loop and closed loop. With open loop the direction commands are sent out and you have to expect that no immovable obstacle is in the way or that the material isn't so tough that the motors are stalled. When that happens, commands get "lost" and the machine operates with things out of the expected position until it is re-zeroed. With closed loop there is feedback from rotary encoders, linear scales or other sensors so the controller always knows exactly where the machine parts are. If something gets in the way, the controller can stop before something breaks. If the feed rate bogs it down the controller knows it and will will either just keep commanding the move until the cut is finished or it'll slow down to not stress the machine. Coming up with a way to close the control loop on Infernal Robotics should fix all the issues with slipping limits and axes getting pulled out of place.

Having four tweakable options for fuel crossfeed would be most useful on these mounts. 1. No crossfeed at all. 2. Outward only. 3. Inward only. 4. Balanced flow, in and out, just like connecting an inward and an outward flowing fuel pipe so that engines and tanks on this mount will share fuel with engines on the tank the mount is attached to. #4. Would make mounting multiple LV30 engines around a Kerbodyne tank a simple job. Attach the mounts, set the crossfeed to option 4, attach the engines and yer done. This option would essentially disable the decoupler for autopilots that look for a stage to run dry before triggering decouplers attached to those parts - while still allowing for manual space bar triggering. #4. Would only be needed if you have tanks on this mount. With just engines you'd need option #2. It would require a plugin to be "context sensitive" so that if only an engine is attached itwould default to #2. If only a tank is attached it would default to #3. #1 and #4 only become useful if a tank *and* an engine are on the mount. Without such a plugin, the setting will have to be done manually and it will be possible to set it the wrong way.

That does nothing for Infernal Robotics.

Thus the challenge. Could you cancel out Kerbin's orbital velocity and let Kerbol's gravity pull you in to an intercept with Eve or Moho then get into a retrograde orbit around them? Of course to do that you'd have to thrust the ship prograde to catch the planet.

Mistress Mary, quite contrary. How does your orbit go? Retrograde! Simple rules. One point for each body visited and orbited. One point for each body landed on and returned from. All orbits, including takeoff from Kerbin, must be retrograde. Any mods you want except for infinite fuel mods or anything that warps like hyperedit or interstellar or extraplanetary launchpads. MechJeb's Ascent Guidance isn't real good for this because when set to go West it first angles towards the East then wastes a ton of fuel twisting the trajectory around. You may also find MechJeb difficult to work with getting into and out of orbit, it seems to prefer doing everything in a prograde fashion. I expect such a mission to use quite a bit more fuel since you're going against the usual gravity slingshot assists and velocity assists taking off prograde from rotating planets and moons.

Here is a short and simple file from a nearly vanilla KSP. http://m.uploadedit.com/b039/1410677933105.txt The only mods installed are KAS, MechJeb, HyperEdit and Blizzy's toolbar. The Clampotron shown as docker has control from here set and I never set that on the dockee port - but I can't see what designates which port has control. If control is set to an RGU, command pod, probe body or other part with Command capability, what designates that attribute? I have another save on a much modded install that has apparently become 'confused' and managed to get at least two command/control parts with control from here active and/or SASS active. Right clicking any of the docking ports or RGUs (there are no command pods or probe bodies on it) and setting Control From Here has no effect. SASS shows as being OFF when I right click on every port and RGU and set control to it. If I can edit the quicksave and save this, that will be very nice.

I went back to build 318 and the problem of more than one part having control from here and/or SASS active is still there. Deleted all the mechjeb_settings files, didn't change anything. Here's the quicksave http://m.uploadedit.com/b039/1410676688707.txt What do I look for in there to edit so that just one part of the ship has control and only one or none has SASS active? I did all the moving parts around with build 318, not a problem until I updated MechJeb to 319 to separate the assembled lander to land on and return from Gilly to see if I had it worked out so Rendezvous Autopilot could do its job. Seems to be somewhat like the one old build where it wasn't setting *any* part to be in control upon undocking and the craft would just wibble around uncontrollably until a command or control part was set by the user. Edit: Now this is odd. Started a fresh save, fresh launch. Moved ONE part of the ship from one port to another and build 318 has it fighting itself. When it's doing this and I use Hyperedit to change the orbit even a tiny bit the ship's pieces get sent off in all directions at high speed. Edit Two: Tried build 317 tonight and this time this massive, very sluggish ship that requires many RCS thrusters to get it to turn went into a high speed tumble (with RCS off) after decoupling the VAB assembled docking port node then docking it to a different port. Hit F9 and tried it again. Got the first piece moved and all seemed OK until I decoupled node on the second piece. The craft began to wobble back and forth at ever increasing speed. No engines active, RCS off, SASS off on both prior to the docking - yet somewhere it appears to be getting conflicting command or control inputs. Editish: Solved it! Some suddenly screwy behavior from Quantum Struts mounted on Oscar-B fuel tanks. Took some shooting of troubles to figure that out because when I came up with this design they had worked there without a problem.

Andy Wilkinson "Toadicus" last worked on it 2014-07-17 according to the last entry on the git with the source. Oh, same person doing Tweakable Eveyrthing, Galaxy Generator, Adaptive Docking Node and more. Last activity was three weeks ago. KAS support was also added.

Ah, so that's why the VTOL engine mounts often wouldn't return to exactly center. Sort of like having end stops with loose mounting bolts. Hit them hard and they creep out of position.

If you're taking requests/ideas for parts, I have a couple. In my additions to PolecatEZ's ReStock, I've made a crude, multi engine interstage adapter for the Thundermax tanks. What would be very nice is a good looking one that has a fairing. I would make a scaled up Kerbodyne decoupler cfg to go with it. The even larger Thundermaximus fuel tanks could also benefit from a multi engine interstage adapter. The other part is a really tiny decoupler that just surface attaches but nothing can be attached to it. It should have as close to zero mass and drag as possible while not being treated as "massless" in flight like the little girder "struts". When activated it should self destruct so it leave no debris. I quite often build rockets with engines I want to go up unlit then activate later, without having some parts drop off. Separatrons are great for kicking things out of orbit, but if mounted without a stack or radial decoupler icon in their stage, MechJeb's Ascent Guidance will ignite them out of order. Auto staging can be disabled and staging run manually, which strictly obeys the displayed stack order. Auto staging can be set to stop below the level without a decoupler, but that's not ideal if there are higher stages that need to be auto triggered - such as having part of the ship come off to land on another body then lift back to orbit to deliver a payload then be deorbited with sepratrons. Without an extra decoupler in there, MechJeb will burn the deorbit engines during liftoff of the lander. The only way to have fully automatic staging with Ascent Guidance that will stick to the same order as doing it manually is to add "throwaway" decouplers solely to put at least one in every level of the stack. Thus the desire for a lightweight, self destructing "dumbcoupler" that has the sole function of acting as a marker/trigger for use with MechJeb's Ascent Guidance. Or more correctly to *block* it from undesired operation.

I've a problem with SASS in build 319 I've never had before when working with docking and undocking several parts of a ship. When I set control from here on a docking port or RGU or other such part, SASS is not letting go of control on previous docking ports that had control when they docked to the main assembly. Whichever part has control is not overriding all other SASS settings like it did with previous builds. My latest lander assembly test around Gilly is paralyzed because on the lander the docking ports are all fighting one another for control so it's trying to rip itself apart. Didn't happen with build 318 and previous. The log http://m.uploadedit.com/b039/1410590424249.txt (this site allows txt files up to five megabytes and auto expires them in 30 days)

Yup. That should do the job. And now you know what George Lucas stole was inspired by for the design of R2-D2.

Or just shut off RCS completely with R. I need to go see if there's another MechJeb update. The last one I downloaded has a problem with SASS where it's not relinquishing control to the ONE part set as control from here.

As a substiture for the MechJeb Eye Pod I'd like to see one made to look like the head of Analyzer from Space Battleship Yamato. (AKA Star Blazers, as it was much modified into for US broadcast.) From the 1974 anime https://www.youtube.com/watch?v=QzdnvUyYdEs From the 2010 movie. A major character in the anime, he got less than a minute of screen time in the live action movie. At least he got the same voice actor who was in the anime.

That's why I'm repurposing two of the upper stage side boosters for the lander. I'm going to try a way to get rid of the big engines on them to make it more nimble at turning because MechJeb's rendezvous autopilot overcontrols it with RCS so it wobbles back and forth a lot when full instead of smoothly rotating and stopping on the correct heading.

Someone did Quantum Struts Continued but the thread got nuked in the last forum changes. I should have the download on my PC. Edit: I have it, whom can I toss it to for uploading somewhere? The last person to touch it only patched some minor thing, possibly just to remove the version check. Works fine in .24.2

Just tried. Came back with log error. Yet there it is to download. It needs Hooligan Labs airships, Quantum struts and ReStock Reloaded, and the last release of the old Stretchy Tanks/SRB.

My lander uses 13 T800 tanks, one T400, six aerospikes, one LV45, one LV909, a 2 man can - and six of the large Hooligan Labs inflatable parachutes. Chutes for going down are 2 radials, 2 drogue, 4 large. Set turn start to 35K, turn end 100K, 0 degrees, shape 52%. Inflate the bags, rise to around 24K. Engage Ascent Guidance at no less than 100m/sec then dump the airbags before starting the turn. It also has the top mount chutes and landing gear set up to jettison. I even have a Kerbal rip the ladder off and drop it before liftoff. Even with Stock Drag Fix the lander needs no more than a 50% fuel load to land. I have a kethane mining rover (lands with no chutes and jettisons engines and tanks after touchdown) to refuel with a KAS hookup. Might be possible to put that capability on the bottom of the lander as a stage to leave behind.

You don't want to use Hyperedit to specify an orbit that will be below ground level at the spawn point. I kinda temporarily blew up Kerbin last night then couldn't get to VAB or even exit KSP.

Yup, for testing, testing and more testing. Still in R&D on my Eve mission. I know the ship design can get there and back. Just need to do a few more alterations to save some weight and parts and refine the latest Gilly lander so MechJeb can successfully fly it with full tanks.

Final section of the Duna ship coming in to dock. The T800 tanks and engines on the upper section were never used. They were a leftover from a fuel depot launcher this was based on. Duna5 by g_alan_e, on Flickr Same basic design used for a planned Eve mission. Shot taken before docking the second pair of boosters. Mission never flown due to PC being too wimpy. Also obsoleted by .24.x part mass changes making the wee little Gilly lander unbalanced. Would have been a failure anyway due to the large number of trips up and down that small lander would have needed to refuel the transfer ship. The Eve lander and rovers, one for mining Kethane and one for converting it, worked just fine in testing. screenshot8 by g_alan_e, on Flickr First of my ships to actually make an un-assisted trip to Eve! Again with the docked in orbit side boosters, this time all four brought up in a single launch on a carrier, docked to the top end then each decoupled and side docked. Deleted the drilling rover by installing two small drills on the converting rover, which got replaced by a less complex and lighter (yet larger than the first version) Gilly lander. All worked well but the Gilly lander was still too small to refuel in a decent amount of time, and the lack of the ability to carry things atop the side boosters caused some other compromises. Save was abandoned without returning to Kerbin because the core+can had already been tested to be able to return. Eve-test-flight by g_alan_e, on Flickr Further changes are in-progress. I've redesigned it so the assembled core, side boosters and Eve rover go up in a single launch, along with components to convert two of the side boosters into a Gilly lander able to hold a combined 30400 units of fuel and oxidizer in two large Kerbodyne tanks and one Rockomax X16. I need to install a method of jetissoning or destroying or knocking off the Kerbodyne engines because their mass makes it difficult for Rendezvous Autopilot to steer when full. Since the rover no longer needs to dock, I removed all its RCS thrusters and mono tanks, then installed two of the small, spherical ones so it has a place for mono to go while converting/transferring. I think I'll also do away with the big Kethane tank too for a smaller one for mass and length savings. I've also come up with a way (still unbuilt) to eliminate the need to undock the Eve lander in order to remove Gilly lander parts from the middle of the ship. The mission plan has also been changed to enter Gilly orbit first, assemble the lander and refuel before going to Eve, then stop at Gilly again on the way back. No changes will be made to the manned Eve lander since it works just fine. None of these would have been possible without Kerbal Joint Reinforcement and Quantum Struts. Now there's Stock Drag Fix that fixes the "feature" where KSP adds the mass of fuel tank contents in its drag calculations. Since how much fuel real rockets have in their tanks has zero effect on aerodynamic drag, SDF removes that from the stock KSP drag model. Note, SDF not for use with FAR, NEAR or any other mod that messes with drag or other aero, except for RSS - but with *only* RSS, not RSS plus any other drag altering mod. The main thing SDF does is get your rockets to orbit using quite a bit less fuel. It will also alter how air/space planes fly so their balance may need changed.

You need to download the latest dev version, link is below the link to the last official release. And if you're doing Science or Career mode you'll need to do more science to unlock all of MechJeb - or edit its cfg to fully unlock it.