MaxPeck

Okay, so we have various community mods, why not a community texture map? i think if mod developers were to sign on to such a thing, it would dramatically reduce the game's memory requirements. An added bonus would be a serious amount of continuity between the visual appearance of parts, as well.

So, if you have multiple parts that use the same texture, does the game know to only load that texture once, or does it reload a new instance of the same texture for each part? Here's where I'm going with this: If I understand correctly, a lot of the memory usage in the game is from loading textures. Each part in stock, and each mod loads a series of textures to wrap around its parts, and each of those textures eats up some memory. It seems to me that there are only so many variants of textures that the game really needs. Some kind of insulated material, various metal textures, engine bell-like textures, etc. So if there was a community texture palette that was, say, 2048X2048, but contained a whole bunch of samples of various materials to wrap your models in, would it ultimately save memory? I get that some people are going to want to add unique elements to their mods, but for mods that just need a stock-alike look, would this be more effective than each part or mod loading its own unique texture?

No way... I see this as a great spinoff! Kerbal Budget Simulator. You open the game and see a view of the KSP. Enjoy it, it's the last time you'll see it for a while. Next, you get to forecast your needs 24 months out. Down to the part. Then the game will wait 2 days just to look at your estimates, and then spend 2 weeks "processing it". It will send it back requesting revised figures and demanding you get updated prices for all parts you want to include in your rockets. It will then demand that you attempt to find other sources, or substitute cheaper parts. Once you've gotten that done, it will reduce your request by 10% and send it to the KSP administrator for approval. The next phase of the game has you sitting in front of a spreadsheet trying to explain budgeting to a political appointee who was eating crayons last week and happens to be the brother-in-law of someone in the administration. IF you get past that, you'll have to go to appropriations, which will take anywhere between one and ten months. Finally you will be appropriated funds, but won't be able to use them for 2 years, at which point you will have to submit a detailed purchase request for each part you want to put on a rocket. These have a 50-50 chance of being accepted. During that 2-year wait, various political initiatives will cause your budget to be reduced further, so that you'll actually probably only get a maximum of 75% of your actual appropriation, and possibly less, depending on your reputation. Now that you have your money, the Administrator will immediately encumber 10% for his "contingency fund", and depending on your reputation, anywhere from 5 to 20% of your funding will be wasted on frivolous things each month, or re-allocated by the administration to "planetary climate studies" and "educational outreach". Finally, your team will build a rocket (you don't get to do that, you're the budget guy). If it launches successfully, it will trigger a series of reviews, and a chunk of your budget will be spent on PR for the flight and improvements for things the engineers should have figured out BEFORE blasting a billion dollars into space, but somehow didn't. If the flight isn't successful, it will trigger legislative oversight hearings and a suspension of your program for at least 5 years, during which time you will barely be funded enough to buy a cup-o-noodles, because since you aren't flying rockets, we can better use that money in the Department of Vote Buying. How on earth could that NOT be fun? PS: This was pretty much my life for 6 years, albeit not at NASA, but in another part of government. WORST JOB EVER.

Can work both ways. NASA can have their appropriation reduced, which would impact the whole NASA budget in the future, but NASA can also reallocate its funding internally. For example, they could take funding from manned space flight operations and move it to the political cause du jour, like climate studies. So you could have both options, you could lose appropriated funding, or you could have your own management shift your funding to another program.

You don't have enough control authority with that configuration. It looks like your elevons are at the wing root, which is going to make pitch control all but impossible and roll control difficult as well. Think of an airplane's control surfaces as levers that extend from the CG. The longer that lever arm, the more effective your control surfaces will be. Move your ailerons to the wingtip and add canards to the nose, or extend the tail and add a proper elevator. Also, make sure your main landing gear is just a hair behind your CG so your aircraft can rotate when it reaches takeoff speed.

This is promising! I agree with @jlcarneiro that this would be better run in a MM patch though - you wouldn't have to mess with the original file, and it's much easier to make corrections, because you can try different values and then I think you can F11 to reload them without having to end and restart your game.

