triffid_hunter

Actually there is - Maneuver nodes! First get into LKO, then set up a maneuver node that barely escapes Kerbin's SOI in the direction of kerbin's travel (for outer planets) or in reverse direction (for inner planets). Then create a second node in Kerbol's SOI to intercept the target's orbit, and drag it around to find your intercept. DO NOT EXECUTE THESE NODES - instead, wait until *kerbin itself* is at the position of the second node, then delete both nodes and construct a new one to burn straight from LKO. I made a video about it:

I think you should make a new forum thread, and let this one die

is it just me or does the download link in top post simply redirect back to this forum thread? tried in browser first, wget finds same conundrum:

From what I've seen, providing/filling fuel is implemented as an engine that consumes a negative quantity of fuel. I would expect you to no longer be able to receive fuel if you remove the engine module.

This is a bug with latest mechjeb release, seems to be fixed in mechjeb dev. If you go into attitude control you'll notice that many of the fields go to infinity when this happens. I can generally trigger it by decoupling a ship without a SAS wheel from a larger ship that does have a SAS wheel somewhere.

This mod is very understated, I'm surprised it's not more popular any chance we could optionally add RocketParts to the list of supplied resources?

excellent, glad to know it's not just me just a heads up, I did manage to trigger this in the VAB today, same sequence- holding a part for radial attach, then shift+c to go no_snap -> 90

