How have things that have made the game unplayable made it into 1.1.3?

[Greenfire32]

8 minutes ago, regex said:

Can you name a few?  The ways in which KSP allows you to build are pretty much infinite and the interaction between individual parts are unlike anything I've ever played.  KSP allows you to do some incredibly complex things.

The editor portion of KSP is very similar to Spore's creature/building/craft creation. That's about it as far as similarities go though.

I guess I only bring it up not to say that there are KSP-like games out there that do it better, but instead I bring it up to say that some of KSP's mechanics are not as unique as they may have been previously thought.

[KerikBalm]

Spore's editor isn't close to what KSP does.

The closest thing to what KSP does that I can thing of was the 2D browser game called fantastic contraptions... which had you use various parts and it simulated physics on all those parts - and you have to design things to get a target into the goal.

That had its own version of the Kraken that some people could exploit, and that others would have frustratingly shake their thing in a positive feedback of oscillations until something broke ... which sounds familiar.

I see they've now developed it into a 3d VR game, which looks like a lot of fun

http://fantasticcontraption.com/

[Randazzo]

Didn't we already have one of these this week?

Anyhow...

Anyone who contends that the gaming industry regularly releases perfect software is delusional or lying. AAA studios have released entirely jacked up software (Total War: Rome 2, Battlefield 4, SimCity, to name a few recent debacles.) quite frequently. It's not even shocking at this point. Squad has done better than many major development houses, but yes there are issues that arose from switching game engines. Hopefully, those issues will get worked out soon.

 

 

 

[Guest]

36 minutes ago, Greenfire32 said:

I guess I only bring it up not to say that there are KSP-like games out there that do it better, but instead I bring it up to say that some of KSP's mechanics are not as unique as they may have been previously thought.

It's not that KSP's mechanics are unique, it's that the combination of them is unique.  KSP's physics simulation is very ambitious and you can combine parts in surprising ways that the developers may not have thought of (or desired).  Accounting for that while running thermal and aerodynamic simulations (no matter how simple you may think they are) is a monumental programming task, and there are bound to be bugs.  And then there's KSP running on several pieces of third party software that all have to work together.  And then there's the fact that we recently received an upgraded back-end API, which changed how they do things which means Squad has to change and adapt to new method calls, etc...

Edited July 22, 2016 by regex

[klgraham1013]

Honestly, I'm taking a break until 1.2, but I've got some faith in the current team.  The doom and gloom is taking a backseat for the foreseeable future.

[Starwaster]

From the way that ship is shuddering, it looks like a bug I've seen recently where an orbiting ship has 'Landed' status. Look at it in the map and hover over it. Or use the ship information button and see what status it is.

If it's 'Landed' then I have to say it's a Hyperedit problem unless you can replicate it as having 'Landed' status when having launched normally.

[Andem]

*cringe*

[Snark]

3 hours ago, Foxster said:

I think it depends what kind of development you've done.

Absolutely.  Different types of software development have different parameters:  different staffing levels, different funding, different "success" criteria, different results.

3 hours ago, Foxster said:

I've spent 25 years working in IT, doing development in more languages than I can remember. This is big corporate stuff for a major TelCo. You can't afford to mess about and throw stuff out there and if it doesn't work then try again - you get it right first time or the country's telephones stop working.

Yah, that describes most of my career, too.  I've been in little companies, so I have a feel for what the constraints are there, but most of my time has been at major corporations where a failure is Not Acceptable.  Shipping a service that has to have six nines of reliability, where an outage means hemorrhaging multiples of my annual salary per minute, is very different from a small video game.  So I totally hear where you're coming from.

3 hours ago, Foxster said:

So I know it is perfectly possible to get it right first time if you have the right people, processes and skills.

You left out "money".  You also left out "number of people" (which boils down to "money" again).  You left out a lot of other stuff, too.

I understand your frustration... but is it possible that "inexpensive video game from small indie studio" may have different parameters from "critical infrastructure software for major national government or multibillion-dollar corporation"?

It's apples and oranges.

I've been the primary architect for services that really had to be incredibly rock solid.  And they were.  But we had things going for us that Squad doesn't, and probably never will:

• The resources of a multibillion-dollar corporation.
• Lots of really senior engineers and architects.
• A release schedule that has time to "do it right", because the economics are such "late" is enormously better than "wrong".
• An easier technical problem to solve, i.e. software that only needs to do certain things in certain ways, rather than an open-ended sandbox that lets people do anything at all with it.
• A more stable software platform to solve it on, which is completely under the control of the developers.
• A completely controlled hardware environment.
• Vast amounts of internal corporate "infrastructure" to draw upon:  even if the actual team developing a particular service may only be a dozen people, they've got the output of thousands of engineers helping them.
• A type of product (web service, or API) that's extremely friendly to automation, thus making it possible to write exhaustive unit tests in a way that's much harder with a UI-based, highly-human-interactive.
• ...I could go on, but I've already expended considerably more words than most people would probably care for. 

If Squad had 50 million users instead of 1 million, or if they charged $1000 per copy of the game, or if it were okay for them to take a few years between updates, or if they could release to one-and-only-one hardware configuration and not have to deal with innumerable what-ifs, or any one of a number of other things were different, then yeah, they could hit a higher bar.

But that's not the situation, so the results are different.

[Foxster]

I can see where you are coming from but I personally think there is no excuse for poor quality. I don't think it matters if you are delivering software in a corporate or game environment, if you want to keep and attract customers then an excellent product is the best way. 

I just don't agree with accepting half-arsed is OK.  

Edited July 22, 2016 by Foxster

[kiwi1960]

I have only just woken up within the last 1 hour... once I got my head around the title... I'm still groggy... and read the first post... decided this topic wasn't what I needed for the first thing in the morning and stopped reading... after the second post. So, sorry.... to all that have posted... but let me say this... I have never had the problems you have... not once... ever.... so I'm guessing you cannot blame this on ANY version of KSP.... but the problem looks real... ergo, it must be you and the things you design.

Easy fix... design something normal and tell us if the problem persists.

I cannot for the life of me understand how you can blame the version of KSP when this is a problem that would have had its own patch immediately HAD IT BEEN THE VERSION....

So... sort of unfair to blame the tools when its sort of obvious to me the problem lies with the designs.... and implementation rather than the game itself.

Sorry if this sounds harsh, not my intention, but come on... to me, the shuttle the OP posted looks ugly and un-flyable anyhow.... its actually a credit to KSP that it made it so far before saying to you "Look, I have done the best I can, but really, I'm not playing this game with you anymore because I'm getting a headache...."

 

Edited July 23, 2016 by kiwi1960
typos

[purpleivan]

5 hours ago, Snark said:

Not a fan-boy, just someone who actually does this for a living, and has been doing so for a couple of decades, and therefore has a certain amount of perspective about how things actually work in this industry.  (And you'll note that most of my post isn't specifically about Squad, anyway, just about the software industry in general.)

There are plenty of cases of player pain, and plenty of things that KSP does that players are legitimately unhappy about.  Heck, there are plenty of things that I'm unhappy about, and I'm not shy about posting about them, either.  And you don't see me following around with a mop trying to "correct" or "explain" every single instance of somebody expressing something about the game that they're unhappy about.

A player can always legitimately complain about their personal experience with the game-- because that's something within their sphere of knowledge.  Every player is the ultimate authority on what makes that player unhappy about the game experience.  So of course they're within their rights to complain, because they know what they're talking about, by definition.

For example, suppose the OP in this thread had simply said "Here's this terrible thing, it happens to me all the time, I hate this and it's ruining my game.  I really wish Squad would get off their duffs and fix this."  In that case, I would have cheerfully held my peace.

What I do take issue with is when people start complaining about something they don't actually know about, e.g.  software development process.  (E.g. changing the statement from "I don't like this" to "This shouldn't be happening for this stage of development.")

I understand the frustration, really I do.  I've got plenty of friends and relatives (i.e. just about all of them) who aren't software engineers, and of course any time they have a problem with somebody's software, they come to me for tech support.  Occupational hazard of being the resident tech geek. 

And the one universal constant I've experienced is that people who haven't done software for a living have no clue whatsoever how hard it is.  Even when you tell them "it's hard", they still don't really grasp why it's hard, or just how hard.  You pretty much have to do it for a living to understand that.

So when I see a thread get started that consists of people making assertions or implicit assumptions about an area that they don't have personal experience with, and the "echo chamber" gets going... yeah, I like to inject a drop (or in my case, a gallon, usually... sigh) of reality into the discussion.

So I'll stop posting explanations of How Software Development Works as soon as I stop seeing discussions of commercial software development practices by people who aren't familiar with commercial software development practices.

By which I suppose that means "never," but oh well. 