I think the hardest thing is the second mun landing. With the first, as long as you get down in one piece, it's a success. The second mission to add to or resupply the first was incredibly hard until I finally unlocked the wonder that is mechjeb.

Most of the software products I use are lab products or drive instrumentation, not games. That being said, the standard seems to be you pay when a new version comes out, but updates and revisions are included in the price of purchase. For example, you pay for V1. That includes 1.0, 1.0.1-1.0.5, 1.1, 1.4, 1.9.9 etc. When you get to V2, it's a new product you have to shell out for, as support for V1 gets sunset. I would expect KSP to follow the same model.

Let me try something different for a minute. So for all my blustering about 1.1 and the lack of stability, I have to say that I'm about 85% happy with 1.1.2. Granted I haven't gone very far in the game, but with RSS and about a dozen or so mods, its still running smooth, much better than 1.1.0 and 1.1.1. If they can just straighten out the VAB/SPH graphics weirdness and the wheels-o-doom issue, I might have to actually admit that I'm a happy customer. Of course I've yet to experience the docking bug or any of the CTD issues others are talking about, but so far, so good. The wheel/landing gear issue is a definite downer for me though, being an aviation guy, I really enjoy just playing in the SPH.

I didn't say the devs are lazy, nor would I. I said >>I<< was lazy. The devs have worked their butts off, no two ways about it. My comment about the opportunity cost of keeping Unity vs. switching/developing a different engine was mainly ironic, as hindsight tends to be 20/20 and circumstances are not always as we would wish. After doing a lot of reading over the weekend, I was shocked at the number of developers of all sorts of simulations and games, who couldn't make U5's wheels work ended up dumping the engine altogether and switching to Unreal, or other engines. None of what I'm saying is meant to criticize the devs or Squad, who have done a heroic job of keeping KSP going. I don't want to be misunderstood on that point. My last few posts are more aimed at those elistist members of the community who go on the offensive against anyone who dares express displeasure with the current state of the program. These fora are not shrines to KSP or the devs, they're a feeback mechanism, and a lot of the feedback right now is rooted in frustration. Cost of doing business. Am I happy with the current state of KSP? Nope. Tried playing last night for an hour and after two-dozen consecutive takeoff failures from the runway, I gave up frustrated. I don't play games to be frustrated at their broken mechanics. I expressed my discontent, as have others, and was promptly harrangued for it. I'm not one to let a good harranguing go unanswered, which is probably part of the whole aviator mindset. This isn't about overflow complaints from mod threads, which I agree are inappropriate, but rather something I've observed for a while and finally spoke out about. You need to let people vent without beating them up over it. That's part of product feedback. Squad clearly understands it, which is why you don't see them on here arguing with people, but some members of the community tend to make things rather... unwelcoming. At any rate, I've said my piece. It's Miller time.

