Papa BullDust

Duuuude, I just wanted to say that the three videos of the RovoMatic3000 in this thread were delightful. Not only a great showcase of the (in)ability of the wheels, but fun to boot. I particularly like the type of "help" you attached to the rover to "help" it up the hills. Thanks for taking the time to post these

Hi @AFF Sorry for the long wait you've had for a reply; personally I've been away from the forums for a bit. However, I have found the above modification (note the post above yours) to the original mod does still work; I use it myself. In fact it still works even though I've removed the part in my install. This is because of the way the mod (cfg really) works to apply MechJeb 'modules' into each command part rather than looking for the MJ part itself. Short of drastic changes to KSP's vessel module system, or one of the devs renaming something crucial, it should continue to work. Apologies to others for necroing, but I fell others may ask the same question and an answer is better than leaving questions hanging.

Awesome job Jim, thank you VERY much indeed

Hi @Vanamonde , since you seem to have inherited the dubious task of "The Name Changer", may I request one please? I'd like mine changed to: Papa BullDust Cheers muchly

@Jim DiGrizI specifically came to the forums today to write about this issue, only to find user @dmsilev has nicely summarised the problem with the new Bi-impulsive. It can, in certain situations "waste" dV by performing the plane change at the same time as the acceleration burn whilst deep within a gravity well. I would like to add a simple request to add back into MechJeb the true Hohmann (co-planar) fuctionality. This would allow once again, the plotting of a later plane change manoeuvre at a more optimal time. I realise that this may well clutter up the interface a little, but MechJeb (I would argue) is a learning tool also; it may also encourage new users to seek out the differences between the two modes. TLDR; please add the old Hohmann transfers back in!

You don't need to know much more than anyone does at the outset. There are extensive in-game tutorials to teach you the basics like controlling your craft, taking off, landing and the like; y'know, the gamey aspects of the game. The physics comes in to explain WHY you're doing what you do. Believe it or not, you know more about physics than you realise. Like for example, to get to space you launch upwards. However, in order to stay 'up' you need to know what an orbit is for example (always falling towards the planet, but travelling so fast SIDEWAYS that you always miss), which teaches you WHY rockets lean over more the higher they go; i.e. the physics of it all. Don't worry, you'll pick up loads of tips, just immerse yourself in the game and the community. They're a REALLY helpful bunch Good luck brave adventurer on your (pretty awesome) journey. o7

@Ultimate Steve @RealKerbal3xI'm pretty sure it's when @UomoCapra would have first started writing the message for preview's sake. It wasn't posted until about an hour ago. Argh, sniped! Well played @CobaltWolf

Wow, Better Burn Time and Take Command both obviated?! Tasty To me, that's the highest accolade for a mod; to be included/reworked in the stock game. Nicely done Squad.

Hi Shaun, What you want is to change the FOV (Field of View) rather than the POV (point of view). This thread details firstly the controls to change it, but it doesn't seem to provide a method to save or keep a specific setting from session to session. This thread is quite old, but a cursory glance of a forum search for FOV doesn't seem to unearth much except a newer article pretty much restating the first. It seems you can change it, but can't save it flight to flight.

Since this thread has risen from the proverbial to eat all of our brains, does anyone have a working link to the .pdf originally linked by FellipeC, or the piano transcript mentioned by OrtwinS? Both seem to be down

