BudgetHedgehog

It hangs on loading because it can't find the Monopropellant resource used in that cockpits RCS. Do you know why KSP isn't loading the stock MP resource? Do you have any mods that change it or something? You can upload your output log to Mediafire, Dropbox, Google Drive etc - throw us a link to download it and we can try and help more.

No it isn't.

If official accounts could stop pulling April Fools pranks 12 days before the fact, that'd be great too. Would mean none of these 'flame wars' would happen in the first place.

Do you laugh at gullible people in real life as well?

Actually, it's because of 1 - no-one considered that April Fools pranks can be executed 12 days before April Fools Day. Yeah, it says 'a week on Wednesday' which is April 1st, but at this point in March, April Fools doesn't even cross peoples minds. Yesh, the best ones are the ones that take months brewing and preparing, but the release is on April 1st, not 12 days beforehand! Ffs..

This will be my only post on this topic, I hope it covers everything. Either this is an April Fools joke posted at the wrong time in which case, just no, or it's serious, in which case, very much no. EDIT out the long ass post I made while people were posting elsewhere: Really? An April Fools joke? 12 days before April Fools? Jesus guys, talk about a sense of timing.. this is the kind of announcement you make ON April 1st, not 12 days beforehand, no matter what the 'a week next Wednesday' is on about.. And here I thought they had some sense..

Known issue, here's the fix. Replace your VirginGeneric dll (in VirginKalactic) with this one.

Check that the NASAmission folder is present in the Gamedata folder. Chances are you deleted it accidentally.

'Reticulating splines' is a reference to The Sims.

I don't think it's fair to bring past quotes into the present. Companies are allowed to change their mind, after all. They're staffed by people and people have an annoying habit of not predicting the future. It's better to take the current state of things + what they're saying now and forming opinions on that. I'll say that about any product, good or bad.

Woo, thank you for all your hard work on this! It's very much appreciated!

I can't check, but was that the root part? If so, don't do that. It's a stock KSP bug that's triggered by rescaling the root part.

Removing the Texture Replacer config will fix them, but if you really want reflections on them, you can save and reload the craft and you'll be able to grab them again.

The code to gimbal gradually already exists in the stock game - it's useGimbalResponseSpeed = true with gimbalResponseSpeed = [number]. High values (like 10) make it quicker, lower values like 3 or 4 make it slow to respond. Squad just needs to use it. It's right there, sitting and waiting to be used for something and it just isn't. They don't need to code anything more or redo the animations, it's literally 2 extra lines in the engines config. EDIT: Although, as ferram4 said on the previous page, SAS currently isn't aware of it (though it's an easy fix).

I'm pretty sure DDSLoader is simply a load time saving mod. Rather than having KSP load a png/tga/mbm, decompress it and then recompress it to a format your graphics card can display, it simply allows the Gamedatabase loader to load those recompressed textures which is quicker. I don't think it saves any memory in and of itself, so I'd say go for ATM. But.. why not use both?

One of my favourite parts of KSPI! Thanks

Jesus, this thread.. Anyway, focus on bugfixing, balance and optimisation (if applicable). Chucking more features into an already buggy game that can barely support its own weight is ridiculous. If however, you chuck them into a smooth running game that has room for them, the whole experience will be less stressful as you can get a full and complete look at it and how it supposed to fit in with the rest of the game without being disturbed by bugs and out-of-balance things. Not to mention that, if the next update is KSP going live as it were, it'll be met with reviewers and critics that forgive missing content if the game actually works well without bugs more than the other way round. Or, since you want the next version to be 1.0 because it contains everything you planned from the start, you chuck in every applicable feature, call it 1.0 but don't leave Early Access. Then for 1.1, you fix and rebalance etc and only then should you leave Early Access. My point is: don't leave Early Access with a buggy and unoptimised product.

Gonna bump this thread and say that the solar hub (CO-8P Solar Hub/COREsolarHub2) is defined as being in advancedElectrics, but the actual name of that node is advElectrics which means it doesn't currently appear in the tech tree

Okey dokey: There may be more, but that's all I could find. For now.

To clarify: what skybox? What suits? What are the filenames? What are the file extensions? Can you post a screenshot of TextureReplacer\Default?

Can't view it, "You need to sign in to see this page."

Why? There should absolutely be fire if I'm burning liquid fuel and oxidiser.

Also, there's ActiveTextureManagement for reducing RAM usage or you can force OpenGL for graphics rendering. Both reduce RAM requirements because, as nekogod said, literally nothing can change the fact that a 32-bit program can only access 4Gb of RAM. Your only options are decreasing RAM usage or Linux64.

1, Lights on all the things. Really makes a station look inhabited (see SSPE). Would love. Also, this is in the Tiny Additions list as well - intended? 2, Yeah, this doesn't appeal to me. For sure, as a stock expansion or a mod, but until FTL travel (or warp drives) or other ways of travelling between them that don't result in sitting at max timewarp for 10 minutes are added.. yeah, not too excited about it. 3, I don't want more engine smoke, I want better engine smoke. Basically, HotRockets pls. 4, Why not make it a launch clamp like part, like FASA does? Looks great, acts like a launch pad tower, and can be placed wherever the user sees fit.

Ok, so I'm over my head.. Having been inspired by Atlas V, I want to triple the gimbal range of engines (but only those with gimbal range of 1 or less) and then make them use KM gimbal. Sarbian gave the last part of the code but it uses the current gimbal range. So I'm thinking: @PART[*]:HAS[@MODULE[ModuleGimbal]]:BEFORE[km_Gimbal]:AFTER[StockRebalance] { MODULE { gimbalRange *= 3 } } would do it, but how to restrict it to engines with ranges of 1 or less? Is it #gimbalRange[<1]? Can MM read </>? Would it be better to write [1|0.5] or something and hope no engines appear that have a gimbal range of 0.75? Where would this go in the HAS section? The last part of the code, written by sarbian, is PART[*]:HAS[MODULE[ModuleGimbal]] { @MODULE,*[ModuleGimbal] { @name = KM_Gimbal_3 %yawGimbalRange = #$gimbalRange$ %pitchGimbalRange =#$gimbalRange$ } } which would be great, but I'm still limited to the existing range, hence the first bit that I'm stuck on..