I never said the devs were lazy. I said I was lazy, and I'm quite happy to own up to the fact that I'm not going to spend any time whatsoever digging through old forums for a quote about something that doesn't really matter in the greater scheme of things. What's done is done, and I just made an observation about the opportunity cost of making a decision to proceed with an engine that didn't quite work right, or to try a different one. I actually think quite the opposite of the devs, they've worked their butts off, quite obviously, and I begrudge them not a thing in terms of their efforts or labor, and have a lot of respect for what they've done. I think the devs are great people, and they've worked very hard at creating and updating KSP, and were I ever to pass through Mexico City, I'd happy buy them a round of beers and thank them for their hard work. Doesn't change the fact that a year was spent pursuing solutions that still haven't made the game perform as advertised. The problems being encountered aren't due to KSP dev's labor or efforts, they're entirely rooted in the Unity engine. Again, square peg, round hole. You can sit there all day and argue that non-software developers have no idea... etc, but at the end of the day, a not insignificant number of users have been playing a game that was, in one way or another, crippled for the last year to make it playable, and which is still largely unplayable for many of them. Most users have graphics and/or memory problems with the stock game. Mod makers, who generally make add-on content for games to enhance them, are creating mods just to make the game functional. 1.0.5 was the closest thing KSP has had to a stable release, and even then you have to play it with your graphics throttled way back and an eye on memory usage. Why should I expect them to listen to me? I don't. One disappointed user is nothing, I get that. However, if they're smart, as I suspect they are, they'll listed to the combined complaints of the community via the community feedback pathways they've set up. They'll realize that a lot of people really want to play this incredibly popular thing they've made and yet can't, and only they have the ability to make it right. Not all of us are software engineers, not all of us are superusers. Not all of us have the accumen to be able to go into a bugtracker and provide complete and detailed engineer-level specs as to what's going on. For some people here, their only recourse is to come on these boards and say "my thing's broke." Those bug reports are every bit as valid as the ones on the official bugtrackers with detailed specifics, and to dismiss those people because they don't speak code or lack the ability to communicate with their machine beyond "play my game, please, Mr. computer" is unfair, and that's largely what I've been going on about. Far, far too many "code pros" on here routinely jump on people trying to report undesired or unexpected behavior, instead of seeing those complaints as an indicator of a larger problem. And when you dismiss and chastise the casual user for communicating their frustrations in the only media they have, you alienate them. When someone comes on here and says "I bought your game, but it doesn't work and it looks like other people have the same problem" and your knee-jerk response is "if you think it's so easy, you go learn to code and write it yourself, or kindly shut up and move on"... and then call them whiners and ingrates... THAT, sirs, is what's disappointing about the community.

Shhhh.... it upsets the software developers on here if you expect actual performance for a product you paid for. In the world of software development, apparently "almost" is good enough. Expecting something to be a finished product is just crazy talk. Do you even dev, bro? The worst part, and I'm far too lazy to actually look for it, but I remember talk back when 1.0 was released where the devs came right out and said the best solution was to use a different engine, but declined to do so because it was too much work. Here we are a year and 8 patches/releases later and hundreds of labor hours have been invested in still trying to hammer that square peg into a round hole. But we're not software/game devs so we have no right to question those who are. Nothing to see here, move along.

I will say that 1.1.2 has it's upsides. I'm on a macbook pro mid-2014, and the game feels much more responsive than previous releases. I am completely in love with the UI scaling features, and didn't realize how much I needed those until I had them. I haven't had any CTD so far, even with a healthy number of mods. My main complaint is still the ridiculousness surrounding the spaceplanes, I just had 26 consecutive takeoff failures with a design that worked fine in 1.0.X and 1.1. All of the failures were either LY-01/05 landing gear related, or the aircraft just wildly yawing during rollout. I've tried dickering with the landing gear settings, but all with the same result. Seems like as long as you're content to shoot rockets at space, all is well, but spaceplanes just aren't getting any love. Actually, it does kind of parallel the real space program in that sense...

Ulysses, I've spoken my piece and counted to three. Time to probably let this one go. Bickering ain't gonna fix nothing. Just have to wait around for Squad to release the next batch of fixes.

EVERY job can say the same thing. Software/game development isn't special, except that it is apparently exempt from customer service concerns. The plumbing comparison is valid because we're not talking about the type of business, we're talking about the way you do business I did buy a product. I bought a computer game that was billed as released and marketable. I didn't invest in a Kickstarter project, I didn't join a club, I bought a product based on advertising and a promise of a good in exchange for currency. And as for those who think Squad would be justified in throwing up their hands and saying screw it and moving on, I would remind you of two things: 1. Squad isn't a software company. This is a one-off thing for them. There isn't another project for them to go to, this is their whole deal 2. Bigger, actual established development houses have folded for less. This is a very competitive industry and Squad is lucky to have found a niche. The one product they make has never been stable and if they walked away from it now, it would probably be the end of Squad as a game maker. If EA released a comparable game next month that actually worked as advertised, I'd be willing to wager that the vast majority of casual KSP players would buy it and KSP would go down as a footnote in game history, largely forgotten until it got rereleased as a gold classic on GOG in five years I bought this game at 1.0. As soon as it was released commercially I was one of those who said "shut up and take my money!" I've since talked others into buying it and even bought it as a Christmas gift for one of my kids. But I'm sorry, as someone who DID buy a finished product, I've been sorely disappointed in it.

