BudgetHedgehog

It is available because someone hacked an x64 version together and the people demanded it as it evidently could be done. Ever since it was released, it's been a nightmare for users and even more so for modders. I could be wrong, but the radial decoupler bug we have now was the result of Squad fixing the fact they were broken on the x64 release. It's really far from suitable for release and always has been. Also, x64 < x86. x86 is higher, must be better, right?

No real reflections in OpenGL and I have an AMD Radeon HD 7500M/7600M Series. Regarding AA, I have it set to override application settings and it still doesn't work. Don't know if it needs to be turned off in-game though..

In other news, I'm an idiot. (thank you) - - - Updated - - - Wait... where is the batch file in that? Because it should be in that Kerbal Space Program folder. It searches for, for example, "GameData\Squad\Parts\Command\Mk1-2Pod\model.mu" so you need it at the folder above Gamedata, i.e. Kerbal Space Program (for Steam installs). Also - double check your Squad folder - that command appears when the parts can't be found and that's either due to wrong installation OR no such part as model.mu can be found i.e. it's already renamed mu.bak or is .png or whatever. I just ran the Unprune and got stuff renamed back correctly, and ran the Prune and things got renamed correctly again.

I don't think it can be fixed - I've noticed the same timewarp prevention when mousing over the KAC window. I did bring the issue up with Trigger back in October, but was told that "there's no lock model that will stop click through and run the clock in there".

Also, I'd just like to point out that 1.7.1 is missing Part Revamp-MM.cfg. A pretty important file to leave out, I think Disregard, I didn't look properly

Recompile it yourself without the x64 check or use Linux.

I would just like to point this out - if a real life customer's payload is like 30cm too wide or whatever, it's possible to put it on a hinge and fold it up so the package is smaller. No stock hinges means we can't do this so having to use a next size up fairings and whole rocket seems a bit drastic for something that is easily solved in real life (and in KSP with Infernal Robotics). I say procedural ones are necessary because there's no way to make a payload fit that a real life company would use. Either procedural ones or fixed sized ones and a way to fold and contract things. My 2 cents.

Could you post a screenshot of where you've put it?

To clarify, the one that contains Gamedata, KSP.exe, KSP.log, KSP_Data, any crash log folders etc.