Bug report! Problem: hard crash (Floating Point Exception) 1) go to SPH (doesn't seem to happen in VAB) 2) place command pod 3) select a radially mountable part 4) hover over command pod for radial placement 5) press shift+C a few times 6) at the transition from 'no snap' to '90°', KSP bombs, printing "Floating Point Exception" to terminal using linux 64 bit binary This behaviour isn't new in 0.23, but 0.23's massively faster load time has allowed me the patience to find a way to reliably reproduce it Other than this, works perfect in 0.23. may want to update thread title

GLC works great for me, that's what I've been using to record my videos. ps: congrats on inheriting EL, I'll grab this ver and test it soon

http://bugs.kerbalspaceprogram.com/issues/1230

I have, you want SURFACE_VELOCITY, BACK. would really love a couple of buttons for easy access to surface pro/retrograde While I'm at it, any chance of moving the aerobrake prediction out of landing autopilot? I think it makes sense to separate those and make aerobrake prediction available maybe one tier earlier in the tech tree

Keosync is at 2868km, a bit beyond the range of the starter omni antenna. Instead, put 6+ sats in a ring at at half-sync (1585km) so there's always one or two within range of KSC, and they're also within range of each other so signals can pass around the whole ring. Then you get no more blackouts in space near Kerbin. Then you can put something with an omni and a dish or two up at keosync (2868.7km). the omni will hit your half-sync ring, and the dish can point at Mun or Minmus maybe put a matching pair opposite KSC to keep Mun/Minmus online 24/7 (or is it 6/7 since Kerbin's day is 6 hours?) highly elliptical polar orbits become pretty useful around this point see my half-sync ring + two keosync sats - I set the pictured craft in an orbit with apo at 1585km and orbital period of 7/8 * 3h (2:37:30, peri about 1219km), then dropped off a sat every time I got to apo, then circularised the sat targeting an orbital period of exactly 3h (can see reading of 2:59:60.0 pictured) Yes, I placed every last one manually using only the orbital period readout from KER. MJ was used just for orientation and ascent autopilot, but not injection orbits or circularising since it's frankly not accurate enough. With a range of 2.5Mm you need >5.5 sats at half-sync for an unbroken, zero blackout ring. I went with 8 for redundancy and because I didn't know how accurately I could position them.

Bug report: If I radially attach things, then I can only attach the welded part to my rocket by the nodes that appear at the radial attachment points. Example (5x X200-16 tanks arranged in a 4-pointed star using I-beams): PART { name = Station-Core-4 module = Part author = UbioZurWeldingLtd rescaleFactor = 1 PhysicsSignificance = -1 node_stack_top4294427884 = 2.086163E-07,0.4687508,2.086163E-07,0,1,0,2 node_stack_bottom4294427884 = 2.086163E-07,-0.4687492,2.086163E-07,0,1,0,2 node_stack_top4294426714 = -3.13744,-8.813257E-07,-3.137441,0.7071068,4.768372E-07,0.7071069,0 node_stack_bottom4294426714 = -0.8771394,6.429071E-07,-0.8771399,-0.7071068,-4.768372E-07,-0.7071069,0 node_stack_top4294423812 = -3.987281,0.4687499,-3.987282,-7.787723E-08,1,3.225779E-08,2 node_stack_bottom4294423812 = -3.987281,-0.4687501,-3.987282,-7.787723E-08,1,3.225779E-08,2 node_stack_top4294426620 = -3.137441,-5.002676E-07,3.13744,0.7071068,2.384186E-07,-0.7071067,0 node_stack_bottom4294426620 = -0.8771402,2.618489E-07,0.8771398,-0.7071068,-2.384186E-07,0.7071067,0 node_stack_top4294423614 = -3.987282,0.4687499,3.987281,-5.034347E-08,1,-4.366267E-08,2 node_stack_bottom4294423614 = -3.987282,-0.4687501,3.987281,-5.034347E-08,1,-4.366267E-08,2 node_stack_top4294426596 = 3.137441,-8.813257E-07,3.137441,-0.7071069,4.768372E-07,-0.7071069,0 node_stack_bottom4294426596 = 0.87714,6.429071E-07,0.8771403,0.7071069,-4.768372E-07,0.7071069,0 node_stack_top4294423582 = 3.987281,0.4687499,3.987282,-5.506751E-08,1,-2.280971E-08,2 node_stack_bottom4294423582 = 3.987281,-0.4687501,3.987282,-5.506751E-08,1,-2.280971E-08,2 node_stack_top4294426572 = 3.137441,-5.002676E-07,-3.13744,-0.7071068,2.384186E-07,0.7071067,0 node_stack_bottom4294426572 = 0.8771402,2.618489E-07,-0.8771396,0.7071068,-2.384186E-07,-0.7071067,0 node_stack_top4294423550 = 3.987282,0.4687499,-3.98728,5.506752E-08,1,-2.280971E-08,2 node_stack_bottom4294423550 = 3.987282,-0.4687501,-3.98728,5.506752E-08,1,-2.280971E-08,2 node_attach = 1.25,0,0,1,0,0,1 cost = 4900 category = Structural subcategory = 0 title = Station Core:4way manufacturer = UbioZur Welding Ltd description = Warranty void during re-entry. attachRules = 1,1,1,1,0,0,0 mass = 4 dragModelType = default maximum_drag = 1.8 minimum_drag = 2.3 angularDrag = 14 crashTolerance = 6 breakingForce = 200 breakingTorque = 200 maxTemp = 2900 fuelCrossFeed = True MODEL { model = Squad/Parts/FuelTank/fuelTank4-2/model position = 2.086163E-07,8.34465E-07,2.086163E-07 scale = 1,1,1 rotation = 0,0,0 } MODEL { model = Squad/Parts/Structural/structuralIBeam2/model position = -2.00729,-1.192093E-07,-2.007291 scale = 1,1,1 rotation = 90,225,0 } MODEL { model = Squad/Parts/FuelTank/fuelTank4-2/model position = -3.987281,-1.192093E-07,-3.987282 scale = 1,1,1 rotation = 4.462037E-06,315,1.848235E-06 } MODEL { model = Squad/Parts/Structural/structuralIBeam2/model position = -2.007291,-1.192093E-07,2.00729 scale = 1,1,1 rotation = 90,315,0 } MODEL { model = Squad/Parts/FuelTank/fuelTank4-2/model position = -3.987282,-1.192093E-07,3.987281 scale = 1,1,1 rotation = 360,44.99999,2.706683E-07 } MODEL { model = Squad/Parts/Structural/structuralIBeam2/model position = 2.007291,-1.192093E-07,2.007291 scale = 1,1,1 rotation = 90,45,0 } MODEL { model = Squad/Parts/FuelTank/fuelTank4-2/model position = 3.987281,-1.192093E-07,3.987282 scale = 1,1,1 rotation = 360,135,-3.155136E-06 } MODEL { model = Squad/Parts/Structural/structuralIBeam2/model position = 2.007291,-1.192093E-07,-2.00729 scale = 1,1,1 rotation = 90,135,0 } MODEL { model = Squad/Parts/FuelTank/fuelTank4-2/model position = 3.987282,-1.192093E-07,-3.98728 scale = 1,1,1 rotation = 360,225,3.155136E-06 } RESOURCE { name = LiquidFuel amount = 1800 maxAmount = 1800 } RESOURCE { name = Oxidizer amount = 2200 maxAmount = 2200 } } I'm not familiar enough with KSP's part system to derive what's wrong with this, but it simply refuses to attach as a vertical stack.. it'll snap to a node, but when I click the part remains semi-transparent and red-tinged meaning it's placed but not attached... I can successfully radially attach it though. Also, if I summon one as the root (first) part, I can successfully attach other parts to it.

+1 for Douglas Adams reference I like the rest of your idea too, ie a highly expanded tech tree with some random variations thrown in, like a 1 in 1e7 chance of discovering quantum physics shortly after the telescope, balanced to roughly follow our historical pace of development

I can't for the life of me remember where I saw this idea and so can't credit its original author, but it's the most sensible one I've seen yet: (not quoted verbatim, just my own wording of the idea itself)

sure, start at 1km, end at 45km, turn shape 100%

Problem isn't that it won't toggle them, problem is it toggles them ALL to 'closed' :/

Every single time I've tried MechJeb's "manage air intakes", it closes ALL of them causing instant flameout

works great for me. Does your directory structure look like KSP\GameData\MechJeb\Plugins\MechJeb2.dll ? Is your KSP folder under Desktop or Program Files (windows) ? because windows restricts write access to those trees, which screws up some mods. Instead, try C:\Games\KSP....

Unfortunately, the 304.x driver is the most recent one that supports the graphics chip in my laptop

For those who haven't checked out that thread, he today found that MechJeb does not cause this bug- it happens in stock KSP however MJ and friends may exacerbate it (like kethane with the ScaledSpace bug) Kudos for some good science there Jean

I've given up on MechJeb's rendezvous and docking autopilots, they're completely hopeless in terms of fuel usage and time. These two procedures I do manually these days- specifically I'll use Smart A.S.S. and occasionally the maneuver planner rather than the autopilots. The docking pilot has the right idea, but it needs to combine 'holding still in Z and moving towards docking axis' and 'moving in to dock' into a single mode, and that mode needs to have a narrowing tolerance window so that if you start it 200m out it allows itself to be really coarse with the adjustments as long as they're approximately ok (and thereby save a TON of mono), and become finer as it gets closer. Ideally it should have the two ports aligned and the relative motion vector parallel to the docking axis by about 10m out. For visualisation purposes, envisage a curved horn or funnel coming to a ~1cm point 10m out from the target port. The docking pilot should use the minimum amount of RCS fuel to maintain appropriate forwards velocity while remaining within this shape. A while ago I made a quicksave then let MechJeb's docking autopilot do the procedure. Came back in 15 minutes (yeah it takes aaages), and disgusted at it using 300 units of monoprop I did it myself. With 7 units of monoprop and about 5 minutes. If I'm feeling lazy, I'll engage the docking autopilot then make judicious use of timewarp to prevent it constantly spamming RCS and shredding the monoprop. The rendezvous autopilot should avoid the phasing orbit completely if a single burn could get an adequately close intercept. I've had numerous situations where I did one burn of ~30m/s to get my intercept within 2km then a tiny adjustment burn of maybe 4m/s to get it within 200m, where the rendezvous autopilot used a couple hundred m/s creating a phasing orbit then plotting an intercept from there.

MechJeb can already do this. Target the craft you want to rendezvous with, then at the bottom of the ascent autopilot there's "launch to rendezvous with target". This relies on the LPA being correct- the easiest way to get it right is to do a launch with the autopilot, then revert after the circularisation burn is complete and the autopilot deactivates itself. LPA stands for "launch phase angle", and is simply the angle between KSC and your craft when the circularisation burn is complete. This tells MechJeb how far in front of your target to launch. If you want to place a craft at a particular angle vs another craft, simply add that angle to the LPA before hitting launch to rendezvous! If the orbital periods aren't exactly the same, they'll slowly drift. One of the instrumentation dialogs shows you your orbital period. I don't even use the docking autopilot these days. Instead, I set Smart A.S.S. to PAR- then use engine burns or translation to make the target prograde marker push the pink target sigil towards the center of the navball. This is waay faster and massively more efficient on RCS than MJ's docking autopilot. If rotational alignment is important to you, use four regular ports on a quad adapter like this. Make sure to roll into proper alignment prior to docking though

I think if it's done this way then we'd end up with a whole page of various MechJeb parts with different capabilities, unless the tech tree provides a way to obsolete older parts. Then we have the issue of old ships can't plot the new maneuvers despite the fact that we all know how easy firmware upgrades are with basically everything, and it still doesn't follow the player's piloting ability, it simply follows their ability to gain science I'd much prefer MechJeb's abilities to follow the player's ability to pilot rather than a simple stack of parts with varying utility in the tech tree

THIS! Sometimes I'd be quite happy to sacrifice some thrust for a bit extra ISP, or the other way.. or perhaps I want a fuel tank with a size that's right in between two stock tanks. Procedural wings and fairings seem to be quite popular at the moment, making _everything_ procedural as part of the tech tree implementation would make me a very happy clam I disagree most emphatically. Current day space missions are flown with VASTLY more instrumentation and automation than stock KSP currently provides, I'm sure they have something a fair bit more advanced than MechJeb tucked away in mission control and duplicated on the craft I'd love to see MechJeb integrated into the tech tree in a sensible fashion.. perhaps at the start you only get the instrumentation (delta-V in the VAB, vessel, orbit and surface info during flight) and as you fly more and more missions you slowly open up the various autopilots- Smart A.S.S. first of course, then perhaps maneuver planner, ascent, rendezvous/docking, landing. For best results, I'd love to see these opened up by player demonstrating ability to perform these maneuvers manually- perhaps something like * "12 successful launches, ascent autopilot level 1 unlocked!" * "40 staging events on successfully returned craft, auto-stage unlocked!" * "20 degree plane change completed after gaining electronics level 4, Smart A.S.S. level 3 (normal/antinormal) unlocked!" Alternatively, the text could read "MechJeb has learnt ..." (ala Black & White) instead of "... unlocked" Hopefully the devs will create an API which allows MechJeb's author to implement exactly this! I like where you're taking this I think a strong driving force during early career should be commissions; ie "take sensor X to position Y, return within 7 days and gain a 350% bonus in 'science'." As career progresses, I think these commissions should become less important, allowing the player to perform their own science. I'd love to be able to find anomalies in space, eg take a gravity sensor to L3/L4/L5 for an unannounced bonus, or drop Magic Goo on the moon arch- essentially silent commissions. Later in one's career I'd love to see some really massive commissions like a Moons of Jool grand tour- "land Billionaire Richie Kerman on 2 of Jool's moons and complete a full orbit of at least one other then land him back at KSC within 5 years to receive 60 million Kubles and 5000 science points." Lastly, I'd be interested what the devs think of an exchange rate between science points and funds which varies based on events such as disasters (slightly poorer rate), deaths (vastly poorer rate) and surprise commissions (rate increase).