You know, I started writing this whole long post about this thing and then I realized it just doesn't matter what I think. But then there's this: See, the thing is, it doesn't matter if we work in the industry or not. We're a special group, known as "paying customers" who are dissatisfied with a product that has never worked as advertised. If I pay a plumber to fix my pipes, I expect them to be fixed. If I buy a car, I expect it to work. If they don't, and the response you get from the people you paid was "you're not a plumber, you don't understand... if you think it's so easy, go to plumber school", well, there's a phrase for that... it's called "poor customer service". If I buy a car and the engine does weird stuff, I expect the manufacturer to make it right, I don't need to be an engine expert or a car builder to have that expectation. But hey, the community will work to fix the lapses... as with ATM and DTL. People are writing mods on their own time, creating patches on their own time, just to make the game playable. It should be playable on day 1, and mods should add to the game, not make it functional. But, admittedly, I'm not a software developer... I'm just some schlub who dropped his $40 on the table expecting to get a playable game. Enjoy your vacation guys.

Broke is broke, regardless of the reason. You can try your best and still not succeed, sometimes for reasons entirely beyond your control. I'm not advocating for an engine switch. That would be a lot of work, I understand that. This needs to be fixed by Unity/PhysX or there needs to be an engine change. These are the only solutions. Tweaks to .cfg files, adjusting settings - these are just bandaid fixes that may mute the problem slightly, but won't solve it. This is only going to be solved at the game engine level, either through Unity and PhysX working out their problem, or KSP going in a different direction. Neither is going to happen anytime soon, so like I said, KSP goes on the shelf for the immediate future. Good luck though, guys, and I sincerely hope the devs can work this out at some point. I appreciate all their hard work on this, and I really look forward to the day this is a playable game.

I spent the better part of last night and this morning reading about Unity, PhysX and the wheel dilemma. I'll preface this by saying I'm not a game designer, nor am I a professional programmer. I know this is a wall of text, but I want to save folks from wasting a lot of time working an unsolvable problems. Here's what I've learned: This isn't a KSP problem. It's not a Unity problem or a PhysX problem. It's an integration problem. From what I've been reading, virtually no one who uses wheel-based assets in Unity has had any luck getting them to work in U5. I read stories of people who write driving simulators who are frustrated to the point of losing the capacity to speak (write) coherent English. I read a rather lengthy outburst from someone who writes vehicle simulations for car manufacturers - who recently updated from U4 to U5 and is so aggravated that he ported his entire project to Unreal Engine rather than lose one more day trying to make the wheels in U5 work. That says something that a complete engine change was easier than trying to make a module in the existing engine behave. The funny thing, as I understand it and as noted by some others, is that Unreal and Unity both use PhysX. The conclusions that I read seems to imply that the problem is in how Unity integrates the wheels. This is coupled with the fact that U5 doesn't treat wheels as wheels, it treats them as a line pointing straight down from the center of the axle to the ground. So as long as the bottom of your wheel touches a hard surface, you're fine; but if your wheels become angled, or if you encounter sudden terrain, you're screwed. Think of it as a rolling donut 1m tall - the only part of the donut that counts is the part that exists in a straight line from the center of the mass to the bottom of the donut. If the donut encounters a 0.25m tall cube, it doesn't climb the cube, it overlaps it until the line touches it, and rather than a gradual increase as you'd see in a real wheel, what you get instead is a momentary jump from 0 to 0.25m. The physics engine then creates a force change to compensate, and your wheel blasts off. This is why we're getting dancing and other phantom forces... Unity doesn't handle modular parts well, because the assumption is that wheels will be a fixed part of an asset, not added at runtime in all manner of helter-skelter configurations. So if your wheels aren't pointing straight down at the hard surface they're sitting on, the physics engine reads it as a collisions and applies force to compensate. It also explains why people have issues with the fixed nose wheel - if the three parts of your tricycle gear aren't perfectly perpendicular to the runway, one or more of them will generate phantom forces as Unity detects constant collisions with the uneven surface it sees. So if your aircraft starts with a slight nose-down or nose up cant to it, and you haven't compensated by leveling the wheels, you're either going to bounce like mad or lose steering ability. This is also going to be a problem with landing - if you don't make a perfect 3-point landing with the wheel lines perpendicular to the runway, Unity is going to see those offset collisions and apply forces to compensate, probable upward and forward, which explains the bouncy landings people are posting all over youtube. So the problem is threefold: 1. PhysX changed how wheels work 2. Unity doesn't implement it well 3. KSP uses Unity No amount of settings changes or .cfg tweaks are going to fix it, kids. This isn't something you can design around. Until Unity figures out how to make Physx wheels work, or KSP decides to use a different, less problematic engine, this is what we're stuck with. KSP will forever be a game that almost works because the engine itself is the problem, not KSP. KSP is brilliant, but it's just held back by the Unity-PhysX problem. 'Fraid KSP is going on the shelf for me for a while until they get this sorted, I'm not spending my free time being frustrated by a game that continues to be broken at its core. I get that the devs have done a lot of work to get to this point, and I've had a lot of fun with it until now, but the bottom line is that you spent a lot of time building a project that was doomed to never work right due to the tools you built it in. It's not their fault, really, that Unity handles wheels so poorly, but unless they're willing to invest more work to port the game to an appropriate engine, it seems this is the best we're going to get. I understand their reluctance to do so, and I don't blame them, but the only probably outcome is that we bought a game that turned out to be a lemon, and the devs really aren't to blame for it. There is a petition on the Unity forums to get the Unity developers to enable a legacy compatibility mode so that U5 can use older versions of PhysX... seems to me that's probably the best solution at this point. So if you want to see this work, that's probably where the community needs to focus its energy right now - getting Unity to make their product work. In the meantime, KSP devs, thank you for all you've done, and I really hope it works out.