As another very long standing games dev (back to the 8 bit days) I second everything that Snark had to say. KSP is pretty much the worst possible case for ensuring a perfectly behaving game, what with it's reliance on a physics as the absolute core of the game, as well as user made content being thrown into the mix with that. Add to that the need to use a third party engine that's outside your control and that it's a PC game with all of the issues that can arise from the game running on a massive range of hardware as opposed to just consoles X,Y and Z.

These factors alone would make it extremely difficult to ensure that all player experiences of the game are perfect (or even close to it), but when you add the fact that Squad is a pretty small developer; one which is smaller in total than a lot of bigger budget games' QA teams, then the fact that the game for the vast majority of the time, for most players, is a reliable and reasonably performing experience, is a small miracle.

Again not a fan-boy (but definitely a fan) just a realist and someone who also does this for a living.

 

Edited July 22, 2016 by purpleivan

[foamyesque]

My biggest gripe about KSP is that it maxes out hardware even in screens that shouldn't require heavy number crunching, such as the VAB, SPH, or main menu. I think there's some major optimization work still to do there.

[Guest]

3 minutes ago, foamyesque said:

My biggest gripe about KSP is that it maxes out hardware even in screens that shouldn't require heavy number crunching, such as the VAB, SPH, or main menu. I think there's some major optimization work still to do there.

Have you been reading the dev notes?  That's a huge part of what's coming in 1.2.

[Snark]

1 hour ago, kiwi1960 said:

I have never had the problems you have... not once... ever.... so I'm guessing you cannot blame this on ANY version of KSP.... but the problem looks real... ergo, it must be you and the things you design.

Easy fix... design something normal and tell us if the problem persists.

Yes and no.

On the one hand, it seems highly likely to be something specific to the design.  I, too, have never had this problem, at all.  So it's tempting to guess that "player A always gets the problem, player B never does" because A is designing things differently, in general, than player B.

