MaxPeck
-
Posts
473 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Article Comments posted by MaxPeck
-
-
22 minutes ago, mcirish3 said:
Unity was chosen unfortunately becuase the Idea men of KSP did not think KSP would be very successful and thus had to go with the cheapest option. By the way I agree/remember that the Devs mentioned they wished that they had used a different graphics engine a year ago or so. But it was not out of laziness, or even an unwillingness to start over per say that they did not switch. They understood that to do it right they would infact have to either use another off the shelf Graphics engine that may or may not work as needed, thus leaving them in the same boat Unity put them in 2-4 years down the road, or they would have to develop their own engine which would take 4-6 years. In either case it could potentially be 4-6 YEARS before the switch was finished, and to be honest I don't think they are in a financial position to take that long to rebuild the game from the ground up like that. So the choice is Either keep using Unity or risk losing it all and start over and not have a finished product for a VERY VERY long time if ever. Unless it taks Squad 4 years to get this working they have in the end saved time and they keep their revenue flow. I am sorry, thinks suck for those of you who have serious bugs but most of this is out of the Devs hands ATM. I am sure they will fix it as soon as they can. ALso the argument about adding content to the Unity 4 version. That was really a no go. 1.0.5 was approaching the upper limit of what was doable for content with out a larger resource pool to work with. I actually hardly played 1.0.5 because my older PC just could not handle everything and the game was very laggy even without mods. 1.1.2 runs very very well for me even with the bugs.
As for the community. You have to understand that some of the attitude towards people complaining about KSP to the devs is a backlash against complaining in general becuase people have also been complaining A LOT to Mod makers. Mod makers do their work for fun and in their spare time and for free. Whining and complaining and harassing them is UNACCEPTABLE, becuase they owe you nothing. SOme of that backlash against people doing that has probably carried over to this thread a bit.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.
-
4 hours ago, CloudlessEchoes said:
If you are too lazy to properly quote them in context (about them being lazy, ironically enough), why should they listen to you? You do realize that using a different game engine essentially makes it an entirely different game from the ground up right? Perhaps graphical assets would be re-used but that's it. The game wouldn't look, feel, or act like the KSP we know. And then people would complain about that! In the "ideal" world the best solution is probably a custom engine built from the ground up. That way everything works exactly as you want it to. But that's no easy task. They probably wouldn't have the expertise, or resources to do that.
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.
-
3 hours ago, steve_v said:
If craft are exploding en-masse due to a physics engine bug, fix the physics engine bug, call in someone who can, or just don't release until it's sorted.
I'm actually not too disgusted by the hacky fix for explode-on-load clipping, but all the band-aid fixes so far have introduced new problems, and none of them address the real (and common to all the wheel related bugs AFAICT) cause.
The latest "autostrut" band-aid for bouncing and jittering is already shaping up to be a can-of-worms, particularly for mods like IR, and I'm not convinced this is better than the previous jello suspension "fix" TBH.Gear and landing legs still react violently or explode if faced with a sudden change in terrain height (or a kerbal for that matter), softening the suspension won't fix this, strutting things won't fix this. Endless mucking with module parameters won't fix this either. It's an engine bug, stop buggering about and fix it properly. If that requires another Unity upgrade, so be it.
That's just wheels (and those were advertised as being "way better" than 1.0.x). What about the crashing? Or the graphical FUBARS in the VAB and elsewhere? (esp. on Mac) What about windowed mode being totally broken on GNU/Linux, to the point that its random window geometry shenanigans stalls my window manager? There are more.
The real kicker: What about the ~1300 open bugs on the tracker? This number is still increasing, and most of the serious ones are from the pre-release. What is the point of doing a pre-release at all, if you don't actually fix the bugs it reveals?
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.
-
9 hours ago, AdmiralTigerclaw said:
Words
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.
-
7 hours ago, AdmiralTigerclaw said:
Your sentiment might make sense if comparing software engineering to plumbing was even remotely... Well, comparable.
See, your plumbing isn't like a program. Your plumbing is more like a single line of code. When your single line of code is broken, you can see it's broken and you know what's wrong and where. You can pay the software engineer to come in and fix that one line of code easily. The problem is found, you've directed him RIGHT to it. It gets fixed.
Most people who answer you: "You're not a software engineer, you wouldn't understand" fall back on such a response because making people understand is a long and time consuming task. Explaining the problems in software development is a time-consuming, and inefficient task. The time spent telling you all about what's broken is time wasted. You can't fix it, why bother wasting time explaining anything further? If you take your car to the shop for repairs, or get your plumbing worked on, 'you' (to refer to most average people) can barely wrap your head around the problem as it is before you add in the industry jargon and knowledge of national/international standards. And this is a simple problem that you can physically see(smell;hear;feel) and find. The guys working on your stuff might humor you if you seem to at least understand what's going on to begin with, but will try and keep it short and simple. They're there to fix it, not instruct you.
Now, looking back at your plumbing example... I said that your plumbing is more like a single line of code. If you want your plumbing example to hold water (pun not intended), then a program isn't your plumbing. A program is plumbing, for an entire city. Imagine, if you will, a city of 500,000 people, with a grand total of 10 plumbers to find and fix any leaks.
TEN PLUMBERS to cover a hundred square miles of buildings ranging from single-family homes, to sprawling office complexes and industrial facilities. They have to go in, find the leaks, and fix them one at a time. This, is programming.
Now, imagine that your ten plumbers are working with blueprints and schematics for a water distribution system built by someone else. Now they have to keep things patched up and flowing without even intimately knowing everything going on below their feet. This is programming on top of an engine, like KSP is built on top of Unity.
Now, imagine that you have ten plumbers, and then about a thousand people wandering around an otherwise empty city designed to hold 500,000, randomly shouting about how a water fountain isn't working in a park, or a toilet won't flush, or the shower's cold. Imagine now, that only 100 of those people actually give detailed information about the problem. Like the address, floor, room, and any other observations they discovered once they realized something was busted.
This is the reality of the situation a dev is presented with. Hundreds of thousands of potential points of failure, policed by ten on-the-payroll workers, bombarded by failure reports with only a fraction of said reports actually useful enough to find and fix the problem. And what makes it even better is that as useful as the failure reports are, they flood in from non-employees. These are 'phone in' reports from customers who might have just woke up to discover their kitchen flooded. Everyone wants their problem fixed, NOW.
People, across many program dev projects and boards, just seem to fail to understand this concept. It's no wonder 'You're not a programmer, you wouldn't understand' has become the mantra. You really aren't a programmer. You really DON'T understand. Your product isn't something that's been under constant development and improvement for a hundred years (cars), and it's not some simple break that's easy to find and fix (plumbing). Software engineering just isn't the same kind of product/service that people are used to. The reality is that it's FAR more complicated while still being all but On-Demand. This is 'the standard', or really, compared to a lot of indy-devs, above the standard. You want that 'perfect and complete' feel in your software? Look at the kind of money and product you get: Microsoft's Windows operating system. Easily $300 for the lowest end copies, still needs some patching after every new version, been in development and constantly built upon for almost 30 years now, and uses a small army of codemonkeys for said development backed by one of the largest companies in the software world.
Let me clarify something for you: You spent $40.
You didn't buy a product.
You invested $40 in a project that is likely to be ongoing for another half-decade. Buckle down and grit those teeth. Sometimes it will be painful. I've been waiting for the return of 64 bit and a fix for a major memory leak since this time last year. A few more weeks to fix some additional bugs popping up?
I can wait.
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:
5 minutes ago, ibanix said:I "love" all the arm-chair software development, from people who have likely never worked in the industry.
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.
Kerbal Space Program patch 1.1.2 is now live!
in Developer Articles
Posted
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.