BudgetHedgehog

Also, MJ calculates the absolute best time to transfer that has the absolute lowest dV requirement - if burning in 15 minutes costs just like 10m/s more than a burn in 1 year, MJ will choose the later one. A combination of that and Kerbin days being 6 hours rather than 24, means nodes are almost always a year away. If you have KAC installed, you might notice the first transfer to Duna used to occur on day I think 59, but now occurs in the next year - because of the shorter days.

In my KSP, if a burn takes more than 3 minutes to complete (no matter the target), it's poorly designed and I need to increase TWR. It's why I've recently started doubling up on LV-Ns for almost any interplanetary mission (used to have 2, now have 4) - sure, it's possible to split up a burn into several smaller ones and is more efficient (i.e. the most efficient way is with just one LV-N), but I find that it creates more problems than it solves - it's a lot simpler and easier to just send a refuelling probe in the same window.

Download and install the Props patch too?

It's.. difficult. Technically, this mod is a bunch of cfgs and text (and screen pictures) anyway so reinstalling WaRi's will just end you up where you started so you'd have to have some kind of medium between the two. That would require changing the cfgs yourself because most of the image filepaths have changed, some things are background handlers, others are page handlers, Vessel View support would have to be changed.. It won't be an easy task, I tell you that now.

Apologies for first the double post and second, for not explaining my problem clearly. I'll try different crafts, but while launching from Kerbin in a relatively low part count ship, I'd say FPS was in the single digits while looking horizontally. Not sure if this is the clouds or water or whatever, but the FPS increased whenever I looked skyward. What I don't understand is that this would've worked fine on the previous version, so I must've made some mistake while installing, but I'm almost positive I didn't. Reinstalling will take a while because I have some of my own edits I'd rather not replace so I'll have to keep them safe while I delete everything around them.. Hrmm, I'll get back to you.

Yep, I'm getting that too.. It's annoying that EVE doesn't save settings properly because I managed to get the Mun looking perfect but it was gone next time I started up the game.. I will say though, the 'no white horizons' thing is looking spectacular.

Jool. Easy to get an intercept and some beautiful sights too. A big moon system to visit that, with a bit of planning and careful gravity assists, can be done with relatively low amounts of fuel. Dres is a sad and lonely space potato, Moho takes far too much dV to get to and Eeloo isn't really worth the trip. Looks pretty though.

Did you... is that a Mainsail on the back with a Jr docking port at the bend? No wonder it won't work, you're pushing a wet noodle! I presume that's the remnants of your lifter stage (I see an LV-N tucked in the middle there) so just limit thrust, don't go full throttle and make sure your ship isn't moving at all during thrusting or you'll end up with this again. I also don't see any SAS units in there so any unwanted turning will take ages to correct. As an aside, with that weight, you're going to be burning for ages on one nuke. Better to have two or more radially attached (ideally, somewhere near the middle of the whole craft). Also, you could safely halve that number of struts and also also, I hope there are other RCS ports on your lander that I just can't see or you're going to have a bad time tying to translate because they don't look terribly balanced.

No crashes here, but serious FPS drop compared to the last version.. I'll keep it all though, I don't mind launching a slideshow, I like a little challenge now and then EDIT: problem solved by looking at the sky instead of horizontally.

Yeah, I'm gonna need a picture to understand just what on earth is going on...