(We don't know that that's the explanation-- maybe player B has more RAM, or something-- but it's at least a plausibly likely scenario.)

However, that's not the same thing as saying that player A is doing it wrong.  After all, this is a sandbox game that doesn't just allow you to put things together in all sorts of ways:  it encourages you to.  The fact that you can design rockets every which way is a big part of KSP's appeal.  If the game allowed the player to design a rocket, then making it go wonky and screwy in a clearly buggy way is not cool.  It's a bug.

It's not completely clear to me whether @glen.mack was running a purely stock game or not.  If not, potentially it could be a mod causing the problem, and not Squad's fault at all.  But let's say he's running stock:  In that case, it's a bug, and the onus is on Squad to fix it rather than on the player not to design things that way.

So I think that the OP here is perfectly within his rights to complain about getting bitten by this, and there's no point in trying to blame the player.

If that sounds like a reversal of what I've posted thus far in the thread, it's not.  It is (or, at least, sounds as though it likely is) a legitimate bug, and a legitimate complaint.  Bugs are always legitimate player pain, and should be addressed at an appropriate priority based on factors such as severity of bug, number of players affected, technical cost and risk, etc.

My earlier posts were simply to point out that "this is a bug and I'd like it to be fixed" does not equate to "the fact that this bug is here means that the developer's process is broken or wrong."

[foamyesque]

Just now, regex said:

Have you been reading the dev notes?  That's a huge part of what's coming in 1.2.

Nope, but honestly, I'll believe it gets fixed when it's running on my machine. I love KSP and I've been playing it for years, and this behaviour has been around (despite multiple bugfix/optimization updates-- which, to be fair, have made other pieces better) for all of them.

[Curveball Anders]

4 hours ago, Foxster said:

I can see where you are coming from but I personally think there is no excuse for poor quality. I don't think it matters if you are delivering software in a corporate or game environment, if you want to keep and attract customers then an excellent product is the best way. 

I just don't agree with accepting half-arsed is OK.  

Then you must work in a very different universe than mine.

There is always a balance between 'perfect' and 'good enough', and the point of that balance is called 'available resources'.

The crucial 'resources' might be time, money, skills, hardware, location, dependencies, corporate rules, legal obligations or yada yada yada.

All systems running this modern world are more or less 'half-arsed', because the mythical 'perfect' system is still in development, and will remain there forever.

[Raptor9]

7 hours ago, Starwaster said:

From the way that ship is shuddering, it looks like a bug I've seen recently where an orbiting ship has 'Landed' status. Look at it in the map and hover over it. Or use the ship information button and see what status it is.

If it's 'Landed' then I have to say it's a Hyperedit problem unless you can replicate it as having 'Landed' status when having launched normally.

The bug that is shown in the OP is a Hyperedit problem.  I've seen this exact situation myself with Hyperedit in KSP 1.1.3, and so have users in the Hyperedit sub-forum. A work-around appears to be: "teleport to orbit, then go to Space Center and back."

What gets me is that players still immediately jump to blaming Squad for bugs they encounter after posting screenshots (or in this case video) of a KSP install that clearly has mods installed (in some cases, a metric ton of them).  Squad is not responsible for bugs that are generated from the installation of a mod.  Having said that, Squad has very smartly been working with the code of KSP over the past several versions of KSP to ensure it is mod-friendly (not mod-proof, that's impossible).  It would seem they [Squad] recognize that a significant portion of the KSP fan base leans on mods as a way to enhance their gameplay, however Troubleshooting Step 1 should always be "Attempt to replicate bug in a mod-free KSP install".

Edited July 23, 2016 by Raptor9

[Starwaster]

2 hours ago, Raptor9 said:

The bug that is shown in the OP is a Hyperedit problem.  I've seen this exact situation myself with Hyperedit in KSP 1.1.3, and so have users in the Hyperedit sub-forum. A work-around appears to be: "teleport to orbit, then go to Space Center and back."

What gets me is that players still immediately jump to blaming Squad for bugs they encounter after posting screenshots (or in this case video) of a KSP install that clearly has mods installed (in some cases, a metric ton of them).  Squad is not responsible for bugs that are generated from the installation of a mod.  Having said that, Squad has very smartly been working with the code of KSP over the past several versions of KSP to ensure it is mod-friendly (not mod-proof, that's impossible).  It would seem they [Squad] recognize that a significant portion of the KSP fan base leans on mods as a way to enhance their gameplay, however Troubleshooting Step 1 should always be "Attempt to replicate bug in a mod-free KSP install".

Yes but blamestorming takes less effort

[kiwi1960]

6 hours ago, Snark said:

Yes and no.

On the one hand, it seems highly likely to be something specific to the design.  I, too, have never had this problem, at all.  So it's tempting to guess that "player A always gets the problem, player B never does" because A is designing things differently, in general, than player B.

(We don't know that that's the explanation-- maybe player B has more RAM, or something-- but it's at least a plausibly likely scenario.)

However, that's not the same thing as saying that player A is doing it wrong.  After all, this is a sandbox game that doesn't just allow you to put things together in all sorts of ways:  it encourages you to.  The fact that you can design rockets every which way is a big part of KSP's appeal.  If the game allowed the player to design a rocket, then making it go wonky and screwy in a clearly buggy way is not cool.  It's a bug.

It's not completely clear to me whether @glen.mack was running a purely stock game or not.  If not, potentially it could be a mod causing the problem, and not Squad's fault at all.  But let's say he's running stock:  In that case, it's a bug, and the onus is on Squad to fix it rather than on the player not to design things that way.

So I think that the OP here is perfectly within his rights to complain about getting bitten by this, and there's no point in trying to blame the player.

If that sounds like a reversal of what I've posted thus far in the thread, it's not.  It is (or, at least, sounds as though it likely is) a legitimate bug, and a legitimate complaint.  Bugs are always legitimate player pain, and should be addressed at an appropriate priority based on factors such as severity of bug, number of players affected, technical cost and risk, etc.

My earlier posts were simply to point out that "this is a bug and I'd like it to be fixed" does not equate to "the fact that this bug is here means that the developer's process is broken or wrong."

My point is.... lets use Fallout 3 as an example... I used mods in that game which really screwed up my games... but if I was careful, and used the mods ... or game... in this case, as was intended, the bugs wouldn't be there.... KSP for the vast majority of gamers works well... or rather, the few bugs (wheels etc) being the exception.

If I wanted to screw up the game, I could do like you have done.... BUT... I don't... and the problem isn't there.... what you call a bug... and wanted fixed, isn't a bug.... so it doesn't really need fixing. Clipping and extreme designs are the problem, and the game is saying "I cannot handle this abnormal design... so I'm going to cause problems"...

So if its not really a bug, it doesn't need fixing... in which case fixing it COULD cause problems for the vast majority (read: everyone except you) ...

So... either you suffer or learn to build workable designs..... because un-workable designs MAY work in the game... but when they don't... you cannot realistically post about a bug...

the only bug is in your designs. Sorry to say that... but its my opinion, take it or leave it, and I'm entitled to have it and express it....

The needs of the one do not always outweigh the un-needs of the many....