Had some trouble getting the "free" version (as per Gordon Dry's post above) to work in 1.4.x Having looked through Module Manager documentation, it's all still correct, the problem is that you now have to specify that the newly inserted MechJeb module is running. Therefore, the patch becomes: @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore isEnabled = True } } Presumably, the others look like this: @PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[MechJeb2]:Final { %MODULE[MechJebCore] { isEnabled = true %MechJebLocalSettings { FOLLOWED BY THE REMAINDER AS LISTED IN OGRDON DRY's POST You might need a '%' sign in front of the 'isEnabled' in the latter case (the edit or create flag to MM)

How are you ever going to become an almighty Scolipede if you give up now? I realise you have fairly short... appendages, which may cause difficulties in the keyboard/mouse department, but building rockets isn't exactly rock... oh. Seriously though, space needs more Pokemon. If you don't feel like you can get there on your own, watch some Twitch my little arthropodic friend. We have a great community with an Academy for learning with Das Valdez and even the CEO of SpaceFedEx, EJ_SA occasionally pays homage to your brethren with the Pokemon theme played during launches (always my favourite!). There are a host of others from dogs to comic-book guys and even YouTube stars popping in for some inpromptu action (I'm looking at you Quill18). You must persist. Just remember, build your rockets entirely out of steel girder segments. Since poison has no effect, your poison can't melt steel beams...

Steam shortcuts do honour Launch options set in steam. I've set the KSP 64-bit with %command% etc and a newly created desktop shortcut launches the 64-bit with Steam overlay. Whilst I agree the 64-bit probably does need to be the default by now, I suspect short of setting that default, the problem lies in the Steam implementation of different launch configurations and the inability in Steam to set a default selection... Citing the 'Play GTA' vs 'Play GTA online'... I never want to play the single player any more! Meanwhile, %command% setting works in every practical way.

Frankly, in my recent-ish trip to Duna (and I'd use the same technique for other planets) I sent a set of three relays for equatorial coverage, along with several other manned ships. However, when doing a mission all in one transfer window, I like to plot the transfers so that the relays arrive first. That way they're in the vicinity and at least not on an escape trajectory by the time the manned vessels enter the SOI. I tend to slightly overkill the dV on board the relays' transfer stage so that they can take a faster less 'efficient' path to the body. Depending on how long til your manned craft arrive, you may even have enough time to set the separation orbits for the relays too.

May I say your mods have been invaluable to so many, many space programs (my own included) and so I thank you sincerely for all your work and effort. I'm also in awe of the example you set in gifting your work into the public domain. Good luck sir. o7 May I also note, that @linuxgurugamer has been an absolute machine as of late when it comes to mod maintenance. So many mods I've known and loved that had fallen by the wayside have been returning en masse with his dedication.

Then by the time ya get to play it tomorrow, loads of mods will be updated too! #brightside

Absolutely, this is by far my most commonly used method. The trick I outlined is really only necessary if one of the docking vehicles is a large station that might not stand the stress of being re-aligned each time a ship needs to dock. Really quite niche indeed! (Which pretty much negates the whole 'written for new players vibe I was going for. I really should think more before I post... :p) @DrLicor Heck yeah man, Scott Manley was my staple go-to in the early days, and this tutorial in particular stands the test of time.

I only really use acronyms for vessels, so I've included pictorial examples. LiBKOR: Life Boat - Kerbin Orbital Return (500dV and a probe core clipped in for SAS without pilot) The additional bits are so that a stack of these can just be shipped and attached to a station for emergencies. PMV-R: Payload Mobility Vehicle - RCS edition. (4-7T = mass)

A couple of tips for when you want to align two vessels for docking, let's say a station and a small craft, and you've got within say 100 or so metres with approx 0 relative velocity. First, 'switch to' the station and if the docking port to which you wish to attach the approaching craft has a symmetry partner, i.e. a docking port facing the other way, simply 'control from here' on that partner docking port and note which way the centre of the navball faces. This will be the exact direction the incoming craft must face in order to align with the intended docking port. So switch back, and do the usual things (control from the small craft's docking port, set the station port as the target) and of course, align the craft so it faces the direction you noted. It's then just a matter of drifting slowly towards the station, translating with IJKL+HN (or docking mode) using the prograde marker to 'pull' the target marker under the centre of the navball. Success! (Disclaimer: success is not guaranteed) Similarly, if there is no symmetrical partner docking port, 'control from here' on the port where you plan to dock, note its direction, and envisage the other side of the navball. Since the navball has numbers to show you how many degrees radial (into the blue or brown halves) you're pointing, and how many degrees 'round' the navball you point e.g. 0 degrees being North, East at 90 etc., these can help to picture the opposite side. This comes quite naturally after a few tries, I find myself only needing to note two directions, for example, say the station port was facing 20 degrees into the blue half of the navball and at about 225 degrees round. I face 20 degrees into the brown half facing 45 degrees (taking 180 from 225 as there are 360 degrees round... you know this) It can be as simple a thought process as that. This is quite a niche tip as, for a lot of rendez-vous situations, you could just eyeball the alignment. This trick is really if you need to be more exact (bigger craft, less wiggle room in the docking alignment) or you, like me, are rubbish at and/or dislike guestimating. Lastly of course, you could just install the Community NavBall Docking Alignment Indicator mod.

Oh Teddles; you've truly made a difference, and I can only wish that your dreams don't just fly high, but actually make it to orbit! Good luck dude.

Okay, a little amateurish, but I'll chuck these in for good measure: I usually have a wry smirk each time I see a Kerbal unfurl this!

@DMagic Cheers for the response my friend; you've enhanced the future lives of every Kerbal that I look after in my copy of KSP.

I'm having the same problem; heavily modded install of KSP 1230 using Orbital Science v1.2.3 (Win x64) but the same thing occurs with Universal Storage goo canisters and materials bays. A sample was collected, and the segments reset by a lvl 2 engineer (the parts visually close and the data seems to be collected) but when back in the pod and a second run attempted I get an error "No more samples can be collected". Is this a bug, or is this an intended change to stock behaviour, requiring a higher level Kerbal? The only reason I have to believe that this is down to Orbital Science is that the error message I get appears in the DMModuleScienceAnimateGeneric.cs Also, truly awesome sets of mods DMagic, multi-props to you for the great work. <3

Excellent stuff man, I particularly enjoyed the music track (very appropriate) and a nice cheeky finish... blissful!

I can see this; one can have preconceptions about how the code is supposed to work. I used to work with large amounts of healthcare data and we always had a policy of having a colleague look over what we had done before it was sent out. Not quite the same, but a similar principal.