Not sure where to look (I had the same error come up during loading) as the only thing that comes up is: [LOG 00:51:53.620] [ModuleManager] ModuleManager applied 430 patches and found 1 error 1 error in GameData/MP_Nazari/MP_Nazari.cfg EDIT: AHA! Found the bugger: [LOG 00:51:50.682] [ModuleManager] Skipping a patch with unbalanced square brackets or a space (replace them with a '?') : @PART[Courier EDIT2: well, at least I found it eventually...

Working for me now too

[LOG 22:22:39.567] [Crew Assignment]: Part Mk1-2 Command Pod holds 3 crew, but only 1 are available. [LOG 22:22:39.575] [Applicants]: Enter Dilfen Kerman. Will wait around for 3.0 days [LOG 22:22:39.576] [Crew Assignment]: Neillan Kerman just became an intrepid astronaut. [LOG 22:22:39.578] [Applicants]: Enter Kirtop Kerman. Will wait around for 2.6 days [LOG 22:22:39.579] [Crew Assignment]: Billy-Bobny Kerman just became an intrepid astronaut. Honestly, every time I find something like this, I always laugh.. Sometimes, reading the log can be pretty fun by itself!

It seems that researched parts aren't saved as 'researched' upon exiting the R&D building.. Research all, "yes", exit R&D, enter R&D, I get the option to research all again. I'd post the output/log and KSP.log but neither are of any use (just the same "[WRN 22:35:05.372] BorderedTilingSpriteMesh: Mesh has 300 or more vertices and might not be dynamically batched!" already posted and that's a warning, not an error).

I see a lot of NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:InternalGetTransform () at UnityEngine.Component.get_transform () [0x00000] in <filename unknown>:0 at ferram4.FARControllableSurface.CalculateSurfaceFunctions () [0x00000] in <filename unknown>:0 at ferram4.FARControllableSurface.FixedUpdate () [0x00000] in <filename unknown>:0 If that helps narrow down the search. Nothing about fairings though, I searched 'fairing' and all that could be found was loading them and adding them to the ship.

What you should do is in the first paragraph. You'll use like 30m/s or so for the radial burn and a couple hundred for the circularising. With 35% of fuel and a nuclear engine, you'll be fine. Yes, the second way consumes a lot more fuel, is the most inefficient way to do what you want and I only wrote that to explain what happens when you do it. You can safely igore the second paragraph - just do what I told you to do in the first paragraph (change PE, then circularise at PE).

Change PE to the desired orbit height (either use the Change Periapsis window in MJ or just do it yourself with a small radial burn (the blue symbols on the manoeuvre node.). When at that new PE, circularise. If you just immediately say 'circularise at 10km' or whatever, MJ will do just that - make a node at 10km that circularises. Because you're travelling at pretty much right angles to it and are going straight to the core, you need to kill the vertical velocity (with respect to the Muns surface) and replace it with sideways orbital velocity. Probably in the region of around 1km/s burn I'm guessing? A bit less? That's how much speed to have to kill and regain once you reach 10km. If you just do a small radial burn, you push your vector outside the Muns surface so are travelling sideways in respect to the surface. The you just need to slow down to orbital velocity.

1, No. Well, none that I can think of. The only ATM config I have touches the base RPM, not Hyomotos. 2, I have MM 2.0.5, but I haven't really played much since getting that version. 2.0.1 played nicely with it though. This is the MM ATM config I mentioned in 1: ACTIVE_TEXTURE_MANAGER_CONFIG { folder = JSI enabled = true OVERRIDES { JSI/RasterPropMonitor/.* { compress = false mipmaps = false scale = 1 max_size = 0 filtering = Bilinear make_not_readable = true } JSI/RasterPropMonitor/ExampleMFD/ { compress = false mipmaps = false scale = 1 max_size = 0 filtering = Bilinear make_not_readable = true } } } 3, You need to select a docking port as the reference part in the Target Management menu. 4, Correct - the dev builds of MJ are not compatible with RPM. The only one I know for sure that is, is the one off of Spaceport, 2.2.1 I think as that was the one 0.16 of RPM was compiled against.

Started a new career, was returning from Minmus with a boatload of Science. It'd been a very successful mission - I don't know exactly how much I'd gotten, but it was in the thousands at least. Anyway, I re-enter fine, all IVA (because I love KerbQuake) and when I come down through the clouds, I feel the parachutes deploy fully. Well, that's a bit odd - the ground looks very far below me.. and all my instruments are telling me I'm below 500m anyway... So I rotate the capsule to look around and see this: It fell over, of course, when it hit the ground and rolled down the hill. Exploded pretty much immediately, along with all my Science. I also have permadeath on so the first kerbal I'd taken to space, the one who was famous among kerbals has now died. Buh.

I think that's what happened - if on an impact course, circularising at 100km would need a huge amount of dV because MJ would do it on one manoeuvre i.e. as soon as your craft gets to 100km, it'd do a burn to cirularise, regardless of your current trajectory. As mentioned, doing a small radial burn to move the PE into a flyby height and then telling MJ to circularise at PE is needed. Or you could aerobrake, I guess.

Sounds an awful lot like the Alt+F5 "quicksave as" dev debug tool that they left in that turned out to be super awesomely useful to players. It like they said "Oh hey, you know these really good tools that we use for bug testing and everything? Yeah, how about we don't tell the people playing our early access alpha game, there's no reason they'd need to know about something that helps with identifying and reproducing bugs"

When it's working well, the Final Frontier mod does exactly that.

Hmm... Lucky you should ask this now because I'm testing the LFB 1x2 for a different reason so I just checked in the VAB and I get dV for it... For reference, I'm using the version off of Spaceport because that's the last one that had RPM support. Don't know exactly the build or version number, sorry.

Thanks. I suspect FAR also did it's job at keeping the dV requirements low too. The strange effects were at low throttle, yes.. but also only at certain angles...

Ok, confess: did you do this, Proot?