Hmm.. Not sure I'm a fan of the twin nozzles as I think the KR-2L (hereby called Jeff because I can never remember it's proper name) is modelled after either an F-1 or J-2X which are both single nozzles.. That said, disregarding comparisons to real life, I wouldn't mind if Jeff had two nozzles, similar to KWR's Vesta VR-9D. And you should definitely make the main SLS engine (I don't even know, the one with four nozzles.. Chris) have the nozzles in a square shape. EDIT: Also, the SLS SRBs should, all going well, have the Space Shuttle ones replaced by "advanced ones". Sadly, I can't seem to find any concept art of them other than this. Might be groovy to model the NASA SRBs (..Sally) after those. EDIT EDIT: I've always hated Chris' engine fairing/housing thing above the engine whatever it's called.. they just kinda pudge out with piddly little nozzles sticking out the bottom. Would love something more integrated and streamlined.

Playing Devils Advocate here: would it not be quicker and easier to have Developer written in front of you instead of a number that you then need third-party documentation to translate via? Your second point is moot as you'd have to look up the whole list of careers even if it was either plain text or integers - "shall I go for profession 496 or 273? I have no damn clue, let me consult the table to find out what they are". This is assuming the table A, exists and B, is up to date and C, is correct.

Is it weird that I'm hyped for that? The NASA revamp, I mean.. I honestly didn't think you'd tackle them, but now you are, I'm more stoked than a fireplace in winter

Are you using OpenGL? I recently discovered that that'll make reflections not work (and they do in default DX9 mode).

That is not extremely large. This is what I mean when I say 'extremely large'. Besides, your rocket has the length to help stabilise it. Large fins at the back means higher drag at the back which stabilises the rocket. Of course that'll fly. I'm on about not having fins at all or if you do, very small ones.

A well-reasoned argument. I guess what with them adding new aero, resources and whatnot, the game has all the features they intended it to have and as such, aren't comfortable with being EA, but still.. jumping into 1.0 full release with those does sounds a bit weird. I hope there is something more substantial behind it than 'just because', I am with you there. That's a different thing entirely and completely acceptable - the issue is people are complaining they want a refund because.. I don't honestly know why. They bought the game at a time when the EULA states any release may be the last and that Squad is under no obligation to communicate or make anything new. What you're on about is people purchasing KSP 1.0 and finding it unsatisfactory - nobody knows what it'll be like, how many bugs will be present whatever and until they do, they have no right to expect a refund for buying 1.0 because no-one has done that yet - it's literally impossible to buy KSP 1.0 so expecting a refund from it doesn't make sense. You're conflating buying an EA game and expecting a refund off of it and buying a full release game and it being too buggy to cope. These are two different things - one entitles you to a refund, the other does not. I don't think KSP hasn't yet reached a stage where it entitles anyone to a refund based on satisfaction (stuff like 'I don't like the imbalance of Outsourced R&D, I want a refund'). When 1.0 drops and people buy it and aren't satisfied and want a refund, that's Squads fault for shipping a buggy or whatever release (and for not listening when we say have at least 1 update before then). But, as things stand now, no-one is really entitled to a refund based on future updates not meeting expectations simply because there may not be any future updates - this is what the EULA states as of now.

*psst* he's running out of memory and should install ATM. 4Gb RAM is so not enough to run KSP+B9, the stock game uses about 2Gb by itself and depending on the OS, that leaves between 0 and -500Mb for B9. No chance on an x86 OS without ATM and very little chance on an x64 OS. Though with 4Gb RAM, I'd be surprised if it was an x64 OS.

The point people are making is this: the test teams aren't perfect, as evident by all previous versions. What will they miss that players catch? Maybe nothing, maybe a lot of things, maybe one big thing. We just don't know and that is why it'd be prudent to have at least one update in EA with the intended 1.0 features.

I think the point people are actually making is that while this bugfixing and new aero and stuff is all very well and going to be done, Squad are betting on it being completely and entirely balanced and bugfree upon release to the public. Given the current track record (I'm sure QA and experimentals folk are lovely people but damn, you guys missed a fair amount of bugs), I think it would behoove Squad to release at least one update with the current upcoming features under the EA banner and use player feedback to rebalance and bugfix for the actual 1.0 release. Being Early Access is great, things can be unbalanced, bugs can exist and the reviews will still be positive. But once they leave it, critics will be harsher and the excuse that 'it's in Beta at the moment, that'll be fixed' doesn't work any more. New aero - great! But does it break game balance? We don't know - it's being introduced in the same update as leaving early access. Bugfixes? Great! But did they fix all the important ones? What about the small but annoying ones? What bugs have appeared, but weren't discovered? Again, we don't know, and Squad are potentially shipping a buggy full release. Financial concerns, yeah, I'm with you on that, I don't know why people keep thinking that's a thing because Max has denied that at least twice. Same for stability - if people make KSP use more RAM, Squad aren't entirely to blame for that. The stock game works fine and doesn't run out of memory (did they fix the memory leak bugs?), that's fine. And they're jumping in Unity 5 as soon as possible which will mean x64 support which means stability won't be an issue for modded installs either. People complaining about wanting refunds or not getting what they're entitled to can go take a long jump with a short rope as far as I'm concerned. The ToS and EULA were and remain pretty clear on what they get when they give Squad $15.

Is it bad that this was how I've always imagined tourism contracts? - - - Updated - - - I think people are either forgetting or just plain don't know that launching something like the pFairings first pic, the ridiculously oversized fairings, are close to impossible with improved aero. It's a fact of life - you've got this huge bulbous thing up front, it's like launching a beach ball on a firework, of course it'll spin round, you disintegrate and you have no choice but to either brute force it and take it slow and steady or chop it up into smaller sections. Physics, by its own nature, prohibits extremely large payloads, even if aerodynamically shaped. If you have a large and dense payload, you'll need more rocket to lift it which means the payload:rocket width ratio isn't as extreme. If you have a large but light payload (such as the pFairings first pic), things will go bad and you will not go to space today. Simple as. People moaning about how unlimited pFairings will ruin game balance clearly haven't tried them with a realisticish atmo, such as the one provided by FAR or NEAR. EDIT: Though, I'm not opposed to limited pFairings either. And kujuman made a great point that "standard launchers aren't quite standard" due to the different sizes in fairings. I'm just saying that tech or otherwisely limited fairings doesn't need to be a thing because aerodynamics will already limit payload size. In short, I agree with both sides of the argument - fixed size fairings are awesome and I wouldn't complain if they were included, and pFairings are also awesome as physics and aerodynamics limit the size anyway without a need for arbitrarily limiting size. But yeah, here's hoping for hinges so I can make a large and light payload not so large so I can actually take it to space in one go.

Very much wrong. A quick look at the FAR graphs for straight wings and swept wings will show you that for supersonic speeds, swept wings are a lot better.

That's intended behavior - what ATM is doing is processing the textures and creating a cache of them. For heavily modded installs, this may take an hour or so. Then, next time, KSP loads the cache ATM created instead of each texture individually again and you get loads times of under like 5 minutes. If you quit during loading, ATM has to start creating the cache again. Also, this is a fairly recent addition to ATM - it's possible the last time you played was before this was included. As for making it a bit more manageable, people have reported success splitting up Gamedata so ATM only has to cache a small number of textures each time (say, just KWRocketry, then just Stock parts etc). If you do the above, let KSP load completely and ATM is still lagging or taking ages to load, and you're certain you're using version 4-3, post your log and computer specs.

Ah, now that, I don't know. All I know is that it's a thing. And yeah, for fun sometimes, I take my FAR planes into the stock soup and see how they act - one of my favourite SSTOs could barely maintain level flight. Another nice SSTO I like to make involves 2 Mk2 adapters, one intake, one RAPIER and some fins at the back for control. The Mk2 shapes are perfect for getting some advantage of the lifting body effect as that drone can easily make LKO but I assume it wouldn't even fly at all in stock. Also, Manley made a video today about Shuttle aerodynamics that touches on this subject a little - with FAR/NEAR, the whole underside of one acts as a nice flat surface for air to push against and keep you up but in stock, you need to add in just more wing segments.

Recompile it yourself without the x64 check or use Linux. Yes, biplanes work. But not well, just like in real life. You end up with the wing interaction creating too much drag for the additional lift. Biplanes were only invented because they're structurally stronger. You don't really need as much 'wing' as you do in stock as you can get a fair amount from the lifting body effect.

Damn, that's a good looking part. Trust Nova to make parts I immediately want Thanks for the share!

Excellent, glad I could help