@taniwha I looked at your .version and AVC's model .version and I can't figure out why it doesn't show up in AVC. Somebody smarter than me will have to figure it out.

Dunno if this is possible, but do you think there is a way to run AVC prior to starting up KSP? I know that sounds like a tall order, but it would help to know if I need to get updates before starting loading the actual game. I have a mac, so CKAN isn't really an option, and I like AVC better anyway. Is there a way to create a standalone executable from the .dll or create an environment that uses the dll without invoking the whole game? If not, that's cool, just a thought that popped into my head as I was looking at the massive list of updates needed.

@taniwha Yeah, there's a list of mods during loading and AVC calls home for each and checks the local version against what's in your repository to make sure players have the latest version. I'll take a look at it and see if I can't figure out why it's not showing up. I know you're a busy man so I don't mind taking a look at it.

Do a Google search for ESET Online Scanner. It's a virus scanner that runs on-demand through a web app. Nothing is installed on your computer, and it's got a decent chance of killing anything that's plaguing you. For the really persistent stuff, there's MalwareBytes, and I used to use HiJackThis to check under the hood back when I still used Windows machines, but I'm not sure if that's still a thing or not.

For early game bases, check out Pathfinder. I use a combination of MKS, Pathfinder and Planetary Bases Inc., along with USI-LS. Roverdude's stuff is on the money and all you really need, but I like a multi-layered approach to setting up a base. Pathfinder is good for early bases, the parts are lightweight and inflatable, so it's possible (with KIS) to land a container or two with everything you need to get a base up and running. I then usually get an Extraplanetary Launchpads setup and a workshop or two and start setting up a more permanent base using MKS and Planetary Bases Inc. modules. Typically I'll land a couple of light probes to scout a landing site, and then I'll land the pre-supply pathfinder stuff, and then the crew, and then the rest follows. Enjoy!

I don't know why, but EP is still not showing up in AVC. I see the version file, and it looks like it's right, but it doesn't appear in the list of mods when the game is loading. Just FYI.

I, for one, can't wait until KSP is out of Beta... this is going to be an awesome game once it's actually playable.